Révision: Red Hat fait Docker à la dure

Le projet Atomic de Red Hat est une manière avisée d'exécuter des conteneurs Linux. Le système d'exploitation Atomic Host est livré avec Docker (conteneurs), Flannel (mise en réseau), OSTree (gestion d'hôte), Etcd (magasin de clés-valeurs distribué) et Kubernetes (orchestration) déjà installés. 

Kubernetes est l'un des deux systèmes d'orchestration de conteneurs les plus populaires, l'autre étant Docker Swarm. Vous pourriez l'appeler «à pleine puissance», mais cela entraîne une complexité et des frais administratifs supplémentaires.

Kubernetes coordonne la création de «pods» sur plusieurs hôtes Atomic. Les pods sont des groupes de conteneurs Docker qui séparent logiquement les services dans une application. Les conteneurs d'un pod partagent une adresse IP et communiquent via localhost.

Flannel fournit un réseau de superposition pour les hôtes Atomic, permettant à chaque pod du cluster de communiquer avec tout autre pod ou service au sein du cluster. Ce réseau de superposition est utilisé uniquement pour la mise en réseau de conteneurs. Un service proxy Kubernetes permet d'accéder à l'espace IP hôte.

Etcd est utilisé pour stocker les configurations pour Kubernetes et Flannel sur tous les hôtes du cluster.

Les clusters de conteneurs atomiques font certaines hypothèses en raison de Kubernetes. Les administrateurs n'ont vraiment pas le choix avec Atomic: utilisez Kubernetes ou trouvez un autre OS de conteneur. 

Si vous êtes irrité par la «conception par convention» et que vous voulez plus de liberté et de flexibilité dans un hôte de conteneur, vous pouvez envisager RancherOS ou VMware Photon. Si votre objectif ultime est d'exécuter de nombreux conteneurs sur de nombreux hôtes, alors Atomic Host, Kubernetes et vos amis peuvent être exactement ce dont vous avez besoin.  

Administration du système Atomic Host

Atomic Host utilise sa propre version de la dockercommande, atomicbien que la vraie  dockercommande soit disponible dans / bin / docker. Son emplacement dans / bin fait allusion à certaines des retouches qui ont été apportées à RHEL / CentOS / Fedora pour rendre le système d'exploitation Atomic spécialement conçu pour les conteneurs. Normalement, seuls les binaires système importants résident dans / bin.

Vous gérez Atomic Host via deux sous-systèmes. RPM-OSTree gère le déploiement et les mises à jour du système hôte, tandis que Docker gère le provisionnement des conteneurs pour l'exécution des services et des applications. Ces deux sous-systèmes sont gérés par la atomiccommande située dans / usr / bin /.

RPM-OSTree rend le système de fichiers Atomic immuable; c'est-à-dire que le système de fichiers est en lecture seule, sauf pour / var et / etc. Le répertoire / var / lib / docker est l'endroit où tous les fichiers et images liés à Docker sont stockés, tandis que / etc contient tous les fichiers de configuration. Comme nous le verrons plus tard, cela simplifie et sécurise les mises à niveau et les rétrogradations de l'hôte, une exigence essentielle lors de la gestion de potentiellement des milliers d'hôtes de conteneurs dans un cluster.

La atomiccommande est destinée à être un point d'entrée unique vers le sous-système de conteneur - une commande parapluie pour tout ce qui concerne le conteneur, y compris les opérations de l'hôte. La atomiccommande ressemble et ressemble beaucoup à la dockercommande, mais résout un problème fondamental partagé par tous les systèmes d'exploitation hôtes du conteneur: démarrer un service au niveau du système dans un conteneur au moment du démarrage, de manière fiable et transparente, à l'aide de fichiers d'unité Systemd.

Dans Atomic, cela se fait avec ce qu'on appelle un conteneur super-privilégié, qui a la capacité de voir et de manipuler l'hôte lui-même. Ainsi, bien que cela atomicressemble à une commande Docker standard, elle comble les lacunes entre Docker et RPM-OSTree - configuration des scripts d'installation, configuration des services, attribution des privilèges appropriés, etc. - pour permettre le déploiement fiable d'une application basée sur des conteneurs .

En termes simples, la  atomic commande vous permet de manipuler l'infrastructure hôte sous-jacente (groupes de contrôle, espaces de noms, SELinux, etc.) pour exécuter vos applications. Par exemple, supposons que vous ayez créé une application de conteneur Network Time Protocol (ntpd) qui nécessite la capacité SYS_TIME afin de modifier l'heure système de l'hôte. Vous pouvez configurer cela en ajoutant des métadonnées à votre image de conteneur à l'aide de la commande:

LABEL RUN /usr/bin/docker run -d —cap-add=SYS_TYPE ntpd

Ensuite, lorsque vous exécutez le conteneur ( atomic run ntpd), le système lira ces métadonnées et configurera la capacité SYS_TIME et d'autres ressources pour le conteneur. 

Installation et configuration de l'hôte atomique

L'installation a été difficile, principalement parce que j'ai trouvé la documentation désorganisée et déroutante. La documentation suppose un haut niveau de connaissance de l'écosystème Red Hat que tous les lecteurs n'auront pas. Après quelques faux départs, j'ai finalement réussi à installer à partir d'un ISO bare-metal. La prise en charge de l'installation de machines virtuelles avec autre chose que virt-manager est pénible. Atomic Host n'est certainement pas compatible avec Windows ou Mac à cet égard.

Pour toute personne familiarisée avec une installation CentOS, la procédure sans système d'exploitation sera facile. Les seules différences notables sont dans la disposition du disque, avec un espace réservé automatiquement pour Docker et les conteneurs, ainsi que la pléthore de montages pour SELinux, cgroups, etc. qui accompagnent l'installation d'un OS de conteneur.

Utiliser Kubernetes pour gérer des conteneurs dans un cluster est beaucoup plus compliqué que d'exécuter Docker sur un seul hôte, mais une plus grande complexité s'accompagne d'une fiabilité et d'une capacité accrues. Avec Kubernetes, vous gagnez également le confort de savoir que le système a été testé dans des environnements de production à grande échelle (chez Google).

Il n'y a pas de moyen simple de configurer un maître Kubernetes. La documentation est répartie sur divers sites Web de projet et, souvent, les documents sont consultés sur d'autres sites pour plus de détails, alors soyez prêt à passer beaucoup de temps à lire, à rechercher des documents et à expérimenter. L'effort total consiste à modifier une douzaine de fichiers répartis dans quelques répertoires / etc. Bien sûr, l'astuce est de savoir quelles sont ces modifications. Kubernetes n'est pas vraiment fait pour l'expérimentation occasionnelle avec des conteneurs. Il s'agit de produits de production lourds.

Après avoir configuré le maître avec Kubernetes, des certificats, des services et un réseau de superposition Flannel, puis installé Flannel (flanneld), Kubernetes (kubelet) et Etcd sur chaque nœud, j'ai enfin lancé un cluster de conteneurs à cinq nœuds. Malheureusement, cela a consommé pas mal de mémoire et je n'ai pas pu trouver un moyen de tester en utilisant un seul nœud, comme je l'ai fait lors du test de RancherOS et VMware Photon.

À ce stade, Kubernetes peut être utilisé pour lancer et gérer des pods, ces groupes de conteneurs qui encapsulent des services et des applications.

Stockage et mise en réseau de l'hôte atomique

Comme la plupart des systèmes d'exploitation hôtes de conteneurs, Atomic Host adopte une approche minimaliste, avec juste assez d'espace disque inclus pour exécuter l'hôte. Cela ne laisse pas grand-chose pour les nombreux conteneurs Docker qu'un cluster typique exécutera, vous devrez donc attacher un stockage externe à l'hôte pour cela.

Dans Docker, les images et les fichiers associés sont généralement stockés dans / var / lib / docker, et sur la plupart des systèmes d'exploitation standard, vous monteriez simplement un périphérique à ce stade du système de fichiers pour ajouter du stockage. Cependant, Atomic utilise des volumes directs LVM (Linux Volume Manager) via le back-end de Device Mapper pour stocker les images et les métadonnées Docker: / dev / atomicos / docker-data et / dev / atomicos / docker-meta. Cela signifie que vous devrez en savoir plus sur LVM et les volumes afin d'ajouter de l'espace à un hôte Atomic.

Le point de départ de la gestion du stockage dans Atomic est le script de configuration, / etc / sysconfig / docker-storage-setup. Atomic Host a un pool de stockage pour le stockage Docker (et hôte), donc l'astuce ici est d'ajouter un nouveau périphérique dans ce pool. Vous ferez cela en ajoutant à la liste des périphériques dans le fichier, comme ceci:

DEVS="/dev/vdb /dev/vdc"

Ensuite, vous exécutez le script d'assistance, / usr / bin / docker-storage-setup. Si tout se passe bien, vos disques ont été ajoutés au pool et votre hôte Atomic a de l'espace pour Docker. Je suppose que LVM sera géré en production avec des outils d'administration existants, ou avec des scripts tels que Ansible / Salt / Chef / Puppet, donc apparaîtra probablement plus standard pour les administrateurs travaillant dans de grands environnements de centre de données.

Project Atomic utilise Flannel pour fournir un réseau de superposition de conteneurs via Etcd. Vous configurez cela en poussant un fichier de configuration JSON dans le magasin de valeurs-clés Etcd, à l'aide d'outils tels que Curl. Pour configurer un sous-réseau pour les conteneurs, nous pouvons créer un fichier JSON qui ressemble à ceci:

   "Réseau": "172.16.0.0/12",

   «SubnetLen»: 24,

   "Backend": {

      "Type": "vxlan"

   }

}

