GitOps – deployment strategies

Dlaczego GitOps zmienia sposób myślenia o deployment

W świecie DevOps tradycyjne podejście „push” do wdrożeń powoli ustępuje miejsca nowszej filozofii GitOps. Zamiast bezpośrednich deploymentów z CI/CD pipeline’ów, GitOps traktuje Git jako jedyne źródło prawdy dla całej infrastruktury i aplikacji.

Podstawy GitOps – od teorii do praktyki

GitOps bazuje na prostej zasadzie: **declarative state w Git = desired state w production**. Każda zmiana w infrastrukturze lub aplikacji musi przejść przez standardowy Git workflow z pull requestami i code review.

### Kluczowe komponenty GitOps

**1. Git Repository jako Source of Truth**
Wszystkie manifesty Kubernetes, konfiguracje Helm charts i definicje infrastruktury przechowywane są w Git. Każda zmiana wymaga pull requesta.

**2. GitOps Operator**
Agent działający w klastrze, który monitoruje repozytorium Git i automatycznie aplikuje zmiany. Popularne rozwiązania to Flux, ArgoCD czy Jenkins X.

**3. Declarative Configuration**
Wszystko definiowane jako kod – od deploymentów aplikacji po konfigurację sieciową i monitoring.

Strategie deployment w GitOps

GitOps nie ogranicza się do jednej strategii wdrażania. Możesz implementować różne patterns w zależności od wymagań aplikacji.

### Rolling Updates w GitOps

Najczęstsza strategia dla aplikacji bez wymagań zero-downtime. GitOps operator stopniowo zastępuje stare pody nowymi.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: webapp-deployment
  namespace: production
spec:
  replicas: 3
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxUnavailable: 1
      maxSurge: 1
  selector:
    matchLabels:
      app: webapp
  template:
    metadata:
      labels:
        app: webapp
        version: v2.1.3
    spec:
      containers:
      - name: webapp
        image: myapp:v2.1.3
        ports:
        - containerPort: 8080
        readinessProbe:
          httpGet:
            path: /health
            port: 8080
          initialDelaySeconds: 10
          periodSeconds: 5

### Blue-Green Deployment z GitOps

Strategia zero-downtime, gdzie utrzymujesz dwa identyczne środowiska. GitOps przełącza traffic między nimi przez zmianę service selectors.

apiVersion: v1
kind: Service
metadata:
  name: webapp-service
  namespace: production
spec:
  selector:
    app: webapp
    version: blue  # GitOps zmieni na 'green' po successful deployment
  ports:
  - port: 80
    targetPort: 8080
  type: LoadBalancer

**Proces Blue-Green w GitOps:**
1. Deploy nowej wersji jako „green” environment
2. Testy smoke i health checks
3. Update service selector w Git repository
4. GitOps operator przełącza traffic
5. Cleanup starego „blue” environment

### Canary Deployments

Stopniowe kierowanie części ruchu na nową wersję. W GitOps implementowane przez Istio service mesh lub Nginx ingress.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-canary
spec:
  http:
  - match:
    - headers:
        canary:
          exact: "true"
    route:
    - destination:
        host: webapp-service
        subset: v2
      weight: 100
  - route:
    - destination:
        host: webapp-service
        subset: v1
      weight: 90
    - destination:
        host: webapp-service
        subset: v2
      weight: 10  # 10% traffic na nową wersję

Implementacja GitOps Operator

### Flux – prosty start z GitOps

Flux to jeden z najpopularniejszych GitOps operatorów dla Kubernetes. Łatwy w konfiguracji i integracji.

# Instalacja Flux
kubectl create namespace flux

# Deploy Flux operator
kubectl apply -f https://raw.githubusercontent.com/fluxcd/flux/master/deploy/flux-deployment.yaml

# Konfiguracja Git repository
kubectl create secret generic flux-git-deploy \
  --from-file=identity=/path/to/private-key \
  --namespace=flux

**Flux configuration:**

apiVersion: apps/v1
kind: Deployment
metadata:
  name: flux
  namespace: flux
