CCsolutions.io
Platform Engineering

GitOps & Infrastructure as Code: Infrastruktur die versioniert, reviewbar und auditierbar ist

Wenn Infrastruktur-Änderungen per kubectl apply oder manuell in der AWS-Konsole passieren, hat niemand einen vollständigen Überblick. GitOps ist die Antwort.

100%
IaC-Coverage
Keine manuelle Ressource außerhalb von Terraform oder Git
Git
Single Source
Git als einzige Quelle der Wahrheit für Infra und Deployments
Auto
Drift-Alert
ArgoCD erkennt und meldet Infrastruktur-Drift sofort
PR
Changes
Jede Änderung durch Pull Request mit Review und Plan-Output

Infrastructure as Code (IaC) bedeutet, die gesamte Infrastruktur in Code zu beschreiben, nicht als Klick-Dokumentation, sondern als ausführbare, versionierte Konfiguration. GitOps geht einen Schritt weiter: Git ist die einzige Quelle der Wahrheit, und jede Abweichung wird automatisch erkannt und korrigiert.

Die häufigsten Herausforderungen

1

Nobody knows what changed and when

Wenn Infrastruktur-Änderungen manuell in der Cloud-Konsole gemacht werden, gibt es keinen Audit-Trail. Was sich zwischen letztem Dienstag und dem Produktionsausfall geändert hat, ist nicht rekonstruierbar.

2

Reproduzierbare Environments sind unmöglich

Wenn Staging und Produktion in ihrer Konfiguration abweichen, weil sie unterschiedlich entstanden sind, sind Staging-Tests nicht verlässlich. 'Works on staging' und 'breaks in production' hat oft diese Ursache.

3

Infrastructure Drift ist unsichtbar

Wenn jemand manuell eine Security-Group-Regel ändert oder eine Ressource löscht, ohne dass die Änderung in Code reflektiert wird, driftet die tatsächliche Infrastruktur von der Dokumentation weg, unsichtbar, bis es ein Problem wird.

Der CCsolutions-Ansatz

CCsolutions implementiert IaC-Projekte mit Terraform (oder OpenTofu als Open-Source-Alternative): die gesamte Cloud-Infrastruktur, VPCs, Kubernetes-Cluster, IAM-Policies, Datenbanken, Load Balancer, wird in Terraform-Modulen beschrieben. Pull Requests für Infrastruktur-Änderungen, Code-Reviews, automatische Terraform-Plan-Ausgaben.

GitOps für Kubernetes-Deployments via ArgoCD: der gewünschte Zustand aller Kubernetes-Ressourcen ist in Git definiert. ArgoCD vergleicht kontinuierlich Git-Stand mit Cluster-Stand und signalisiert Abweichungen, oder korrigiert sie automatisch, je nach Konfiguration.

Das Ergebnis: eine Infrastruktur die sich wie Software verhält. Jede Änderung hat einen Author, einen Commit, eine Review. Rollbacks sind ein `git revert`. Neue Umgebungen sind ein `terraform apply`. Audit-Trails entstehen automatisch.

Technologien

Terraform / OpenTofu ArgoCD GitHub / GitLab Atlantis (Terraform-Automation) AWS Config / Azure Policy Terrascan / Checkov (IaC-Security) Renovate (Dependency-Updates)

Häufige Fragen

Was ist der Unterschied zwischen Terraform und ArgoCD?

Terraform verwaltet Cloud-Infrastruktur (AWS-Ressourcen, Azure-Ressourcen, Netzwerke, Datenbanken). ArgoCD verwaltet Kubernetes-Workloads (Deployments, Services, ConfigMaps). Zusammen decken sie die gesamte Stack-Layer ab. Infrastruktur und Applikations-Layer.

Müssen bestehende manuelle Ressourcen zu Terraform migriert werden?

Bestehende Ressourcen können mit `terraform import` in den IaC-State übernommen werden. Das ist ein einmaliger Aufwand, der die Migration sicherer macht als Neuerstellung. CCsolutions hat diesen Prozess für viele Kunden durchgeführt.

Wie wird verhindert, dass Entwickler weiterhin manuelle Änderungen machen?

Durch IAM-Policies die direkte Konsolen-Änderungen einschränken, und durch Policy-Enforcement (AWS Config, OPA) der manuelle Änderungen als Drift markiert. Wer eine Infrastruktur-Änderung braucht, öffnet einen Pull Request, das ist der einzige Weg.

Bereit, loszulegen?

Wir analysieren eure Situation kostenlos und zeigen, was in eurem konkreten Fall möglich ist.

IaC-Assessment anfragen