\newpage Déploiement de conteneurs ========================= Historiquement, le passage d'une application en production ou simplement dans un environnement de qualification, n'est pas toujours aisé. Parfois d'ailleurs, on ne teste pas, on fait les modifications en production ... et à chaque déploiement, on prie pour ne pas écraser une modification qui faisait que notre projet tombait en marche dans cet environnement. Déployer des conteneurs sur sa propre machine, c'est extrêmement simple grâce. Et mieux encore, tout l'environnement étant contenu dans l'image, il suffit de suivre les bonnes pratiques pour que le déploiement en production se fasse de manière transparente. ## L'orchestration Cependant, notons une différence de taille entre notre environnement de développement sur nos machines locales et la production : les clients ! Pour répondre de manière adéquate, il convient de dimensionner correctement les machines, le nombre de conteneurs que chacune peut exécuter, en fonction de caractéristiques (on privilégiera les machines avec des SSD pour les serveurs de base de données par exemple), ... Il n'est pas question pour un administrateur système de faire cette répartition de la charge à la main : le nombre de critères à prendre en compte est beaucoup trop grand, évolue sans cesse ; cela serait trop long s'il y a beaucoup de conteneurs et de variété de machines. Ce processus d'optimisation s'appelle l'*orchestration*. Il s'agit de réussir à répartir au mieux les conteneurs sur les différentes machines disponibles. Ce sujet fait l'objet de très nombreuses thèse depuis plusieurs années (avant les conteneurs, c'était pour répartir les machines virtuelles entre différents hôtes), et autant de projets disponibles. Citons par exemple [Google Kubernetes](https://kubernetes.io), [Hashicorp Nomad](https://www.nomadproject.io/) ou encore [Apache Mesos](https://mesos.apache.org/), ... Le point commun entre la plupart des orchestrateurs, c'est généralement leur extrême complexité de mise en œuvre. Dans le cadre de notre TP, nous allons plutôt utiliser l'orchestrateur intégré à Docker, dont la caractéristique principale est sa simplicité[^dockerconEU2017]. [^dockerconEU2017]: À noter qu'une annonce faite à la Docker Con EU 2017 indique le début du support de Kubernetes au sein de Docker EE, pouvant être utilisé en symbiose avec Swarm. ### Concepts clefs Regroupés au sein d'un cluster (on parle de *swarm* pour Docker), chaque *Docker engine* représente un nœud (*node*) dans lequel on va déployer des *services*. Certain nœud ont un rôle de *manager*, parmi ceux-ci, un seul est élu leader et prendra les décisions d'orchestration. Les autres sont là pour prendre le relais en cas de dysfonctionnement sur le manager élu. Les services sont un groupe de tâches (typiquement une image avec sa ligne de commande à lancer) que le `manager` va conserver à l'état désiré. Le service va indiquer par exemple le nombre d'instances que l'on désire avoir dans le cluster. En cas de crash d'un manager ou d'un *worker*, le (nouveau) manager fera en sorte de redéployer les conteneurs perdus, afin de toujours maintenir le cluster dans l'état désiré. En terme de cluster, des tâches sont l'équivalent des conteneurs, hors de Swarm. ## Création du cluster Swarm ### Initialisation du cluster La première chose à faire, est d'initialiser un cluster swarm. Pour se faire, ce n'est pas plus compliqué que de faire :