Environnements et Promotion d'Artefacts¶

Structurer les environnements de déploiement, promouvoir les artefacts de façon traçable et gérer la configuration et les secrets sans les exposer.

Dev / Staging / Production¶

Trois environnements couvrent la majorité des besoins. Chacun a un rôle précis.

Le principe de parite¶

L'environnement de staging doit être le plus proche possible de la production. Les différences entre environnements sont une source majeure de bugs qui n'apparaissent qu'en prod.

Checklist de parite :

• même image Docker, même version
• même moteur de base de données et version
• même configuration réseau (certificats, DNS)
• même taille d'infrastructure (ou proportion representive)

Promotion d'artefacts¶

Un artefact (image Docker, binaire, wheel) est builde une seule fois en CI, puis promu de staging en production. On ne rebuilde jamais pour la prod.

graph LR
    A["Commit Git\n+ tag SHA"] --> B["CI Build\nimage Docker"]
    B --> C["Registre\nd'artefacts"]
    C -->|"Deploiement staging"| D["Staging\nTests E2E"]
    D -->|"Validation OK\nPromotion"| E["Registre prod\n(retag)"]
    E -->|"Deploiement prod"| F["Production"]
    style F fill:#2ecc71,color:#fff
    style B fill:#3498db,color:#fff

Le retag (ou la promotion dans le registre) signale explicitement qu'une image a été validee. En staging on deploie myapp:abc1234 (SHA du commit). En production on deploie myapp:1.5.0 (tag de release), mais c'est le même binaire.

Configuration par environnement¶

La configuration qui varie entre environnements ne doit pas être dans l'image. Le principe est celui des 12-factor apps : la config dans l'environnement, pas dans le code.

Variables d'environnement¶

# .env.staging
DATABASE_URL=postgres://user:pass@staging-db:5432/app
LOG_LEVEL=debug
FEATURE_NEW_DASHBOARD=true

# .env.production
DATABASE_URL=postgres://user:pass@prod-db:5432/app
LOG_LEVEL=warn
FEATURE_NEW_DASHBOARD=false

Fichiers de config par environnement¶

# config/staging.yaml
api:
  rate_limit: 100
  timeout: 30s
  debug: true

# config/production.yaml
api:
  rate_limit: 1000
  timeout: 10s
  debug: false

Gestion des secrets¶

Les secrets (mots de passe, clés API, certificats) obeyent a des règles strictes.

Règles fondamentales :

• Jamais dans le code source : ni en clair, ni encodes en base64
• Jamais dans l'image Docker : une image est potentiellement publique
• Jamais dans les variables CI en clair : utiliser les secrets du CI (masked, protected)
• Rotation périodique : les secrets ne doivent pas être eternels

Principe de moindre privilege¶

Chaque composant n'a accès qu'aux secrets dont il a strictement besoin. L'API ne connait pas les credentials de la base de monitoring. Le pipeline CI ne connait pas les secrets de production.

graph TB
    CI["Pipeline CI"] -->|"secret: REGISTRY_TOKEN"| REG["Registre Docker"]
    APP["Application"] -->|"secret: DB_PASSWORD"| DB["Base de donnees"]
    APP -->|"secret: API_KEY"| EXT["API externe"]
    CI -.->|"N'a PAS acces"| DB
    CI -.->|"N'a PAS acces"| EXT
    style CI fill:#3498db,color:#fff
    style APP fill:#2ecc71,color:#fff

Outils¶