Tech

Automatisierte Build-Pipelines mit GitLab CI und APPUiO

1. Apr 2018

Update: Demo-Projekte veröffentlicht

Dieser Blogpost ist unterdessen veraltet. Wir haben neue Demo-Projekte mit Source-Code, öffentlicher CI/CD pipeline und Kubernetes-Integration vorbereitet: https://gitlab.com/appuio und wir sind gespannt auf Dein Feedback in Form von Issues und Merge Requests!

Zusammenfassung

„Deploy early and often“ ist einer der wichtigsten Grundsätze von agiler Entwicklung. Eine Lösung für dieses Problem sind automatisierte Build- und Deployment-Pipelines.
Bei diesem Projekt kommt eine solche Pipeline zum Einsatz, basierend auf GitLab CI und OpenShift. Es wird eine PHP-Beispielanwendung entwickelt und auf APPUiO deployt.
Es werden drei Umgebungen in Form von OpenShift-Projekten genutzt: test, qual und production. Dabei handelt es sich um das gängigste Set-up, allerdings lässt sich das anpassen und einfach erweitern. Die Idee besteht darin, jeden Commit auf den master Branch automatisch für die test-Umgebung zu builden und zu deployen. Wird ein Git-Tag erstellt, wird das zuvor generierte Docker-Image mit dem Git-Tag markiert und automatisch auf die qual-Umgebung deployt. Das Deployment für die production-Umgebung erfolgt hingegen manuell und kann über GitLab ausgelöst werden.

Pipelines

In der .gitlab-ci.yml Datei sind zwei Pipelines definiert: Eine wird für jeden Commit auf den Master-Branch ausgeführt und setzt sich aus den Phasen lint, build und deploy-test zusammen. Bei der lint-Phase wird ein Docker-Container gestartet, in dem der PHP-Code auf korrekte Syntax überprüft wird. Während der build-Phase wird ein neuer OpenShift-Build (S2I) aufgerufen. In der letzten Phase wird das erstellte Image für die test-Umgebung deployt.
Die zweite Pipeline wird beim Erstellen eines Git-Tags gestartet. Sie setzt sich aus den Phasen release, deploy-qual und deploy-production zusammen. Während der ersten Phase wird das Docker-Image, das für den entsprechenden Git-Commit erstellt wurde, mit dem Namen des erstellten Git-Tags markiert. In der deploy-qual-Phase erfolgt das automatische Deployment des markierten Docker-Image in die qual-Umgebung. Die deploy-production-Phase muss manuell gestartet werden und deployt in die production-Umgebung.

APPUiO

Die Anwendung und der Build werden auf APPUiO ausgeführt. Das ermöglicht es uns, die Konzepte und Lösungen zu nutzen, die OpenShift für die Arbeit mit Builds und Deployments bietet. Im Verzeichnis openshift sind die YAML-Dateien enthalten, die die verwendeten OpenShift-Ressourcen beschreiben. Diese Dateien und der Code befinden sich im gleichen Git-Repository. Das garantiert, dass immer die gleiche Code-Version unter Verwendung der gleichen Version der OpenShift-Ressourcen erstellt und deployt wird.

Build

OpenShift BuildConfig ist Bestandteil des Build. Dafür wird ein PHP source-to-image builder genutzt und ein Docker-Image erstellt, in dem die Anwendung enthalten ist. Das Image wird mit dem Git-Commit-Hash markiert und in der OpenShift-Docker-Registry gespeichert.

BuildConfig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
apiVersion: v1
kind: BuildConfig
metadata:
  labels:
    app: ${APPNAME}
  name: ${APPNAME}
spec:
  strategy:
    type: Source
    sourceStrategy:
      from:
        kind: ImageStreamTag
        name: 'php:7.0'
        namespace: openshift
      incremental: true
  source:
    git:
      ref: ${COMMIT_SHA}
      uri: ${REPOSITORY_URL}
    type: Git
  output:
    to:
      kind: ImageStreamTag
      name: '${APPNAME}:${APP_TAG}'

Deployment

Für die Ausführung der Anwendung wird DeploymentConfig genutzt. Dank der rolling Deployments lassen sich Systeme ohne Ausfallzeiten ausrollen und Endbenutzer werden nicht durch Unterbrechungen für Updates gestört. Anhand von liveness- und readiness Checks kann OpenShift testen, ob der Container korrekt ausgeführt wird (liveness), und den eingehenden Datenverkehr zulassen (readiness). Darüber hinaus werden ein OpenShift-Dienst und eine Route erstellt, um den Datenverkehr von ausserhalb des Clusters zur Anwendung zu routen. Für jede Umgebung wird eine eigene URL festgelegt, die sich aus GitLab heraus öffnen lässt.

DeploymentConfig
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
apiVersion: v1
kind: DeploymentConfig
metadata:
  name: ${APPNAME}
spec:
  replicas: 1
  selector:
    app: ${APPNAME}
  strategy:
    type: Rolling
  template:
    spec:
      containers:
      - name: ${APPNAME}
        image: "docker-registry.default.svc:5000/${OPENSHIFT_PROJECT}/${APPNAME}:${APP_TAG}"
        imagePullPolicy: Always
        ports:
        - name: web
          containerPort: 8080
        livenessProbe:
          httpGet:
            path: /
            port: web
        readinessProbe:
          tcpSocket:
            port: web
      restartPolicy: Always

 

Demo

Drei Dinge sind erforderlich, um die Pipeline in Aktion sehen zu können:

  1. Ihr eigener fork des Repository in GitLab, mit aktiviertem GitLab CI.
  2. Ein Projekt in APPUiO für jede Phase: test, qual und production
  3. Ein Service-Account mit edit-Berechtigungen für alle Projekte

Schritt für Schritt

  1. Einrichtung einer Kubernetes-/OpenShift-Integration in GitLab: https://docs.gitlab.com/ce/user/project/clusters/index.html#adding-an-existing-kubernetes-cluster
  2. Konfiguration von .gitlab-ci.yaml für Ihre APPUiO-Projekte
  3. Commit und Push der Änderungen
  4. Build der Anwendung durch die automatisierte Pipeline und Deployment der Anwendung für das test-Projekt
  5. Erstellung eines Git-Tags
  6. Erstellung von Image-Tags durch die automatisierte Pipeline und Deployment der Tags für das qual-Projekt
  7. Manuelle Ausführung eines Deployments für die production-Umgebung durch Aufrufen der Pipeline in GitLab und das Klicken auf die Schaltfläche zum Abspielen des deploy:production-Jobs

Ausblick

Eine mögliche Erweiterung dieses Set-ups wären automatische Deployments von Feature-Branches. Damit wird jeder Merge-Request gebuildet, und eine Live-Version der Anwendung steht zum Testen der implementierten Änderungen bereit. So lassen sich Änderungen ganz einfach überprüfen und testen.
Weitere Informationen zu automatisierten Builds und Deployments mit GitLab und APPUiO werden unter Dokumente bereitgestellt. Unter APPUiO Public besteht die Möglichkeit, ein Projekt zu erstellen.

Aarno Aukia

Aarno ist Mitgründer der VSHN AG und als CTO für die technische Begeisterung zuständig.

Kontaktiere uns

Unser Expertenteam steht für dich bereit. Im Notfall auch 24/7.

Kontakt