Qu’est-ce que Podman ? Le successeur de Docker ?

Qu’est-ce que Podman ?

Podman est un moteur de conteneur développé par RedHat, et oui, si vous avez associé le moteur de conteneur à Docker, vous êtes correcte.

Podman veut être l’alternative au moteur de conteneur Docker bien connu, mais après savoir qu’est-ce que Podman nous nous posons la question : Que nous offre RedHat avec Podman ? Pourquoi devrions-nous migrer vers Podman ? Podman est-il le remplaçant de Docker ou juste un autre concurrent ? Il est tôt pour répondre à toutes ces questions, mais dans cet article, nous essaierons de décrire quelles sont les astuces dont Podman dispose pour détrôner l’actuel roi des conteneurs.

Facilité d’utilisation

En me documentant pour écrire cet article, je suis tombé sur une présentation de l’ingénieur de RedHat Dan Walsh, qui a commencé par expliquer comment remplacer Docker par Podman et comment effectuer cette migration en une série d’étapes.

La première consiste à exécuter :

dnf install -y podman

Then execute:

alias docker=podman

Et il termine sa présentation en disant : « Avez-vous des questions ? »

C’est évidemment une blague, mais l’idée est de montrer que la migration vers Podman est très simple, puisque les ingénieurs de RedHat ont accordé une attention particulière à l’utilisation de la même nomenclature lors de l’exécution des commandes Podman. Donc, si vous êtes un utilisateur de Docker, vous connaissez déjà la plupart des commandes de Podman. Donc, effectivement, c’est aussi simple que, au lieu d’exécuter docker run, exécuter podman run, et le résultat sera exactement le même.

Dan se réfère également à un fil de Twitter pour représenter la facilité de migration, dans lequel un autre ingénieur RedHat a utilisé sa « méthode de migration » en utilisant les deux commandes décrites ci-dessus et, au bout de quelques mois, il l’avait complètement oublié puisqu’il a continué à utiliser les mêmes commandes que vous utilisez dans Docker depuis des années.

