Secrets et strategies de deploiement

Gestion des secrets

Les secrets (mots de passe, tokens, cles API) ne doivent jamais etre dans le code. Voici comment les gerer.

Variables CI/CD GitLab

# Dans GitLab : Settings > CI/CD > Variables
# Definir les variables protegees et masquees :
# - KUBE_CONFIG (fichier, protege)
# - DB_PASSWORD (masque, protege)
# - DOCKER_AUTH_CONFIG (masque)

# Utilisation dans .gitlab-ci.yml :
deploy:
  script:
    - echo "$KUBE_CONFIG" > /tmp/kubeconfig
    - export KUBECONFIG=/tmp/kubeconfig
    - kubectl create secret generic app-secrets \
        --from-literal=db-password="$DB_PASSWORD" \
        --dry-run=client -o yaml | kubectl apply -f -

Kubernetes Secrets

# secret.yaml (NE PAS committer les valeurs reelles)
apiVersion: v1
kind: Secret
metadata:
  name: app-secrets
  namespace: production
type: Opaque
data:
  db-password: cGFzc3dvcmQ=    # base64 encode
  api-key: bXktYXBpLWtleQ==

# Utilisation dans un Deployment
env:
  - name: DB_PASSWORD
    valueFrom:
      secretKeyRef:
        name: app-secrets
        key: db-password

Strategies de deploiement

# Rolling Update (par defaut dans K8s)
# Les pods sont remplaces progressivement
spec:
  strategy:
    type: RollingUpdate
    rollingUpdate:
      maxSurge: 1        # 1 pod en plus pendant la mise a jour
      maxUnavailable: 0  # Aucun pod indisponible

# Blue-Green avec 2 deployments
# 1. Deployer la nouvelle version (green)
kubectl apply -f deployment-green.yaml
# 2. Verifier que green fonctionne
kubectl get pods -l version=green
# 3. Basculer le service vers green
kubectl patch service mon-app -p \
  '{"spec":{"selector":{"version":"green"}}}'
# 4. Supprimer l'ancienne version (blue)
kubectl delete -f deployment-blue.yaml

# Canary : envoyer un pourcentage du trafic
# 10% du trafic vers la nouvelle version
# 90% vers l'ancienne
# Progressivement augmenter si tout va bien