GitLab CI/CD

Die Pipeline des Projekts bflies-next baut und prüft die bestehende Java-Webanwendung, erzeugt daraus ein Container-Image und rollt den Stand des Branches master automatisch in die Kubernetes-Umgebung INT aus. Ein PROD-Rollout ist im aktuellen Stand noch nicht konfiguriert.

Die Pipeline ist in .gitlab-ci.yml im Repository bflies-next definiert. Sie orientiert sich beim Kubernetes-Rollout an der Pipeline von ETE und verwendet Kustomize zur Erzeugung des konkreten INT-Manifests.

Ausführung nach Git-Referenz

Git-Referenz	Maven-Build	Container-Image	Trivy-Bericht	INT-Rollout
Beliebiger Branch	Ja	Nein	Nein	Nein
master	Ja	Ja	Ja	Ja
Git-Tag	Ja	Ja	Nein	Nein

Für Branches wird die Version des WARs aus Branch-Slug und kurzem Commit-Hash gebildet. Auf master erhält das Container-Image den unveränderlichen Tag master-<CI_COMMIT_SHORT_SHA>. Bei einer Tag-Pipeline wird der Git-Tag als Build- und Image-Version verwendet.

Die eingebundene Trivy-Komponente ist gegenwärtig intern auf den Branch master begrenzt. Obwohl die Komponente auch für Tag-Pipelines eingebunden wird, werden ihre Scan- und Report-Jobs bei Tags deshalb nicht ausgeführt.

Stufen und Jobs

Build

Der Job maven-war verwendet den internen Maven-Worker und führt folgenden Build aus:

mvn --batch-mode --no-transfer-progress -Dbuild.version="${BUILD_VERSION}" clean verify

Dabei entstehen insbesondere folgende Artefakte mit einer Aufbewahrungszeit von einem Tag:

• target/bflies.war,
• die für Tomcat benötigte JavaMail-Bibliothek,
• das Dojo-Buildprotokoll,
• der Dojo-Buildbericht.

Der Maven-Cache liegt pipelinespezifisch unter .m2/repository und wird über die Projekt-ID getrennt.

Container-Image

Der Job docker-build übernimmt die Maven-Artefakte und baut mit Buildah das in docker/Dockerfile beschriebene Tomcat-Image. Das Ziel ist:

docker.tdm-consult.com/docker/com.tdmconsult/bflies-next:<Image-Tag>

Das Image wird in die interne Registry übertragen. Buildah schreibt zusätzlich den Digest in das Dotenv-Artefakt image.env:

BUILT_IMAGE=<Image-Name>@<Digest>

Die nachfolgende Sicherheitsprüfung scannt dadurch exakt das gebaute Image und nicht lediglich einen veränderlichen Tag.

Sicherheitsprüfung

Die zentrale GitLab-Komponente trivy-report erzeugt für master einen JSON- und einen HTML-Bericht. Sie untersucht das zuvor gebaute Image auf nicht behobene Schwachstellen der Schweregrade HIGH und CRITICAL. Scan-Ergebnisse lassen den Build derzeit nicht fehlschlagen; der Scan-Job ist mit allow_failure: true konfiguriert.

Der HTML-Bericht und ein Status-Badge werden im S3-kompatiblen Report-Speicher veröffentlicht. Die Komponente bringt Standardwerte für Scanner-Image, Report-Worker, S3-Endpunkt, Bucket und Report-URL mit. Diese Werte können zentral oder projektspezifisch überschrieben werden.

Kubernetes-Rollout nach INT

Der Job k8s-rollout-int läuft nur auf master. Er führt folgende Schritte aus:

1. Bildung des Image-Tags master-<CI_COMMIT_SHORT_SHA>.
2. Auswahl des Kubernetes-Kontexts tdm-rke-02.
3. Einsetzen des Image-Tags in die Kustomize-Basis.
4. Rendern des Overlays src/deployment/k8s/overlays/int nach k8s-manifest.yaml.
5. Anwenden des Manifests im Namespace bflies-int.
6. Warten auf den erfolgreichen Rollout des Deployments bflies-next, maximal zehn Minuten.

Das gerenderte Manifest wird für einen Tag als Pipeline-Artefakt gespeichert. Die zugehörige GitLab-Umgebung heißt int; als Ziel-URL ist folgende Adresse hinterlegt:

https://bflies-rke02-int.tdm-consult.local/bflies/

Die Pipeline rollt keine Datenbank aus. Sie setzt im Namespace bflies-int den vorhandenen Service bflies-mysql-srv und das vorhandene Secret bflies-mysql-sec mit dem Key user voraus.

Benötigte Variablen

In GitLab zu hinterlegende CI/CD-Variablen

Die folgenden Werte enthalten Zugangsdaten und müssen in den GitLab-Einstellungen als geschützte CI/CD-Variablen gepflegt werden. Geheime Werte dürfen weder in .gitlab-ci.yml noch in den Kustomize-Dateien abgelegt werden.

Variable	Erforderlich für	Inhalt und Hinweise
DOCKER_AUTH_CONFIG	Image-Build und Trivy-Scan	Docker-config.json mit Leserecht für Basisimages und Schreibrecht für das Projektimage. Der Build-Job erwartet den JSON-Inhalt als Variable, nicht den Pfad einer File-Variable. Maskiert und geschützt speichern.
AWS_ACCESS_KEY_ID	Veröffentlichung des Trivy-Berichts	Zugriffsschlüssel für den S3-kompatiblen Report-Speicher. Maskiert und geschützt speichern.
AWS_SECRET_ACCESS_KEY	Veröffentlichung des Trivy-Berichts	Geheimer Zugriffsschlüssel für den Report-Speicher. Maskiert und geschützt speichern.
AWS_DEFAULT_REGION	Veröffentlichung des Trivy-Berichts	Region für die AWS-CLI; der für die interne S3-Installation vorgegebene Wert kann als Gruppenvariable gepflegt werden.

