Optimiser pour construire dans le cloud

Docker Build Cloud exécute vos builds à distance, et non sur la machine où vous invoquez le build. Cela signifie que les transferts de fichiers entre le client et le constructeur se font sur le réseau.

Le transfert de fichiers sur le réseau a une latence plus élevée et une bande passante plus faible que les transferts locaux. Docker Build Cloud a plusieurs fonctionnalités pour atténuer cela :

• Il utilise des volumes de stockage attachés pour le cache de build, ce qui rend la lecture et l'écriture du cache très rapides.
• Le chargement des résultats de build vers le client ne tire que les couches qui ont été modifiées par rapport aux builds précédents.

Malgré ces optimisations, construire à distance peut encore donner des transferts de contexte lents et des chargements d'images lents, pour de gros projets ou si la connexion réseau est lente. Voici quelques façons d'optimiser vos builds pour rendre le transfert plus efficace :

• Fichiers Dockerignore
• Images de base allégées
• Builds multi-étapes
• Récupérer des fichiers distants dans le build
• Outils multi-threads

Pour plus d'informations sur comment optimiser vos builds, voir Bonnes pratiques de construction.

Fichiers Dockerignore

En utilisant un fichier .dockerignore, vous pouvez être explicite sur quels fichiers locaux vous ne voulez pas inclure dans le contexte de build. Les fichiers attrapés par les motifs glob que vous spécifiez dans votre fichier d'ignorance ne sont pas transférés au constructeur distant.

Quelques exemples de choses que vous pourriez vouloir ajouter à votre fichier .dockerignore sont :

• .git — ignorer l'envoi de l'historique de contrôle de version dans le contexte de build. Notez que cela signifie que vous ne pourrez pas exécuter de commandes Git dans vos étapes de build, comme git rev-parse.
• Répertoires contenant des artefacts de build, comme des binaires. Artefacts de build créés localement pendant le développement.
• Répertoires vendor pour les gestionnaires de paquets, comme node_modules.

En général, le contenu de votre fichier .dockerignore devrait être similaire à ce que vous avez dans votre .gitignore.

Images de base allégées

Sélectionner des images plus petites pour vos instructions FROM dans votre Dockerfile peut aider à réduire la taille de l'image finale. L'image Alpine est un bon exemple d'image Docker minimale qui fournit tous les utilitaires OS que vous attendriez d'un conteneur Linux.

Il y a aussi l'image spéciale scratch, qui ne contient rien du tout. Utile pour créer des images de binaires liés statiquement, par exemple.

Builds multi-étapes

Les builds multi-étapes peuvent faire que votre build s'exécute plus rapidement, parce que les étapes peuvent s'exécuter en parallèle. Cela peut aussi rendre votre résultat final plus petit. Écrivez votre Dockerfile de telle manière que l'étape finale d'exécution utilise l'image de base la plus petite possible, avec seulement les ressources que votre programme nécessite pour s'exécuter.

Il est aussi possible de copier des ressources d'autres images ou étapes, en utilisant l'instruction Dockerfile COPY --from. Cette technique peut réduire le nombre de couches, et la taille de ces couches, dans l'étape finale.

Récupérer des fichiers distants dans le build

Quand c'est possible, vous devriez récupérer des fichiers d'un emplacement distant dans le build, plutôt que de regrouper les fichiers dans le contexte de build. Télécharger des fichiers sur le serveur Docker Build Cloud directement est mieux, parce que cela sera probablement plus rapide que de transférer les fichiers avec le contexte de build.

Vous pouvez récupérer des fichiers distants pendant le build en utilisant l' instruction Dockerfile ADD, ou dans vos instructions RUN avec des outils comme wget et rsync.

Outils multi-threads

Certains outils que vous utilisez dans vos instructions de build peuvent ne pas utiliser plusieurs cœurs par défaut. Un tel exemple est make qui utilise un seul thread par défaut, sauf si vous spécifiez l'option make --jobs=<n>. Pour les étapes de build impliquant de tels outils, essayez de vérifier si vous pouvez optimiser l'exécution avec la parallélisation.