Avant, j'utilisais souvent l'étiquette :latest pour mes images de base dans les fichiers Docker, ce qui impliquait un versioning implicite.
Cette pratique semblait pratique pour s'assurer d'avoir la dernière version d'une image sans avoir à spécifier manuellement une version à chaque fois.
Cependant, cette approche présentait plusieurs inconvénients significatifs.
- Elle compromettait la reproductibilité des environnements de développement et de production. Deux builds successifs pouvaient aboutir à des environnements différents si une nouvelle version de l'image était publiée entre-temps.
- Ca introduisait une incohérence et une opacité dans le contrôle des versions utilisées, rendant difficile la détection et la correction des problèmes liés à des mises à jour incompatibles ou bug.
- Ca pouvait conduire à des problèmes de sécurité si la dernière version contenait des vulnérabilités non identifiées au moment du déploiement.
Maintenant, je spécifie explicitement le versioning de chaque image Docker en fixant une version spécifique, comme :12, par exemple.
Cette approche a plusieurs impacts positifs:
- elle assure une reproductibilité cohérente des environnements en éliminant les variations inattendues dues à des mises à jour automatiques.
- ça facilite également le diagnostic et la résolution de problèmes en permettant à tous les membres de l'équipe de travailler avec des versions identiques des dépendances.
- ça améliore la sécurité en permettant une évaluation des vulnérabilités connues pour chaque version utilisée
L'utilisation d'outils comme Snyk ou Renovate-bot permet de simplifier la gestion des mises à jour en détectant automatique les nouvelles versions disponibles et propose des mises à jour via des MR/PR, facilitant le passage d'un versioning implicite à un versioning explicite sans coût supplémentaire.
Cela permet non seulement un meilleur contrôle sur ce qui est déployé en production mais aussi d'intégrer ces mises à jour de manière contrôlée et sécurisée.
