J'en profite pour partager mon expérience sur l'utilisation de docker-compose.
J'utilise docker-compose depuis des années et je me suis vite rendu compte de ses limitations.
Si il permet de définir facilement une stack de containers, il n'est pas adapté pour effectuer nombre de tâches lors du lancement de l'application "containerisée".
Par exemple, docker-compose n'est pas adapté pour:
- Lancer l'initialisation des tables de la base de donnée
- Générer des clés
- Ajouter un ou plusieurs utilisateurs d'administration dans l'application "containerisée"
- etc
Si on essaye, on se retrouve à devoir jouer avec les scriptes de points d'entrée (entrypoint) des containers et ça peut vite devenir complexe.
Comme au niveau pro je n'ai pas le choix des outils, je l'utilise malgré tout.
Mais à coté, depuis longtemps, j'utilise aussi Ansible pour l'intégration des applications ("containerisée" ou pas) dans l'infrastructure:
- Déploiement de l'application (ou de sa stack)
- Déploiement des configurations
- Initialisation des tables de la base de donnée
- Génération de clés (et stockage pour plus tard)
- Ajout d'utilisateurs
- Configuration de reverse proxy ou load balancer
- Ajout d'un sous-domaine
- Configuration du système de backup
- Configuration du système de teste de l'infra
- Etc
Les possibilités sont immense.
Mais récemment j'ai décidé de me passer de docker-compose sur mon infrastructure personnelle et d'utiliser directement Ansible pour la définition de la stack de containers.
L'idée c'est d'avoir un rôle Ansible qui déploie l'application et d'utiliser un playbook pour appliquer le rôle, personnaliser l'installation et l'intégrer dans l'infra.
Le rôle s'occupe, par exemple, de:
- Créer les containers
- Déployer les fichiers de configuration avec la config par défaut
- Initialiser la base de données
Les paramètres de l'application ainsi que du déploiement sont personnalisable par des variables dans Ansible.
Le playbook s'occupe de l'intégration dans mon infrastructure:
- Il définit sur quel hôte l'application sera déployée
- Personnalise l'installation
- Créer des utilisateurs
- Configure le reverse proxy
- Configure un sous-domaine pour la nouvelle application
Le rôle est réutilisable et facilement partageable tandis que le playbook est dépendant de l'infrastructure.
Et si je crée un rôle qui déploie son application via des containers Docker, il peut être utilisé sur n'importe quel système où Docker est installé (ou presque).
Et à coté, je crée aussi un playbook qui déploie l'application en locale pour du dev. Mais avec le système de tags d'Ansible ou pourrait avoir un seul playbook qui s'adapte en fonction de la cible (dev/test/prod).
En plus avec l'arrivée des collections Ansible, on a un système qui permet de distribuer en une fois des rôles, des modules, des exemples de playbook et la doc en rapport avec un projet ou une application.
En bref, Ansible m'apporte une plus grand liberté et flexibilité que docker-compose et ce commentaire est beaucoup trop long, j'aurai du créer un journal. :(
# À propos de docker-compose
Posté par Yuul B. Alwright . En réponse au journal LinuxFr avec Docker. Évalué à 10.
Merci beaucoup ce travail. ;)
J'en profite pour partager mon expérience sur l'utilisation de docker-compose.
J'utilise docker-compose depuis des années et je me suis vite rendu compte de ses limitations.
Si il permet de définir facilement une stack de containers, il n'est pas adapté pour effectuer nombre de tâches lors du lancement de l'application "containerisée".
Par exemple, docker-compose n'est pas adapté pour:
- Lancer l'initialisation des tables de la base de donnée
- Générer des clés
- Ajouter un ou plusieurs utilisateurs d'administration dans l'application "containerisée"
- etc
Si on essaye, on se retrouve à devoir jouer avec les scriptes de points d'entrée (entrypoint) des containers et ça peut vite devenir complexe.
Comme au niveau pro je n'ai pas le choix des outils, je l'utilise malgré tout.
Mais à coté, depuis longtemps, j'utilise aussi Ansible pour l'intégration des applications ("containerisée" ou pas) dans l'infrastructure:
- Déploiement de l'application (ou de sa stack)
- Déploiement des configurations
- Initialisation des tables de la base de donnée
- Génération de clés (et stockage pour plus tard)
- Ajout d'utilisateurs
- Configuration de reverse proxy ou load balancer
- Ajout d'un sous-domaine
- Configuration du système de backup
- Configuration du système de teste de l'infra
- Etc
Les possibilités sont immense.
Mais récemment j'ai décidé de me passer de docker-compose sur mon infrastructure personnelle et d'utiliser directement Ansible pour la définition de la stack de containers.
L'idée c'est d'avoir un rôle Ansible qui déploie l'application et d'utiliser un playbook pour appliquer le rôle, personnaliser l'installation et l'intégrer dans l'infra.
Le rôle s'occupe, par exemple, de:
- Créer les containers
- Déployer les fichiers de configuration avec la config par défaut
- Initialiser la base de données
Les paramètres de l'application ainsi que du déploiement sont personnalisable par des variables dans Ansible.
Le playbook s'occupe de l'intégration dans mon infrastructure:
- Il définit sur quel hôte l'application sera déployée
- Personnalise l'installation
- Créer des utilisateurs
- Configure le reverse proxy
- Configure un sous-domaine pour la nouvelle application
Le rôle est réutilisable et facilement partageable tandis que le playbook est dépendant de l'infrastructure.
Et si je crée un rôle qui déploie son application via des containers Docker, il peut être utilisé sur n'importe quel système où Docker est installé (ou presque).
Et à coté, je crée aussi un playbook qui déploie l'application en locale pour du dev. Mais avec le système de tags d'Ansible ou pourrait avoir un seul playbook qui s'adapte en fonction de la cible (dev/test/prod).
En plus avec l'arrivée des collections Ansible, on a un système qui permet de distribuer en une fois des rôles, des modules, des exemples de playbook et la doc en rapport avec un projet ou une application.
En bref, Ansible m'apporte une plus grand liberté et flexibilité que docker-compose et ce commentaire est beaucoup trop long, j'aurai du créer un journal. :(