Für den Kubernetes-Rollout referenziert die Pipeline derzeit keine zusätzliche geheime Projektvariable. Der verwendete Deployment-Worker beziehungsweise dessen Runner-Umgebung muss einen gültigen Kubeconfig mit dem Kontext tdm-rke-02 bereitstellen. Falls dies über GitLab statt über den Worker erfolgt, kann ein geschützter Variablenwert KUBECONFIG vom Typ File verwendet werden; der angegebene Kontext muss darin vorhanden sein. Die Berechtigung in den Ziel-Namespaces wird über das RoleBinding gitlab-deployer-binding erteilt.

In der Pipeline definierte Variablen

Diese nicht geheimen Werte sind direkt in .gitlab-ci.yml festgelegt:

Variable	Aktueller Wert	Zweck
REGISTRY	docker.tdm-consult.com	Interne Container-Registry
IMAGE_NAME	docker.tdm-consult.com/docker/com.tdmconsult/bflies-next	Vollständiger Name des Anwendungsimages
IMAGE_MAVEN	docker.tdm-consult.com/docker/com.tdmconsult/gitlab-maven-worker:latest	Build-Image für Maven
IMAGE_BUILDAH	docker.tdm-consult.com/docker/buildah/stable:v1.33.2	Build-Image für das Container-Image
IMAGE_GITLAB_JDB_WORKER	docker.tdm-consult.com/docker/com.tdmconsult/gitlab-jdb-worker:latest	Worker mit kubectl und Clusterzugriff
MAVEN_OPTS	-Dmaven.repo.local=${CI_PROJECT_DIR}/.m2/repository	Ablage des Maven-Caches im Projektverzeichnis
K8S_NAMESPACE	bflies-int	Ziel-Namespace des INT-Rollouts
K8S_OVERLAY_PATH	src/deployment/k8s/overlays/int	Zu renderndes Kustomize-Overlay

Die Trivy-Komponente definiert außerdem Standardwerte für IMAGE_AQUASEC, IMAGE_REPORT_WORKER, S3_ENDPOINT, S3_BUCKET und GITLAB_REPORT_FQDN. Sie müssen nur als GitLab-Variable gesetzt werden, wenn die zentralen Standardwerte überschrieben werden sollen.

Von GitLab bereitgestellte Variablen

Die Pipeline verwendet zusätzlich automatisch bereitgestellte GitLab-Variablen. Sie müssen nicht manuell angelegt werden:

Variable	Verwendung
CI_SERVER_FQDN	Adresse der eingebundenen CI-Komponente
CI_PROJECT_DIR	Arbeitsverzeichnis und Maven-Repository
CI_PROJECT_ID	Schlüssel des Maven-Caches
CI_PROJECT_NAMESPACE und CI_PROJECT_NAME	Ablagepfad des Trivy-Berichts
CI_COMMIT_BRANCH und CI_COMMIT_TAG	Auswahl der auszuführenden Jobs
CI_COMMIT_REF_SLUG	Artefakt- und Build-Version auf Branches
CI_COMMIT_SHORT_SHA	Build-Version, Image-Tag und Artefaktnamen

Voraussetzungen außerhalb von GitLab

Vor dem ersten automatischen INT-Rollout müssen folgende Voraussetzungen erfüllt sein:

• Der Namespace bflies-int existiert auf tdm-rke-02.
• Das RoleBinding gitlab-deployer-binding ist im Namespace bflies-int angelegt und berechtigt die von der Pipeline verwendete Deployment-Identität.
• bflies-mysql-srv ist erreichbar und verweist auf die bestehende MySQL-Datenbank.
• bflies-mysql-sec enthält unter user das Passwort des Datenbankbenutzers bflies.
• Der Namespace kann Images aus docker.tdm-consult.com abrufen, gegebenenfalls über ein zentral verwaltetes imagePullSecret.
• Der Round-Robin-DNS-Name bflies-rke02-int.tdm-consult.local verweist auf die Ingress-Knoten des Clusters.

RoleBindings für die Deployment-Identität

Das RoleBinding gitlab-deployer-binding muss einmalig durch die Clusteradministration in beiden Business-Flies-Namespaces angelegt werden:

Umgebung	Namespace	RoleBinding
INT	bflies-int	gitlab-deployer-binding
PROD	bflies-prod	gitlab-deployer-binding

Das Binding verbindet die vom GitLab-Deployment-Worker verwendete Identität mit der im Cluster dafür vorgesehenen Rolle beziehungsweise ClusterRole. Subject und RoleRef müssen dem zentralen Clusterstandard entsprechen. Die Anwendungspipeline legt das Binding bewusst nicht selbst an, weil sie die dadurch erteilte Berechtigung bereits zum Ausrollen ihrer Manifeste benötigt.

Die Existenz der Bindings kann administrativ geprüft werden:

kubectl -n bflies-int get rolebinding gitlab-deployer-binding
kubectl -n bflies-prod get rolebinding gitlab-deployer-binding

Das PROD-Binding wird bereits vor Einführung der PROD-Pipeline eingerichtet, damit für die spätere Promotion dasselbe Berechtigungsmodell wie in INT gilt.

Noch nicht umgesetzt

• automatischer Rollout nach PROD,
• separates PROD-Kustomize-Overlay,
• Freigabe- oder manuelles Promotion-Verfahren von INT nach PROD,
• Deployment von MySQL durch die Anwendungspipeline,
• automatischer Rollback bei einem fehlgeschlagenen Rollout.