Von OpenTofu zu Argo CD: GitLab als Control Plane für AWS

Cloud-Umgebungen zu konfigurieren ist aufwendig: Netzwerke, Subscriptions, Services und alle Komponenten der darunterliegenden Infrastruktur wollen berücksichtigt werden. Ein manuelles Setup ist fehleranfällig, uneinheitlich und schwer zu reproduzieren.

Dieses Tutorial zeigt, wie sich eine vollständig automatisierte Cloud-Umgebung aufsetzen lässt, mit GitLab als Schaltzentrale. Die gesamte Cloud-Infrastruktur ist als Code definiert, liegt in GitLab und wird mit OpenTofu über GitLab-CI/CD-Pipelines auf AWS ausgerollt. Darüber hinaus übernehmen dieselben Pipelines den Build und das Deployment einer echten Webanwendung, nach GitOps-Praktiken mit Argo CD.

Warum Infrastructure as Code und GitOps wichtig sind

Zunächst lohnt der Blick darauf, warum Infrastructure as Code (IaC) und GitOps wichtig sind und wie GitLab diese Praktiken auf einer Plattform zusammenführt.

IaC sorgt dafür, dass Umgebungen drei Eigenschaften mitbringen:

• Reproduzierbar: Dieselbe Konfiguration lässt sich überall ausrollen.
• Versioniert: Jede Änderung wird in einem Versionskontrollsystem (VCS) nachvollzogen, üblicherweise in Git.
• Automatisiert: Kein menschliches Eingreifen nötig.

GitOps führt diese Prinzipien in den Anwendungslebenszyklus weiter. Statt Änderungen manuell auf Kubernetes-Cluster (oder andere Infrastruktur) anzuwenden, liegt der gewünschte Zustand der Anwendungen in Git. Ein GitOps-Operator wie Argo CD sorgt fortlaufend dafür, dass der Cluster dem Stand im Repository entspricht. Das bringt:

• Konsistenz zwischen Umgebungen
• Schnellere Wiederherstellung durch Rollbacks, die nicht mehr verlangen als das Zurücknehmen eines Commits
• Bessere Zusammenarbeit, weil Teams Änderungen über Merge Requests prüfen und freigeben
• Mehr Sicherheit durch Deployments, für die Entwicklungsteams keinen direkten Zugriff auf den Cluster brauchen

GitLab vereint alle Fähigkeiten, die dieser Ansatz verlangt:

• Source Code Management: Infrastruktur- und Anwendungscode an einem Ort führen.
• CI/CD-Pipelines: Bereitstellung mit OpenTofu und Deployments mit Kubernetes-Manifesten automatisieren.
• Terraform-States: State-Dateien der Infrastruktur sicher speichern und verwalten.
• Container Registry: Container-Images neben Code und Pipelines bauen, ablegen und verwalten.

Mit GitLab läuft alles über eine Plattform, von der Bereitstellung der Cloud-Infrastruktur bis zur Auslieferung der Anwendung.

Für dieses Tutorial sind nötig:

• Grundkenntnisse in GitLab-CI/CD-Pipelines und Git
• Vertrautheit mit IaC (Terraform oder OpenTofu) und GitOps
• Ein AWS-Konto
• Ein Kubernetes-Cluster (EKS wird im Tutorial bereitgestellt)
• Ein Dockerfile für die Beispiel-Webanwendung

Das Tutorial enthält Anleitungen für folgende Schritte:

• Eine vollständige AWS-Umgebung mit OpenTofu bereitstellen
• Kubernetes-Werkzeuge automatisch konfigurieren
• Eine Beispiel-Webanwendung mit Argo CD nach GitOps-Prinzipien ausrollen
• Eine Beispiel-Webanwendung mit GitLab CI/CD bauen und paketieren

Wie sich dieses Beispiel in der eigenen GitLab-Umgebung nachbauen lässt, steht weiter unten. Der Quellcode des Beispiels liegt in der SATEC Public Demo Group.

Eine vollständige AWS-Umgebung mit OpenTofu bereitstellen

Der erste Schritt ist die Bereitstellung der Cloud-Infrastruktur mit OpenTofu, dem Open-Source-Fork von Terraform. Netzwerkkomponenten lassen sich damit deklarativ definieren und ein Amazon-EKS-Cluster anlegen.

Damit dieser Vorgang reproduzierbar und sicher bleibt, setzen wir auf CI/CD-Variablen in GitLab statt auf fest verdrahtete Werte. Über diese Variablen lässt sich die AWS-Umgebung pipelineübergreifend dynamisch konfigurieren.

Folgende Umgebungsvariablen sind erforderlich und werden unter Settings > CI/CD > Variables in der übergeordneten Gruppe angelegt, damit alle Projekte sie erben:

• TF_VAR_region: AWS-Region, in der die Infrastruktur entsteht (etwa eu-west-1)
• TF_VAR_instance_type: EC2-Instanztyp für die Worker Nodes (etwa t3.medium)
• TF_VAR_instance_count: Anzahl der Worker Nodes im Cluster
• TF_VAR_cluster_name: Name des bereitzustellenden EKS-Clusters
• AWS_ACCESS_KEY_ID: AWS-Access-Key für die Authentifizierung
• AWS_SECRET_ACCESS_KEY: AWS-Secret-Key für die Authentifizierung