Pas plus de gros démons (#nobigfatdaemons)

Il s’agit d’une référence au service Docker (daemon en anglais). Comme nous le savons, Docker est un outil merveilleux, avec des avantages et des options infinis. Il est capable de gérer tout ce qui concerne nos conteneurs : réseau, stockage, exécution, motorisation, etc., et tout cela est géré par le même service Docker, ce qui peut apporter quelques inconvénients, car plus nous utilisons de conteneurs, plus le service Docker devient complexe.

C’est pourquoi RedHat a décidé de développer son outil sans dépendre d’un service, et c’est la principale différence entre Docker et Podman.

Podman n’a pas besoin d’un excellent service (démon) pour fonctionner.. Ils ont décentralisé tous les composants nécessaires à la gestion des conteneurs et les ont individualisés en composants plus petits qui ne seront utilisés qu’en cas de besoin. Cette décentralisation nous offre un grand nombre d’avantages que nous verrons plus tard.

Podman : Pods ou conteneurs ?

Podman a un nom très descriptif, et oui, lorsque nous parlons de Pods, nous faisons référence aux mêmes unités que nous utilisons dans le monde de Kubernetes.

Podman est capable d’exécuter des conteneurs exactement de la même manière que Docker, mais il est également capable d’exécuter des Pods.

Pour ceux qui ne connaissent pas le monde de Kubernetes, nous aurons bientôt un article qui en parlera plus en profondeur, mais nous pouvons déjà clarifier qu’un Pod est l’unité de mesure minimale dans Kubernetes. La différence fondamentale est qu’un Pod peut contenir plusieurs conteneurs. Surtout, on utilise un conteneur principal accompagné d’un ou plusieurs « conteneur adjoints » fonctionnant dans le même Pod que le conteneur principal, pour « l’aider » à la tâche principale pour laquelle il a été conçu.

Si cela vous semble de la magie noire, pour l’instant pensez qu’un Pod est une unité dans laquelle il peut y avoir un ou plusieurs conteneurs. Nous approfondirons ces concepts.

Imaginez que chacun des sceaux du logo de Podman est un conteneur, donc ce que vous avez est un pod.

Gestion des images

Podman utilise un outil basé sur scopio pour l’inspection et la gestion des images de type OCI.

Avec Podman, vous pouvez inspecter les images OCI sans les télécharger, et encore mieux, vous pouvez prendre des éléments d’un référentiel et les déplacer directement vers un autre sans que cette image ne passe par votre appareil. Vous n’auriez pas à télécharger l’image pour inspecter ou utiliser ses composants.

Bien que Podman soit capable de créer des images de la même manière que Docker avec la commande Podman build, l’équipe Redhat nous propose également un autre outil appelé buildah.

Buildah est un outil de gestion d’image étroitement lié à l’utilisation de Podman. Parmi ses fonctionnalités, il permet de manipuler une image ou un conteneur en cours d’exécution pour créer de nouvelles images, monter le répertoire racine d’un conteneur pour sa manipulation ou créer de nouvelles images au format traditionnel ou OCI. Si vous voulez en savoir un peu plus sur Buildah, voici le lien vers son référentiel officiel.

Podman est rootless (sécurité dans Podman)

Grâce à l’architecture modulaire de Podman, il n’est pas nécessaire d’exécuter vos conteneurs en tant que root. C’est un grand avantage, puisque vous pouvez exécuter vos conteneurs avec différents utilisateurs qui ont différents privilèges et sans le risque que quelqu’un ait accès au service de conteneur et puisse exécuter des conteneurs en tant qu’utilisateur root et faire des ravages sur vos serveurs.

Ce que Podman fait lorsqu’il s’exécute en tant qu’utilisateur non root est de créer un répertoire dans le répertoire de base de l’utilisateur et de stocker toutes les informations sur les images et les conteneurs que cet utilisateur contient. Donc, si par exemple vous exécutez podman images avec votre utilisateur non root, il affichera uniquement les images que cet utilisateur a créées ou téléchargées.

Un autre avantage de Podman est qu’il est capable d’utiliser la séparation des UID à l’aide d’espaces de noms, ce qui vous donne une couche supplémentaire d’isolation lors de l’exécution de vos conteneurs.

En termes de sécurité, l’infiltration dans le service Docker est encore plus dangereuse que l’obtention des privilèges root (sudo).

Lorsque vous obtenez des autorisations d’administrateur (sudo) et faites quelque chose sur le système, il s’enregistre toujours dans le journal d’audit du système, il laisse toujours des traces à suivre. Mais si vous accédez au service Docker et le faites à partir d’un conteneur qui obtient des privilèges et vous vous débarrassez de ce conteneur, il est pratiquement impossible de savoir ce que vous avez fait. Il n’est conservé dans aucun journal, il n’a pas d’enregistrement de vos actions. Ce qui présente Podman comme un outil plus sûr.

Intégration avec Systemd

Podman nous permet d’exécuter des conteneurs sur lesquels Systemd est activé par défaut, sans aucune modification.

Il prend en charge l’activation de socket, vous pouvez donc utiliser systemd pour configurer une socket et avoir accès à une API distante via laquelle vous communiquez avec Podman. Ils ont développé une série de bibliothèques Python afin de mettre en œuvre des intégrations et de vous communiquer avec l’API distante Podman.

En fait, il existe déjà une application appelée Pypodman développée en Python, qui est capable d’exécuter tout ce que Podman exécute localement, mais à distance, en communiquant avec l’API distante, ce qui ouvre un monde de possibilités.

Conclusions

Bien que nous savons maintenant qu’est-ce que Podman Il n’y a pas de conclusion claire quant à savoir si Podman est un remplaçant pour Docker ou s’il réussira à détrôner le roi des conteneurs.

Docker a des avantages par rapport à Podman. Tout d’abord la distribution et l’acceptation dont il dispose, ou des outils comme Docker swarm, docker-compose, etc. Maintenant, si vous voulez orchestrer des conteneurs dans Podman, votre alternative est d’utiliser Kubernetes ou, comme je préférerais RedHat, d’utiliser OpenShift en utilisant cri-o qui est le runtime utilisé par Podman.

Ce que nous savons, c’est que RedHat mise beaucoup sur le monde des conteneurs, de l’acquisition de CoreOS pour son utilisation sur la plateforme OpenShift, au développement de Podman, qui est actuellement le moteur de conteneur par défaut de RedHat 8 et CentOS 8.

Et qu’en penses-tu : Podman est-il le substitut de Docker ? Les avantages qu’il nous offre sont-ils suffisants ? Pensez-vous qu’il pourra prendre le trône ?

Si vous êtes intéressé par le monde des conteneurs ou de la technologie en général, restez à l’écoute pour les prochaines entrées. Nous parlerons et ferons des didacticiels pour en savoir plus sur docker-compose, Swarm, Kubernetes, OpenShift et bien plus encore.

Avez-vous quelque suggestion ? Quels sujets vous intéressent ? De quoi pensez-vous que nous devrions parler sur le blog ? Exprimez votre opinion dans la zone de commentaires. Nous voulons la connaître.

Pour conclure cet article sur qu’est-ce que Podman, rappelez-vous que Pandora FMS est un logiciel de supervision flexible, capable de superviser vos appareils, infrastructures, applications, services et procédures commerciales.

Voulez-vous savoir ce que Pandora FMS peut vous offrir? Pour en savoir plus, cliquez ici.

Ou si vous avez à surveiller plus de 100 appareils, vous pouvez également profiter d’un ESSAI GRATUIT de 30 jours de Pandora FMS Enterprise. Obtenez-le ici.

Par ailleurs, n’oubliez pas que si vos besoins en matière de supervision sont plus limités, vous avez à votre disposition la version OpenSource de Pandora FMS. Pour plus d’informations, cliquez ici.

N’hésitez pas à envoyer vos questions, l’équipe de Pandora FMS se fera un plaisir de vous aider!