• [^] # 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 . En réponse au journal Alternatives à Docker (ou presque). É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.