Conteneurs et artefacts reproductibles

Conteneurs et artefacts reproductibles

1. Construire une image de qualité

   Un artefact de livraison doit être reproductible : deux constructions de la même révision donnent la même image. Sans cela, « ça marche en préproduction » ne prouve rien.

   Construire et versionner

   docker build -t mon-service:1.4.2 .
   docker tag mon-service:1.4.2 registry.exemple.fr/mon-service:1.4.2
   docker push registry.exemple.fr/mon-service:1.4.2

   Le tag est le numéro de version, jamais latest seul : latest est une étiquette mouvante, et un déploiement doit pouvoir dire exactement quelle version tourne.

   Le fichier de construction multi-étapes

   # syntaxe moderne : 'AS etape' nomme l'etape
   FROM python:3.12-slim AS deps
   WORKDIR /app
   COPY requirements.txt .
   RUN pip install --no-cache-dir -r requirements.txt
   
   FROM python:3.12-slim AS runtime
   WORKDIR /app
   COPY --from=deps /usr/local /usr/local
   COPY . .
   USER 1000:1000
   CMD ["python", "-m", "app"]

   La construction multi-étapes garde la couche de compilation hors de l'image finale : l'artefact livré ne contient que ce qui sert à exécuter. Exécuter avec un utilisateur non privilégié fait partie de la même discipline.

   reproductibilité

   • .dockerignore pour exclure .git, les tests et les fichiers locaux ;
   • versions de base épinglées par digest, pas seulement par étiquette ;
   • dépendances verrouillées (requirements avec versions épinglées, verrou de dépendances) ;
   • ordre des copies stable pour que le cache de couches reste valable.

2. Vérifier avant de publier

   La chaîne doit bloquer ce qui ne doit pas être livré, pas seulement signaler. Trois contrôles à placer avant la construction :

   1. analyse de dépendances : vulnérabilités connues et licences interdites ;
   2. analyse statique : erreurs manifestes, secrets par inadvertance ;
   3. analyse de l'image : après construction, avant publication.

         - name: Vérifier les vulnérabilités
           run: pip-audit --strict
   
         - name: Construire
           run: docker build -t mon-service:1.4.2 .
   
         - name: Scanner l'image
           run: |
             test "$(trivy image --severity HIGH,CRITICAL --format json mon-service:1.4.2 | jq '.Results | length')" = "0"

   Le point clé : l'étape échoue si la vérification échoue. Un tableau de bord consultable après coup ne remplace pas une porte fermée dans la chaîne.

3. Registre et gestion des versions

   Un registre d'images est un dépôt d'artefacts. Il doit être accessible par la chaîne, protégé par des identifiants dédiés, et able de signaler ce qu'il accepte.

   Versionner correctement

   # version semantique : MAJEUR.MINEUR.PATCH
   1.4.2    # version stable fixee
   1.4      # serie de correctifs
   1        # toute la serie 1.x
   sha-9f2c1ab   # version exacte et immuable

   Déployer en production avec une étiquette mouvante est la première cause de « ça marchait hier ». Le déploiement doit nommer la révision, par exemple par empreinte de commit.

   Les secrets de la chaîne

   • un secret par usage, jamais un secret partagé ;
   • accès en écriture uniquement pour la chaîne de construction, en lecture seule ailleurs ;
   • rotation périodique et journalisation des accès ;
   • aucun secret dans les journaux de la chaîne : un secret affiché dans la sortie d'une étape est compromis.

4. Exercices

   1. Construction en deux étapes : transformez un fichier de construction simple en version multi-étapes et comparez la taille des deux images.
   2. Reproductibilité : construisez deux fois la même image et vérifiez que l'empreinte obtenue est identique. Si elle change, identifiez la source d'instabilité.
   3. Porte fermée : ajoutez une étape qui échoue si une vulnérabilité critique est détectée, et provez-le avec une image volontairement vulnérable.