Zum Inhalt

CI/CD- & Flux-Pipeline

Diese Seite beschreibt, wie Code-Änderungen automatisch zu laufenden Containern in der Stage-Umgebung werden – von der GitLab-CI-Pipeline in den Service-Repositories bis zum GitOps-Rollout durch Flux.

Diagramm öffnen

Ein Klick auf die Grafik öffnet sie groß und zoombar.

CI/CD- und Flux-Pipeline der Stage

① GitLab-CI: Build & Push

Jedes Service-Repository (odi-schema-backend, odi-ckan-service, odi-staging-backend, odi-metadata-service, odi-frictionless-backend, odi-schema-staging-frontend, open-data-web …) enthält eine .gitlab-ci.yml mit dem gleichen Muster. Bei jedem Push auf main laufen zwei Stufen:

  1. bump-version – erhöht das -dev-N-Suffix der Version (package.json bzw. pyproject.toml), committet sie mit [skip ci] zurück und reicht die neue Version als VERSION an die Build-Stufe weiter.
  2. build-image – baut das Image mit Kaniko (ohne Docker-Daemon) und pusht es in die Stage-Container-Registry, getaggt mit der neuen Version (z. B. 2.8.3-dev-42) und dem beweglichen Tag dev.
2.8.3        ──(manuelle Basis-Anhebung)
2.8.3-dev-1  ──(push) → 2.8.3-dev-2 → 2.8.3-dev-3 → …

Benötigte CI/CD-Variablen (pro Projekt)

IONOS_STAGE_REGISTRY (Stage-Registry-Host) · IONOS_STAGE_REGISTRY_USER · IONOS_STAGE_REGISTRY_PASSWORD (masked) · CI_PUSH_TOKEN (masked, write_repository). Der Image-Name wird automatisch aus $CI_PROJECT_NAME abgeleitet (= GitLab-Projektname, z. B. odi-ckan-service) – eine eigene Image-Variable entfällt. Ausnahme open-data-web: baut zwei Images über IONOS_STAGE_REGISTRY_IMAGE_FRONTEND und IONOS_STAGE_REGISTRY_IMAGE_NEST (aus _deployment/Dockerfile.frontend bzw. Dockerfile.nest).

② Flux Image-Automation

Im Stage-Cluster überwacht Flux die Registry und aktualisiert die Manifeste automatisch. Pro odi-*-Image existiert ein Paar im Namespace flux-system:

  • ImageRepository – scannt die Tags des Images in der Stage-Registry (Intervall 5 min).
  • ImagePolicy – wählt den neuesten passenden Tag. Filter: ^\d+\.\d+\.\d+-dev-\d+$, Policy semver: ">=0.0.0-0" (schließt -dev-*-Prereleases ein).

Im Deployment markiert ein Kommentar die zu aktualisierende Image-Zeile:

image: odi-container-registry-stage.cr.de-fra.ionos.com/odi-ckan-service:0.6.0-dev-4 # {"$imagepolicy": "flux-system:ckan-service"}
  • ImageUpdateAutomation – schreibt den neuen Tag in das Manifest und committet die Änderung zurück ins Repo odi-kubernetes-stage (Branch main).

③ GitOps-Rollout

Die Flux Kustomization gleicht den Pfad clusters/stage kontinuierlich mit dem Cluster ab (prune: true, Intervall 10 min bzw. sofort bei Git-Änderung) und wendet die aktualisierten Manifeste an. Ergebnis: Die Pods laufen mit dem neuen Image – ohne manuellen Deploy-Schritt.

Manuell ist nur der Code-Commit

Versionierung, Build, Registry-Push, Manifest-Update und Rollout laufen automatisch. Entwickler:innen pushen lediglich ihren Code auf main.

Zusammenspiel mit den Umgebungen

Dieselbe Mechanik gilt grundsätzlich für beide Umgebungen; die Stage nutzt durchgängig die -stage-Registry und -dev-N-Tags. Den Aufbau und die Unterschiede der Umgebungen beschreibt die Seite Umgebungen: Stage & Produktion.