Construction de conteneurs optimisés pour Kubernetes

Docker crée un nouveau calque d'image chaque fois qu'il exécute une instructionRUN,COPY ouADD. Si vous générez à nouveau l'image, le moteur de génération vérifiera chaque instruction pour voir si elle contient un calque d'image mis en cache pour l'opération. S'il trouve une correspondance dans le cache, il utilise la couche d'image existante plutôt que d'exécuter à nouveau l'instruction et de reconstruire la couche.

Ce processus peut réduire considérablement les temps de construction, mais il est important de comprendre le mécanisme utilisé pour éviter les problèmes potentiels. Pour les instructions de copie de fichiers telles queCOPY etADD, Docker compare les sommes de contrôle des fichiers pour voir si l'opération doit être exécutée à nouveau. Pour les instructions deRUN, Docker vérifie si une couche d'image existante est mise en cache pour cette chaîne de commande particulière.

Bien que cela ne soit pas immédiatement évident, ce comportement peut entraîner des résultats inattendus si vous ne faites pas attention. Un exemple courant consiste à mettre à jour l'index de paquetage local et à installer les paquetages en deux étapes distinctes. Nous allons utiliser Ubuntu pour cet exemple, mais le principe de base s’applique également aux images de base pour d’autres distributions:

Exemple d'installation de package Dockerfile

Ici, l'index du package local est mis à jour dans une instructionRUN (apt -y update) et Nginx est installé dans une autre opération. Cela fonctionne sans problème lors de sa première utilisation. Toutefois, si le fichier Dockerfile est mis à jour ultérieurement pour installer un package supplémentaire, il peut y avoir des problèmes:

Exemple d'installation de package Dockerfile

Nous avons ajouté un deuxième package à la commande d'installation exécutée par la deuxième instruction. Si un laps de temps important s'est écoulé depuis la génération de l'image précédente, la nouvelle génération peut échouer. C'est parce que l'instruction de mise à jour de l'index du package (RUN apt -y update) a changénot, donc Docker réutilise la couche d'image associée à cette instruction. Puisque nous utilisons un ancien index de package, la version du packagephp-fpm que nous avons dans nos enregistrements locaux peut ne plus être dans les référentiels, ce qui entraîne une erreur lors de l'exécution de la deuxième instruction.

Pour éviter ce scénario, assurez-vous de consolider toutes les étapes interdépendantes en une seule instructionRUN afin que Docker réexécute toutes les commandes nécessaires lorsqu'un changement se produit:

Exemple d'installation de package Dockerfile

L'instruction met maintenant à jour le cache de package local chaque fois que la liste de packages est modifiée.

L'exemple précédent montre comment le comportement de mise en cache de Docker peut renverser les attentes, mais il y a d'autres choses à garder à l'esprit concernant la façon dont les instructions deRUN interagissent avec le système de couches de Docker. Comme mentionné précédemment, à la fin de chaque instructionRUN, Docker valide les modifications en tant que couche d'image supplémentaire. Afin de contrôler l'étendue des couches d'image générées, vous pouvez nettoyer les fichiers inutiles dans l'environnement final qui seront validés en prêtant attention aux artefacts introduits par les commandes que vous exécutez.