Alle Variablen sind in GitLab als protected definiert, sensible wie der AWS Secret Access Key zusätzlich als masked, sodass sie nur in sicheren CI/CD-Kontexten sichtbar werden. Die Sicherheit lässt sich weiter erhöhen, indem man diesem Tutorial zu CI/CD-Variablen folgt. Die Trennung von Code und Konfiguration macht die Pipeline flexibel und unabhängig von der jeweiligen Umgebung.

Ist das konfiguriert, läuft die OpenTofu-Pipeline automatisch und erledigt Folgendes:

• Netzwerkressourcen bereitstellen (VPC, Subnetze, Gateways, Routing-Tabellen)
• EKS-Control-Plane und Worker-Node-Gruppen bereitstellen
• Die Pipeline auslösen, die Argo CD und CertManager in den neuen Cluster ausrollt

Das Diagramm oben zeigt, wie die Bereitstellung der Infrastruktur abläuft.

1. Eine GitLab-Pipeline startet aus dem Infrastruktur-Repository, in dem die Terraform- beziehungsweise OpenTofu-Konfigurationsdateien liegen.
2. GitLab CI/CD führt die OpenTofu-Befehle aus und verwaltet die State-Datei über das integrierte Terraform-State-Backend sicher in GitLab.
3. OpenTofu verbindet sich über die konfigurierten Provider mit AWS und legt alle nötigen Ressourcen an: VPC, Subnetze, Gateways, Load Balancer und das über mehrere Availability Zones verteilte Amazon-EKS-Cluster.

Am Ende dieser Phase stehen AWS-Umgebung und Kubernetes-Cluster vollständig bereit und sind betriebsfähig.

Den Abschluss dieses Vorgangs bildet ein Post-Deploy-Schritt: Er löst eine zweite GitLab-Pipeline in einem eigenen Repository aus, die Argo CD und CertManager über den Helm Provider automatisch in den neuen EKS-Cluster ausrollt.

Kubernetes-Werkzeuge automatisch konfigurieren

Stehen AWS-Infrastruktur und EKS-Cluster, folgt als nächster Schritt die Konfiguration der Kubernetes-Werkzeuge, die für den Betrieb der Umgebung nötig sind: Argo CD, CertManager und der Ingress NGINX Controller.

Dieser Vorgang läuft vollständig automatisiert über eine zweite GitLab-Pipeline in einem separaten Repository.

Die zweite Pipeline wird automatisch aus der Infrastruktur-Pipeline heraus gestartet, über einen Trigger-Job, sobald die OpenTofu-Bereitstellung erfolgreich abgeschlossen ist.

In der Praxis heißt das: Diese Kernkomponenten werden als Teil desselben durchgängigen Workflows ausgerollt, ohne manuelle Schritte. Das Deployment selbst übernimmt OpenTofu über den Helm Provider, mit dem sich Helm-Charts deklarativ als Code über GitLab verwalten lassen.

Vereinfacht sieht der Ablauf so aus:

1. Die erste Pipeline stellt den EKS-Cluster bereit und löst über einen GitLab-Trigger-Job die zweite aus.
2. Die zweite Pipeline nutzt OpenTofu mit dem Helm Provider, um:
   • die Kubeconfig aus dem EKS-Cluster zu laden,
   • Argo CD zu installieren (für die GitOps-Verwaltung),
   • CertManager zu installieren (für die automatische Verwaltung von TLS-Zertifikaten),
   • den Ingress NGINX Controller zu installieren (für das Routing des Ingress-Verkehrs). (Hinweis: Der Ingress NGINX Controller wird im Kubernetes-Ökosystem abgekündigt. Für neue Deployments empfiehlt sich, Alternativen wie Traefik oder einen Ansatz über ein API-Gateway zu prüfen.)
3. Jedes Helm-Release ist in der OpenTofu-Konfiguration definiert, sodass Upgrades und Rollbacks über gewöhnliche Änderungen am Infrastrukturcode laufen.
4. Zuletzt startet eine dritte Pipeline, die die Beispiel-Webanwendung ausrollt. Diese Pipeline wendet die Argo-CD-Anwendungsmanifeste an, die die Webanwendung und die zugehörigen Ressourcen definieren.

Eine Beispiel-Webanwendung mit Argo CD nach GitOps-Prinzipien ausrollen

Sind alle Kubernetes-Kernkomponenten installiert (Argo CD, CertManager und Ingress NGINX Controller), beginnt die letzte Phase der Automatisierung. Dieser Schritt läuft automatisch an, sobald die Installation der Helm-Charts abgeschlossen ist.

Eine dritte GitLab-Pipeline startet und rollt eine Beispiel-Webanwendung über Argo CD in den neu erstellten EKS-Cluster aus.

Das Diagramm unten zeigt den Gesamtablauf:

