Navigation
⌂ Root-Index Zielbild: Enterprise-Infrastruktur verstehen Rechenzentrum, Bare Metal und Hardware-Basis Netzwerk, DNS, Load Balancer und Firewall Linux, Betriebssystem-Baseline und Systemdienste Virtualisierung und Private Cloud Storage, Backup und Datenhaltung Kubernetes, OpenShift und Container-Plattform Infrastructure as Code mit Terraform und Ansible GitOps, CI/CD und Plattform-Auslieferung Security, IAM, PKI und Zero Trust Observability, Monitoring, Logging und Tracing High Availability, Disaster Recovery und SRE Praxis: Enterprise-Referenzarchitektur von Portal bis Datenbank
Tool / Betriebsframework

GitOps, CI/CD und Plattform-Auslieferung

GitOps macht Git zum überprüfbaren Zielzustand für Plattform und Anwendungen. CI baut Artefakte; CD/GitOps bringt sie kontrolliert in Umgebungen.

Diagramm GitOps, CI/CD und Plattform-Auslieferung

Fachliche Bedeutung

Schnelle Lieferung ohne Kontrolle ist riskant. Kontrolle ohne Geschwindigkeit blockiert Innovation. GitOps verbindet Änderungsgeschwindigkeit mit Nachvollziehbarkeit: jede Änderung hat Commit, Review, Pipeline und Rollback-Punkt.

CI vs CD vs GitOps

CI kompiliert, testet und baut Images. CD deployt. GitOps-Controller vergleichen Git-Zustand mit Cluster-Zustand und synchronisieren Abweichungen.

Umgebungsstrategie

Development, Test, Integration, Staging und Produktion sollten nicht per Hand auseinanderlaufen. Unterschiede gehören in Werte-Dateien, Overlays oder Parameter, nicht in komplett andere Manifeste.

Secrets und Promotion

Images werden durch Stages promoviert. Secrets werden nicht in Klartext ins Git gelegt. Für produktive Änderungen braucht es Genehmigung oder definierte automatische Gates.

Rollback

Rollback ist kein Wunsch, sondern ein getesteter Prozess: Image-Version, Manifest-Version, Datenbankmigration, Feature Flags und Traffic-Routing müssen zusammenpassen.

Ausführliche Beispiele

GitOps-Verzeichnisstruktur

platform-gitops/
  clusters/
    prod-eu1/
      apps/order-api/kustomization.yaml
      namespaces/orders-prod.yaml
      policies/network-policy.yaml
    test-eu1/
      apps/order-api/kustomization.yaml
  base/
    order-api/deployment.yaml
    order-api/service.yaml
  overlays/
    prod/order-api/values.yaml
    test/order-api/values.yaml

Kustomize-Overlay

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization
resources:
  - ../../base/order-api
patches:
  - path: replica-count.yaml
images:
  - name: registry.example.com/order/order-api
    newTag: 1.4.2-prod

Pipeline-Gates

quality_gates:
  - unit_tests
  - container_scan
  - sbom_created
  - policy_check
  - integration_tests
  - approval_for_prod
  - smoke_test_after_deploy

Typische Stolperfallen

  • Pipeline baut direkt nach Produktion ohne Review.
  • Git enthält Klartext-Secrets.
  • Manuelle Cluster-Änderungen werden nicht zurückgeführt.
  • Rollback ignoriert Datenbankmigrationen.
  • Jede Umgebung hat eigene Manifest-Kopien.

Prüf- und Verständnis-Checkliste

  • Git ist führender Zielzustand.
  • Pipeline erzeugt reproduzierbare Artefakte.
  • Prod-Promotion ist nachvollziehbar.
  • Secrets sind extern geschützt.
  • Rollback wurde real getestet.

Merksatz

Eine Infrastrukturkomponente ist erst enterprise-tauglich, wenn sie geplant, automatisiert, überwacht, geschützt, wiederherstellbar und fachlich begründet ist.