Dockerfile stratégies pour Git

Je vais partager ce que j'ai trouvé jusqu'à présent.

Il existe différentes stratégies pour l'obtention de votre code source de Git dans un Docker construire. Beaucoup de ces différentes manières d'interagir avec le Panneau de mécanismes de mise en cache, et peut être plus ou moins bien adaptées à votre projet et comment vous avez l'intention d'utiliser Docker.

Lancez la commande git clone

Si vous êtes comme moi, c'est l'approche qui nous vient à l'esprit quand vous voyez les commandes disponibles pour vous dans un Dockerfile. Le problème, c'est qu'il peut interagir dans plusieurs non-intuitif façons avec le Panneau de construire des mécanismes de mise en cache. Par exemple, si vous faites une mise à jour de votre dépôt git, puis exécutez de nouveau le panneau de construire qui a un git clone de commande, vous pouvez ou ne pouvez pas obtenir le nouveau commit(s) en fonction de si le précédent Dockerfile commandes ont invalidé le cache.

Un moyen de contourner ce problème est d'utiliser docker construire --no-cache, mais alors si il y a quelque temps-intensif commandes précédant le clone qu'ils vont avoir à courir à nouveau trop.

Un autre problème est que vous (ou quelqu'un que vous avez distribué votre Dockerfile) peut inattendue revenir à un bris de construire plus tard, lors de l'amont dépôt git mises à jour.

Deux oiseaux-une pierre d'approche tout en utilisant git clone est de le mettre sur un line1 avec une révision spécifique de caisse, par exemple:

RUN git clone https://github.com/example/example.git && cd example && git checkout 0123abcdef

Mise à jour de la révision de vérifier dans le Dockerfile va invalider le cache à la ligne et de provoquer le clone/caisse à exécuter.

Un possible inconvénient de cette approche est que vous devez avoir git installé dans votre conteneur.

EXÉCUTER curl ou AJOUTER un tag/commettre archive URL

Cela évite d'avoir à le faire git installé dans le conteneur de l'environnement, et peuvent être explicite lorsque le cache va casser (c'est à dire si la balise/révision est la partie de l'URL, l'URL changement buste le cache). Notez que si vous utilisez le Dockerfile AJOUTER une commande de copie à partir d'une URL distante, le fichier va être téléchargé à chaque fois que vous exécutez le construire et de le HTTP-tête Last-Modified sera également utilisé pour invalider le cache.

Vous pouvez le voir, cette approche utilisée dans le golang Dockerfile.

Submodules à l'intérieur de Dockerfile référentiel

Si vous gardez votre Dockerfile et Docker construire dans un autre référentiel à partir de votre code source, ou de votre Panneau de construire nécessite plusieurs source de dépôts, à l'aide de submodules (ou git sous-arbres) dans ce référentiel peut être un moyen d'obtenir votre source de repos dans votre contexte. Cela évite certains problèmes avec le Panneau de mise en cache et en amont de la mise à jour, comme vous le verrou en amont de la révision dans votre sous-module/sous-arbre de spécifications. Leur mise à jour va briser votre Débardeur cache de l'évolution de la construction de contexte.

Notez que ce soit uniquement les fichiers de votre Panneau de construire contexte, vous devez toujours utiliser AJOUTER des commandes dans votre Dockerfile copier ces chemins là où vous vous attendez à eux dans le conteneur.

Vous pouvez le voir, cette approche utilisée dans le ici

Dockerfile à l'intérieur de dépôt git

Ici, vous avez juste votre Dockerfile dans le même dépôt git parallèlement au code que vous voulez construire/test/déployer, il est automatiquement envoyé dans le cadre de la construction en contexte, donc vous pouvez par exemple AJOUTER . /projet de copier le contexte dans le récipient. L'avantage de ce système est que vous pouvez tester des modifications sans avoir à potentiellement commit/push pour les obtenir dans un test de docker construire; l'inconvénient est que chaque fois que vous modifiez tous les fichiers dans votre répertoire de travail, elle invalide le cache à la commande ADD. L'envoi de la construction d'une grande source/répertoire de données peut aussi être beaucoup de temps. Donc, si vous utilisez cette approche, vous pouvez également en faire une utilisation judicieuse de la .dockerignore fichier, y compris en faisant des choses comme ignorant tout dans votre .gitignore et peut-être le .répertoire git.

Volume de cartographie

Si vous utilisez le Panneau de configurer un dev/environnement de test que vous souhaitez partager entre une grande variété de source de repos sur votre machine hôte, le montage d'un répertoire de l'hôte comme un volume de données peut être une stratégie viable. Cela vous donne la possibilité de spécifier les répertoires que vous souhaitez inclure dans le panneau au moment de l'exécution, et évite les préoccupations au sujet de docker construire la mise en cache, mais rien de cela ne sera partagée par les autres utilisateurs de votre Dockerfile ou le conteneur de l'image.

--

Références:

• “Git stratégies pour Docker” Ryan Baumann - /etc (blog), 29 Juillet 2015

OriginalL'auteur Hemerson Varela