Je ne sais pas comment nommer Dockerfiles. Beaucoup sur GitHub utilisent Dockerfile
sans extension de fichier. Dois-je leur donner un nom et une extension; si oui quoi? Ou est-ce que je les appelle simplement Dockerfile
?
Je ne sais pas comment nommer Dockerfiles. Beaucoup sur GitHub utilisent Dockerfile
sans extension de fichier. Dois-je leur donner un nom et une extension; si oui quoi? Ou est-ce que je les appelle simplement Dockerfile
?
Réponses:
Ne changez pas le nom du dockerfile si vous souhaitez utiliser le générateur automatique sur hub.docker.com. N'utilisez pas d'extension pour les fichiers docker, laissez-la null. Le nom du fichier doit être: (aucune extension du tout)
Dockerfile
cependant, vous pouvez faire comme ci-dessous aussi ...
dev.Dockerfile
, uat.Dockerfile
, prod.Dockerfile
Etc.
Sur VS Code, vous pouvez utiliser <purpose>.Dockerfile
et cela fonctionne en conséquence.
dev.Dockerfile
, test.Dockerfile
, build.Dockerfile
Etc.
Sur VS Code, j'utilise <purpose>.Dockerfile
et il est reconnu correctement.
Je pense que vous devriez avoir un répertoire par conteneur avec un Dockerfile (sans extension). Par exemple:
/db/Dockerfile
/web/Dockerfile
/api/Dockerfile
Lorsque vous construisez, utilisez simplement le nom du répertoire, Docker trouvera le Dockerfile. par exemple:
docker build -f ./db .
Si vous souhaitez utiliser le générateur automatique sur hub.docker.com, il doit l'être Dockerfile
. Donc là :)
Il semble que ce soit vrai, mais personnellement, il me semble que ce n'est pas une bonne conception. Bien sûr, ayez un nom par défaut (avec l'extension) mais autorisez d'autres noms et ayez un moyen de spécifier le nom du fichier docker pour les commandes.
Avoir une extension est également agréable car cela permet d'associer des applications à ce type d'extension. Lorsque je clique sur un Dockerfile sous MacOSX, il le traite comme un exécutable Unix et essaie de l'exécuter.
Si les fichiers Docker avaient une extension, je pourrais dire au système d'exploitation de les démarrer avec une application particulière, par exemple mon application d'édition de texte. Je ne suis pas sûr, mais le comportement actuel peut également être lié aux autorisations de fichier.
J'ai créé deux Dockerfiles dans le même répertoire,
# vi one.Dockerfile
# vi two.Dockerfile
pour construire les deux Dockerfiles utilisez,
# docker build . -f one.Dockerfile
# docker build . -f two.Dockerfile
Remarque: vous devriez être dans le répertoire de travail actuel.
Dois-je leur donner un nom et une extension; si oui quoi?
Vous pouvez nommer vos Dockerfiles comme vous le souhaitez. Le nom de fichier par défaut est Dockerfile
(sans extension), et l'utilisation de la valeur par défaut peut faciliter diverses tâches lors de l'utilisation de conteneurs.
En fonction de vos besoins spécifiques, vous souhaiterez peut-être changer le nom du fichier. Si vous construisez pour plusieurs architectures, par exemple, vous souhaiterez peut-être ajouter une extension indiquant l'architecture comme l' équipe resin.io l' a fait pour le conteneur HAProxy, son exemple ARM multi-conteneur :
Dockerfile.aarch64
Dockerfile.amd64
Dockerfile.armhf
Dockerfile.armv7hf
Dockerfile.i386
Dockerfile.i386-nlp
Dockerfile.rpi
Dans l'exemple fourni, chaque Dockerfile est construit à partir d'une image en amont différente, spécifique à l'architecture. Le Dockerfile spécifique à utiliser pour la génération peut être spécifié à l'aide de l' --file, -f
option lors de la création de votre conteneur à l'aide de la ligne de commande.
Dockerfile
est bon si vous n'avez qu'un seul fichier docker (par répertoire). Vous pouvez utiliser la norme de votre choix si vous avez besoin de plusieurs fichiers docker dans le même répertoire - si vous avez une bonne raison. Dans un projet récent, il y avait des fichiers docker AWS et des fichiers d'environnement de développement local car les environnements différaient suffisamment:
Dockerfile
Dockerfile.aws
Dockerfile.armv7hf
côté de a Dockerfile.i386
.