spec:
  template:
    spec:
      containers:
      - name: flux
        image: docker.io/fluxcd/flux:1.14.2
        args:
        - --git-url=git@github.com:company/k8s-manifests
        - --git-branch=master
        - --git-path=production
        - --sync-interval=5m
        - --registry-poll-interval=1m

### ArgoCD – enterprise GitOps

ArgoCD oferuje zaawansowany UI i multi-cluster support, idealne dla większych organizacji.

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: webapp-production
  namespace: argocd
spec:
  project: default
  source:
    repoURL: https://github.com/company/k8s-manifests
    targetRevision: HEAD
    path: apps/webapp/production
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true
    syncOptions:
    - CreateNamespace=true

Security w GitOps

GitOps znacznie poprawia security posture przez eliminację bezpośredniego dostępu do production clusters.

### Principle of Least Privilege

### Audit Trail

Każda zmiana w production ma pełny audit trail w Git history:

# Sprawdzenie historii deploymentów
git log --oneline --grep="deploy"

# Kto wprowadził problematyczną zmianę
git blame manifests/webapp-deployment.yaml

# Rollback do poprzedniej wersji
git revert HEAD~1
git push origin master

Rollback i Disaster Recovery

### Instant Rollback

Rollback w GitOps to po prostu git revert:

# Rollback ostatniego deployment
git revert HEAD
git push origin master

# GitOps operator automatycznie wykryje zmianę i rollback aplikację
# Czas rollback: 30-60 sekund w zależności od sync interval

### Disaster Recovery

GitOps ułatwia disaster recovery – cała infrastruktura jest w Git:

# Odtworzenie całego środowiska
git clone https://github.com/company/k8s-manifests
kubectl apply -R -f ./production/

# GitOps operator automatycznie zsynchronizuje wszystkie aplikacje

Monitoring i Observability

GitOps wprowadza nowe wymiary monitorowania:

**Sync Status Monitoring:**
– Drift detection – różnice między Git a rzeczywistym stanem
– Sync latency – czas między push do Git a deployment
– Failed syncs – błędy podczas aplikacji manifestów

# Prometheus metrics dla Flux
flux_sync_duration_seconds
flux_sync_last_success_timestamp
flux_resource_sync_state

Wyzwania i rozwiązania

### Problem: Secrets Management

GitOps + secrets = wyzwanie. Nie możesz przechowywać plaintext secrets w Git.

**Rozwiązania:**
– **Sealed Secrets:** Encrypted secrets w Git, decrypted w klastrze
– **External Secrets Operator:** Integracja z HashiCorp Vault, AWS Secrets Manager
– **Helm secrets:** Szyfrowanie values.yaml z sops/gpg

# Sealed Secret example
apiVersion: bitnami.com/v1alpha1
kind: SealedSecret
metadata:
  name: webapp-secrets
  namespace: production
spec:
  encryptedData:
    database-password: AgBy3i4OJSWK+PiTySYZZA==...

### Problem: Multi-environment Management

**Rozwiązanie – Git Branching Strategy:**
– `master` branch = production
– `staging` branch = staging environment
– `develop` branch = development environment

Best Practices

### Repository Structure

k8s-manifests/
├── apps/
│   ├── webapp/
│   │   ├── base/          # Kustomize base
│   │   ├── production/    # Production overlay
│   │   └── staging/       # Staging overlay
├── infrastructure/
│   ├── monitoring/
│   ├── ingress/
│   └── cert-manager/
└── platform/
    ├── flux/
    └── argocd/

### Commit Messages

Structured commit messages ułatwiają śledzenie deploymentów:

deploy(webapp): bump to v2.1.3

- Fix memory leak in user service
- Update database connection pool size
- Security patch for CVE-2018-1234

Closes: #123
Reviewed-by: @senior-dev

Przydatne zasoby:

• Weave Works – GitOps documentation
• Flux GitHub repository
• ArgoCD official documentation
• Kubernetes deployment management

Czy GitOps zmieni sposób w jaki Twój zespół wdraża aplikacje? Podziel się swoimi doświadczeniami z tradycyjnymi metodami deployment w komentarzach!