Editions ENI Livres | Vidéos | e-Formations
Orchestration par Docker Compose
Redéployer automatiquement avec Docker Compose
1. Principe de Docker Compose
En faisant abstraction de la construction des images et en ne se concentrant que sur leur instanciation sous forme de conteneurs, le script ci-dessous reprend l’ensemble des commandes qui doivent être lancées pour démarrer l’application exemple, voire la redémarrer si l’ensemble venait à être perdu (arrêt de la machine hôte, suppression accidentelle des conteneurs, etc.) :
docker run -p 8080:8080 -d -e KEYCLOAK_ADMIN=armoire
-e KEYCLOAK_ADMIN_PASSWORD=vBWtB2PloopC042cszXZ --name iam quay.io/keycloak/
keycloak:18.0.2 start-dev
docker run -d --hostname my-rabbit -p 15672:15672 -p 5672:5672
-e RABBITMQ_DEFAULT_USER=rapido
-e RABBITMQ_DEFAULT_PASS=k5rXH6wmBhE2bukfXFsz --name mom rabbitmq:3-management
docker run -d -p 27017:27017 --name db mongo:4.4
docker run -d --name ged -p 9000:8080 nuxeo
docker run --name recep
-e Securite__CheminFichierCertificatClient=/certif/clienttestoidc.pfx
-e Securite__MotDePasseCertificatClient=oLG78hFS65gBNfx89PmPPp
-e URLBaseServiceAPI=https://localhost:7136
-v "C:\Users\jpgou\OneDrive\Securite\ClientCertificate:/certif:ro"
recepteurmessages
--RabbitMQ__HoteServeur=mom
--RabbitMQ__NomQueueMessagesCreationPersonnes=personnes
--GED__URLAtomPub=http://localhost:9000/nuxeo/atom/cmis
--GED__ServiceAccountName=Administrator
--GED__ModeleURLExpositionDirecteDocuments=http://localhost:9000/nuxeo/atom/
cmis/default/content/{nomFichier}?id={idDoc}
--Securite__FichierMotDePasseCertificatClient=/run/secrets/pwdcertifclient
docker run -d --name api
-e Securite__CheminFichierCertificatClient=//certif//clienttestoidc.pfx
-e Securite__EmpreinteCertificatClient=41E81F27F42F381B7406129DAAB055802F9A64B9 ...Fonctionnalités supplémentaires de Docker Compose
1. Retour sur la gestion des conteneurs
Docker Compose a été abondamment montré par l’exemple en ce qui concerne le lancement de l’application et la compilation des images qui la compose, mais finalement, son mode de fonctionnement n’a pas été expliqué de manière théorique, ni les autres fonctionnalités qui sont possibles dans cette technologie. Cette section opère donc un retour en arrière sur Docker Compose et ce pour quoi cette technologie existe.
Pour faire court, la commande docker compose (ou docker-compose, d’ailleurs ; nous avons vu qu’il s’agit du même outil) fonctionne de la même manière que la commande docker, sauf qu’elle réalise l’opération sur tous les conteneurs spécifiés dans le fichier docker-compose.yml utilisé. Ainsi, docker-compose stop équivaut à un docker stop sur tous les conteneurs, le docker-compose up précédemment utilisé créait les conteneurs et les démarrait, docker-compose restart permettra de les relancer, la commande docker-compose build lancera la recompilation de toutes les images, etc. Au final, seule la commande up est un peu différente de l’équivalent qui est un docker run en mode unitaire.
Il existe aussi docker-compose logs, qui est particulièrement utile pour agréger les logs de tous les services, surtout sur la commande up a été lancée avec l’option -d comme souvent (dans le cas inverse, la commande ne rend pas la main et affiche les logs en continu).
À ce propos justement, après le démarrage de l’ensemble de conteneurs sans l’option -d, il est possible d’arrêter tout par le raccourci [Ctrl] C, qui va entraîner l’arrêt...
Exploitation d’une infrastructure Docker
1. Le réseau dans Docker
Depuis la dernière édition du présent ouvrage, la gestion du réseau dans Docker a atteint une telle complexité qu’il faudrait désormais presque un livre entièrement dédié au sujet, surtout qu’elle est assez complexe. L’auteur tâchera de montrer ci-dessous les principales pistes pour que le lecteur soit en mesure de se retrouver dans la jungle des options réseau et trouver efficacement celles qui conviendront à son cas, forcément particulier. Cette section est également l’occasion de poser un cadre théorique un peu plus complet aux quelques approches de gestion du réseau qui ont été utilisées précédemment dans l’exercice (réseau en mode host, réseaux overlay et mode bridge principalement).
a. Mode de fonctionnement standard (bridge)
De façon à simuler une réelle machine étanche, les conteneurs possèdent leur propre interface réseau (nous verrons quelques exceptions un peu plus loin). Par défaut, Docker fonctionne en mode dit bridge (pont, en anglais), à savoir que le démon Docker établit une couche d’indirection entre l’interface réseau de la machine hôte et celle créée pour les conteneurs. Cette interface réseau intermédiaire s’appelle docker0.
La commande ifconfig exécutée sur une machine sur laquelle Docker est installé montre les caractéristiques de cette interface, en plus des traditionnelles interfaces réseau ethernet eth0 et boucle locale lo :
jpg@Ubuntu1410:~$ ifconfig
docker0 Link encap:Ethernet HWaddr 56:84:7a:fe:97:99
inet...Exemples de fichier Dockerfile pour d’autres plateformes
Le choix a été fait dans cette quatrième édition de focaliser sur une plateforme, en l’occurrence .NET, pour montrer à quel point Docker était désormais intégré profondément dans la plupart des piles technologiques. Le parti-pris sur les anciennes éditions avait plutôt été de montrer la diversité des technologies supportées, en créant une application exemple avec plusieurs langages.
Bien que la nouvelle approche soit plus réaliste, elle possède un inconvénient, à savoir qu’elle passe outre les petites spécificités des autres langages. La présente section a pour but de pallier cette perte en montrant des exemples de fichier Dockerfile pour quelques technologies parmi les plus utilisées. Ceci étant dit, ladite perte est très légère, car 95 % de ce qui a été montré plus haut en termes de manipulation de Docker s’applique à toutes les plateformes de développement et seules quelques particularités minimes nécessitent adaptation.
Le but n’est pas d’être exhaustif par rapport aux plateformes, ni d’ailleurs d’entrer dans les détails d’une plateforme, mais juste de mettre le pied à l’étrier au lecteur qui serait intéressé par une technologie pour démarrer le plus rapidement possible le passage en Docker d’une application, dans l’esprit de la technologie de conteneurs Docker, qui est de simplifier au maximum le travail de chacun en séparant bien les différentes responsabilités, en particulier celle de développement et celle de déploiement.
