Comment gardez-vous des images de conteneur petites et sûres ?

Utilisez des builds multi-stage pour que les compilateurs et les dépendances de build n'atteignent jamais l'image finale, partez d'une base minimale comme distroless ou slim, et tournez avec un utilisateur non root. Ordonnez les couches pour que l'installation des dépendances soit mise en cache séparément des sources, ajoutez un .dockerignore, épinglez les images de base par digest, et scannez au build. Ne passez jamais de secrets en arguments de build, parce qu'ils restent dans l'historique des couches.

Pour la taille, les deux choses qui font le gros du travail sont les builds multi-stage et l'ordre des couches. Vous construisez dans une image complète avec la toolchain, puis vous ne copiez que le résultat compilé dans un runtime minimal, ce qui fait typiquement passer une image de plusieurs centaines de mégaoctets à quelques dizaines. L'ordre compte parce que l'installation des dépendances doit être sa propre couche au-dessus de la copie des sources, sinon chaque changement de code invalide le cache et reconstruit tout. Un .dockerignore empêche le répertoire git local et node modules d'être envoyés au démon tout court. Pour la sécurité, je tourne avec un utilisateur non root et un système de fichiers racine en lecture seule quand l'application le permet, j'épingle l'image de base par digest pour qu'un rebuild soit reproductible, et je reconstruis régulièrement pour que les correctifs de la base arrivent vraiment plutôt que d'épingler et d'oublier. Le scan tourne dans le pipeline et échoue sur les vulnérabilités hautes qui ont un correctif, et on publie un SBOM avec l'image pour pouvoir répondre en quelques minutes à la question quels services utilisent cette bibliothèque quand le prochain gros avis de sécurité tombe. Les secrets ne vont jamais dans les build args ; ils sont visibles dans l'historique.