In dieser Phase verbindet sich GitLab mit der von OpenTofu erzeugten Kubeconfig zum Cluster und wendet die Argo-CD-Anwendungsmanifeste an, die den gewünschten Zustand der Webanwendung definieren.

Die Pipeline:

• lädt und aktualisiert die Kubeconfig, um sich mit dem EKS-Cluster zu verbinden,
• aktualisiert Zugangsdaten und Repository-Angaben dynamisch über CI/CD-Variablen,
• erstellt den Kubernetes-Namespace für die Anwendung (aws-summit-app),
• wendet die Argo-CD-Manifeste an (repository.yaml, application.yaml, cluster-issuer.yaml),
• erstellt ein Container-Registry-Secret, damit die Anwendung Images über einen Access Token sicher aus GitLab ziehen kann.

Das alles läuft automatisch über GitLab CI/CD, ohne manuelles Eingreifen.

Sind die Manifeste angewendet, erkennt der Argo-CD-Controller sie und synchronisiert den Anwendungszustand mit dem Repository, wodurch die Beispiel-Webseite in den EKS-Cluster ausgerollt wird.

Das Ergebnis ist eine voll betriebsfähige Kubernetes-Umgebung, in der:

• die Infrastruktur mit OpenTofu bereitgestellt ist,
• die Cluster-Werkzeuge deklarativ mit Helm installiert sind,
• die Anwendungen per GitOps über Argo CD ausgerollt und verwaltet werden.

So entstehen durchgängige Automatisierung, Nachvollziehbarkeit und Reproduzierbarkeit, alles über GitLab gesteuert.

Eine Beispiel-Webanwendung mit GitLab CI/CD bauen und paketieren

Bevor Argo CD die Anwendung ausrollt, muss sie gebaut, containerisiert und in der GitLab Container Registry veröffentlicht werden.

Dafür sorgt eine eigene CI/CD-Pipeline, die einer GitOps-Repository-Struktur folgt: Quellcode und Kubernetes-Manifeste liegen in getrennten Repositorys.

Die GitLab-Gruppe ist dabei in zwei Bereiche gegliedert:

• Apps/ enthält die Quellcode-Repositorys der Anwendungen.
  • Beispiel: aws-summit-app/web enthält den Quellcode der Beispiel-Webseite.
• Deployments/ enthält die Repositorys mit den Kubernetes-Manifesten je Anwendung.
  • Beispiel: aws-summit-app/web unter Deployments definiert die Kubernetes-Manifeste, mit denen die Webseite ausgerollt wird (deployment.yaml, ingress.yaml, service.yaml und weitere).

Diese Trennung ermöglicht einen sauberen GitOps-Ablauf, denn Anwendungscode und Deployment-Konfigurationen sind voneinander unabhängig und bleiben über die Automatisierung dennoch synchron.

Die CI/CD-Pipeline im Anwendungs-Repository automatisiert diese Aufgaben:

• Bauen und paketieren: Die Pipeline kompiliert den Quellcode und baut das Docker-Image anhand des mitgelieferten Dockerfile.
• In der GitLab Container Registry veröffentlichen: Das Image wird automatisch getaggt und in die integrierte GitLab Container Registry geschoben.
• Deployment-Manifeste aktualisieren: Ist das Image veröffentlicht, führt die Pipeline einen Job aus, der die Image-Referenz im zugehörigen Deployment-Repository aktualisiert (unter Deployments/aws-summit-app/web).

Das geschieht automatisch, indem der neue Image-Tag committet oder ein Merge Request erstellt wird.

Sobald Commit oder Merge Request vorliegen, erkennt Argo CD die Änderung im Deployment-Repository und synchronisiert die aktualisierten Manifeste mit dem Kubernetes-Cluster. Damit ist die neue Anwendungsversion ohne manuelles Eingreifen ausgerollt.

Fazit

Dieses Tutorial hat gezeigt, wie sich eine vollständig automatisierte Cloud-Umgebung mit GitLab als Dreh- und Angelpunkt aufbauen lässt und damit die eingangs gesetzten Ziele erreicht: eine Infrastruktur, die reproduzierbar, versioniert und automatisiert ist. Aus der Kombination von OpenTofu für die Bereitstellung, GitLab CI/CD für die Pipeline-Orchestrierung und Argo CD für die GitOps-basierte Auslieferung ergibt sich ein Lebenszyklus, der sich vollständig über eine Plattform verwalten lässt, von den Cloud-Ressourcen bis zur laufenden Anwendung.

Als GitLab-Partner mit ausgewiesener Erfahrung in Cloud-Infrastruktur und DevSecOps-Praktiken unterstützt Clober (Gruppe SATEC) Organisationen dabei, vergleichbare automatisierte Umgebungen passend zum eigenen Bedarf umzusetzen.

Hinweis: Dieser Beitrag beruht auf einer Live-Demo, die das DevSecOps-Team von Clober (Gruppe SATEC) 2025 auf dem AWS Summit Madrid gezeigt hat.

Ressourcen

• GitLab-CI/CD-Komponenten
• GitLab Container Registry
• GitLab-verwaltetes Terraform-State-Management