Comprendre le contexte Docker Construire (Pourquoi utiliser Dockerignore) –

Le contexte de construction Docker fait référence aux fichiers et répertoires qui seront disponibles pour le moteur Docker lorsque vous exécutez docker build. Tout ce qui ne figurent pas dans le contexte de la construction ne sera pas accessible aux commandes de votre Dockerfile.

Vous devriez vérifier votre utilisation de docker build pour garder vos contextes de construction petit. L’inclusion accidentelle de fichiers inutiles peut entraîner un contexte de construction excessivement volumineux, ce qui entraînera des versions plus longues.

Quel est le contexte de construction?

Voici un simple docker build commander:

docker build . -t my-image:latest

Cela crée une image Docker en utilisant le Dockerfile trouvé dans votre répertoire de travail. L’image résultante sera marqué comme my-image:latest, Bien que ce détail est important de ne pas ce tutoriel.

Au sein de votre Dockerfile, vous utiliserez probablement COPY pour ajouter des fichiers et des dossiers à votre image:

FROM httpd:latest

COPY index.html /usr/local/apache2/htdocs/index.html
COPY css/ /usr/local/apache2/htdocs/css/

Cet exemple copie le index.html fichier et css répertoire dans votre conteneur. À première vue, il ressemble au COPY L’instruction fait simplement référence à un chemin résolu par rapport à votre répertoire de travail.

Ce n’est pas tout à fait le cas. COPY ne peut accéder qu’aux ressources disponibles dans le contexte de construction. Dans cet exemple, le contexte de construction est le répertoire de travail, de sorte que les fichiers et dossiers dans celui-ci sont disponibles. Par défaut, Docker utilise le contenu du répertoire passé à docker build comme contexte de construction.

Pourquoi le contexte de construction est-il utilisé?

Le contexte de construction est important car la CLI Docker et le moteur Docker peuvent ne pas s’exécuter sur la même machine. Quand tu cours docker build, la CLI envoie les fichiers et les dossiers à construire au moteur Docker. Cet ensemble de fichiers et de dossiers devient le contexte de construction.

De plus, tous les contextes de construction ne sont pas aussi simples que la réutilisation de votre répertoire de travail. Docker prend également en charge les URL de référentiel Git comme chemin d’accès donné à docker build. Dans ce cas, le contexte de construction devient le contenu du référentiel spécifié.

Le comportement par défaut «inclure tout» du contexte de construction convient à de nombreux petits référentiels. Les problèmes deviennent apparents une fois que vous ajoutez des fichiers à votre répertoire de travail qui ne sont pas utilisés par votre Dockerfile. Les ressources telles que les binaires prédéfinis, les fichiers de documentation et les bibliothèques de dépendances seront incluses dans le contexte de construction même si elles sont redondantes.

L’inclusion d’un trop grand nombre d’actifs dans le contexte de construction peut devenir une perte de performances. Vous copiez inutilement des fichiers qui ne seront jamais utilisés. Le ralentissement sera particulièrement évident si vous êtes connecté à un démon Docker distant ou si vous utilisez un disque dur mécanique lent. Vous verrez «envoyer le contexte de construction au démon Docker» dans votre shell pendant que la copie est terminée.

Docker essaie de minimiser la copie redondante par lui-même. Le backend utilisé build depuis Docker support kit d’installation 18,09 ajoutée pour les transferts supplémentaires. Cela signifie que Docker n’aura généralement besoin que de copier les fichiers ajoutés ou modifiés depuis votre dernière compilation. Il copiera toujours tout le lot sur la première version.

Exclusion de ressources du contexte de construction

Pour résoudre la copie inutile pour le bien, il faut dire Docker ce qu’il peut omettre dans le contexte de la construction. Le départ de Let en créant un Dockerfile:

FROM node:latest
WORKDIR /my-app
COPY package.json package.json
COPY package-lock.json package-lock.json
COPY src/ .
RUN npm install

Ce simple Dockerfile pourrait être utilisé par une application écrite en Node.js. Les programmes Node.js utilisent npm comme gestionnaire de paquets. Les packages sont installés sur un node_modules dossier. Quand tu cours npm install localement, lors du développement, les packages seront téléchargés sur le node_modules dossier dans votre répertoire de travail.

Le Dockerfile court npm install lui-même pour acquérir les dépendances. Cela garantit que l’image est entièrement autonome. Il n’y a pas besoin de copier dans le local node_modules dossier, comme il est pas utilisé par le Dockerfile.

Malgré cela, Docker inclura toujours le node_modules dossier dans le contexte de construction par défaut. Pour l’exclure, créez un .dockerignore fichier dans votre répertoire de travail. Ce fichier a une syntaxe similaire à celle de .gitignore.

node_modules/

Tous les chemins répertoriés dans .dockerignore sera exclu du contexte de construction. Vous devez vous assurer que .dockerignore est mis à jour avec les modifications apportées à la structure du système de fichiers de votre projet. Vous pouvez réduire considérablement le temps de copie du contexte de construction de Docker en vérifiant que seuls les chemins pertinents (ceux réellement utilisés par votre Dockerfile) Sont présents dans le contexte de la construction.

Dans le cas de notre exemple, le node_modules dossier pourrait inclure des milliers de fichiers si nous avons beaucoup de dépendances dans notre projet. les copier au démon Docker dans le cadre du contexte de construction pourrait prendre plusieurs secondes et serait une opération inutile. Le Dockerfile les ignore complètement, aller chercher ses propres dépendances via npm install au lieu.

Autres problèmes de contexte de construction

N’utilise pas .dockerignore peut introduire d’autres questions aussi. Un Dockerfile avec cette ligne est particulièrement problématique:

COPY . /my-app

Cela copiera tout dans votre répertoire de travail. Cela peut sembler une bonne idée jusqu’à ce que vous vous rendiez compte que votre .git l’histoire et tous les fichiers secrets vont aussi se retrouver à l’intérieur de votre récipient.

La copie d’un contexte de construction non filtré empêche également la mise en cache de la couche Docker de fonctionner efficacement. Comme quelque chose dans votre répertoire de travail changera probablement entre les versions, Docker devra exécuter le COPY instruction à chaque fois. Cela créerait une nouvelle couche de couches et nouvelles pour toutes les suivantes instructions, même si les actifs qui vous intéressent ont pas changé.

Compression du contexte de construction

Vous pouvez compresser le contexte de construction pour améliorer encore les performances de construction. Passe le --compress drapeau à docker build pour appliquer la compression gzip. La compression se produit avant que le contexte ne soit envoyé au démon Docker.

docker build . -t my-image:latest --compress

Cela peut améliorer les performances dans certains scénarios. La compression ajoute cependant ses propres frais généraux: votre système doit maintenant compresser le contexte et le démon Docker récepteur doit le décompresser. L’utilisation de la compression peut en fait être plus lente que la copie des fichiers d’origine, dans certaines circonstances. Expérimentez avec chacune de vos images pour évaluer si vous constatez une amélioration.

Conclusion

Le contexte de construction Docker définit les fichiers qui seront disponibles pour la copie dans votre Dockerfile. Le contexte de construction est copié sur le démon Docker avant la construction commence.

Construire des contextes par défaut d’inclure le contenu du répertoire ou Git référentiel vous passé à docker build. Vous pouvez omettre des éléments du contexte de construction en créant un .dockerignore déposer. Cela augmente l’efficacité en réduisant la quantité de données redondantes transmises au démon Docker.