En général, le chaînage des commandes en une seule instructionRUN offre un contrôle considérable sur la couche qui sera écrite. Pour chaque commande, vous pouvez configurer l’état de la couche (apt -y update), exécuter la commande principale (apt install -y nginx php-fpm) et supprimer tous les artefacts inutiles pour nettoyer l’environnement avant sa validation. Par exemple, de nombreux Dockerfiles enchaînentrm -rf /var/lib/apt/lists/* à la fin des commandesapt, supprimant les index des packages téléchargés, pour réduire la taille de la couche finale:

Exemple d'installation de package Dockerfile

Pour réduire davantage la taille des couches d’image que vous créez, il peut être utile d’essayer de limiter d’autres effets secondaires non désirés des commandes que vous exécutez. Par exemple, en plus des packages explicitement déclarés,apt installe également les packages «recommandés» par défaut. Vous pouvez inclure--no-install-recommends dans vos commandesapt pour supprimer ce comportement. Vous devrez peut-être expérimenter pour savoir si vous comptez sur l’une des fonctionnalités fournies par les packages recommandés.

Nous avons utilisé les commandes de gestion de paquets dans cette section à titre d'exemple, mais ces mêmes principes s'appliquent à d'autres scénarios. L’idée générale est de créer les conditions préalables, d’exécuter la commande minimale viable, puis de nettoyer les artefacts inutiles en une seule commandeRUN afin de réduire la surcharge de la couche que vous produisez.

Multi-stage builds ont été introduits dans Docker 17.05, permettant aux développeurs de contrôler plus étroitement les images d'exécution finales qu'ils produisent. Les versions en plusieurs étapes vous permettent de diviser votre fichier Dockerfile en plusieurs sections représentant des étapes distinctes, chacune avec une instructionFROM pour spécifier des images parentes distinctes.

Les sections précédentes définissent des images pouvant être utilisées pour créer votre application et préparer les actifs. Ceux-ci contiennent souvent des outils de construction et des fichiers de développement nécessaires à la production de l'application, mais non nécessaires à son exécution. Chaque étape ultérieure définie dans le fichier aura accès aux artefacts produits par les étapes précédentes.

La dernière instructionFROM définit l'image qui sera utilisée pour exécuter l'application. En règle générale, il s'agit d'une image réduite qui installe uniquement les exigences d'exécution requises, puis copie les artefacts d'application générés par les étapes précédentes.

Ce système vous permet de moins vous soucier de l'optimisation des instructionsRUN dans les étapes de construction puisque ces couches de conteneur ne seront pas présentes dans l'image d'exécution finale. Vous devez néanmoins faire attention à la manière dont les instructions interagissent avec la mise en cache des couches dans les étapes de construction, mais vos efforts peuvent viser à réduire le temps de construction plutôt que la taille de l'image finale. Il est toujours important de prêter attention aux instructions lors de la dernière étape pour réduire la taille de l’image, mais en séparant les différentes étapes de la construction de votre conteneur, il est plus facile d’obtenir des images rationalisées sans la complexité de Dockerfile.

En règle générale, il est recommandé de regrouper chaque fonctionnalité indépendante dans une image de conteneur distincte.

Cela diffère des stratégies courantes utilisées dans les environnements de machines virtuelles, dans lesquels les applications sont fréquemment regroupées dans la même image afin de réduire la taille et de minimiser les ressources nécessaires à l'exécution de la machine virtuelle. Les conteneurs étant des abstractions légères qui ne virtualisent pas l’ensemble de la pile de système d’exploitation, ce compromis est moins convaincant pour Kubernetes. Ainsi, même si une machine virtuelle de pile Web peut regrouper un serveur Web Nginx avec un serveur d’applications Gunicorn sur une seule machine pour desservir une application Django, dans Kubernetes, celles-ci peuvent être fractionnées dans des conteneurs distincts.

Concevoir des conteneurs qui implémentent une fonctionnalité distincte pour vos services offre de nombreux avantages. Chaque conteneur peut être développé indépendamment si des interfaces standard entre services sont établies. Par exemple, le conteneur Nginx pourrait potentiellement être utilisé pour créer un proxy vers un certain nombre de backends différents ou pourrait être utilisé comme équilibreur de charge si une configuration différente lui était attribuée.

Une fois déployée, chaque image de conteneur peut être mise à l’échelle de manière indépendante pour prendre en charge diverses contraintes de ressources et de charge. En divisant vos applications en plusieurs images de conteneur, vous gagnez en flexibilité en développement, organisation et déploiement.

Dans Kubernetes,pods est la plus petite unité pouvant être directement gérée par le plan de contrôle. Les pods consistent en un ou plusieurs conteneurs ainsi que des données de configuration supplémentaires pour indiquer à la plate-forme comment ces composants doivent être exécutés. Les conteneurs d'un pod sont toujours planifiés sur le même nœud de travail du cluster et le système redémarre automatiquement les conteneurs en échec. L'abstraction du pod est très utile, mais elle introduit une autre couche de décisions sur la manière de regrouper les composants de vos applications.

Comme les images de conteneur, les modules deviennent également moins flexibles lorsque trop de fonctionnalités sont regroupées dans une seule entité. Les pods eux-mêmes peuvent être mis à l'échelle à l'aide d'autres abstractions, mais les conteneurs qu'ils contiennent ne peuvent pas être gérés ou mis à l'échelle indépendamment. Par conséquent, pour continuer à utiliser notre exemple précédent, les conteneurs distincts Nginx et Gunicorn ne devraient probablement pas être regroupés dans un seul conteneur, de manière à pouvoir être contrôlés et déployés séparément.

Cependant, il existe des scénarios où il est logique de combiner des conteneurs fonctionnellement différents en une unité. En général, ces situations peuvent être classées comme des situations dans lesquelles un conteneur supplémentaire prend en charge ou améliore les fonctionnalités principales du conteneur principal ou l'aide à s'adapter à son environnement de déploiement. Certains modèles courants sont:

Comme vous l'avez peut-être remarqué, chacun de ces modèles prend en charge la stratégie de création d'images de conteneur principal génériques standard pouvant ensuite être déployées dans divers contextes et configurations. Les conteneurs secondaires aident à combler le fossé entre le conteneur principal et l'environnement de déploiement spécifique utilisé. Certains conteneurs side-car peuvent également être réutilisés pour adapter plusieurs conteneurs principaux aux mêmes conditions environnementales. Ces modèles tirent parti du système de fichiers partagé et de l'espace de noms réseau fourni par l'abstraction du pod, tout en permettant un développement indépendant et un déploiement flexible de conteneurs normalisés.

Des problèmes surviennent fréquemment lorsque les développeurs implémentent une fonctionnalité de gestion de services significative dans des conteneurs. Par exemple, l’exécution de services systemd dans le conteneur ou la démonisation de serveurs Web peuvent être considérées comme des pratiques recommandées dans un environnement informatique normal, mais elles sont souvent en conflit avec les hypothèses inhérentes au modèle de conteneur.

Les hôtes gèrent les événements du cycle de vie du conteneur en envoyant des signaux au processus fonctionnant en tant que PID (ID de processus) 1 à l'intérieur du conteneur. Le premier processus lancé est le PID 1, qui serait le système init dans les environnements informatiques traditionnels. Toutefois, comme l'hôte ne peut gérer que le PID 1, l'utilisation d'un système init traditionnel pour gérer les processus au sein du conteneur signifie parfois qu'il est impossible de contrôler l'application principale. L’hôte peut démarrer, arrêter ou tuer le système init interne, mais ne peut pas gérer directement l’application principale. Les signaux propagent parfois le comportement souhaité à l'application en cours d'exécution, mais cela ajoute de la complexité et n'est pas toujours nécessaire.

La plupart du temps, il est préférable de simplifier l'environnement d'exécution dans le conteneur afin que le PID 1 exécute l'application principale au premier plan. Dans les cas où plusieurs processus doivent être exécutés, le PID 1 est responsable de la gestion du cycle de vie des processus ultérieurs. Certaines applications, comme Apache, traitent cela de manière native en créant et en gérant des travailleurs qui gèrent les connexions. Pour d'autres applications, un script wrapper ou un système d'initialisation très simple commedumb-init ou le système d'initialisationtini inclus peut être utilisé dans certains cas. Quelle que soit l'implémentation que vous choisissez, le processus exécuté en tant que PID 1 dans le conteneur doit répondre de manière appropriée aux signauxTERM envoyés par Kubernetes pour se comporter comme prévu.

Les déploiements et services Kubernetes offrent une gestion du cycle de vie des processus de longue durée et un accès fiable et persistant aux applications, même lorsque les conteneurs sous-jacents doivent être redémarrés ou que les implémentations changent. En retirant la responsabilité de surveiller et de maintenir la santé du service hors du conteneur, vous pouvez utiliser les outils de la plate-forme pour gérer des charges de travail saines.

Pour que Kubernetes puisse gérer correctement les conteneurs, il doit comprendre si les applications qui y sont exécutées sont saines et capables d’effectuer un travail. Pour ce faire, les conteneurs peuvent implémenter des sondes d'activité: points de terminaison réseau ou commandes pouvant être utilisées pour signaler la santé de l'application. Kubernetes vérifiera périodiquement les sondes d'activité définies pour déterminer si le conteneur fonctionne comme prévu. Si le conteneur ne répond pas correctement, Kubernetes le redémarre pour tenter de rétablir la fonctionnalité.

Kubernetes fournit également des sondes de préparation, une construction similaire. Plutôt que d'indiquer si l'application contenue dans un conteneur est saine, les tests de disponibilité déterminent si l'application est prête à recevoir du trafic. Cela peut être utile lorsqu'une application conteneurisée a une routine d'initialisation qui doit être terminée avant d'être prête à recevoir des connexions. Kubernetes utilise des sondes de disponibilité pour déterminer s'il convient d'ajouter ou de supprimer un pod d'un service.

La définition de points de terminaison pour ces deux types de sondes peut aider Kubernetes à gérer efficacement vos conteneurs et éviter que des problèmes de cycle de vie des conteneurs affectent la disponibilité du service. Les mécanismes permettant de répondre à ces types de demandes d'intégrité doivent être intégrés à l'application elle-même et exposés dans la configuration de l'image Docker.