Archiver les artefacts de build avant de reconstruire une image Docker

À chaque déploiement, la même scène se répète : l’image Docker part de zéro, réinstalle les dépendances Composer, recompile les assets, puis se reconstruit intégralement, alors qu’entre deux déploiements, l’essentiel du code source WordPress n’a pas changé. Le problème n’est pas la reconstruction elle-même, indispensable pour garantir un environnement propre, mais la recompilation systématique d’artefacts qui n’ont pourtant pas bougé.

Une étape d’archivage des artefacts de build, placée avant la construction de l’image, permet de conserver ce qui a déjà été compilé et de ne relancer les étapes coûteuses que lorsque c’est réellement nécessaire.

Le problème, précisément

Un build WordPress conteneurisé enchaîne typiquement trois phases coûteuses en temps : l’installation des dépendances Composer, l’installation des dépendances npm, et la compilation des assets du thème via un outil comme Vite ou Webpack. Reconstruire l’image sans cache force Docker à repasser par ces trois phases, même si seul un fichier PHP métier a changé depuis la dernière construction.

Le snippet commenté : une étape de cache d’artefacts

La solution consiste à extraire les répertoires d’artefacts (vendor/, node_modules/, les fichiers compilés du thème) hors de l’image après chaque build réussi, puis à les réinjecter avant la construction suivante si les fichiers de verrouillage n’ont pas changé :

# Étape de restauration du cache, avant la construction de l'image
CACHE_DIR="/var/cache/build-artefacts/${PROJET}"
HASH_ACTUEL=$(sha256sum composer.lock package-lock.json | sha256sum | cut -d' ' -f1)
HASH_CACHE_FILE="${CACHE_DIR}/hash.txt"

if [ -f "${HASH_CACHE_FILE}" ] && [ "$(cat ${HASH_CACHE_FILE})" = "${HASH_ACTUEL}" ]; then
  echo "Artefacts inchangés, restauration du cache"
  cp -r "${CACHE_DIR}/vendor" ./vendor
  cp -r "${CACHE_DIR}/node_modules" ./node_modules
else
  echo "Dépendances modifiées, reconstruction complète nécessaire"
fi

Après un build réussi, une étape symétrique sauvegarde à nouveau les artefacts fraîchement compilés, avec le nouveau hash correspondant, prêts à être réutilisés au prochain déploiement.

# Étape de sauvegarde du cache, après la construction réussie
mkdir -p "${CACHE_DIR}"
cp -r ./vendor "${CACHE_DIR}/vendor"
cp -r ./node_modules "${CACHE_DIR}/node_modules"
echo "${HASH_ACTUEL}" > "${HASH_CACHE_FILE}"

Invalider au bon moment

Le point sensible de cette approche est la condition d’invalidation. Se fier uniquement à la présence du cache, sans vérifier son empreinte, conduirait à déployer une image avec des dépendances obsolètes après une mise à jour de composer.json. Le hash combiné des fichiers de verrouillage garantit que le cache n’est réutilisé que si les dépendances déclarées sont strictement identiques à la dernière exécution.

• Un changement dans composer.lock ou package-lock.json invalide automatiquement le cache.
• Un changement dans le code source du thème n’invalide pas le cache des dépendances, seulement la recompilation des assets propres au thème.
• Le cache doit vivre hors de l’image finale, sur un volume persistant du serveur de build, jamais copié tel quel dans l’image de production.

Variantes selon l’infrastructure de build

Avec un registre d’images comme cache intermédiaire

Plutôt qu’un répertoire local, certaines plateformes d’intégration continue permettent d’utiliser une image Docker intermédiaire comme cache, taguée séparément de l’image finale et réutilisée comme source de couches déjà construites (--cache-from). Cette variante convient mieux à une infrastructure de build partagée entre plusieurs machines, là où un cache local sur disque ne survivrait pas d’une machine à l’autre.

Avec un cache par étape de build multi-stage

Un Dockerfile multi-étapes peut isoler la phase de compilation des assets dans une étape séparée de l’image finale, ce qui permet à Docker de réutiliser nativement les couches inchangées sans script externe, à condition que l’ordre des instructions place les fichiers les plus stables (fichiers de verrouillage) avant les fichiers qui changent le plus souvent (code source applicatif).

Un cache mal invalidé est pire qu’une absence de cache : il déploie silencieusement du code qu’on croyait avoir mis à jour.

En résumé

Archiver les artefacts de build entre deux constructions d’image réduit sensiblement le temps de déploiement d’une équipe qui reconstruit fréquemment, à condition de soigner la condition d’invalidation du cache. Le choix du registre d’images cible reste un sujet distinct : cette étape de cache d’artefacts fonctionne indépendamment de la destination finale de l’image.