Il est clair qu'à l'heure actuelle, les passions autour de Red Hat ont une
orientation complètement différente et très globale, mais nous parlons toujours de la nôtre - locale et appliquée dans le monde des conteneurs. Depuis le début de cette année, Red Hat travaille activement sur un remplacement de Docker appelé
Podman (ou
libpod ). Pour une raison quelconque, ils n’ont toujours pas écrit sur ce projet sur le hub, mais c’est maintenant le moment idéal pour le connaître, en connaître les origines et réfléchir aux perspectives. C'est parti!
CRI-O comme trame de fond
Si vous regardez le monde moderne des conteneurs Linux, il est facile de voir que le sujet de l'article d'aujourd'hui n'est qu'une des étapes d'une stratégie à long terme de Red Hat. Le
projet CRI-O , que nous avons
écrit il y
a environ un an, en est une confirmation éclatante. En bref, CRI-O est une implémentation de Kubernetes CRI (Container Runtime Interface) pour lancer des runtimes de conteneurs compatibles avec la norme OCI (Open Container Initiative). Encore plus court, il s'agit d'un remplacement pour Docker en tant que runtime pour Kubernetes.
(Une initiative techniquement similaire pour les K8 de Docker Inc est cri-containerd , sur laquelle nous avons également écrit ; dans le même article, il y a une comparaison des performances de ces deux solutions.)L'histoire du CRI-O est telle que pendant que l'OCI préparait des normes pour les conteneurs (
spécification d'exécution et
spécification d' image )
[ce qui, cependant, s'est également produit avec la participation de Red Hat] , un nouveau projet appelé OCID a été créé et placé dans l'incubateur Kubernetes en RH ( Open Container Initiative Daemon), qui a ensuite été [demandé par OCI] renommé CRI-O. Son objectif était «la mise en œuvre d'une interface standard pour l'environnement d'exécution pour les conteneurs dans Kubernetes», et la promotion dans les «masses techniques» a été réalisée dans le cadre d'un projet plus large Red Hat pour créer un système d'exploitation pour les conteneurs -
Project Atomic .
Caps avec le logo CRI-O sur KubeCon + CloudNativeCon North America 2017Au cours des dernières années, CRI-O est passé à la
version 1.0 , a
reçu un support dans Minikube, et sa dernière réalisation peut être considérée comme l'
adoption de l' interface de conteneur par défaut dans
le projet Kubic , qui, plus particulièrement, est développée par la communauté compétitive (pour Red Hat) Distribution Linux - openSUSE.
Revenons au sujet de l'article: Podman faisait à l'origine partie du CRI-O.
L'apparence et l'essence de Podman
L'annonce officielle du projet Podman (le nom est l'abréviation de "pod manager") a
eu lieu en février de cette année:
«Podman (anciennement connu sous le nom de kpod) existe depuis l'été dernier. Au départ, il faisait partie du projet CRI-O . Nous avons alloué podman à un projet distinct - libpod . Nous voulions que Podman et CRI-O se développent à leur propre rythme. Les deux fonctionnent très bien individuellement (en tant qu'utilitaires indépendants) et ensemble. »
Pour cette raison, l'annonce elle-même était intitulée «
réintroduction» . Et la première version publique de Podman -
v0.2 - a eu lieu 2 semaines avant cette annonce. Alors, quelle est l'essence de Podman?
L'objectif de Podman est de fournir une interface de console pour lancer des conteneurs en dehors du système d'orchestration. Il est à noter que les conteneurs lancés peuvent être combinés en groupes spéciaux avec des espaces de noms communs, c'est-à-dire pods - ce concept est déjà bien connu grâce à Kubernetes. Le projet suit l'idéologie des commandes UNIX, où chaque utilitaire ne fait qu'une chose, mais c'est bien. Un autre détail important, que les développeurs soulignent sans relâche, a déjà été cité ci-dessus dans l'annonce: Podman peut être utilisé à la fois avec CRI-O et indépendamment.
En général, l'idée principale de Podman est de fournir aux utilisateurs de Kubernetes qui choisissent CRI-O comme environnement d'exécution de conteneur un analogue de l'interface de la console CLI Docker (pour interagir avec les conteneurs et les images s'exécutant en clusters):
«Podman implémente 38 des 40 commandes CLI Docker définies dans Docker 1.13 (au moment de l'annonce en février - environ trad. ), Mais certaines d'entre elles ne sont pas spécifiquement répétées. Par exemple, en ce qui concerne Docker Swarm - à la place, pour les pods / conteneurs qui doivent être orchestrés, nous suggérons d'utiliser Kubernetes. De plus, certaines commandes pour les plug-ins Docker, tels que les plug-ins de volume et pour le réseau, n'ont pas été implémentées. Une liste complète des commandes Podman et de leurs équivalents dans Docker se trouve sur la page de transfert d'utilisation Podman . »
Un fragment du tableau de comparaison pour les commandes Docker et Podman: la plupart sont les mêmes, mais il y a aussi des différencesCependant, derrière cette identité visible dans l'interface se trouve une différence fondamentale dans l'architecture: si la Docker CLI communique avec le démon Docker pour exécuter des commandes, alors Podman est un utilitaire autonome qui ne nécessite aucun démon pour son travail.
Au moins en raison de cette différence architecturale, il serait plus correct de comparer Podman non pas avec Docker en tant que tel, mais avec crictl, un utilitaire de console de
cri-tools (il est utilisé, en particulier, pour l'
intégration de containerd avec Kubernetes). Et il existe des différences fonctionnelles: Podman peut redémarrer les conteneurs arrêtés et fournit également la gestion des images de conteneurs. (Pour une comparaison plus détaillée, consultez le
blog OpenShift .)
Avec la
sortie de Fedora 28 Atomic Host (en mai), Podman est devenu l'outil de gestion de conteneur par défaut pour cette distribution Linux. Et ce n'est que récemment, en septembre, lors de la conférence Linux All Systems Go! à Berlin, Dan Walsh, le chef de l'équipe d'ingénierie des conteneurs Red Hat, a présenté Podman à un public encore plus large - un enregistrement de la performance peut être vu
ici (mais seulement la présentation
ici ).
Présentation de Podman à All Systems Go! 2018Notes techniques
La dernière version de Podman est la
v0.10.1.3 (datée du 18 octobre) et la dernière avec de nouvelles fonctionnalités est la
v0.10.1 (12 octobre), qui a incorporé plusieurs nouvelles équipes et des drapeaux supplémentaires.
Le code Podman est écrit en Go et est distribué sous la licence gratuite Apache 2.0. Des packages prêts à installer sont disponibles pour Fedora version 27 et ultérieure (il existe également
un guide d' installation pour Ubuntu). Parmi les composants dépendants pour que Podman fonctionne, il y a les utilitaires pour les conteneurs Linux tels que
runc et
conmon , ainsi que
les plugins réseau CNI .
Le démarrage du conteneur avec Podman et son utilisation sont similaires au scénario d'utilisation de
docker habituel:
$ sudo podman run -dt -e HTTPD_VAR_RUN=/var/run/httpd -e HTTPD_MAIN_CONF_D_PATH=/etc/httpd/conf.d \ -e HTTPD_MAIN_CONF_PATH=/etc/httpd/conf \ -e HTTPD_CONTAINER_SCRIPTS_PATH=/usr/share/container-scripts/httpd/ \ registry.fedoraproject.org/f27/httpd /usr/bin/run-httpd $ sudo podman ps ... $ sudo podman inspect -l ... $ sudo podman logs --latest 10.88.0.1 - - [07/Feb/2018:15:22:11 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:30 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" 10.88.0.1 - - [07/Feb/2018:15:22:31 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.55.1" "-" $ sudo podman top <container_id> UID PID PPID C STIME TTY TIME CMD 0 31873 31863 0 09:21 ? 00:00:00 nginx: master process nginx -g daemon off; 101 31889 31873 0 09:21 ? 00:00:00 nginx: worker process
Pour une introduction pratique à Podman, vous pouvez également utiliser le script en ligne Katacoda approprié: «
Conteneurs sans Docker - Lancement de conteneurs à l'aide de Podman et Libpod ».
Enfin, le projet
pypodman , qui est en cours de développement et propose une interface écrite en Python pour l'exécution à distance des commandes Podman, mérite une mention spéciale.
Pas seulement Podman: libpod et l'écosystème
Avec Podman, l'article a mentionné à plusieurs reprises le projet libpod. Quelle est la différence?
Si nous parlons du projet "complet" de Red Hat, il s'appelle en fait libpod et
est hébergé sur GitHub avec ce nom. Aujourd'hui, libpod se positionne comme «une bibliothèque pour les applications qui doivent travailler avec le concept de foyers de conteneurs, popularisé par Kubernetes». Et Podman lui-même est un utilitaire qui fait partie de la bibliothèque libpod.
Si nous revenons à une vision plus large des conteneurs, alors Red Hat a sa propre vision, qui prend vie avec un ensemble d'utilitaires pour toutes les occasions. La plupart d'entre eux sont concentrés dans des référentiels avec le nom parlant
github.com/containers , et cela à lui seul montre les ambitions évidentes de l'entreprise
(à propos, certains de ces projets étaient auparavant localisés sur github.com/projectatomic ) .
Les vues de Red Hat sur la normalisation et le développement de l'écosystème de conteneurs sont
exprimées directement dans le README du projet libpod:
Nous avons déjà écrit sur presque tous ces projets (runc, containers / image, containers / storage, CNI, conmon) dans
la revue CRI-O , cependant, un ajout important depuis lors était un utilitaire pour construire des images de conteneurs appelé
buildah . De plus, Red Hat a déjà des réponses toutes faites à certains autres besoins du monde moderne des conteneurs, comme
udica pour générer des profils de sécurité SELinux et
skopeo pour travailler avec des registres d'images distants.
Résumer
Tout comme Red Hat n'est pas seulement derrière sa plate-forme d'entreprise pour les conteneurs OpenShift, mais prend également une part active à la vie du projet Open Source sous-jacent Kubernetes, la société américaine réalise sa vision de l'infrastructure informatique moderne à un niveau plus fondamental - les conteneurs eux-mêmes, les ingénieurs DevOps et SRE sont tellement soucieux de leur orchestration. Podman et libpod sont des composants importants de l'ensemble de l'écosystème que Red Hat construit dans le monde des conteneurs à normes ouvertes. Si vous regardez ce qui se passe, alors l'accord avec IBM mentionné au tout début de l'article, qui est
présenté comme une initiative pour former un fournisseur leader de solutions dans le domaine des nuages hybrides, semble encore plus intéressant dans toute l'industrie ...
Enfin, je propose une petite enquête sur les connaissances des lecteurs de l'Habra sur le projet Podman avant la parution de cet article. Merci d'avoir participé!
PS
Lisez aussi dans notre blog: