Sommaire
-
Alternatives à Docker (ou presque)
- Avant de commencer
- Moteur de conteneur: Podman
- Gestion d'une stack de conteneurs: podman-compose
- Construction des images: Buildah
- Registre d'images: Docker Distribution et Pulp
- Format d'images: OCI
- Gérer des registres d'images: Skopeo
- Application de bureau: Podman Desktop
- Ansible: Collection Podman
- Interface web: Cockpit-podman
- Conclusion
Alternatives à Docker (ou presque)
Bonjour nal.
Récemment, Docker Inc a fait une annonce concernant la fin de la gratuité de certains comptes sur son Hub. Une annonce qui a fait parler d'elle car tout le monde n'est pas d'accord avec leur décision. Je ne vais pas revenir dessus car il y a déjà un journal ici qui en parle.
Sur les réseaux sociaux, j'ai vu plusieurs personnes demander s’il existait des alternatives. Je vais donc en profiter pour écrire ce petit journal où j'en liste quelque unes que je connais et, pour certaines, utilise très régulièrement.
Dans ce journal, je ne vais présenter que des logiciels libres, pas de services.
Et je me dépêche avant qu'il ne soit trolldi.
Avant de commencer
Une bonne partie des solutions que je vais lister ici viennent de la Containers Organization. Il ne s'agit pas d'une entreprise mais d'une collection de logiciels libres en lien avec les conteneurs.
Ces logiciels sont hébergés sur Github mais n'appartiennent pas à Microsoft.
Moteur de conteneur: Podman
Commençons par le commencement: Le moteur de conteneur.
Je sais que les récentes critiques sont dirigées contre le Hub de Docker, mais j'ai lu plusieurs personnes demander des alternatives concernant le moteur.
Podman est un moteur de conteneur sous licence Apache 2.0 écrit en Go.
Pour plus d'infos:
Fonctionnalités
Tout comme Docker, il propose de:
- Télécharger des images
- Construire des images
- Envoyer des images
- Lancer et gérer des conteneurs
- Etc
Mais également:
- Rootless: Podman peut entièrement fonctionner au niveau utilisateur
- Daemonless: Podman est un outil en ligne de commande, il délègue son travail et s'arrête une fois terminé
- Gestion des Pods: Des groupes de conteneurs gérés comme une seule unité
- Mise à jour automatique des conteneurs avec rollback
- Une intégration optionnelle avec Systemd
- Peut créer des Pods à partir d'un fichier Kube pour Kubernetes
- Peut également créer un fichier Kube pour Kubernetes à partir d'un Pod
Compatibilité avec Docker
À propos de la compatibilité des deux outils.
Concernant les images, vous pouvez lancer des conteneurs Podman à partir d'images Docker. Vous pouvez également générer des images Docker avec Podman.
Vous pouvez également simuler un socket Docker. Et ainsi utiliser des logiciels prévus pour contrôler directement Docker au travers de son socket.
Pour les fonctionnalités communes entre Docker et Podman, les commandes sont les mêmes. À tel point qu'on peut créer un alias docker=podman
.
J'ai utilisé Podman pendant 2 ans dans un précédent job où mes collègues utilisaient toutes et tous Docker. Aucun problème de compatibilité.
Podman et Systemd
L'intégration entre Podman et Systemd peut se faire de différentes façons.
Pour commencer, à partir de tout conteneur ou pod, vous pouvez demander à Podman de générer un fichier de service Systemd. Ce fichier pourra vous servir à gérer le démarrage, redémarrage et arrêt de votre conteneur ou pod depuis Systemd, comme n'importe quel autre service.
Vous avez même une option pour que le fichier de service crée et supprime automatiquement le conteneur ou pod. Ainsi, votre fichier .service
pourra être ré-utilisé sur n'importe quelle machine avec Systemd et Podman.
Ensuite, il est aussi possible d'utiliser Systemd dans un conteneur. Pour lancer facilement un logiciel accompagné de son fichier .service
.
Par exemple, si vous devez conteneuriser un logiciel vous-même mais que vous n'avez pas le temps de le compiler, comprendre comment le lancer, etc. Si, par chance, une des principales distributions GNU/Linux package déjà votre logiciel, vous pouvez simplement créer un fichier Containerfile
ou Dockerfile
qui va:
- Utiliser l'image de la distribution choisie
- Installer le package de votre logiciel
- Activer son service
- Déclarer les dossiers où iront les données comme des volumes
- Indiquer que la commande par défaut du conteneur sera
systemd
Et voilà, il vous suffira de construire votre image à partir de votre Containerfile
ou Dockerfile
. Votre logiciel est conteneurisé. Pour bénéficier des mises à jour, il faut reconstruire l'image.
Finalement, depuis la version 4.4.0, Quadlet a été intégré à Podman. Il s'agit d'un outil qui propose de créer des services Systemd utilisant Podman pour exécuter les logiciels. Mais cette fois en écrivant directement un simple fichier texte dont la syntaxe est très proche de celle de Systemd.
Par exemple, pour lancer un conteneur Python et lui demander d'attendre 60 seconde:
[Unit]
Description=A minimal container
[Container]
Image=centos
Exec=sleep 60
[Service]
Restart=always
Oui, l'exemple est un peu nul, mais c'est un exemple simple. Vous avez plus qu'à sauvegarder votre fichier dans /etc/containers/systemd/
, télécharger ou construire votre image et faire un systemctl daemon-reload
. Voilà, votre service est prêt à fonctionner.
Bon, j'ai peut-être été trop verbeux sur ce point. Revenons à quelque chose de plus court.
Gestion d'une stack de conteneurs: podman-compose
Un des outils très pratiques pour gérer plusieurs conteneurs Docker est docker-compose.
Il est possible, avec Podman, d'utiliser docker-compose en activant la simulation du socket Docker.
Mais on peut également utiliser podman-compose. Son utilisation est très similaire à docker-compose. Il supporte les formats compose-file v2 et v3. Il exécute directement la commande podman, il n'est pas nécessaire d'activer le socket.
Podman-compose est un logiciel libre, écrit avec Python et sous licence GPLv2.
Plus d'infos:
Construction des images: Buildah
Parfois, on a voulu juste construire une image. Rien de plus.
Pour ça, il y a Buildah. Son rôle est justement de construire des images et, optionnellement, de les envoyer vers un registre d'images.
Il s'agit d'un logiciel libre, écrit avec Go et sous licence Apache 2.0.
Pour plus d'infos:
Registre d'images: Docker Distribution et Pulp
Sur ce point, je ne vais pas présenter un service mais deux logiciels qu'on peut utiliser pour auto-héberger la distribution d'images pour conteneurs.
On peut le faire à titre personnel où mutualiser ses ressources et personnes avec d'autres organisations. Par exemple via un chaton ?
Docker Distribution
Ici, je vais parler du projet Distribution de Docker. Il s'agit d'un logiciel libre sous licence Apache 2.0, écrit lui aussi avec Go.
Oui, il s'agit d'un logiciel de chez Docker. Mais il s'agit d'un logiciel libre. S’il prend une mauvaise direction, il pourra toujours être forké.
Il implémente l'API OCI Distribution Specification. Il est donc possible d'avoir d'autres logiciels qui soient compatibles.
L'avantage de ce logiciel est qu'il est simple à déployer et utiliser. Si une organisation héberge déjà son site web, il devrait être facile d'héberger la distribution de ses images avec ce logiciel.
Pour plus d'infos:
Pulp
Pulp est un logiciel libre proposant d’héberger des dépôts de paquets:
- Image de conteneurs avec API Docker Registry HTTP API V2-compatible
- Paquets Python
- Ruby gems
- Paquets RPM
- Paquets DEB
- Collections et rôles Ansible
- OSTree packages
- Chef cookbooks
- Maven packages
- Fichiers
Vous pouvez l'utiliser pour vos dépôts personnels mais également pour faire des miroirs de dépôts existants. Pour les images de conteneur, vous pouvez également demander à Pulp de les construire à partir d'un fichier Containerfile
.
Je ne l'ai pas encore utilisé, donc je ne sais pas s’il est adapté pour des dépôts publics.
Il est écrit avec Python et est distribué sous licence GPLv2.
Pour plus d'infos:
Format d'images: OCI
Pour le format des images des conteneurs, il existe l'OCI Image Format.
Ce format d'image est supporté par Podman et Buildah
Gérer des registres d'images: Skopeo
Skopeo est un petit logiciel qui vous servira à effectuer différentes opérations sur des images hébergées sur des registres.
Fonctionnalités:
- Copie d'images depuis et vers différents sources ou destination
- Type de sources et destinations proposées:
- Stockage local
- Registre implémentant l'API Docker Registry HTTP API V2
- Dossier local
- Archive
- Inspection des propriétés d'une image, sans avoir à la télécharger
- Suppression d'image d'un registre
- Synchronisation entre deux registres
Il s'agit d'un logiciel libre sous licence Apache 2.0, écrit lui aussi avec Go.
Pour plus d'infos:
Application de bureau: Podman Desktop
On arrive à l'application de bureau. Podman Desktop est un logiciel libre écrit principalement avec TypeScript et sous licence Apache 2.0.
Disponible pour Windows, Mac OS et GNU/Linux, il propose:
- Construction et gestion d'images
- Exécution et gestion de conteneur et Pod
- Exécution de Pod sur Podman ou Kubernetes
- Conversion de Pod pour être lancé sur Kubernetes
- Gestion des volumes
- Gestion de plusieurs moteurs de conteneurs: Podman, CRC, Machines Podman Lima et Docker
- Gestion des registres OCI
- Support de proxy
- Système d'extensions
Je ne l'ai utilisé qu'une fois, pour voir à quoi ressemblait son interface.
Pour plus d'infos:
Ansible: Collection Podman
Si vous utilisez Ansible pour gérer le déploiement et la configuration de votre parc, vous pouvez utiliser la collection officielle containers.podman
.
Écrite avec Python et sous licence GPLv3, elle propose de nombreux modules pour gérer vos ressources Podman ou obtenir des informations à leur sujet. Cette collection propose également 2 extensions de connexion, pour Podman et Buildah, ainsi qu'une extension become utilisant Podman unshare.
Pour plus d'infos:
Interface web: Cockpit-podman
Pour terminer, une petite extension pour Cockpit, l’interface web pour serveur.
Il s'agit d'un logiciel libre principalement écrit avec JavaScript et Python et sous licence LGPLv2.1.
Cette interface est un limité à quelques fonctionnalités:
- Téléchargement et gestion d'images
- Création et gestion de Pods et conteneurs
Pour plus d'infos:
Conclusion
Il existe plusieurs alternatives aux solutions de Docker Inc offrant une bonne compatibilité et même des fonctionnalités supplémentaires.
Le modèle du "conteneur à processus unique basé sur un environnement reproductible" offre de nombreux avantages et il serait dommage d'y renoncer suite aux décisions de Docker Inc.
PS: Ce journal a sûrement de nombreuses "fautes" de français. En réalité, ce ne sont pas des fautes mais un moyen de faire vivre la langue. Car seules les langues mortes sont figées. (Je suis déjà loin :p)
# Drôle de saisie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 16 mars 2023 à 18:46.
Merci pour ce journal.
Je ne sais pas avec quoi ça a été écrit, mais c'est vraiment dommage d'avoir toutes ces lignes courtes qui doivent être autant de saut de lignes forcés.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Drôle de saisie
Posté par barmic 🦦 . Évalué à 2.
Il a probablement écris ça dans son éditeur préféré et n'a pas du tout cherché à savoir comment ça rendrait ici.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Drôle de saisie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3. Dernière modification le 16 mars 2023 à 19:09.
Je fais plus que m'en douter :) l'epub est plein de
<br/>
. Comme je dis toujours : un éditeur de texte n'est pas un traitement de texte, là c'est même un maltraitement de texte et ça le rend péniblement lisible. Ce qui est dommage.« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Drôle de saisie
Posté par Ambroise . Évalué à 1.
Le journal dans le flux RSS a, en effet, une mise en page particulière…
[^] # Re: Drôle de saisie
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
Faut pas prendre le particularisme de Linuxfr pour une généralité :) J'ai souvent du Markdwon qui rend très bien ailleurs sauf ici et faut se retaper le boulot (même quand on fait très attention à se conformer CommonMark bah ce n'est pas le dialecte dans lequel on va publier) On sait même passer du traitement de texte à Markdown, sauf que ça marche pas Linuxfr, et c'est un peu décourageant.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Drôle de saisie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 3.
J'écris tous mes journaux et dépêches avec LibreOffice :
Pas super compliqué mais ça facilite la vie, je le fais aussi pour d'autres sites.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Drôle de saisie
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Ce que tu décris se fait exactement de la même façon avec un éditeur de texte : le traitement de texte n'apporte rien de plus ici.
Par contre, nous sommes nombreux et nombreux à faire du Markdown hors ligne et à même prévisualiser avant. Mais ça n'empêche pas que ça casse sur une des plateformes, et en particulier Linuxfr est le plus différent de ce qui est fait ailleurs.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Drôle de saisie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 1.
Si ça apporte un respect de la typographie et ça évite d'avoir des lignes tronquées;
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Drôle de saisie
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6.
Ça se saurait vu le nombre de documents que je vois passer qui sont passés par un traitement de texte et ne respectent pas la typographie.
Quand aux lignes tronquées je vais éviter de répondre à une perception subjective.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Drôle de saisie
Posté par barmic 🦦 . Évalué à 0.
Quand tu publie quelque part s'intéresser à comment est-ce qu'on écris là bas me parait un minimum. C'est pas un contenu qui a était automatiquement récupéré, l'auteur de ce texte l'a rédigé, puis l'a lui même soumi.
Cette manière à l'arrache de faire en surfant sur une polémique du moment, personnellement je trouve pas ça incroyable.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Drôle de saisie
Posté par Yuul B. Alwright . Évalué à 2.
Tu me prêtes des intentions que je n'ai pas. J'ai créé ce journal pour réunir une bonne partie de ce que je pourrai répondre sur les réseaux et ainsi éviter de me répéter.
[^] # Re: Drôle de saisie
Posté par barmic 🦦 . Évalué à 0.
Il n'y a pas de procès d'intention c'est factuel (il n'y a aucune relecture : ça a était fait à l'arrache et il surf sur la polémique il en parle dès la première phrase alors que le reste du contenu n'a qu'un rapport ténu avec la dite polémique). Je n'ai aucun doute que l'intention n'était autre que le partage.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Drôle de saisie
Posté par Yuul B. Alwright . Évalué à 2.
Le problème, c'est pas tant l'outil que j'ai utilisé, mais plutôt mon cerveau qui à l'habitude de faire le même raccourcis clavier quand je termine un paragraphe. C'est un automatisme.
La plupart du temps ça ne cause pas de problème. Mais pour LinuxFR j'ai simplement copié le texte au format Markdown. Au moment de prévisualiser, j'ai pas fait attention à ce point.
[^] # Re: Drôle de saisie
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Quand on fait des journaux un peu long, la prévisualisation ne permet pas de se rendre compte ; et comme on ne peut pas avoir de mode brouillon c'est compliqué.
J'en profite pour demander à la modération de remplacer
```systemd
par```ini
et d'ajouter le saut de ligne qui va bien avant.“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Drôle de saisie
Posté par Benoît Sibaud (site web personnel) . Évalué à 5.
Un peu facile le coup de la prévisualisation qui ne permettrait pas de… Je viens d'éditer le journal sur mobile (moins pratique que sur un grand écran donc), et pourtant on voit tous les défauts en prévisualisation, on veut qu'il y a un espace excédentaire avant le
systemd
du bloc de code, qu'il y a des retours à la ligne partout, etc. Bref, pour les soucis mentionnés ici, ce n'est pas un souci de prévisualisation.[^] # Re: Drôle de saisie
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 4. Dernière modification le 17 mars 2023 à 09:23.
Un souci d'absence de vérification du rendu dans la prévisualisation plutôt, je dirais.
« Tak ne veut pas quʼon pense à lui, il veut quʼon pense », Terry Pratchett, Déraillé.
[^] # Re: Drôle de saisie
Posté par Yuul B. Alwright . Évalué à 3.
Sur mon écran, les retours à la ligne ne m'ont pas semblé poser un problème. Que ce soit sur la prévisualisation ou le journal final. Et j'y ai pas prêté d'attention particulière.
Pour le bloque de code, j'ai essayé d'enlever les triples back-quotes et d'utiliser le bouton "Code Block" de l'éditeur de LinuxFR. Je me suis retrouvé avec tout le reste de l'article sous forme de code block alors que sur le texte source seul l'exemple de configuration était indenté.
[^] # Re: Drôle de saisie
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 2.
La prévisualisation ne permet pas : il faut comprendre, encore une fois dans le contexte d'un journal long, qu'on passe facilement à côté de certaines choses et on se retrouve à demander des modifications en commentaire (quand tu regardes la grosse majorité des corrections demandées, ce sont justement des choses qui auraient pu être rectifiées au moment de la prévisualisation non ?)
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Drôle de saisie
Posté par Benoît Sibaud (site web personnel) . Évalué à 6. Dernière modification le 17 mars 2023 à 11:45.
Oui, la plupart des corrections demandées pourrait être évitées si les personnes relisaient attentivement la prévisualisation et/ou si elles utilisaient des correcteurs orthographiques ou grammaticaux et/ou si elles maîtrisaient parfaitement HTML et Markdown (on comprend bien que ce n'est pas totalement possible). Par des tas de raisons, allant de l'absence d'envie de relire, l'indisponibilité de Grammalecte sur mobile, une erreur d'inattention sur le moment, un manque de temps, une fausse manipulation, etc., il reste des corrections à faire post-publication. On ne résoudra pas tous les problèmes des humains avec simplement de la technique, les meilleurs outils du monde n'empêcheraient pas d'avoir des corrections à faire post-publication. Bref il faut juste faire la part des choses entre les limitations techniques et les limitations humaines, si je puis dire. Si le souci vient du code de prévisualisation, alors on peut regarder ce qui est possible, tandis que si le souci vient du contenu lui-même, alors il ne faut pas blâmer le code de prévisualisation (mais plutôt agir sur des incitations à relire, détecter plus de problèmes en amont, faciliter les corrections post-publication… ou simplement accepter que ça arrive, parce que personne n'est parfait).
[^] # Re: Drôle de saisie
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3.
Arf, je ne blâme pas le code de la prévisualisation…
Je prends le cas où on se relis, ce n'est pas pour autant qu'on voit certaines choses sur le coup. L'« erreur d'inattention sur le moment » est tellement naturelle que la « relecture » est un travail à part entière qui n'est pas possible ici (c'est pour cela que je disais dans un autre message que ça manque de « mode brouillon »)
Pourtant cela n'empêche pas de nombreux commentaires de personnes parfaites de crier automatiquement à l'absence de relecture.
Voilà, le souci. On « prévisualise » le rendu ; ce n'est pas la même chose que de passer autant de temps que celui de rédaction avant d'appuyer sur le bouton.
D'ailleurs, « relire attentivement » se fait presque toujours en revenant plusieurs fois avec un œil neuf, mais à lire les commentaires on a l'impression que faire une prévisualisation suffit et pourtant ce sont les mêmes qui vont se plaindre de cela.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
# Rien à voir ?
Posté par barmic 🦦 . Évalué à 3.
Le hub c'est un dépôt centralisé d'images. Tu peux continuer d'utiliser docker de la même façon et podman a le même fonctionnement à aller chercher ces images docker sur le dockerhub par défaut.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Rien à voir ?
Posté par Yuul B. Alwright . Évalué à 2.
J'ai mal précisé ma phrase. Ça m'apprendra à pas me relire.
Les demandes que j'ai lut concernaient autant le Hub que le moteur et ce qui va autour.
J'ai donc commencé à lister ce que j'utilisais et aussi ce que je connaissais sans avoir testé.
C'est pour cela que ce journal parle autant de Podman, le moteur, que d'outils comme Skopeo.
Pour le Hub, je n'ai pas parlé de services car j'en connais que deux autres: Un par Red Hat et l'autre par Microsoft. Et que les problèmes rencontrés avec Docker Hub peuvent aussi s'y produire. À la place, j'ai parlé de deux logiciels qui peuvent servir à s'auto-héberger.
[^] # Re: Rien à voir ?
Posté par Psychofox (Mastodon) . Évalué à 9.
Podman ne cherche pas sur le dockerhub par défaut. Podman cherche sur les registries configurées dans
$HOME/.config/containers/registries.conf
ou/etc/containers/registries.conf
et dans l'ordre défini.Il et possible que certains packagers de distribs choisissent le docker hub mais pas tous. Exemple chez Fedora les registries fedora, redhat et quay passent avant docker hub.
# systemd
Posté par Psychofox (Mastodon) . Évalué à 6.
Je n'ai jamais pris la peine de tester mais il me semble que systemd permet de faire tourner directement des containers sans passer par un runtime oci comme podman ou containerd.
[^] # Re: systemd
Posté par Misc (site web personnel) . Évalué à 3.
Je suppose que tu ne parles pas de quadlet, mais c'est sans doute la solution recommandé de nos jours.
[^] # Re: systemd
Posté par Psychofox (Mastodon) . Évalué à 6.
Non je pensais à
systemd-nspawn
.[^] # Re: systemd
Posté par steph1978 . Évalué à 5.
Si par "container" tu entends "ensembles de processus dans un cgroup" alors oui il le fait avec nspawn, et bien plus.
selfdock le fait aussi, à sa manière.
Docker combine cgroup pour l'isolation système, aufs pour l'empilement de couche de fichier (avec la dernière en read-write), interface virtuelle pour l'isolation réseau.
# Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par devnewton 🍺 (site web personnel) . Évalué à 5. Dernière modification le 16 mars 2023 à 22:34.
D'après mes tests il est difficile de remplacer vraiment docker par podman dès qu'on utilise docker-compose : la partie réseau n'est pas la même, on ne peut pas rediriger les logs de la même façon…
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par Psychofox (Mastodon) . Évalué à 4.
Ce n'est pas bien compliqué de faire les quelques modifs nécessaires pour que ça marche avec podman-compose non?
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Un cas tout simple : comment centraliser les logs avec Podman ? Par exemple pour tester une suite comme OpenSearch en local.
Avec docker + docker-compose, je change juste logging driver :
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par Yuul B. Alwright . Évalué à 3.
Je n'avais jamais utilisé les Extension fields dans un fichier compose. Mais l'option logging est lui compris par Podman-compose.
Dans le pire des cas, il est toujours possible d'activer la simulation du socket Docker par Podman et d'utiliser directement Docker-compose. Mais je n'ai pas encore essayé cette solution.
Coté réseau, quel problème rencontre-tu ?
De mon coté, j'ai remplacé les fichiers compose par des playbook Ansible où j'indique comme hôte
localhost
. Comme de toute façon Ansible sera utilisé pour le déploiement sur les serveurs, et que dans les deux cas, compose et playbook, on décrit une stack de conteneurs et leurs ressources au format YAML, j'ai préféré supprimer une étape qui me semble redondante.Avec tout les modules disponibles, j'ai plus de possibilité avec un playbook qu'avec un fichier compose. Notamment la création de fichiers à partir de templates, l'exécution de commandes arbitraires dans un conteneur déjà lancé ou l'exécution de tâches dans certaines situations avec les handlers.
Le playbook est écrit pour créer tout les conteneurs dans un pod et pour les mettre à jour en cas de ré-exécution du playbook. Pour l'arrêt et la suppression de la stack de conteneurs, je peux simplement arrêter puis supprimer le pod. Pour supprimer les volumes, réseaux ou images inutilisés, il y a une commande
prune
pour chacune de ces ressources.Le playbook sert également d'exemple pour celui qui servira à au déploiement sur les serveurs.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
Mais il ne gère pas gelf comme driver. Il faudrait que je cherche comment faire un équivalent pour faire remonter ces logs jusqu'à opensearch.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par Psychofox (Mastodon) . Évalué à 5.
Tu as plusieurs options:
faire tourner le pod de logstash en mode privilégié en lui donnant accès àe /run/log/journal pour aller chercher le log de ton appli directement dans journald. Par contre le logstash ne serait du coup plus dans le docker compose.
utiliser le paquet rsyslog de la distrib sur lequel ces containers tournent pour récupérer le log du pod de ton appli dans journald via l'input imjournal et de le renvoyer à opensearch. Dans ce cas tu peux même te passer de logstash puisque rsyslog a un output omelasticsearch.
faire tourner logstash ou autre tournant directement sur ta machine hôte. Il existe un plugin d'input compatible journald.
option 1. ou 2. avec fluentbit ou fluentd qui sont aussi journald et opensearch capables.
utiliser log-driver k8s-file et logger dans un fichier qui est ensuite lu par logstash
ne pas utiliser podman-compose
Mais perso je ne vois pas bien l'intérêt d'avoir l'infra de logging gérée dans le même docker-compose qu'une application individuelle. Ton cas de figure me parait assez alambiqué. En général si on utilise opensearch ou un outil du même type, c'est qu'on veut aggréger les logs de n applications.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par devnewton 🍺 (site web personnel) . Évalué à 5.
J'ai bien N applications dans mon docker-compose. Avoir l'Opensearch avec ça permets de faire la mise au point des dashboards avant passage en prod, d'avoir du tracing distribué en local, de chercher dans les logs avec mieux que grep/journalctl, de tester l'indexation…
Bref entre ça et le réseau qui n'est pas identique (je n'ai pas noté ce qui m'avait coincé lors du test de podman malheureusement), je ne trouve pas que podman soit le "drop in replacement" (le Droopy remplaçant en français?) de docker comme promis.
Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par Misc (site web personnel) . Évalué à 5.
Quand il y a des bugs de ce genre, l'équipe va aller les corriger. J'ai corriger/fait corriger 2 bugs de compat pour faire tourner woodpecker avec podman, et malgré une réticence sur la forme du correctif, ça a fini par être accepté en quelques semaines.
Ensuite, suivant les cas, il y a parfois des bonnes raisons de dévier, et je ne pense pas que la compatibilité avec compose soit une priorité.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par AlexTérieur . Évalué à 4.
Je l'utilise parce que c'est le moteur par défaut sous Fedora depuis plusieurs versions.
Autres problèmes que j'ai rencontré :
- les Dockerfile qui ne marchent pas toujours et qu'il faut modifier à la main, par exemple on doit faire un appel explicite à Bash si on veut lancer une commande dans un conteneur.
- il faut également expliciter un port en entrée et pas seulement en sortie sinon Podman en attribue un aléatoirement
- quelques commandes différentes de podman-compose (pas de "remove orphans" ou de suppression automatique des images intermdédiaires)
Sinon avec Fedora c'est assez cool de gérer les conteneurs grâce à Cockpit.
[^] # Re: Les conteneurs, quand y en a un ça va, c'est quand il y en a plusieurs qu'il y a des problèmes
Posté par Yuul B. Alwright . Évalué à 1.
J'ai souvent écrit des Dockerfile utilisés avec Podman et je n'ai pas rencontré ce problème. Les instructions
run
etcmd
n'ont aucun appelle explicite à Bash.Tu parle de l'option
-p
? Comme avec Docker, il faut préciser le port de l'interface ainsi que celui dans le conteneur vers lequel les requêtes sont redirigée.# distribution -> cncf
Posté par CrEv (site web personnel) . Évalué à 5.
Plus ou moins. Enfin plus moins que plus désormais.
distribution
est maintenant un projet de la CNCF: https://www.docker.com/blog/donating-docker-distribution-to-the-cncf/Justement dans le but de continuer à le faire vivre, en dehors des besoins de Docker Hub.
A noter que de nombreuses registry utilisent
distribution
:# Charliecloud
Posté par Loïs Taulelle ࿋ (site web personnel) . Évalué à 3.
C'est un runner orienté HPC : https://hpc.github.io/charliecloud/index.html
Proverbe Alien : Sauvez la terre ? Mangez des humains !
# Merci pour Pulp !
Posté par damaki . Évalué à 7. Dernière modification le 17 mars 2023 à 18:38.
Merci pour Pulp. Je cherchais un alternative légère à Quay et Nexus et on dirait que ça fera le taf.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.