Il existe de nombreux modèles de construction de conteneurs. Un conteneur n'est qu'une version exécutable de sa propre image. Par conséquent, la façon de créer un conteneur est étroitement liée à la façon dont il démarre.
Certaines images de conteneur fonctionnent correctement sans privilèges spéciaux; d'autres nécessitent des privilèges root. De plus, la même image / conteneur peut combiner plusieurs modèles de construction et scénarios d'utilisation à la fois.
Ci-dessous, nous examinerons les cas d'utilisation de conteneurs les plus courants.
(Pour une introduction à la terminologie des conteneurs, voir la première
partie )
Scénarios d'utilisation des conteneurs
Conteneurs d'application
Les conteneurs d'application sont le type de conteneur le plus courant. Les développeurs et les propriétaires d'applications les gèrent et ils contiennent eux-mêmes le code source, ainsi que des éléments comme MySQL, Apache, MongoDB et Node.js.
Un vaste écosystème de conteneurs d'application se forme. Des projets comme Software Collections fournissent des images de conteneurs d'applications sécurisées et prises en charge pour Red Hat Enterprise Linux. Dans le même temps, les membres de la communauté Red Hat développent et prennent en charge des conteneurs d'applications innovants.
Chez Red Hat, nous pensons que les conteneurs d'applications n'ont généralement pas besoin de privilèges spéciaux. Cependant, lors de la création d'environnements de production de conteneurs, d'autres conteneurs sont nécessaires.
Conteneurs de système d'exploitation
Le conteneur du système d'exploitation est un conteneur qui ressemble beaucoup plus à un système d'exploitation virtuel à part entière. Ces conteneurs utilisent également le noyau hôte, mais exécutent le système d'initialisation complet, ce qui leur permet d'exécuter facilement plusieurs processus. Des exemples de conteneurs de système d'exploitation sont LXC et LXD.
Les conteneurs du système d'exploitation peuvent, en principe, être émulés à l'aide de conteneurs docker / OCI, à condition que vous puissiez exécuter le système à l'intérieur afin que l'utilisateur final puisse installer le logiciel à l'intérieur de ces conteneurs de la manière habituelle et les perçoit comme un système d'exploitation virtuel à part entière.
yum install mysql systemctl enable mysql
Cela simplifie considérablement la conteneurisation des applications existantes. Red Hat travaille dur pour simplifier les conteneurs du système d'exploitation en permettant à systemd de s'exécuter à l'intérieur du conteneur et d'utiliser le démon usiné. Bien que de nombreux clients ne soient pas encore prêts pour l'architecture de microservices, la transition vers un modèle de livraison de logiciels conteneurisé basé sur des images de conteneurs peut encore leur offrir de nombreux avantages.
Conteneurs pour animaux
Bien que Red Hat recommande fortement, promeuve et supporte l'utilisation de
modèles basés sur le
cloud lors du développement de nouvelles applications, nous sommes bien conscients que toutes les applications existantes ne seront pas réécrites de cette manière. En particulier, parce que beaucoup d'entre eux sont si uniques et inimitables que, par rapport aux applications standard, ils ressemblent à des animaux domestiques (
Pets ) contre un troupeau de vaches. C'est pour de telles applications que des
conteneurs spéciaux pour
animaux de compagnie sont conçus.
Les conteneurs pour animaux de compagnie combinent la portabilité et la commodité d'une infrastructure de conteneurs basée sur des serveurs de registre, des images de conteneurs et des hôtes de conteneurs avec la flexibilité d'un environnement informatique traditionnel, implémenté dans un conteneur séparé. L'idée ici est de simplifier la conteneurisation des applications existantes en raison de la même
capacité à utiliser systemd à l'intérieur du conteneur pour utiliser les outils d'automatisation existants, les installations logicielles et d'autres outils pour créer facilement des images prêtes pour le lancement.
Conteneurs Super Privilège
Lors de la construction d'une infrastructure de conteneurs basée sur des hôtes de conteneurs dédiés tels que Red Hat Enterprise Linux Atomic Host, les administrateurs système doivent toujours gérer. Et les
conteneurs Super Privileged (SPC) s'avèrent très utiles dans de tels environnements distribués, que ce soit Kubernetes, OpenShift ou même des conteneurs autonomes. Les SPC peuvent même charger des modules de noyau spécialisés, tels que systemtap.
Dans l'infrastructure créée pour exécuter les conteneurs, les administrateurs auront probablement besoin de conteneurs SPC pour effectuer des tâches telles que la surveillance, la sauvegarde, etc. Il est important de comprendre que, puisque les conteneurs SPC sont généralement beaucoup plus connectés au noyau hôte, les administrateurs doivent Portez une attention particulière aux problèmes de fiabilité et de normalisation lors du choix des systèmes d'exploitation hôtes, en particulier dans les grands environnements en cluster et distribués qui rendent le dépannage difficile. De plus, les administrateurs doivent s'assurer que l'espace utilisateur dans le SPC est compatible avec le noyau hôte.
Outils et logiciels système
Les distributions Linux ont toujours fourni à l'utilisateur des logiciels système, tels que Rsyslogd, SSSD, sadc, etc. En particulier, Red Hat propose des éléments tels que des conteneurs prêts à l'emploi tels que les outils de virtualisation Red Hat, rsyslog, sssd et sadc.
Architecture de conteneur
Alors que la livraison de logiciels conteneurisés prend de l'ampleur, de nouveaux modèles de conception de conteneurs apparaissent. Dans cette section, nous parlerons de certains d'entre eux.
La façon dont le conteneur est enregistré sur le disque (en d'autres termes, le format de l'image) peut grandement affecter la façon dont il démarre. Par exemple, un conteneur conçu pour exécuter sssd doit avoir des privilèges spéciaux à chaque démarrage, sinon il ne pourra pas faire son travail. Ci-dessous, nous examinons brièvement les principaux modèles qui sont actuellement en cours de formation active.
Images d'application
C'est avec ces images que les utilisateurs finaux traitent. Les scénarios d'utilisation de ces images vont du SGBD et des serveurs Web aux applications individuelles et aux bus de service. Ces images peuvent être créées en interne par l'organisation ou fournies par des éditeurs de logiciels. Par conséquent, les utilisateurs finaux se rapportent souvent au contenu de ces conteneurs autonomes avec prudence et scrupule. De plus, bien qu'il s'agisse de l'option la plus simple pour l'utilisateur final de conteneurs, les images autonomes sont beaucoup plus difficiles à concevoir, à construire et à corriger.
Images de base
Une image de base est l'un des types d'images les plus simples. Cependant, les gens peuvent désigner ce terme avec une variété de choses, par exemple, un assemblage d'entreprise standard ou même une image d'application. Bien que, à proprement parler, ce ne soient pas des images basiques, mais intermédiaires.
Il suffit donc de préciser que l'image de base est une image qui n'a pas de couche parente. Les images de base contiennent généralement une copie propre du système d'exploitation, ainsi que les outils nécessaires pour installer des packages logiciels ou mettre à jour l'image ultérieurement (yum, rpm, apt-get, dnf, microdnf). Les images de base peuvent être collectées manuellement par l'utilisateur final, mais dans la pratique, elles sont généralement créées et publiées par des communautés de développement (par exemple Debian, Fedora ou CentOS) ou des fournisseurs de logiciels (par exemple Red Hat). L'origine de l'image de base est critique pour la sécurité. En résumé, le but principal et unique de l'image de base est de fournir une base sur la base de laquelle vous pouvez créer vos images enfants. Lors de l'utilisation de dockerfile, la sélection de l'image de base sous-jacente se fait explicitement:
FROM registry.access.redhat.com/rhel7-atomic
Images de générateur
Il s'agit d'un type d'image spécial sur la base duquel les images enfants des conteneurs d'application sont ensuite créées. Les images du générateur incluent tout sauf le code source écrit par les développeurs, à savoir les bibliothèques de système d'exploitation, les runtimes de langage, les middlewares et les outils
source-à-image .
Au démarrage, l'image du générateur extrait le code source de l'application écrit par les développeurs et crée une image enfant du conteneur d'application prête à être lancée, qui peut ensuite être exécutée dans un environnement de développement ou de production.
Disons que les développeurs ont écrit le code PHP de l'application et veulent l'exécuter dans le conteneur. Pour ce faire, ils prennent simplement l'image de générateur de PHP et lui transmettent l'URL sur le site Web GitHub, où leur code est stocké. En conséquence, les développeurs préparent une image de conteneur d'application pour le lancement qui contient Red Hat Enterprise Linux, PHP des collections de logiciels et, bien sûr, le code PHP source de l'application.
Les images Builder sont un moyen puissant, simple et rapide de transformer le code source en un conteneur construit sur la base de composants fiables.
Composants conteneurisés
Un conteneur est principalement destiné à être déployé en tant que composant d'un système logiciel plus important, et non en tant qu'unité autonome. Et il y a deux raisons principales à cela.
Premièrement, l'architecture de microservices augmente la liberté de choix des composants et conduit également à une augmentation du nombre de composants à partir desquels les applications et les systèmes logiciels sont composés. Les composants conteneurisés aident à déployer ces systèmes plus rapidement et plus facilement. Par exemple, les images de conteneurs permettent de résoudre facilement le problème de la coexistence de différentes versions du même composant. Et des outils de définition d'applications tels que les
déploiements yaml / json dans Kubernetes / OpenShift,
Open Service Broker ,
OpenShift Templates et
Helm Charts permettent de créer des descriptions d'applications de haut niveau.
Deuxièmement, loin d'être toujours, toutes les parties d'un système logiciel peuvent être facilement conteneurisées. Par conséquent, il est logique de n'effectuer la conteneurisation que pour les composants individuels les plus appropriés ou les plus prometteurs en termes de résultats. Dans les applications multiservices, une partie des services peut être déployée en tant que conteneurs, et l'autre en utilisant des méthodes traditionnelles, comme RPM ou des scripts d'installation, voir conteneurs pour animaux de compagnie. De plus, certains composants peuvent être difficiles à conteneuriser, car ils sont mal divisés en composants, ou sont liés à du matériel spécial, ou utilisent des appels d'API de noyau de bas niveau, etc. Par conséquent, dans un grand système logiciel, très probablement il y aura des pièces qui peuvent être conteneurisées et des pièces qui ne peuvent pas être conteneurisées. Les composants conteneurisés sont ce qui peut être conteneurisé et déjà conteneurisé. Les composants conteneurisés sont conçus pour s'exécuter dans le cadre d'une application spécifique, et non par eux-mêmes. Il est important de comprendre qu'ils ne sont pas destinés à un fonctionnement autonome, car ils ne sont utiles que dans le cadre d'un système logiciel plus vaste et, isolés de celui-ci, ils sont pratiquement inutiles.
Par exemple, dans OpenShift Enterprise 3.0, la plupart du code principal a été déployé à l'aide de RPM, mais après son installation, les administrateurs ont déployé le routeur et le registre en tant que conteneurs. OpenShift 3.1 a introduit l'option de déploiement conteneurisé pour master, node, openvswitch et etcd, et une fois installé, les administrateurs peuvent également déployer elasticsearch, fluentd et kibana en tant que conteneurs.
Bien que le programme d'installation d'OpenShift continue d'apporter des modifications au système de fichiers du serveur, tous les principaux composants logiciels peuvent désormais être installés à l'aide d'images de conteneur. Par conséquent, ces composants conteneurisés, par exemple, une instance de l'image etcd incorporée dans OpenShift, ne devraient jamais - et ne seront jamais - utilisés pour stocker le code source de l'application avec laquelle vos clients travaillent, simplement parce que ces composants conteneurisés sont destinés à être exécutés dans le cadre de Plateforme de conteneurs OpenShift.
Dans les nouvelles versions d'OpenShift, la tendance à la conteneurisation des composants ne fait que s'intensifier, et d'autres développeurs de logiciels utilisent de plus en plus cette approche.
Images déployantes
L'image Deployer est un type spécial de conteneur qui, une fois lancé, déploie ou gère d'autres conteneurs. Deployer vous permet d'implémenter des schémas de déploiement complexes, par exemple, le lancement de conteneurs dans un certain ordre ou l'exécution de certaines actions au premier démarrage, comme la génération d'un schéma de données ou le remplissage initial de la base de données.
Par exemple, dans OpenShift, le modèle «type d'image / conteneur» est utilisé pour déployer les journaux et les métriques. Le déploiement de ces composants à l'aide d'images de déploiement permet aux ingénieurs d'OpenShift de contrôler l'ordre dans lequel les différents composants s'exécutent et de vérifier qu'ils fonctionnent correctement.
Images intermédiaires
Une image intermédiaire est une image d'un conteneur qui repose sur une image de base. Les assemblages du noyau, les middlewares et les exécutions de langage sont généralement implémentés en tant que couches supplémentaires au-dessus de l'image de base, puis spécifiés dans la directive FROM avec cette image de base. Les images intermédiaires ne sont généralement pas utilisées seules, mais comme éléments constitutifs de la création d'une image autonome.
Les différentes couches de l'image, en règle générale, sont engagées dans différents groupes de spécialistes. Par exemple, les administrateurs système sont responsables de la couche d'assemblage du noyau et les développeurs de la couche middleware. Dans le même temps, les couches sous-jacentes préparées par une équipe agissent comme une image intermédiaire pour ceux qui sont responsables des couches d'un niveau supérieur. Bien que ces images intermédiaires puissent parfois être utilisées de manière autonome, en particulier lors des tests.
Images polyvalentes (intermodales)
Les images de conteneurs polyvalents sont des images avec une architecture hybride. Par exemple, de nombreuses images des collections de logiciels Red Hat peuvent être utilisées de deux manières. Tout d'abord, en tant que conteneurs d'applications standard avec serveur Ruby on Rails et Apache complet. Deuxièmement, ils peuvent être utilisés comme images de générateur pour la plate-forme de conteneur OpenShift et basés sur eux des images enfants contenant Ruby on Rails, Apache et le code d'application que vous avez transmis au processus
source to image lors de la construction d'une telle image enfant.
Notez que les images polyvalentes gagnent en popularité car elles vous permettent de résoudre deux tâches fondamentalement différentes en utilisant la même image.
Conteneurs système
Lors du déploiement de logiciels système sous forme de conteneurs, ces derniers nécessitent souvent des privilèges de superutilisateur. Pour simplifier cette option de déploiement et garantir que ces conteneurs sont lancés avant le lancement de l'exécution du conteneur et du système d'orchestration, Red Hat a développé un modèle spécial appelé
conteneurs système . Ces conteneurs sont lancés pendant le processus de démarrage du système d'exploitation à l'aide de systemd et de la commande atomique, ce qui les rend indépendants de tout système d'exécution ou d'orchestration de conteneurs. Aujourd'hui, Red Hat propose des conteneurs système pour rsyslog, cockpit, etcd et flanneld et étendra cette liste à l'avenir.
Les conteneurs système simplifient considérablement l'ajout sélectif de ces services à Red Hat Enterprise Linux et Atomic Host.
Conclusion
Les conteneurs semblent être une chose assez simple pour le consommateur final, mais de nombreuses questions se posent lors de la création d'un environnement de production de conteneurs. Pour discuter fructueusement de l'architecture et des méthodes de construction de tels environnements, une terminologie uniforme est requise pour tous les participants. Plus vous vous plongerez dans la conception et la construction de tels environnements, plus les pièges se multiplieront. Enfin, nous n'en rappelons que quelques-uns.
Souvent, les gens ne voient pas la différence entre les termes "image de conteneur" et "référentiel", en particulier lorsqu'ils sont utilisés dans les commandes de docker. Mais si vous pouvez utiliser les commandes sans comprendre les différences, alors lorsque vous travaillez sur l'architecture des environnements de conteneurs, vous devez clairement comprendre que le référentiel est vraiment la structure de données principale.
Il est également assez facile de mal comprendre la différence entre les espaces de noms, les référentiels, les couches d'images et les balises. Chacune de ces choses a son but dans l'architecture de conteneur. Et bien que les fournisseurs et les utilisateurs les utilisent à diverses fins, ce ne sont que des outils.
Le but de cet article est de vous aider à comprendre la terminologie afin de pouvoir créer des architectures plus avancées. Par exemple, imaginez que vous venez d'être chargé de développer une infrastructure qui devrait délimiter la disponibilité des espaces de noms, des référentiels et, de plus, des balises et des couches en fonction des rôles et des règles métier. Et le dernier - rappelez-vous que la façon dont le conteneur est assemblé détermine en grande partie comment il démarre (orchestration, privilèges, etc.).