Grande nouvelle pour les amateurs de Docker la semaine passée, à savoir la disponibilité générale de l’offre Azure Container Service, qui vous permet de déléguer au cloud de Microsoft toute la tringlerie sous-jacente à Docker, et vous occuper uniquement de la partie applicative.
En gros, tout ce qui est de l’infra, vous oubliez, à savoir :
- tout le hardware, bien évidemment puisque c’est du cloud ;
- l’installation du démon Docker ;
- la gestion du cluster ;
- le paramétrage de Swarm ;
- etc.
Azure Container Service s’occupe de tout cela, et pour mettre en ligne une application que vous avez créée sous forme de conteneurs, il ne vous reste plus qu’à pointer votre client Docker sur le service (par une variable d’environnement), et lancer un docker run ou un docker-compose up ! Pour les gens comme moi qui sont plus à l’aise sur le soft applicatif que sur l’installation de serveurs logiciels et leur paramétrage avec des contraintes réseau, il s’agit vraiment d’une bénédiction 
.
Pourquoi cet article ?
Le sujet est tout neuf et la documentation de Microsoft sur le sujet est très bien, mais il manque malheureusement quelques petits détails qui font que, pour un débutant complet, ça peut vite bloquer. Même si on a bien compris les concepts et qu’on connait les outils, il n’est pas toujours évident de savoir comment adapter l’exemple à notre besoin à nous, parce qu’il manque juste la petite phrase ou la capture qui vous indique où trouver l’information dont vous avez besoin.
Le but de cet article est de combler ces petits manques. Je vais donc reprendre le déroulé d’installation d’un cluster ACS, en renvoyant à la doc pour tout ce qui est parfaitement expliqué dedans, mais en me permettant des rajouts sur les quelques infos que j’ai pris un peu de temps à trouver.
Création du cluster
Une fois connecté sur le portail Azure, quand vous cliquez sur “Nouveau” et que vous lancez une recherche sur “Azure Container Service” comme indiqué dans la documentation, vous vous retrouvez avec beaucoup plus d’options que ce qui est indiqué. En particulier, il y a ce qui semble être des instances prédéfinies, dont la séparation en “test / production / large” – du coup – n’est pas du tout expliquée.
Le mieux est de rester sur la toute première option de la liste :
Quand vous arrivez à la première page de paramétrage, quelques indications supplémentaires ne font pas de mal. Tout d’abord, le User name est celui qui sera utilisé pour se connecter au service de cluster Docker que nous sommes en train de créer.
Ensuite, pour la clé publique, c’est sûr que c’est quelque chose de facile quand on est administrateur… Mais vu que l’utilité de Docker (enfin, de mon point de vue), est justement que des développeurs puissent déployer leurs applications de manière simple, un petit rappel ne fera pas de mal pour créer un certificat sous Windows, surtout que les liens auxquels la doc renvoie sont très complexes pour pas grand chose.
Donc, téléchargez d’abord PuttyGen (en faisant attention de ne pas télécharger ça n’importe où, bien sûr), puis cliquez sur le bouton Generate de l’interface, qui vous demandera alors de bouger la souris pour créer de l’entropie. Quand c’est terminé, vous voilà avec le contenu qui nous intéresse, et présélectionné en plus pour vous faciliter le travail :
Vous pouvez alors simplement copier le contenu et le coller dans l’interface Azure. N’oubliez pas de sauvegarder la clé privée (bouton Save private key). Si vous êtes juste en phase de test et que vous n’avez besoin que d’un niveau de sécurité limité, vous pouvez ignorer l’avertissement sur l’absence de mot de passe pour protéger le certificat, ce qui vous évitera de le retaper à chaque connexion du moment que vous êtes sur une machine sûre.
Pour le groupe de ressources, je vous conseille fortement d’en créer un dédié, car le processus va créer tellement de ressources que si on ne les regroupe pas, ou pire qu’on les mélange avec d’autres, ça va vite virer à la pétaudière… Enfin, je garde exprès l’emplacement Europe occidentale pour montrer un peu plus loin une autre limite de la documentation. Au final, l’étape 1 est remplie :
A l’étape 2, on part sur du Swarm plutôt que le choix DC/OS par défaut. Ensuite, à l’étape 3, pensez bien à voir les choix supplémentaires pour les machines. Si c’est juste pour tester le fonctionnement avec plusieurs agents (après tout, c’est bien pour de la distribution qu’on fait ça), augmentez le nombre mis à 1 par défaut, et profitez-en pour utiliser des machines un peu plus petites que celles proposées, de façon que ça coûte moins cher :
Si vous cliquez sur le lien Afficher tout à droite, vous aurez même accès à des instances de machines encore plus petites, ce qui peut être mieux pour le budget si vous ne faites que des essais. Après cela, les étapes supplémentaires sont juste des confirmations, et on peut lancer la création du cluster, qui va prendre quelques minutes.
Mise en place du tunnel SSH
Pour la suite, nous allons passer sur une VM avec un Ubuntu, vu que c’est quand même beaucoup plus courant d’utiliser le client Docker depuis un Linux. La première chose à mettre en place est le tunnel SSH pour accéder au système de gestion (management) du cluster.
Tout d’abord, il nous faut récupérer le fichier .pem depuis la clé que nous avons créée auparavant. Si elle ne l’est plus, il faut revenir la charger dans Putty avec le bouton Load puis utiliser la fonction Export OpenSSH key dans le menu Conversions et fournir un nom avec l’extension .pem. Le fichier sera alors posé sur le répertoire courant de la VM Linux.
La documentation donne une partie de la ligne de commande, mais oublie quelques points qu’il est pourtant nécessaire de préciser :
- Au lieu d’installer le certificat, il est possible de simplement passer la clé par l’option –i (on lui donne alors juste le chemin du fichier .pem créé juste avant).
- Le nom à utiliser avant l’arobase est le nom d’utilisateur, donc si on l’a changé dans l’étape 1, il ne faut pas oublier de le modifier dans la commande également.
- La première partie de l’URL est composée du préfixe DNS choisi à l’étape 3 (dernière zone dans la capture correspondante plus haut) suivi de la chaîne mgmt.
- La documentation ne donne pas les codes à utiliser pour les régions Azure. Dans l’exemple, il y a japaneast, donc on pourrait en déduire que la zone Europe occidentale est codée par europewest, mais c’est bien westeurope qu’il faut utiliser.
- Enfin, attention car on est habitué à cloudapp.net, mais le domaine à utiliser est cloudapp.azure.com.
Une astuce que ne précise pas non plus la documentation est qu’on peut retrouver ceci dans le portail Azure. Pour cela, commencez par choisir le groupe de ressource créé (nom donné à la première étape), et localisez l’icone correspondant à un service et commençant par swarm-master-ip (dans la capture ci-dessous, la dernière ligne).
Une fois cette entrée sélectionnée, on peut facilement retrouver le nom complet à utiliser en allant dans les paramètres et en choisissant Propriétés :
Une dernière astuce est de rajouter l’option –vvv pour avoir le maximum de retours d’information de la commande SSH (mode verbose). Dans notre exemple, cela donnerait :
ssh -vvv -i ~/AzureContainerService.pem -L 2375:localhost:2375 -N azureuser@acsjpgmgmt.westeurope.cloudapp.azure.com -p 2200
Une dernière chose : la commande ne rend pas la main. On peut croire qu’elle ne fait rien quand on n’est pas en mode verbose, mais dans le cas contraire, on voit bien à la fin la phrase Entering interactive session, et le tunnel SSH sera ouvert tant qu’on n’entre pas un signal de terminaison avec le raccourci CTRL+C.
Le plus simple est alors de lancer un second terminal pour la suite.
Accès au cluster
Le reste est très simple donc la documentation ne manque rien :
export DOCKER_HOST=:2375
A part qu’une fois qu’on a lancé un docker run sur ce démon, il est nécessaire pour voir le résultat dans un navigateur de savoir où trouver l’URL de base, ce qui n’est pas évident dans la doc…
Là encore, on peut retrouver ce qu’il faut dans le portail Azure, en prenant dans la liste du groupe de ressources celle commençant par swarm-agent-ip et correspondant à l’icone des services :
En allant dans les propriétés (ou même directement dans le premier panneau qui reprend les paramètres essentiels), on retrouve l’adresse d’exposition du cluster :
Autre chose : inutile de se casser la tête à chercher où ouvrir les ports dans le cas d’un service de conteneurs, les principaux sont ouverts par défaut, comme le décrit la documentation :
En espérant que ces quelques précisions aideront quelques uns à mettre en place plus vite un cluster Docker !