Et pour obtenir cela dans le maître Etcd, nous le poussons dans la clé de configuration réseau:

curl -L //localhost:2379/v2/keys/atomic.io/config -XPUT --data-urlencode [email protected]

Bien que quelque peu encombrant, il est gérable. J'aimerais voir un wrapper pour ces commandes de configuration qui le rendent plus intuitif pour l'administrateur Unix, peut - être quelque chose comme atomic ifconfig…, atomic route…, etc.

Il y a une autre différence qui mérite d'être soulignée: les concepts Kubernetes de pods et de services. Une nacelle est un groupe de conteneurs qui sont relativement étroitement couplés. Tous les conteneurs d'un pod partagent le même hôte et la même adresse IP, et ils vivent ou meurent tous ensemble. Vous spécifiez le nombre d'instances d'un pod que vous souhaitez exécuter et Kubernetes exécute la commande. Si une instance s'arrête ou échoue, Kubernetes en lance une autre pour correspondre à l'état souhaité.

Un service Kubernetes est une abstraction qui définit un ensemble logique de pods et une stratégie permettant d'y accéder. Cela donne à un (micro) service un nom et une adresse uniques et stables tout au long du cycle de vie du pod. Il y a beaucoup plus à cela, mais cela devrait vous aider à comprendre pourquoi vous avez besoin d'un composant séparé pour gérer le réseau. Dans Atomic Host, ce composant est Flannel.

Mises à niveau et rétrogradations de l'hôte atomique

Atomic Host utilise un gestionnaire de packages appelé RPM-OSTree, qui combine les fonctionnalités des traditionnels RPM et OSTree. RPM-OSTree nous donne la possibilité de rouler en avant et en arrière de manière fiable, car le processus est «atomique» (dans le sens du terme base de données). RPM-OSTree fournit des transactions fiables pour les mises à jour, ce qui signifie qu'il est peu probable qu'il endommage le système d'exploitation. Comme les commandes pour les conteneurs, les mises à niveau et les restaurations d'hôte sont effectuées par le atomicsystème de gestion:

atomic host upgrade

atomic host rollback

Notez que je n'ai pas testé de restauration, car je n'avais rien sur quoi revenir en arrière.

Red Hat Atomic Host est le mieux adapté aux organisations avec un investissement important dans les compétences et l'infrastructure Red Hat. Les entreprises qui partent d'un angle différent peuvent envisager d'autres options. L'inclusion de Kubernetes et l'histoire de Red Hat dans les grands environnements de production signifient qu'Atomic Host sera presque un «drop-in» pour exécuter des charges de travail conteneurisées dans les entreprises. Mais je ne vois pas les développeurs la choisir comme plate-forme Docker de choix.