Quelqu'un peut-il m'expliquer pourquoi le processus Docker normal consiste à créer une image à partir d'un Dockerfile, puis à la télécharger dans un référentiel, au lieu de simplement déplacer le Dockerfile vers et depuis le référentiel?
Disons que nous avons un ordinateur portable de développement et un serveur de test avec Docker.
Si nous construisons l'image, cela signifie charger et télécharger tous les packages dans le Dockerfile. Parfois, cela peut être très volumineux (par exemple, PyTorch> 500 Mo).
Au lieu de transporter le grand fichier image vers et depuis le serveur, cela n'a pas de sens de, peut-être compiler l'image localement pour vérifier qu'elle fonctionne, mais surtout de transporter le petit Dockerfile et de construire l'image sur le serveur?
3 Réponses :
Cela a commencé comme un commentaire, mais il est devenu trop long. Il ne s'agit probablement pas d'une réponse complète, mais peut contenir des informations utiles malgré tout.
Souvent, le Dockerfile fera partie d'un processus de construction plus large, les fichiers de sortie des étapes précédentes étant copiés dans l'image finale. Si vous souhaitez héberger le Dockerfile au lieu de l'image finale, vous devez également héberger soit les fichiers traités (généralement temporaires), soit l'intégralité du script de compilation et de dépôt source.
Ce dernier est souvent utilisé pour les projets open source, mais pour plus de commodité, des images Docker prédéfinies sont également fréquemment disponibles.
Une solution efficace à ce problème consiste à écrire l'intégralité du processus de construction dans le Dockerfile en utilisant versions multi-étapes (introduites dans Docker CE 17.05 et EE 17.06). Mais même avec le processus de construction complet décrit de manière indépendante de la plate-forme dans un seul Dockerfile, le référentiel source complet doit toujours être fourni.
TL, DR: Considérez une image Docker comme un binaire normal. Il est pratique de télécharger et d’installer sans avoir à manipuler les fichiers sources. Vous pourriez télécharger la source d’une application C et la construire à l’aide du Makefile fourni, mais pourquoi le feriez-vous si un binaire était mis à disposition pour votre système?
Un analogue plus précis à une image serait un package, c'est-à-dire un rpm ou deb et non un binaire lié statiquement (moins pour les multi-étapes cependant), mais sinon cela cloue il.
Au lieu de transporter le grand fichier image vers et depuis le serveur, cela n'a pas de sens de, peut-être compiler l'image localement pour vérifier cela fonctionne, mais transporte principalement le petit Dockerfile et construit le image sur le serveur?
Absolument! Vous pouvez, par exemple, configurer une build automatisé sur Docker Hub qui ne fera que à chaque fois que vous enregistrez une version mise à jour de votre Dockerfile dans votre dépôt GitHub.
Ou vous pouvez configurer votre propre pipeline de serveur de build / CI en conséquence.
À mon humble avis, l'une des raisons de la construction du concept d'images et de sa mise en référentiel est également le partage avec les gens. Par exemple, nous appelons l'image prête à l'emploi de Python pour effectuer toutes les tâches liées à Python pour qu'un programme python s'exécute dans Dockerfile. De même, nous pourrions créer un code personnalisé (prenons l'exemple que j'ai fait pour l'installation d'Apache avec quelques étapes personnalisées (comme les changements de ports et en plus de faire quelques étapes), j'ai créé son image et je l'ai finalement mise dans le référentiel de mon entreprise.
J'ai appris au bout de quelques jours que d'autres équipes l'utilisaient peut-être aussi et maintenant, lorsqu'elles le partagent, elles n'ont PAS besoin de faire de modifications, utilisent simplement mon image et elles devraient être faites.