Stratégies Dockerfile pour Git
Quelle est la meilleure stratégie pour cloner un référentiel Git privé dans un conteneur Docker à l'aide d'un Dockerfile? Avantages/inconvénients?
Je sais que je peux ajouter des commandes sur Dockerfile afin de cloner mon référentiel privé dans un conteneur Docker. Mais je voudrais savoir quelles approches différentes les gens ont utilisées dans ce cas.
Ce n'est pas couvert dans le guide des meilleures pratiques Dockerfile.
Je partagerai ce que j'ai trouvé jusqu'à présent.
Il existe différentes stratégies pour obtenir votre code source Git dans une version Docker. Beaucoup d'entre eux ont différentes manières d'interagir avec les mécanismes de mise en cache de Docker et peuvent être plus ou moins adaptés à votre projet et à la manière dont vous envisagez d'utiliser Docker.
RUN git clone
Si vous êtes comme moi, c'est l'approche qui me vient à l'esprit lorsque vous voyez les commandes disponibles dans un Dockerfile. Le problème avec cela est qu'il peut interagir de plusieurs manières non intuitives avec les mécanismes de mise en cache de la construction de Docker. Par exemple, si vous effectuez une mise à jour de votre référentiel git, puis réexécutez la build docker qui a une commande RUN git clone, vous pouvez ou non obtenir les nouveaux commit selon que les commandes Dockerfile précédentes ont invalidé le cache.
Une façon de contourner ce problème consiste à utiliser le docker build --no-cache, mais s'il existe des commandes chronophages précédant le clone, elles devront également s'exécuter à nouveau.
Un autre problème est que vous (ou quelqu'un à qui vous avez distribué votre Dockerfile) pouvez revenir de manière inattendue à une version cassée plus tard lors de la mise à jour du référentiel git en amont.
Une approche à deux oiseaux-une pierre à cela tout en utilisant RUN git clone consiste à le mettre sur une ligne1 avec un contrôle de révision spécifique, par exemple:
RUN git clone https://github.com/example/example.git && cd example && git checkout 0123abcdef
La mise à jour de la révision à extraire dans le Dockerfile invalidera le cache sur cette ligne et provoquera l'exécution du clone/extraction.
Un inconvénient possible de cette approche en général est que vous devez avoir installé git dans votre conteneur.
RUN curl ou ADD a tag/commit tarball URL
Cela évite d'avoir à installer git dans votre environnement de conteneur et peut être explicite sur le moment où le cache se cassera (c'est-à-dire si la balise/révision fait partie de l'URL, ce changement d'URL va casser le cache). Notez que si vous utilisez la commande Dockerfile ADD pour copier à partir d'une URL distante, le fichier sera téléchargé à chaque fois que vous exécutez la génération et l'en-tête HTTP Last-Modified sera également utilisé pour invalider le cache.
Vous pouvez voir cette approche utilisée dans le golang Dockerfile .
Sous-modules Git dans le référentiel Dockerfile
Si vous conservez votre build Dockerfile et Docker dans un référentiel distinct de votre code source, ou si votre build Docker nécessite plusieurs référentiels source, l'utilisation de sous-modules git (ou sous-arbres git) dans ce référentiel peut être un moyen valide pour obtenir votre référentiel source dans votre build le contexte. Cela évite certains problèmes avec la mise en cache Docker et la mise à jour en amont, car vous verrouillez la révision en amont dans votre spécification de sous-module/sous-arbre. Les mettre à jour cassera votre cache Docker car il modifie le contexte de génération.
Notez que cela n'obtient que les fichiers dans votre contexte de construction Docker, vous devez toujours utiliser les commandes ADD dans votre Dockerfile pour copier ces chemins là où vous les attendez dans le conteneur.
Vous pouvez voir cette approche utilisée dans le ici
Dockerfile dans le dépôt git
Ici, vous avez juste votre Dockerfile dans le même référentiel git à côté du code que vous voulez construire/tester/déployer, donc il est automatiquement envoyé dans le cadre du contexte de construction, vous pouvez par exemple AJOUTER ./project pour copier le contexte dans le conteneur. L'avantage de cela est que vous pouvez tester les modifications sans avoir à les valider/les pousser pour les intégrer dans une version de docker de test; l'inconvénient est que chaque fois que vous modifiez des fichiers dans votre répertoire de travail, cela invalidera le cache à la commande ADD. L'envoi du contexte de génération d'un grand répertoire source/données peut également prendre du temps. Donc, si vous utilisez cette approche, vous pouvez également utiliser judicieusement le fichier. Dockerignore , notamment en ignorant tout dans votre .gitignore et éventuellement le répertoire .git lui-même.
Mappage du volume
Si vous utilisez Docker pour configurer un environnement de développement/test que vous souhaitez partager entre une grande variété de référentiels sources sur votre machine hôte, monter un répertoire Host en tant que volume de données peut être un moyen viable stratégie. Cela vous donne la possibilité de spécifier les répertoires que vous souhaitez inclure lors de l'exécution du docker et évite les problèmes de mise en cache de la construction du docker, mais rien de tout cela ne sera partagé entre les autres utilisateurs de votre Dockerfile ou de votre image de conteneur.
-
Les références:
- "Stratégies Git pour Docker" Ryan Baumann -/etc (blog), 29 juil. 2015
Vous avez généralement deux approches:
- référencer un coffre-fort où vous obtenez vos données secrètes nécessaires pour accéder à ce que vous devez mettre dans votre image (ici, vos clés ssh pour accéder à votre dépôt privé)
Mise à jour 2018: voir " Comment garder vos secrets de conteneur sécurisés ", qui comprend:
- Utiliser des montages de volume pour transmettre des secrets à un conteneur lors de l'exécution
- Ayez un plan pour faire tourner les secrets
- Assurez-vous que vos secrets sont cryptés
- ou une technique de squash (non recommandée, voir commentaire)
Pour la deuxième approche, voir " Tirer Git dans une image Docker sans laisser les clés SSH derrière "
- Ajoutez la clé privée au Dockerfile
- Ajoutez-le à l'agent ssh
- Exécutez les commandes qui nécessitent une authentification SSH
- Supprimer la clé privée
Dockerfile:
ADD ~/.ssh/mykey /tmp/
RUN ssh-agent /tmp
# RUN bundle install or similar command
RUN rm /tmp/mykey
Construisons l'image maintenant:
$ docker build -t original .
Écraser les couches:
docker save original | Sudo docker-squash -t squashed | docker load