Meetup Docker @ Zenika Amazon EC2 Container Service ECS

Transcript

Pour ceux qui sont présents, êtes-vous prêts ? Oui, c'est bon. Merci d'être venus. Ce soir, nous avons deux présentations, vous êtes chanceux. Nous avons David qui va nous parler de Docker. C'est une introduction à Docker. Je ne sais pas qui connaît ou pas Docker. Qui connaît ? La moitié de la salle. Ça veut dire que la moitié de la salle... J'espère que ceux qui connaissent déjà découvriront quelques petites choses. Parce que c'est un projet récent, il y a pas mal d'évolutions. Ensuite, nous avons Julien d'Amazon qui va nous parler d'ECS, Elastic Container Service. Il y a 3 ans, quand je suis venu voir vos collègues, j'aurais dit : "Quand est-ce que vous nous faites un équivalent d'ECS ?" "On n'a pas besoin." Mais bon, le business change. Ça prouve qu'on est agile chez Amazon. Il va nous faire un petit tour d'horizon et nous montrer comment ça marche. Comme vous avez pu le voir, c'est déjà intégré à l'actualité. Je tiens aussi à remercier Lucas qui nous héberge ce soir et qui nous offre ce flux de vidéos pour tous les gens qui n'ont pas pu venir. On ne se doutait pas que le succès serait si grand... Il y a un Zénith à lire ! On peut avoir un amphithéâtre en tout cas ! Si des gens en font la demande, n'hésitez pas à nous le dire via Meetup, moi et Émile, si vous avez des sujets que vous voulez voir aborder, on prévoit. Si on est en avance, on peut prévoir des salles plus larges sans problème. Il faut juste qu'on sache à l'avance. Je te laisse commencer ta présentation. Merci. Je m'appelle David Gageau, je travaille chez Docker à Paris. Je travaille sur un produit qui s'appelle Docker Machine. Je vais vous montrer aujourd'hui comment mettre en place un cluster à cheval sur plusieurs clouds. On va essayer de faire un cluster sur plusieurs clouds, c'est le plus marrant. Et pour ça, on va utiliser Docker Machine, Docker Swarm et Docker Compose. Ce sont vraiment les outils de base de Docker, certains parmi vous les connaissent peut-être déjà, mais ça vaut toujours le coup de voir comment on peut les associer ensemble. Et puis je vais vous montrer aussi comment on va être à cheval sur plusieurs clouds. On va essayer de faire un réseau qu'on appelle Overlay, qui est à cheval sur plusieurs clouds, ce qui fait qu'une fois qu'on a fait ça, on a un cluster et on ne se pose pas trop la question de savoir où sont les machines. Ça fonctionne un peu magiquement. Avant de faire ça, je vais quand même vous refaire une petite présentation de Docker Machine. Je travaille dessus, ça m'arrange, c'est ce que je connais mieux, donc je peux en parler un petit peu. Docker Machine, c'est l'outil que vous connaissez, si vous le connaissez, vous le connaissez sans doute parce que c'est ce qui vous permet d'installer Docker sur un Mac ou sur un PC sous Windows. Si vous êtes sous Linux, vous avez Docker natif. Si vous êtes sur un Mac ou sous Windows, vous êtes obligé de passer par une VM qui va faire tourner un Linux dans lequel vous allez pouvoir lancer des conteneurs Docker. Et à une époque, on installait Docker via Boot2Docker, et chez Docker, on a créé un outil qui s'appelle Docker Machine qui permet vraiment d'automatiser la création de machines virtuelles VirtualBox dans lesquelles vont tourner des Linux dans lesquels est installé Docker. Mais on peut aussi installer des VM, on peut aussi faire tourner des machines dans Hyper-V, on peut faire tourner des machines sur le cloud Google, Amazon, DigitalOcean. On a un système de drivers dans Docker Machine, il y a 12 drivers, et n'importe qui peut écrire un driver qui gère son propre système de cloud, qu'il soit interne, externe ou autre. Vous pouvez écrire un driver qui doit répondre à une certaine API, et à ce moment-là, Docker Machine pourrait être utilisé pour créer des machines, les provisionner, sur lesquelles Docker est installé. Et ensuite, depuis la ligne de commande, vous allez pouvoir dire, tiens, je vais lancer un conteneur sur cette machine-là ou sur cette machine-là, je vais aller voir ce qu'il y a sur cette machine-là, ou alors je vais regrouper cette liste de machines dans un seul cluster et je vais le voir comme un seul gros host Docker. Ce qu'on va faire aujourd'hui, c'est regrouper plusieurs machines comme si c'était un seul gros host Docker, et après on va juste faire des Docker Run, et on ne sait pas trop où ça va tourner. On verra aussi comment on peut à l'inverse impacter l'endroit où ils vont tourner nos conteneurs. Docker Machine, voilà comment je peux créer une machine facilement avec VirtualBox. On va appeler ça Zenica par exemple. Docker Machine va s'occuper vraiment de tout. Il va télécharger Boot to Docker, qui est une image ISO d'un Linux Tiny Core dans lequel on va faire tourner les conteneurs. Parce que si vous ne le savez pas, Docker tourne nativement sous Linux, mais pas sur Mac. Donc le seul moyen de le faire tourner actuellement, c'est de le faire tourner dans un conteneur Linux. Il va créer la VM, il va attendre qu'elle démarre, c'est la partie la plus lente, et là on ne maîtrise pas grand chose, c'est VirtualBox qui prend son temps. Et une fois qu'il a créé la VM, il va configurer des certificats SSL sur le daemon Docker, sur la machine locale, comme ça après moi je pourrais parler de façon sécurisée à mon Docker sans que j'aie eu besoin d'installer quoi que ce soit, de configurer quoi que ce soit. Ça prend une dizaine de secondes. Une fois qu'on a fait ça, il est en train de provisionner le bout de Docker, il va copier les certificats et normalement il va nous dire que Docker est prêt à fonctionner. En fait, il me dit même comment utiliser Docker Machine. C'est un moyen assez simple. Si je lance `eval $(docker-machine env Zenica)`, il va me lister toutes les variables d'environnement que je dois exporter pour me connecter à cette machine. Quand je fais `docker run` ou `docker build`, il va aller lire ces variables d'environnement. Donc si moi, je set ces variables d'environnement, je vais pouvoir ensuite taper `docker build`, `docker run`, et au lieu de builder sur ma machine en local, il va se connecter sur cette VM. On va faire ce qu'il nous dit de faire. Il me dit qu'il faut faire ça. À partir de ce moment-là, j'ai un Docker qui tourne. J'ai l'impression qu'il tourne sur mon Mac, en fait il tourne dans une petite VM. Et je peux bien sûr faire tourner des conteneurs. Là il va télécharger l'image. On va faire un Hello World. Une fois que j'ai installé Docker Machine, maintenant j'ai un petit alias qui est DM, c'est Docker Machine. Je peux lister toutes les machines que j'ai qui tournent, soit sur VirtualBox, soit ici sur Google. Chaque machine a un nom. Il y a une machine qui est active, c'est celle que je viens d'activer. Je sais si la machine est en train de tourner. Je connais son adresse IP. Et puis je sais quelle version de Docker tourne dessus. Et donc, bien sûr, si la ligne de commande que j'ai faite tout à l'heure pour aiguiller vers la machine Zenica, je peux aussi l'aiguiller vers la machine master et puis faire à nouveau une commande `docker run`. À ce moment-là, il ne pointe plus sur ma machine VirtualBox, il va pointer sur la machine Google. Et vous voyez, moi, une fois que j'ai fait l'aiguillage, je lance les mêmes commandes. Donc qui connaissait déjà ça ? Non ? Il y a des nouveaux déjà ? Il y a au moins un nouveau ! Et alors Docker Machine, l'idée c'est ça, ça marche quand vous avez une machine sur laquelle vous n'avez pas Docker, mais en plus ça marche avec la plupart des providers de cloud, et donc vous pouvez assez facilement créer des machines, supprimer des machines, et les regrouper dans un cluster. Qu'est-ce qui se passe si je voulais créer une machine par exemple sur le cloud Google ? Est-ce que ça serait franchement différent ? Et bien non, ça ne serait pas franchement différent. Je fais ça en fait, et de la même façon, il va se connecter à Google Compute Engine et il va me créer une VM. Alors il y a des choses ici que vous ne voyez pas forcément, c'est que j'ai des variables d'environnement qui définissent mon projet sur Google, qui définissent la zone dans laquelle je tourne, le type de machine, etc. Il y a des valeurs par défaut dans la ligne de commandes, et je peux, par des flags dans la ligne de commandes, choisir mon type de machine, configurer des tags, etc. Mais moi, j'ai fait un élément environnement pour la démo. Et donc, bien sûr, je peux faire la même chose avec Amazon, Azure, DigitalOcean, OpenStack, et une fois que ça fonctionne, je vais pouvoir utiliser ma machine sur le cloud Google. On peut aller voir cette machine, elle a été créée ici. Elle va s'appeler comme ça, test. Bien sûr ça prend un petit peu de temps. Selon le cloud provider ça prend plus ou moins de temps d'installer Docker parce qu'en fait on prend une machine toute vide et on installe Docker dedans. L'idée c'est que si vous vous installez avec Docker Machine, vous maîtrisez complètement. Vous savez que c'est une version officielle de Docker qui a été installée, vous savez que c'est la dernière version, et puis vous pouvez avec Docker Machine faire des upgrades de ces machines, et vous n'avez pas besoin vous-même d'aller l'installer sur la machine. Une fois que vous avez fait ça, vous pouvez même faire un SSH sur la machine. Là je me connecte sur la machine Google, vous voyez, donc là je fais un `docker ps`, je fais un `docker ps` sur la machine Google. Et donc vous voyez, j'ai le même jeu d'instructions pour créer des machines en local de tests ou créer des machines sur le cloud. Alors une fois que j'ai fait ça, j'ai créé une machine, je peux lancer un conteneur, je peux lancer un hello world, c'est bien, je peux lancer une application, on peut essayer de faire ça. Là je suis sur test, on peut faire un `docker run`, je ne sais plus ce que j'ai, il va falloir que je fasse appel à mon anti-sèche, qui n'est pas là, bon je sais. Par exemple, je peux démarrer ça. C'est une petite démo qui démarre juste un petit service web. Et donc, si je me connecte sur cette machine-là, sur la console Google, je ne connais pas son lecteur. Si il peut, je peux même l'obtenir comme ça. Je peux connaître la version qui est installée sur cette machine, je peux faire un SSH, je peux connecter l'URL exacte de mon Docker. Et donc, a priori, je dois avoir quelque chose qui tourne sur le port 80. On peut aller voir ce qui tourne sur la machine. Il y a bien quelque chose qui tourne. Est-ce que j'ai ouvert le port 80 ? Je ne sais pas. Je vais aller plutôt sur la démo que j'avais préparée plutôt que ça parce qu'on ne va pas perdre mon temps. Si il y a du temps, je reviendrai à celle-ci. L'idée, c'est que je suis capable de lancer des conteneurs sur le cloud. Alors moi ce que j'ai décidé de faire maintenant c'est que je vais faire un petit cluster avec Swarm. Donc Swarm, l'idée de Swarm c'est que chacune de mes machines sur lesquelles j'ai Docker, je vais aussi faire tourner un conteneur qui s'appelle Swarm à chaque machine et comme ça les machines vont être reliées entre elles dans un seul cluster, et moi je vais parler à ce cluster toujours avec les mêmes commandes `docker build`, `docker run`, `docker logs`, etc. Je vais pouvoir faire la même chose et je vais attaquer mon cluster comme si c'était une machine unique. Ça c'est l'idée, sur une machine unique j'ai un certain nombre de coeurs, imaginons que j'ai autant de coeurs qu'il y a que la somme des coeurs sur toutes les machines que j'ai sur mon cluster. Et je vais pouvoir toujours parler avec le même jeu, la même ligne de commande, ça c'est vraiment puissant. Quelle que soit la taille de mon cluster, que ce soit une machine, une N machine, je vais parler de la même manière. Alors j'ai déjà créé un petit cluster parce que ça prend du temps de créer tous ces nœuds. Je vais zoomer un petit peu. Ça prend du temps de créer tous ces nœuds en fait. J'ai créé un nœud qui est important ici qui est le master. Ça c'est le master swarm. C'est lui qui va permettre... Ceux qui sont en fond ne voient pas forcément. J'ai créé un Master Swarm, j'ai créé un certain nombre de nœuds sur lesquels je vais lancer des conteneurs. J'ai un Key Value Store qui fait tourner Consul, qui permet à mes différents nœuds swarms de se synchroniser, mais aussi qui va me permettre d'avoir un réseau commun à tous mes nœuds. Pour ça, il faut forcément avoir un Key Value Store. Il y a plusieurs implémentations possibles, j'ai utilisé Consul. Et puis j'ai utilisé un nœud ici, celui-là. J'ai ouvert le firewall sur ce nœud sur HTTP. C'est lui qui va s'occuper de faire tourner. On va essayer de lancer un conteneur dessus qui fait frontend. Et on va essayer de lancer N conteneurs backend sur les différents nœuds. Et donc en fait, moi, quand je vais me connecter sur l'adresse du front, ça va rediriger sur un de ces nœuds-là. Je ne sais pas si c'est clair ce que je dis ici. C'est un truc classique, front-end, en tout cas ce sera à chaque proxy, ça peut être NGinx, et puis des back-end ce sera un site web tout à fait basique. Mais l'idée c'est que j'ai défini ces différents nœuds, je les ai créés comment ? Je les ai créés un petit peu différemment de cette ligne de commande-là. `docker-machine create`, ça, ça crée un nœud avec juste Docker dessus. En fait, si je veux créer un nœud avec Swarm, j'ai des flags qui me permettent de pré-créer ce nœud dans un cluster Swarm. En fait, je n'ai pas besoin forcément de ça. Je pourrais créer la machine avec Docker et ensuite je pourrais provisionner Swarm dessus. Mais Docker Machine offre la possibilité de pré-provisionner du Swarm. Je ne vais pas m'en passer en fait, parce que ça permet d'avoir des commandes assez simples. En l'occurrence, qu'est-ce que j'ai ici ? Vous voyez, ici j'ai créé un nœud pour mon Keystore dans lequel j'ai démarré `docker run`, j'ai démarré Consul qui va me servir de Key Value Store. Ensuite, j'ai démarré une autre machine qui va être Swarm, mais en plus qui va être mon Swarm Master. Donc lui, je l'ai mis dans la zone Europe sur Google et puis je la fais pointer vers le console et je vais donner un nom, c'est ma machine master. J'ai créé une machine front qui elle aussi est en Europe, une machine node qui est en Europe, une machine node 2 qui est aux US et une machine node 3 qui est aux US. Donc déjà mon cluster je l'ai réparti dans deux zones géographiques et on verra tout à l'heure, je vais rajouter une machine sur Amazon ECS dans mon cluster. On verra si ça marche bien. Ça en fait je l'ai déjà fait avant de venir parce que chacune de ces lignes ça prend environ 2-3 minutes. Par contre ce que j'ai pas fait c'est maintenant une fois que j'ai créé mes machines, de la même façon que j'ai fait pointer mes variables d'environnement vers une machine, je vais les faire pointer vers mon Swarm. Je vais lancer cette commande là. Donc en fait, si je décompose, ce qu'il a fait, c'est qu'il va exporter ces variables d'environnement là, qui elles pointent vers l'adresse de mon master. En fait, c'est plutôt ça. Docker, il tourne sur le port 2376 et Swarm sur le port 2376. Donc en faisant aussi `docker-machine use`, maintenant je contrôle complètement un cluster. On peut voir un petit peu à quoi ressemble mon cluster avec `docker info`. Il va me lister tous les nœuds de mon cluster. Il va me dire voilà, il y a 5 conteneurs qui tournent sur ton cluster, il y a 4 nœuds. Il y a un nœud qui s'appelle front, un nœud qui s'appelle master, nœud 1, nœud 2, je ne sais pas où il est passé, j'ai oublié dans l'opération, on va le recréer. Tous ces nœuds là en fait ont été créés. Et quand je fais un `docker ps`, quand je liste les conteneurs qui tournent sur mon cluster, il m'affiche tous les conteneurs qui tournent indépendamment du nœud sur lequel il tourne. D'accord ? Donc maintenant, si je fais un `docker run`, ça va le lancer sur un des nœuds au hasard. En fait, il y a plusieurs stratégies pour définir sur quels nœuds ça va choisir. Mais il y a des stratégies où on essaie de remplir les nœuds, des stratégies où on essaie de faire du random, des stratégies où on fait du spread. Je sais même plus ce que j'ai utilisé moi. Ça va être marqué là-bas ici. Spread. Donc Spread, je pense qu'il va essayer de les distribuer un coup d'un, un coup d'autre. Donc c'est un peu du random. Je ne connais pas exactement l'algorithme, donc je vous laisse faire, il y a tout seul. Mais l'idée, c'est une fois que j'ai ça, moi, je fais des `docker ps`, `docker run`, et je peux lancer un conteneur sur mon réseau. Par contre, ce qui est intéressant, à partir du moment où j'ai un cluster de différentes machines, l'idée, pour simplifier les choses, c'est de créer un réseau commun à toutes mes machines. Et ça, ça n'existe que depuis Docker 1.9. Depuis Docker 1.9, on a la notion de Docker de network overlay et qui nous permettent de créer un réseau commun à toutes les machines. Et ensuite, quand je démarre un conteneur sur une machine, automatiquement, elle va être capable de se connecter, de plier une machine, un nœud par son nom. Un conteneur par son nom. C'est vraiment important. Ça veut dire que vraiment, j'ai un cluster, mais... J'ai plus besoin de l'un, on va être capable de connecter un autre conteneur sur une autre machine, juste par son nom, et ça, ça va être fait automatiquement par mon réseau, mon network overlay. Alors on va le créer, ce network overlay. Voilà comment on fait. C'est vraiment très simple. Ça, c'est les commandes Docker standards. Et puis, je peux aller lister les différents réseaux qui ont été créés, il y en a un par nœud au moins et puis ça c'est mon réseau overlay qui maintenant fait que toutes mes machines sont connectées par un réseau virtuel. Vu comme ça c'est assez abstrait en fait mais en pratique vraiment c'est une puissance. C'est ce qui va nous permettre d'avoir un réseau transparent entre différents cloud providers. Voyons voir si je suis capable de faire tourner quelque chose dans ce cluster. Pour ça je vous ai préparé un petit fichier Docker Compose. Docker Compose, l'idée c'est, pour ceux qui ne connaissent pas, je vais être capable de définir dans un fichier YAML une liste de conteneurs qui doivent tourner sur mon cluster, ça peut tourner sur un nœud ou sur un cluster. Avec un cluster, on a vraiment toute la puissance du Docker Compose. Et chaque nœud va être décrit par l'image Docker que je dois faire tourner, éventuellement, est-ce que je donne un nom, quels sont les ports que je veux exposer, les volumes que je veux partager. Tout ça, de manière déclarative, plutôt que de faire des commandes `docker run` qui sont lancées par un script, je vais avoir une méthode vraiment déclarative pour décrire ce qui tourne sur mon cluster. Vous voyez ici, par exemple, je vais démarrer un conteneur qui s'appelle Interlock. Interlock, c'est développé par un de mes collègues. C'est un conteneur qui va se mettre à l'écoute des événements d'un des mondes au cœur ou d'un des mondes soir. Il va se mettre à l'écoute et donc il va être prévu. À chaque fois qu'un conteneur démarre, qu'un conteneur s'arrête, qu'un port est ouvert, etc. Donc il va pouvoir prendre des décisions en fonction de ces événements. Et en l'occurrence, Interlock fonctionne avec un mécanisme de plugin. Il y a plusieurs plugins qui sont intéressants pour nous. En particulier, il y a un plugin Haproxy qui, à chaque fois qu'un conteneur est démarré sur un cluster, Interlock va être au courant et va reconfigurer à l'avance Haproxy pour qu'il puisse faire par exemple du load balancing entre différents nœuds. Donc dès que j'ai un conteneur qui tombe, il va reconfigurer aussi, dès que j'ai un conteneur qui revient, il va configurer. Mais pour ça, en fait, il faut lui donner l'adresse du swarm à écouter. Et en l'occurrence, je lui donne juste master, je lui donne le nom du nœud, il va se connecter dessus parce que maintenant que j'ai un réseau complètement unifié entre toutes mes machines. Chaque machine a un nom DNS automatique et je n'ai plus besoin de me poser trop la question de savoir où se tourne ce nœud, où tourne ce conteneur. Donc vous voyez, c'est HAProxy, je vais démarrer. Elle est une commande interlock un peu longue. Ce qui nous intéresse, c'est qu'on se connecte à ce swarm et on va lancer le proxy. Et puis ça c'est mon front, d'accord ? Le front je vais lui mettre une contrainte, je vais dire toi tu ne peux tourner que sur un nœud qui s'appelle front. Vous voyez à partir du moment où j'ai un cluster, c'est sûr que je ne vais pas considérer tous les nœuds de la même façon. Certains nœuds vont être exposés à l'extérieur par exemple dans mon firewall ou certains nœuds vont avoir un processus plus gros plus de mémoire où certains ne vont faire tourner le front ça parle de votre tourner le back en fait je peux mettre les nœuds comme je veux surtout mais ne est surtout et sur mes conteneurs et donc à chaque fois que je lance les nouveaux conteneurs je peux cibler des nœuds soit interdire un nœud soit obligatoirement de mon détail ou tel nœud je peux aussi faire des contraintes d'affinités. Ici, je vais définir un autre conteneur qui tourne dans mon cluster, que je vais appeler back, qui va faire tourner une autre image, là c'est juste un petit site web qui tourne sur le port 80-80 et qui affiche une baleine. Par contre, ce que je vais lui dire, c'est toi, tu ne tournes que sur les nœuds qui sont node étoile, donc node 1, node 2, node 3, mais pas le front, pas le back, je ne veux pas que tu te mélanges avec les autres composants. Je veux que tu ne tournes vraiment que sur les nœuds qui te sont réservés. Et en plus, je veux faire une contrainte d'affinité, c'est que tu ne peux pas tourner sur un conteneur qui te fait tourner déjà toi. Donc, en fait, on ne peut pas avoir deux fois l'image back qui tourne sur le même nœud. Imaginons que j'ai un nœud qui prenne beaucoup de mémoire. Je ne veux pas que Swarm commence à m'encaser deux ou trois sur la même machine. Je veux vraiment que la machine soit réservée à ce nœud-là. Alors là, c'est plus pour la démonstration parce que mon conteneur est vraiment très léger, mais vous voyez les contraintes que vous pouvez avoir, soit des contraintes qui interdissent, soit des contraintes qui demandent certains nœuds, soit des contraintes d'affinité avec vraiment des conteneurs. Une fois que j'ai décrit ça dans un fichier, et bien ça c'est une manière complètement standardisée dans mon Docker pour démarrer un ou plusieurs conteneurs. Ici, je vais utiliser ce flag là pour lui indiquer qu'il faut qu'il travaille sur le réseau, sur le network overlay. Je ne sais pas si ça a évolué depuis ça, mais en tout cas, au moment où j'ai préparé ça, il fallait absolument mettre ce flag là pour qu'il puisse connaître les nouvelles fonctionnalités de networking. Et puis, on va démarrer mon cluster. Donc là, il va se connecter sur swarm. Il a à sa disposition un nœud master, un nœud front, trois nodes, ou plutôt deux, je crois, d'ailleurs, non, c'est un qui n'était pas là. Et il est en train de télécharger les images, ou plutôt chaque nœud est en train de télécharger les images qu'il va faire tourner. Et ça démarre mon cluster. Ça, normalement, c'est l'effet magique. On va vérifier qu'il démarre bien, mon cluster. Pour... Voilà, par contre, c'est petit. Donc ça, en fait, je suis connecté sur l'adresse IP de front, c'est celui-là, c'est 100k, 155, 27, 61. Parce qu'en fait, j'ai indiqué que mon interlock, il tournait forcément sur le front. C'est celui qui est ouvert sur le port 80 sur mon firewall. Et il m'indique bien qu'il y a un front-end à chaque proxy, et puis il y a un backend qui tourne. C'est normal, c'est ce que je vais demander. Moi je vais demander de faire tourner interlock qui est une front-end, je vais demander de faire tourner un back-end et donc effectivement ça tourne. Alors quand en fait j'ai demandé à faire tourner mon back, je vais donner un nom ici. Je vais dire, en fait c'est un nom de host virtuel en fait, comme ce que vous avez dans A vous, après, de vous occuper de faire pointer le DNS vers la bonne IP. Donc la bonne IP, c'est celle-ci. Moi, sur ma machine, dans mon ETCOS, j'ai juste dit que si je vais sur test local, ça va sur cette adresse IP. Mais en fait, c'est comme ça que HAProxy va faire l'aiguillage. C'est toujours la même IP que je vais taper là, mais par contre, c'est une application complètement virtuelle. Il va rediriger sur le nœud, je ne sais pas quel nœud. Comment ? Il va rediriger sur ce conteneur-là. Bien sûr, si je commence à avoir de la charge, je peux à tout moment augmenter le nombre de back-ends qui tournent sur mon cluster, juste en changeant une cible, en disant que je voudrais que les conteneurs le tip-back, il y en a deux qui tournent sur le cluster. Alors, ceux qui sont loin, je regrette le derrière. Mais normalement, assez vite, il devrait y avoir ici un deuxième backend qui démarre. Voilà. Et ça veut dire que Haproxy, en fait, l'a pris en compte, l'a intégré dans sa configuration Haproxy, et donc est prêt à servir maintenant. Il va y avoir du load balancing entre les différents nœuds. D'ailleurs, je ne sais pas si on le requête plusieurs fois, je ne sais pas si dans les stats on le voit. Je ne sais pas si on voit bien, je ne suis pas trop habitué à ce truc là. On doit voir ici les nombres de requêtes qui ont été faites globalement sur le backend et ensuite nœud par nœud. Bien sûr, pour montrer que ça fonctionne, si je fais tomber mon cluster, il va être en intégralité. Et si je fais un `docker ps`, je verrai que plus rien ne tourne sur mon cluster. Il a arrêté tous les nœuds et je peux bien sûr le redémarrer. Les images ont pour la plupart déjà été téléchargées. Et donc si je regarde `docker ps`, je vois effectivement qu'il y a bien un interlock qui tourne, deux docker démos qui tournent, et puis ils tournent un sur le node 1, un sur le node 3, puisque j'ai fait cette contrainte d'affinité qui fait que je ne peux pas avoir deux qui tournent sur le même node. Et c'est revenu, ça fait un autre. Alors on va essayer de rajouter un nœud sur Amazon. Vous êtes prêts ? Alors je crois que ma config par défaut Amazon n'est pas forcément super top. Donc ça va être un nœud qui se trouve aux Etats-Unis. Donc je vais rajouter un autre nœud. Toujours sur le même qui peut être vers le même swarm. Je vais lui donner un nouveau nom. Là, ça va être un petit peu lent parce que ça prend une image par défaut qui n'est pas forcément optimisée pour le provisioning de Docker. Je vais prendre des questions pendant que ça se passe. Mais en fait, une fois que ce sera terminé, ce nœud-là aura aussi Docker qui tourne. Il se sera joint aussi au swarm et il se sera joint au réseau overlay. Et donc, je vais être capable d'augmenter le nombre de back-end que je lance puisque maintenant j'ai un autre plus, je vais pouvoir en lancer un de plus. Il se trouve qu'en plus ce sera à cheval sur plusieurs continents et plusieurs platforms. Je ne sais pas si ça sert à un grand plus, mais vous pouvez le faire. Est-ce que vous avez des questions sur ça ? J'ai juste une question. Vous avez défini une stratégie comme quoi mais par contre quand tu as téléchargé des images, tu as téléchargé toutes les images sur tous les nœuds. Est-ce que ça c'est normal ? Ou est-ce que ça peut être configuré ? C'est le comportement actuel de Swarm en fait. En gros, quand tu fais un `docker pull` sur ta machine, tu vois ça pull une image, si tu es connecté à un swarm, tu fais `docker pull`, ça va pré-provisionner des images sur tout le cluster. C'est un vrai avantage et un vrai inconvénient. Un vrai inconvénient pour la registrie en face, qui se prend tout à coup d'une grosse charge. Ça, c'est des choses qui vont évoluer, mais actuellement, ça fonctionne comme ça. L'avantage de tout ça aussi, ça veut dire que si tu as un cluster plutôt homogène, tu fais un `docker pull`, ça va pré-provisionner sur toutes les machines, ce qui fait qu'après, ils vont pouvoir démarrer assez rapidement. Mais c'est un inconvénient clair. En taille disque, en trafic réseau. Swarm, c'est un conteneur. Tout est un conteneur. Swarm, c'est un conteneur qui est développé par un open source. C'est un conteneur qui va permettre, si tu l'installes sur tous tes nœuds qui font ton évoqueur, tu as les machines qui font ton évoqueur, tu fais tourner Swarm, à ce moment-là, ça regroupe toutes tes machines en un seul cluster. Donc c'est ça Swarm. La notion de network, c'est une combinaison de Docker et de Swarm. C'est Swarm qui procure la notion de plugin réseau. Le plugin network overlay, c'est un plugin réseau portant. À partir du moment où tu as un cluster, ça prend tout son sens. Alors effectivement, là en fait quand je crée, quand je provisionne mon cluster avec Docker Machine, il utilise une config basique de Docker Swarm. En fait, toi, tu peux à ce moment-là, tu peux essayer de manager le swarm à la main si tu veux, tu peux créer plusieurs masters avec une notion de réplication et de failover. Il y a même une pull request qu'on nous a soumise aujourd'hui pour intégrer ça dans Docker Machine, pour qu'ils configurent tout seul les swarms en mode réplication. Avec les consoles que tu as dit en postage, tu ne peux pas démarrer à nouveau ? Alors on y va. Est-ce que je peux lancer 5 back en fait ? Je pointe. Il va me dire qu'il va essayer de le faire et il dit que je n'arrive pas à trouver un nœud qui satisfait nœud égale node étoiles. Il ne trouve pas un nœud sur lequel faire tourner son rang. Comment il le fait ? Il n'a pas vraiment de mémoire. Il demande au Swarm au moment de provisionner du nombre de mémoires qu'est-ce qui tourne et à ce moment-là il sait qu'il y en a deux qui tournent à tel et tel endroit et donc quand ils vont lancer cinq, il se fait qu'il faut lancer trois etc, il n'y a pas de monitoring actif en fait des nœuds qui tournent. Oui, si tu veux avoir juste le par exemple tu voudrais pouvoir pour visionner une nouvelle. Je vois par exemple que j'ai 80% de CPU utilisées, je veux démarrer, rajouter des formes, et dès qu'elle va démarrer, comment on sait de quel est besoin, est-ce qu'il y a de cette logique d'autoscaling ? De la même façon, si tu as un nœud qui tombe, il ne va pas chercher à le recréer tout seul, c'est vraiment de pure conscience. Il propose qu'il va le faire. Ça, c'est les choses qui sont dans les cartons. C'est des choses que d'autres outils de provisioning font. Je pense que ce dont parlera Julien, il y aura des choses qui le verront, j'imagine. Mais dans Swarm, il n'y a pas ça. Swarm, c'est vraiment, on va dire, c'est la... C'est vraiment la philosophie de Docker. L'idée, c'est que vous aviez utilisé les outils pour lancer des conteneurs sur une machine, maintenant vous savez les lancer sur un cluster. Et en plus c'est suffisamment simple pour que ça s'applique à tous les types de clusters. Si vous voulez mettre dessus des briques de provisioning, vous mettez dessus des briques d'orchestration, vous mettez des briques d'orchestration par dessus. Mais l'idée c'est que même ces briques d'orchestration, vous pouvez les installer et les déployer avec Swarm. Maintenant Swarm effectivement ne va pas tout faire, c'est l'idée que vous pouvez remplacer certains goûts par vos propres compteurs. C'est quelque chose que j'ai un peu déproché, c'est une sorte de discovery en fait. Et pourquoi j'ai utilisé un équivalent store ? Parce que le réseau overlay a besoin d'un store derrière. Je ne connais pas les détails, je vous invite à creuser dans la doc, mais on a besoin d'un store pour avoir un réseau cross. Il y a plusieurs implémentations d'équivalent store. Là, j'utilise Consul, mais il y en a plein d'autres. Comment résumerais-tu les avantages de ce type de configuration par rapport à un outil plus grand, avec des fonctionnalités civiles ? La comparaison est souvent faite. Kubernetes va t'apporter certains services d'orchestration plus puissants que ce que tu as dans Swarm. Typiquement, tu décris ta cible comme je le fais avec mon Docker Compose, mais tu décris ta carge et il va toujours monitorer si le nombre de nœuds tourne toujours, et s'il y en a un qui est mort, il va le redémarrer. Il y a des choses en commun. On peut aussi utiliser l'un avec l'autre. Il y a quelques semaines, j'ai fait une démo qui avait été faite par des collègues à Kubicon. C'est une démo qui montre comment déployer un Kubernetes sur un cluster grâce à Swarm. Si tu vas voir sur la doc de Kubernetes, tu as la fameuse question : comment installer ça sur un cluster ? D'abord, tu démarres ici, ensuite tu démarres Adcidi, après tu démarres Kubelet, et après tu fais ici, et après tu fais ça. Nous avons créé un Compose File. J'ai pris les images de Kubernetes, un LCD, un API serveur, un contrôleur, un scheduler, et il y a un kubelet par nœud. Et il y a un proxy par nœud aussi. Chaque kubelet proxy sur chaque nœud. Et ça, ça provisionne sur un cluster. À partir de ce moment-là, tu peux faire du Kubernetes par-dessus. Ça, ce n'est pas tout à fait vrai, parce qu'il y a un problème actuellement, chacun va avoir son réseau et il va le complètement dire. Ça, ça va arriver un jour. Mais l'idée, c'est que Swarm est vraiment le couteau suisse qui permet de provisionner tes applis, mais aussi tes middleware. Ça ne cherche pas à tout résoudre. Ça sert juste à être le langage commun de tout ça, en fait. C'est assez dingue, dans un monde de conteneurs, que la doc d'installation de Kubernetes soit des fichiers... C'est aussi un argument pour eux pour te vendre leur service Hosted. Bien sûr, ils disent « Ah, c'est dur à installer, cliquez là, vous l'avez ». C'est normal, c'est bonne guerre. Mais voilà, on oppose souvent les deux, il y a aussi un aspect complémentaire, et puis il y a un aspect vraiment passe-partout de Swarm. Vous avez vu, c'est super léger d'installer en fait un port d'un qui tend sur chaque machine. Peut-être encore une dernière question ? Oui, en fait, là, quand je fais scale, s'ils sont tous tombés, je refais scale égale 4, il va en relancer 4. Il va relancer le nombre de... Tout à l'heure, j'avais un nœud que j'ai du mal de configurer ou je ne l'ai pas fait rejoindre le Swarm. Tu vois, là, j'ai lancé maintenant une machine sur Amazon. Si je fais Docker Info, je devrais avoir un nœud qui s'appelle 4, quelque part. Celui-là, il tourne sur Amazon maintenant. On le voit par ici. Il a été provisionné par Amazon. Et donc, voilà, j'ai rajouté un nœud à mon cluster. Et il est sur un autre cloud provider, dans un autre continent, sur un autre réseau. Mais grâce à mon réseau overlay, je peux faire communiquer tout ça. Et par exemple, je peux m'amuser à avoir un point d'entrée qui est une autre balance sur un autre continent ou alors je peux avoir un continent qui sert de secours à un autre. Il y a certains plans au-delà pour les créations qui sont des portes de la ligne sur les machines quand tu les fais sur Amazon par exemple, ça fonctionne, mais peut-être que tu parles du code que tu les portes de la ligne. En fait, c'est surtout mon Key Value Store. Lui, je l'accède sur le port 8005, je crois, ou plus comme ça. En fait, toutes les machines doivent pouvoir lui parler. C'est grâce à cette machine-là qu'on va pouvoir, à un moment donné, se mettre d'accord. Et puis, bien sûr, il faut ouvrir le port Docker et le port Swarm. Ça, c'est important. Docker Machine, quand je provisionne, j'ouvre le port Docker et le port Swarm, automatiquement. Mais je n'ouvre pas les autres ports. Par exemple, vous démarrez une application sur le port 80, c'est à vous après de prendre la main sur votre cloud provider et d'activer les bonnes règles qui vont dans le firewall. C'est pour ça aussi que si vous avez créé votre cluster avec certaines règles firewall et que vous savez que ces nœuds-là sont ouverts extérieurs, ces nœuds-là sont internes, vous pouvez mettre des labels différents et utiliser ces labels pour déployer votre fonction. Ça c'était HAProxy, il n'y a pas de front-end autre que la CLI Docker à Swarm. C'était HAProxy qui montrait ça. Interlock, c'est juste un mécanisme qui écoute les événements et qui redirige vers des plugins. Et là, le plugin, il démarre un chat proxy et il écoute, il fait les conflits des fichiers et en démarrant un chat proxy, il a cette console. On a un conteneur, c'est-à-dire ? A priori, oui, parce qu'en fait... A priori, oui, il tourne là-dedans. Je ne sais pas comment ça marche, mais a priori, oui. Sinon, on enverra un autre. Avec le concept du réseau overlay, quand tu as lancé des applications web sur Amazon, ils ne se chargent pas automatiquement de configurer toute la partie de NAT, de NAT en communication, parce que non, j'imagine, toi, t'as des en-wall. Il faut voir que c'est une configuration atroce au niveau réseau parce que les machines sont ouvertes sur internet et elles se parlent par internet. Même les machines Google se parlent par l'interface qui va sur internet. Mais grâce au réseau overlay, elles sont capables de se connecter entre elles, de se pinger, de faire des connexions entre elles juste par un nom. Que par une RAS IP, parce que la RAS IP par définition elle est complètement variable en fonction de l'endroit où tu démarres tes conteneurs, par quoi là en fait le réseau overlay va lui permettre d'avoir le nommage de façon transparente. Donc enfin cette IP est une instance ici et tout, elle sera décorée toujours sur un intermock, qui doit mettre ta rachette à la conf... Oui, oui, normalement ça marche, on va essayer pour finir avec ça. Tac, tac, on y va. Normalement, je vais avoir un peu plus de nœuds pour mon bac. Il va en démarrer un sur Easy2. Je ne sais pas où il va chercher. Mon bac est aussi pour la bactérialisation. Des sub-quiddies groupes et tout ça ? C'est là qu'il est en mer de statistiques. En fait, je ne connais pas les détails du plugin Docker Machine pour Amazon. Comme le plugin de Google, ça va faire un certain nombre de choses, donc ça va ouvrir les ports sur le Firewall pour Docker et Swarm, et ça ne fait que ça. Après, toute la config qui est propre à ton cloud provider, c'est à toi aussi de la faire. Et donc, il a démarré tout ça. Donc ici je vois bien que j'ai effectivement maintenant sur le nœud 4, j'ai ma démo qui tourne. Donc on peut aller voir un peu mon interloc où il en est. Alors, ça c'est les problèmes justement que j'avais, c'est que la latence est gigantesque. Ça amazone en plus sur un autre continent que les autres. Donc là j'ai une trop grosse latence. Mais voilà, il a détecté, le nœud est là en fait. Il ne vaut mieux pas que ce soit lui qui serve la requête mais... Voilà. Voilà, j'ai fini avec ma démo, c'était une démo assez simple mais l'idée c'était de vous montrer comment avec Docker Machine on peut provisionner une machine sur le cloud ou une machine sur le cloud. Avec Docker Swarm, on peut les relier dans un cluster qui est homogène avec un espace réseau partagé qui est bien pratique, et puis par exemple on peut utiliser Interlock pour faire du... pour réagir automatiquement au niveau des conteneurs qui sont lancés, et puis on peut utiliser Docker Compose pour décrire notre architecture. Avec tout ça, vous avez les moyens de faire des choses vraiment exceptionnelles. À vous de le faire après. Une petite dernière question. Quand tu rajoutes le troisième, il est trop historique ou pas ? Non, non, non. Quand j'ai rajouté le troisième, la machine est toute neuve. Et donc, si je fais un roll et que ça touche cette machine-là, il va faire le coup. Merci à tous. Si vous avez des questions, n'hésitez pas à me poser. Sinon, mon adresse est david.gajo.docker.com. Merci. Obrigado. On enchaîne ? Vous êtes chaud là. Merci David, c'était super. Je ne connaissais pas bien ce moment. Je vais juste effectivement regarder les docs de base. Alors on va continuer sur l'annonce. Je suis Julien Simon, je suis tech évangéliste chez AWS. Et mon job c'est de faire ce que je fais ce soir, c'est de prendre le TGV, de me balader un peu partout et de venir rencontrer la communauté technique en France. Voilà, je suis très content d'être à Lyon, je vous remercie de m'avoir invité. C'est toujours un plaisir de sortir de Paris. Oups, on a plein de choses à voir. Je préfère vous prévenir, c'est une présentation qui dure d'habitude à peu près une heure et demie. J'ai un peu élagué. Quand vous en avez marre, jetez des cailloux, hurlez, sortez en courant. Je vais essayer de faire une heure. Après, s'il y a un million de questions, je suis bien obligé de répondre. On pourra répondre après l'apéro ? Après l'apéro c'est dangereux surtout pour moi. Mais oui, une remarque pour commencer, si vous avez envie de tweeter et prendre des photos pour la présentation, évidemment il ne faut pas vous gêner. Ça fait plaisir après de les lire, de prendre les commentaires et d'améliorer la présentation. Si tous les commentaires sont bons, je suis juste content et j'aurais envie de revenir. J'en profite pour vous indiquer mon compte sur Twitter, donc adjultsimons, adjultsimons, adjultsimons, adjultsimons, qui est le compte français d'AWS, celui-là je pense que vous connaissez déjà. Et puis si vous vous intéressez aux technos que je vais présenter ce soir, les hashtags qu'il faut suivre sur Twittdeck ou ailleurs, c'est ECS et ECR. Alors le problème qu'on essaie de résoudre, il est facile à énoncer, il est... il est difficile à résoudre. Le problème qu'on essaie de l'admettre, c'est sur la base d'un ensemble de ressources matérielles, on a un ensemble de machines, en l'occurrence ici ça va être des machines virtuelles, ça ne change pas la situation. On a un ensemble de machines qui fournissent une capacité agrégée de CPU, une capacité agrégée de mémoire, et sur cette grille finalement, CPU et mémoire, on va essayer et essayer de placer au mieux un nombre arbitraire d'applications qui s'exécute dans des containers de créateurs. Et la meilleure image que je peux trouver, c'est vraiment ce petit jouet d'enfant que j'ai mis. On a tous joué à ça, à faire rentrer le cube bleu et le triangle jaune au bon endroit. Mais imaginez ça avec, au lieu d'avoir un jeu de 3 par 3, imaginez 1000 par 1000 ou 100 000 par 100 000. Et vous voyez que même avec un petit nombre de formes, ça peut vite devenir compliqué. Et finalement, ce qu'on essaie de faire, c'est ça. C'est d'orchestrer un cluster d'instances qui font tourner Docker, et on va essayer de placer au mieux nos containers. Et pour ça, il y a vraiment deux exigences. La première, c'est de savoir précisément dans quel état est le cluster. C'est combien il reste de mémoire sur telle ou telle machine, où s'exécute tel container, combien de copies d'un container s'exécute, etc. Donc vraiment gérer l'état. Et les gens qui font des systèmes distribués dans la salle, on en a un petit peu parlé tout à l'heure, David a mentionné Consul, et c'est exactement à ça que ce genre d'outil peut servir. C'est difficile d'avoir une vue principale à l'instant T des ressources sur un système distribué. C'est un problème difficile. Et donc, si on n'a pas ça, on n'a rien. La deuxième chose, c'est une fois qu'on sait décrire l'état du cluster, c'est d'être capable de manière flexible, rapide, escalable, de prendre les décisions de placement des containers. On a 1000 instances, on a 258 000 containers, il faut qu'on en place 500 de plus, où est-ce qu'on les met et si possible arriver à décider ça dans un temps court, quelle que soit la taille du cluster. Il faut aussi que le cluster soit multi-tenant, on doit pouvoir le partager entre des users, entre des projets, entre des applications, des clusters dédiés, c'est un autre temps, ça a eu son charme, mais le cluster dédié à une seule appli, c'est plus possible. Il faut que ça soit scalable, vous savez que chez AWS c'est notre obsession, c'est de penser à l'échelle tout de suite, de se dire ok, quel est le plus gros cluster qu'on peut imaginer au monde, de multiplier ça par 100 et d'essayer de le faire marcher. Et puis, David en a un peu parlé tout à l'heure, c'est effectivement des points importants. Il y a souvent beaucoup de plomberie quand on travaille avec ce genre de solution. Alors, tu as mentionné une autre solution, je ne vais pas la répéter, mais effectivement, moi je vais prendre un exemple plus générique qui va peut-être vous parler. Parce qu'il y a des gens qui ont fait du Hadoop dans la salle, qui ont monté des clusters. Quel est le premier truc qu'on installe avant même d'installer Hadoop ? David, tu n'as pas le droit à répondre. Généralement, même systématiquement, le premier truc commensal, c'est du Keeper. Donc, c'est exactement, moi, j'ai vécu ça et ça recoupe tout à fait ce que tu disais tout à l'heure. C'est-à-dire de dire, effectivement, avant d'arriver à une solution de cluster qui marche, il faut sauter 18 haies. Et surtout, une fois que c'est en prod, il faut faire vivre tout ça. Je suis comme tout le monde, je n'aime pas perdre mon temps avec de la plomberie. Je veux aller vite, je veux faire mes projets, je veux faire du business et j'aime pas qu'on m'impose une procédure d'installation et des procédures opérationnelles. En particulier, la haute disponibilité, la redondance de tout ça, ça doit être intégré dans le produit. Ça sert à rien de dire qu'on fait des clusters scalables si il faut se réveiller toutes les nuits pour réparer ce qui est cassé. Et puis, la gestion de l'état, elle doit être intégrée dans le cluster. Donc le key value store, le fameux qui va vous servir, il est intégré dans le produit. L'objectif c'est vraiment d'avoir une solution managée, clé en main, qui nécessite le minimum de plomberie, et qui vous permet le plus possible d'arriver en prod, et de lancer les applications, et de faire votre boulot. Donc les deux produits dont j'ai parlé ce soir, il y a ECS, EC2 Container Service, qui a été lancé en avril, et donc qui est le service manager qui permet de construire des clusters Docker. Alors on a toujours du match chez AWS, c'est-à-dire que les choses sont gratuites, mais en l'occurrence sur ECS, l'utilisation de ECS n'induit aucun coût supplémentaire. C'est comme ça que j'ai le droit de le dire. Donc là cette solution-là, elle ne rajoute rien à votre facture. Ce qui va être facturé, c'est les instances que vous créez, etc. C'est les VM, c'est normal. Mais l'utilisation en IAM de ECS ne coûte rien. C'est sympathique. Et ECR, qui est notre registry Docker, qui a été lancé il y a deux semaines, ou trois semaines maximum. Et donc, qui vous permet d'héberger vos images dans votre propre registry, avec vos propres droits d'accès, etc. Pour les clients qui sont dans la web, c'est sympa de pouvoir tout mettre au même endroit. Et puis d'avoir sans doute des temps de chargement d'images qui sont aussi un peu plus rapides. Là, il y a un niveau d'utilisation gratuit qui est ce qu'il est. Et puis ensuite, comme toujours chez nous, c'est de la facturation à l'usage. Comme dans S3, comme dans tous ces services que vous connaissez. Alors j'ai encore deux trois choses à vous dire mais on a dit qu'on faisait du live ce soir. On fait du live. C'est parti. Donc là pour l'instant j'ai vraiment à peu près rien dans les poches. J'ai deux démos à faire. La première j'ai rien, on va la commencer. La deuxième je l'ai à peu près parée parce qu'elle est un petit peu lourde aussi et je voulais pas perdre trop de temps. Donc on va créer un premier cluster dans la bonne fenêtre. Ça va, vous voyez bien au fond ? De précision, je suis désolé pour les gens qui sont en vidéo, ils vont avoir senti beaucoup de mal à lire l'écran. Mais ce n'est pas grave, parce que la deuxième précision, c'est que toutes les commandes que je tape là, vous les trouverez dans mes slides. Il y a ma presse et tout un tas de slides bonus où vous trouverez absolument toutes les commandes. Donc, ne vous embêtez pas à noter, à couvrir après tout ce que je vais taper. Concentrez-vous sur l'écran, posez des questions, vous trouverez tout dans les slides et donc les gens en vidéo aussi. Donc là je viens simplement de dire ok je vais travailler avec un cluster qui s'appelle MyCluster, c'est très original et que je vais lancer dans la région EU-West1, c'est à dire Amazon, la région basée en Irlande. Donc là c'est purement déclaratif, c'est juste de dire je travaille avec ce cluster là et puis maintenant je vais le lancer en une commande. Donc ECS CLI qui est la ligne de commande pour ECS, vous l'aurez compris. Hop, je démarre un cluster, je donne une paire de clés SSH parce que j'ai envie de me connecter sur les instances probablement. Capabilis IAM, on va oublier pour l'instant. On va lancer trois nœuds dans le cluster et puis on va lancer les instances qui sont de type T2 micro. Voilà, c'est chez AWS, il y a toute une panoplie d'instances qui varient en taille mémoire, en puissance CPU, etc. T2Micro c'est assez petit, c'est un giga de RAM, mais surtout ça n'induit que très peu de coûts supplémentaires. Donc il y a moyen de faire de gros clusters et de beaucoup jouer et de faire beaucoup de prototypage sans que ça ne vous coûte rien. Donc on va laisser faire ça. Ça prend entre 3 à 4 minutes et on continue. Voilà, ça c'est fait. Alors à quoi ressemble un cluster ECS ? Alors le cluster il est délimité par les pointillés. A l'intérieur du cluster on va trouver trois instances, ce qu'on appelle les instances ECS. Ce sont les machines qui vont héberger Docker et les containers à l'intérieur de Docker. Alors je le dis tout de suite comme ça, ça lève toute ambiguïté, une instance ECS c'est avant tout une instance EC2. C'est une machine virtuelle qui est configurée avec une image particulière qui contient Docker, qui contient l'agent ECS, on va en parler dans deux secondes. Donc une instance c'est une instance EC2 configurée pour ECS. Sur une instance ECS, on va donc trouver l'environnement Docker tout près installé. Oui, c'est Amazon Linux, je ne l'ai pas précisé. Pardon, il y a d'autres OS sur tout à l'heure. Mais là, c'est Amazon Linux avec Docker et donc là j'en suis. Donc tout ça, ça va démarrer automatiquement le marge. Et puis, une fois qu'on va commencer à jouer avec, on va lancer ce qu'on appelle des tâches. La tâche c'est l'équivalent, ce qui est produit par un fichier Docker Compose. Et donc à l'intérieur d'une tâche, on aura au moins un container et potentiellement plusieurs si on en a mis plusieurs dans le fichier. Une fois qu'on a fait ça, si devant on a envie de mettre des load balancer et on le fera, on le fait. On peut load balancer les services qui tournent sur l'intégralité du cluster. Alors à quoi sert l'agent ? Alors l'agent il va communiquer en fait, c'est lui qui va communiquer entre l'instance, chaque instance et le backend, le service ECS lui-même. Donc le service ECS lui-même, il a un moteur de gestion de cluster qui va prendre les décisions de placement, qui va aller prendre les décisions de démarrage de containers, de gestion globale des instances. Et puis on a un team value store, on l'a déjà dit trois fois, qui va stocker l'état distribué du cluster, qui va savoir précisément à tout instant qu'est-ce qui tourne où, qu'est-ce qu'il y a comme ressources. Donc toute cette partie jaune-là, vous n'avez pas à vous en soucier, c'est un service managé. La seule chose que vous allez faire finalement, c'est créer un cluster, décider combien d'instances vous voulez mettre dedans, et puis ensuite démarrer des tâches, lancer des conteneurs. C'est toujours intéressant de savoir ce qui se passe un peu sous le capot. Petite précision, si vous ne voulez pas utiliser l'image Amazon ECS, c'est tout à fait possible, vous avez peut-être vos propres images, il n'y a aucun souci, le code de l'agent est sur GitHub, vous le prenez, vous le compilez, vous l'installez sur vos machines, il n'y a pas de difficulté. Simplement, en particulier pour du dev ou du test, c'est bien sympa d'avoir une image toute prête et puis de ne pas se poser de questions. Ok ? C'est clair ? Ça va ? Suivez ? Alors une petite référence client, c'est toujours intéressant, j'aime bien savoir ce que font les gens avec nos technos et les autres d'ailleurs. Coursera, ils ont témoigné en octobre à notre conférence annuelle, qui s'appelle ReInvent, vous avez sûrement entendu parler de ça. Je vous ai mis le lien de la vidéo, je vous conseille de la regarder, c'est des vidéos de 45 minutes techniques, super intéressantes. Alors, il y a une tonne de slides dans cette présentation, j'en ai gardé qu'une. Ils ont comparé différentes technologies, ils ont essayé de le faire eux-mêmes, ils ont essayé de faire un orchestrateur eux-mêmes. On peut imaginer que ce n'est pas des manchots, c'est pour ça. Ils ont eu du mal, ils ont laissé tomber. Ils ont regardé Mesos, ça leur plaisait techniquement, mais ils avaient du mal à le productiser, ils avaient du mal à le faire tourner en prod. Et puis ils ont regardé Kubernetes, qui n'est pas un service manager, ce n'est pas moi qui l'ai dit, David l'a expliqué tout à l'heure. Et donc, c'est sympa, ça marche bien, mais en termes opérationnels, en termes de production, c'est lourd. Quand on a une plateforme de la taille de celle de Coursera, on peut imaginer qu'on a déjà suffisamment de soucis, qu'on a envie de dormir la nuit et qu'on n'a pas envie de se rajouter des couches de services qui peuvent provoquer les incidents. Alors, un petit deuxième, sous un ordre, différents, idem, même topo vidéo et témoignages assez compliqués, assez riches. Remind c'est une société américaine qui fait une messagerie entre les profs et les parents d'élèves. Ils ont 10 ou 15 millions d'abonnés. Donc ils ont des pics de charges terribles. On peut imaginer qu'au mois de juillet il ne se passe pas grand chose et puis qu'à la rentrée scolaire ou que quand il y a des conseils de classe ça doit taper fort. Et eux étaient hébergés donc ils ont une archi en microservices qui est intéressante, ils en parlent dans leur présentation. Ils ont un cluster de plusieurs dizaines de machines et ils tournaient sur Heroku. J'aime bien Heroku, tout le monde aime bien Heroku, mais pour eux ça posait des problèmes. Et vous voyez que la latence d'un de leurs principaux services, ils l'expliquent dans leur presse, la latence est quand même un petit peu erratique. Alors la latence moyenne, ok, admettons, mais on voit que le 95e ou 99e percentile, c'est quand même très agité. Et ça, ça veut dire qu'il y a des utilisateurs qui ont de mauvais expériences. Donc, ça, c'était Heroku. Là, ils sont passés sur ECS. Ça se passe un peu mieux. Donc, meilleure scalabilité, meilleur temps de réponse, meilleure expérience. Ok. Voilà, alors je pense que le cluster est créé. Donc on va attaquer la première démo. On va faire une petite prière au dieu des démos. Bon, ça va. Je suis en filaire, je n'ai pas de Wi-Fi. On va voir, c'est toujours un normal moment. Donc le cluster normalement est créé. On va aller chercher une image qui est sur notre registre. On va démarrer une application PHP qui est magnifique, vous allez voir, vous allez voir toute l'étendue de mes talents en PHP, on va la scaler, on va la load balancer si on a le temps, si on a envie, sinon on revient, puis on va regarder un peu ce qui se passe sous le capot, parce que comme tout est, enfin une grande partie de tout ça est basé sur EC2, il y a plein de choses intéressantes à regarder, ok ? Alors on y va. Ok, on va vérifier. Je pense que là c'est bien. Ça là c'est visible ? Ok, donc... Voilà le cluster que j'ai créé tout à l'heure. On le voit dans la console. Je vais essayer de vous montrer un peu de lignes de commandes aussi. Service Discovery, c'est le deuxième. C'est celui qu'on a vu tout à l'heure. MyCluster, c'est celui qui vient de créer. Après je vais pas faire trop de lignes de commandes parce qu'on peut s'y perdre vite fait. Mais ceux qui connaissent un petit peu AWS, vous allez retrouver vite vos réflexes, il y a une ligne de commandes, il y a du JSON, il y a tout ce qu'il faut. J'en profite pour ça, ça n'a pas grand chose à voir mais je vous montre un truc qui est sorti il y a pas longtemps, vous avez peut-être raté, qui s'appelle AWS Shell, il y a des gens qui connaissent ça, qui est un projet de la communauté qui a été réintégré. Donc l'avantage de ça, vous voyez tout de suite, c'est que on a de la complétion, on a la doc qui s'affiche directement en dessous. Bon, alors maintenant qu'est-ce qu'on va faire ? On va essayer de regarder ce qui se passe dans notre API. Alors, on a un fichier Docker Compose. Je vais lancer un service phpDemo. Il y a une image, vous voyez qu'elle est hébergée sur le registry ECR. Je ne montre pas comment on fait ça, parce que la présentation dure 6 heures. C'est super simple, il y a une commande qui va vous taper une commande Docker Login. Allez. Ah mince, oui je sais pourquoi. Donc Docker login avec un magnifique token, vous exécutez ensuite cette commande là et puis après vous utilisez les commandes normales de Docker. Donc vous faites du push, du pull, c'est les mêmes commandes. La seule différence c'est de pointer sur un repo qui est ailleurs. Donc, on va aller chercher cette image-là. Je vais revenir sur ça juste après, parce que ça, c'est effectivement un petit peu nouveau. Elle est ouverte. On va mapper le port 80 du container sur le port 80 de l'instance. Et puis, on a un point d'entrée où on va lancer un Apache, comme si l'appli web s'apparaît. Alors, qu'est-ce que c'est que CPU shares et même limite ? Je réembrouille complètement. Souvenez-vous de tout ce que j'ai dit au début. Le problème c'est faire rentrer le carré bleu dans le trou qui va bien. Le problème vraiment c'est du placement. Donc je vais dire voilà, moi cet appui je lui donne 100 points de CPU. Ce n'est pas 100 CPU mais chaque instance, on le voit là, c'est assez gros. Une instance T2 micro elle a 1024 points de CPU. C'est comme ça, c'est une valeur qu'on a décidée. On va décider que ce service là va en prendre 100. Alors si vous vouliez que ce service ait l'intégralité du CPU d'une instance, vous mettriez 1024 et puis c'est comme ça. Donc ça c'est à vous de le jauger, c'est à vous de décider quelle fraction de la machine vous voulez consacrer à ce service. Et la mémoire c'est plus compréhensible, 328 mégas de mémoire, j'ai je crois un giga, voilà, available memory, peu ou prou j'ai un giga, donc je vais lui en consacrer 128. Donc là tout de suite on voit qu'à force d'entasser les containers avec des règles de placement, avec des règles pas de placement mais d'allocations de ressources comme ça, à un moment ça va être plein. Pour l'instant c'est vide, donc tout va bien. Et donc voilà, alors là je l'ai fait simplissime pour faire une démo aussi qui reste courte. Alors j'ose pas dire que 100% de la syntaxe de Docker Compose est supportée, mais je veux dire 99,9 et puis David m'enverra des mails ensuite après en me disant, ça ça marche pas, ça ça marche pas. Mais non, c'est un fichier Compose et il n'y a pas de surprise. Bon et bien allons-y, démarrons. Voilà, donc comment est-ce qu'on démarre un service comme ça ? Donc ECS-Cli, Compose, pour lui dire que... Eh, il doit y avoir quelque chose qui s'appelle Compose dans le répertoire, regarde un peu. Service Up. Donc là, il va démarrer une copie de cette tâche. Donc si je regarde un petit peu ce qui se passe là, je vois le service qui apparaît. OK ? Je vois la Task Definition qui va être la représentation de mon fichier, finalement la description de mon service. Alors je retrouve les ports, je retrouve l'Entry Point. Si j'avais monté des volumes, je les verrais là aussi, etc. Donc tout ça, ça peut être versionné, ça peut être... Ça peut être géré proprement. Je lui ai dit que je lui en voulais une, Desired Task. Il y en a une qui est demandée et 0 qui tourne, mais ça ne veut pas parler. C'est l'effet démo. Ça commence. Ah oui, je sais ce que c'est. J'ai oublié un truc. Il faut que je mette à jour la version de l'agent. J'ai recréé le cluster juste avant d'arriver et je ne l'avais pas fait. Ça va marcher. Donc on est toujours sur une tâche demandée. Désolé, c'était ma faute, c'est la version de l'agent qui n'était pas mise à jour. Il démarre une tâche, vous voyez que ça va vite. Il va sélectionner une instance où il y a de la place. Comme elles sont toutes vides, il en choisit une. Il va télécharger l'image et lancer le conteneur. Sur cette instance, je dois pouvoir le voir. ECS CLI PS me permet de voir la liste de tous les conteneurs sur le cluster. Je vois qu'il y a, à cette IP et sur ce port, sur lequel je vais essayer de me connecter. Normalement, ça va démarrer. Voilà, magnifique. Je cherche un job en tant que développeur PHP. On va évidemment démarrer un peu plus qu'une, mais c'est le Hello World. Je vous remontre les commandes rapidement. La commande pour créer le cluster, une commande pour démarrer le service. C'est plutôt simple. J'ai montré ce qui se passe. J'ai mes trois instances. Pourquoi j'en ai trois ? Quand je crée un cluster ECS, je crée un autoscaling group. Un autoscaling group, c'est un mécanisme qui gère entre min et max copies de cette instance. On peut le configurer intelligemment avec des alarmes : si la charge CPU totale dépasse 100% pendant 5 minutes, il peut en démarrer 2 ; si elle est inférieure à 10% pendant 20 minutes, il peut en éteindre 2. C'est CloudWatch, notre technologie de monitoring. Si vous avez des questions, on pourra en parler à l'apéro. Sous ECS, c'est EC2. C'est une bonne nouvelle, car EC2 a été lancé en 2006 et a été testé par Netflix, Airbnb, Spotify, Uber, et d'autres. On peut imaginer que c'est bien débogué. L'orchestration s'appuie sur quelque chose de robuste. Dans cet autoscaling group, on voit ce qu'on lui a dit. On lui a dit qu'on en veut 3, mais pas plus de 3. Il en fait 3. On va lui ajouter un load balancer. On va créer un load balancer, choisir le réseau, le balancer sur le port 80, et lui dire qu'on veut les deux availability zones pour avoir de la redondance. J'ai oublié de mettre un nom. On va l'appeler PHP Load Balancer. Il nous faut un security group. On va laisser passer HTTP sur le port 80, sans sécurité, pour que tout le monde puisse se connecter. Le health check se fera sur index.php. On va baisser tous les timeouts pour que ça aille plus vite. On ajoute les instances du groupe d'autoscaling. Il y en a bien trois. On fait Create. On a un load balancer. On voit mes trois instances qui sont out of service parce qu'il les configure. Il n'y en a qu'une qui devrait être in service puisque j'ai qu'une copie de mon service qui tourne. On va laisser faire ça. Vous voyez entre parenthèses, load balancer. Je l'ai fait en console, mais je pourrais le faire en ligne de commandes. En script, c'est 3 lignes, on n'en parle plus. On va le laisser se connecter gentiment à ses instances, et passer de 3 à 10 instances. Ça c'est la commande qui permet de scaler un cluster existant. Tu passes à 10 noeuds s'il te plaît. Qu'est-ce qu'il a encore ? Ah oui, c'est l'autocorrection de PowerPoint. Il a modifié l'autoscaling groupe. Il va le modifier. Entre la console et la ligne de commande, il y a toujours ces petits instants de doute. Maintenant, on va passer à 10. L'autoscaling va lancer 10 instances. On va regarder ce qui se passe dans la console EC2. Dans un délai raisonnable, des instances vont démarrer. Il boot une instance EC2, comme a fait David tout à l'heure. Il va booter l'Amazon Linux avec l'image ECS, lancer l'agent, et se connecter au classifier. Ça prend 2 minutes, mais il en lance déjà 4. Elles vont aussi rentrer dans le load balancer. C'est ça la question ? Non ? Vas-y. L'autoscaling group, je vais revenir dessus. J'ai gardé ça pour la fin. Toute la création, l'initialisation du cluster, est faite par un template CloudFormation. CloudFormation, c'est la description de toute l'infrastructure dans des fichiers JSON. Dans le template, on lui dit sur quelles A-Z démarrer. La haute disponibilité est intégrée. Vos instances sont démarrées dans toutes les AZ présentes dans la région. Ça répond à ta question ? Merci. Il y en avait une autre ? Oui, c'est ça. Tu lui dis le port 80. Tu lui dis combien de fois il doit pinguer pour décider qu'elle est en bonne santé ou malade. C'est sympa et pas compliqué. On revient sur... Vas-y, vas-y. C'est une question. C'est la lancée de tous les 10 parce que toi, tu as forcé... Comment on le fait intelligemment ? On le fait avec CloudWatch. On peut mettre des alarmes sur CPU reservation, memory reservation. On met une alarme, l'alarme alerte l'autoscaling qui dit de démarrer. C'est toujours EC2, il n'y a pas de différence, ce sont des métriques. Ça c'est lié au provisionnement de la tâche. Si tu veux déployer une tâche qui n'a plus de mémoire, il faut le faire avant. La bonne pratique est de dire que quand il reste plus que 10% d'espace, tu n'attends pas d'avoir l'erreur pour en démarrer. Le temps de démarrage d'un conteneur est zéro. Il faut essayer de ne jamais arriver au moment où tu es saturé. J'ai une instance in-service, donc ça doit être celle de tout à l'heure. Si je prends mon load balancer, elles vont arriver. Elles vont arriver, c'est parce qu'elles ne sont pas encore... On va jeter un œil tout de suite. Je copie ça pour ne pas le perdre. Voilà, ça arrive. Ils sont là. J'ai l'impression qu'il y en a 10. On va aller voir. Oui, ça a l'air d'être 10. Elles devraient arriver gentiment dans le load balancer. Ah oui, c'est la même histoire. La raison, c'est qu'on vient de supporter Docker 1.9 hier et que les outils de ligne de commande ne sont pas encore parfaitement à jour. Je ne me suis pas senti hier à 22h de remonter tout de A à Z. Je ne voulais pas trop provoquer les dieux de la démon. Ah je sais pourquoi, j'ai oublié un truc. Parce que vous m'avez perturbé, je n'ai pas ajouté le LB dans l'autoscaling. On va le faire tout de suite. Si j'avais attaché le LB à l'autoscaling group, mes nouvelles instances auraient été ajoutées. C'est pas grave. Maintenant je vais le refaire rapidement. Et puis après on va se connecter, on va voir que ça marche et après on fait la deuxième démo. Voilà, ça y est. Il les a rajoutés tout seul. J'en ai une qui est un service, donc ça c'est bien. Normalement, si je me connecte là, ça marche. D'accord ? On va rajouter maintenant tout ça. On a vu. Et maintenant, on va lui dire, tiens, je voudrais 8 fois mon conteneur, s'il te plaît. 8 fois ma tâche. ECS, CLI, Compose, Service, KL8. Il fait ce qu'on a déjà vu. Si je regarde dans mon service, Desired, 8, il n'y en a qu'une qui tourne, il va s'agiter. Vous voyez, ça va vite. Il démarre 7 nouveaux conteneurs. Le temps que ça run, il y en a trois. Mon copain, l'autre load balancer, va en voir d'autres. Elle rentre in service parce que le health check marche. Et assez vite, j'en ai 8. Là, vous me dites que c'est nul parce que c'est la même page qui s'affiche. Sauf que, comme je tiens vraiment à être développeur PHP, j'ai modifié cette page pour acheter. Quand j'ai appris HTML, je pense qu'il n'y en a pas un dans la salle qui était né. Il y avait Blink. On va s'arrêter là pour celle-là. On va vite enchaîner sur la deuxième. Ce qu'il faut retenir, c'est qu'en deux commandes, pour faire un cluster de dev, tester un truc, c'est super. Du test, l'intégration continue, tout ce que vous voulez. Et après, honnêtement, tout le reste c'est du EC2. C'est du load balancing, du security group. Si vous connaissez un peu EC2, ou si vous l'apprenez, vous faites 90% du même travail. Vous vous appuyez sur des technologies très solides, qui existent depuis longtemps. Il y a quand même un truc nul dans ce que j'ai montré : on a tout fait tourner sur des ports fixes. Un port 80, il n'y en a qu'un par instance. Donc, quand je dis j'ai 10 instances ECS et je voudrais 8 copies de mon appli PHP, sans surprise, elles vont tourner sur 8 instances différentes. On peut le vérifier. Si je fais ça, croyez-moi sur parole, il n'y a pas deux fois la même adresse IP. Pourquoi ? Parce que le port 80 n'est disponible qu'une fois. Le scheduler a essayé de démarrer. Il va dire, ah non, le port 80 est déjà pris, j'essaie ailleurs. Et il va faire comme ça jusqu'à ce qu'il ait placé tout. On arrive à faire du load balancing. On crée un ELB, qui sait load balancer des services avec des ports fixes. Service 1, en interne il est sur le port 80, en externe, il est sur 80-80, sur chaque instance, et tout ça va sur ce mode balancer. Ça a un gros problème, c'est que je ne peux pas avoir plus de copies de service 1 que d'instances. Et quand je perds une instance, je risque de perdre un tiers. Et quand on fait des microservices, on n'a pas envie d'avoir ce genre de contraintes. On a envie d'avoir la liberté de placer ces services partout, d'avoir plein de copies partout, d'avoir peut-être plusieurs copies par instance. Les microservices, par définition multiples, peuvent avoir plusieurs versions d'un même service qui tournent en parallèle, plusieurs copies qui tournent en parallèle, des déploiements continus, etc. Vous avez des serveurs qui s'allument, comment vous connaissez l'état de votre cluster ? C'est très compliqué. Vous êtes incapables de dire tel service, il est à telle adresse IP sur tel numéro de port, etc. Ça change tout le temps. Il y a des questions qui méritent d'être traitées. La première, c'est est-ce qu'on peut déployer chaque service et le scaler indépendamment ? C'est dommage de faire du microservice si on a un déploiement monolithique. Est-ce qu'on peut avoir plusieurs copies d'un même service sur le même serveur ? Comment un microservice va enregistrer son nom et son numéro de port ? Il va falloir une autorité centrale qui possède cette connaissance. Mais comment on fait ? Et comment il se découvre ? C'est-à-dire un service qui a besoin d'un autre service, comment il trouve son copain ? Comment il trouve l'IP ? Comment il trouve le port ? Et une fois qu'on a répondu à tout ça, si j'ai, comme tout à l'heure, 8 copies du même service, comment je fais du load balancing ? Bienvenue dans le monde merveilleux des microservices. La bonne nouvelle, c'est qu'on peut répondre à tout ça. Est-ce qu'on peut déployer ce qu'il y a indépendamment ? Oui, on l'a vu tout à l'heure. Un service, c'est une image Docker, une task definition, qui est le reflet d'un Docker compose, et une service definition qui est simplement combien j'en veux. On peut traiter et déployer indépendamment. Comment est-ce qu'on fait pour avoir plusieurs copies d'un service sur un même serveur ? Si on ne peut pas utiliser des ports fixes, on va utiliser des ports variables. On va laisser Docker assigner un port aléatoire. Comment est-ce qu'ils vont s'enregistrer ? Comment au démarrage d'un conteneur, on va savoir que ce conteneur-là, c'est le service Toto sur le port 1, 2, 3, 4. On va utiliser un outil qui s'appelle Registrator. Registrator, ce n'est pas un outil Amazon. C'est un outil qui va regarder ce qui se passe quand un conteneur démarre, l'introspecter, dire celui-là il s'appelle Toto et il est sur le port 1, 2, 3, 4, et envoyer l'info à Consul. Consul est un key-value store qui va être le gestionnaire de l'état des microservices. Comment est-ce qu'il se découvre ? Qui a l'information ? On a dit que c'était Consul. Donc à qui on va demander ? On va demander à Consul. Comment on va demander ? Consul supporte du HTTP, du RPC, et du DNS. On va faire du DNS, parce que c'est simple. On va sur chaque instance, installer un agent sur le port 53 qui va servir de résolveur DNS pour l'instance. Et qui sera capable de parler à son maître et de lui dire le service Toto, où il est. Rends-moi un numéro de port et rends-moi une IP. Ça, ça marche avec des records DNS qui sont des records SRV. On fait le look up à chaque fois. L'objectif, c'est que dès que quelque chose tombe, Consul désenregistre le service et ne résolve que des copies de services qui marchent. Et comment on va faire le load balancing ? Il y a deux types de services : les services user-facing, qui sont appelés par le navigateur, et les services internes, qui sont appelés par un service user-facing. Les services user-facing sont mieux s'ils sont accessibles sur le port 80. On va créer un ELB qui sera visible sur le port 80. Et puis à l'autre bout de la chaîne, on va avoir notre user-facing site qui tombe sur un port aléatoire. On va intercaler un router HTTP qui s'appelle Fabio, développé par eBay, qui est sur GitHub. L'idée, c'est de dire que quand les requêtes arrivent sur le LB sur le port 80, elles vont être envoyées par le LB à un des Fabio qui va tourner sur le port 9999. Et Fabio, via Consul, va trouver un front. Le service interne, c'est simple, on a dit qu'on faisait du DNS. Le front va dire, je veux le service Toto. On va faire un look-up DNS et lui dire telle IP, telle numéro. Un beau schéma vaut mieux qu'un bon discours. On voit trois instances ECS au sein d'un cluster. Les carrés blancs, c'est les microservices applicatifs. J'ai une application. Si vous êtes connectés sur le wifi, vous pouvez lui taper dessus. C'est une application composée de trois services. Il y a un service portail, qui est le service Front, qui va générer cette page. Vous pouvez aller sur l'URL démo.fr. Il n'y a pas de mot de passe. Vous pouvez taper dessus et vous amuser avec. Et puis, j'ai un service. J'ai deux services BAC. Un service STOX qui va afficher les cours de la bourse. Ça appelle une API chez Yahoo Finance. Et puis la météo, c'est mon moment préféré de tout le meetup. Non, on n'est pas à Grenoble ici, c'était hier, réveille-toi. Ici on est à Lyon, il fait 3 degrés 51, donc ça c'est openweather API. Et on va regarder à Paris. Et comme d'habitude, il ne fait plus chaud à Paris. Ce qui est très rigolo, c'est que quand je suis allé à Marseille c'était pareil, quand je suis allé à Bordeaux c'était pareil. Hier il gelait à Grenoble et il faisait 4 degrés à Paris, mais je suis d'accord que c'est la pollution. Je vais regarder dans ma ville natale quand même. Regardez, ce n'est pas la pollution en ville. Ouais c'est ça, il y a un petit nain derrière qui envoie des températures. Voilà le service. Maintenant qu'on l'a vu, c'est plus facile de comprendre le reste. J'ai trois instances sur ce cluster et plusieurs copies. Là, en l'occurrence, à l'instant T, je crois que j'ai qu'une copie de Portal, qu'une copie de Stocks et qu'une copie de... Mais on va en créer davantage. Quand du trafic arrive, je tape un ELB sur le port 80. Il va choisir un des Fabio. Brique noire, infrastructure. Brique blanche, service. Et ce Fabio-là, comme la reine, il va choisir un des portails qui tournent sur un port aléatoire. Ce portail va faire des look-up DNS via l'agent Consul qui tourne sur le port 53 sur son instance. Mais il est bien possible que, par exemple, si on y arrive sur ce portail-là, il fait son look-up et puis c'est possible que lui le renvoie sur ce stocks-là et sur ce weather-là. Il n'y a aucune adhérence entre les copies sur l'instance. C'est l'eau de balancer. Vous voyez le truc, il y a des aiguillages partout. Et donc, évidemment, j'ai toujours mon agent ECS, mon registrateur et puis mon serveur Consul. Avant qu'on me pose la question, je sais qu'il n'est pas rebondi, mais il y a des fois, même moi, bon, tu m'arrêtes. Ok, vous voyez le truc ? On va regarder ce qu'il y a en termes de cluster là-dessus. C'est « Service Discovery ». Voilà. J'ai mes trois services. Vous voyez bien ? Et puis j'en ai qu'un de chaque. Ils sont placés, je ne sais pas où, ce n'est pas mon problème. Ils sont placés sur mes trois instances. Je vais me connecter sur une des instances. C'est des alias, c'est SSH, pas de panique. Ok, c'est jamais. Oui je l'ai pas fait mais je peux faire Docker PS, c'est du Docker, il n'y a pas de soucis. Je vois quoi ? Je vois un registrateur, un consul, l'agent ECS, et là sur celle-là, tiens, il n'y a pas de microservice. On va les voir ailleurs. Voilà, là c'est mieux. J'ai un weather, un portal et puis mes trois briques d'infra. D'accord ? Et je dois avoir Fabio Pliton quelque part. Sinon, c'est inquiétant. Voilà, il faut que je l'ai lancé. Voilà, il est là. Lui, qu'est-ce qu'il fait ? Il écoute sur les ports de Consul et regarde ce qui se passe. Il regarde le trafic Consul qui passe et ça lui permet de savoir, tiens, ce service-là est tombé, tiens, ce service-là est débarqué. Je vais laisser cette fenêtre ouverte, on va voir les événements qui arrivent. Ça c'est la UI de Consul. On voit trois copies de l'agent. C'est normal, on a trois nœuds. On voit qu'on a trois agents Consul sur le port 53. Ça c'est bien. Il y a trois Fabio, c'est parce que le else check lui-même est et le service, ça compte pour deux. Et je vois que j'ai un portal, un stock price, un bonheur. Donc c'est ça Consul. Enfin là c'est juste, c'est la partie pas marrante de Consul, c'est la partie User Interface. Ce qui est intéressant c'est le protocole qui est en dessous, un protocole distribué. Il y a des gens qui ont étudié ça, les horloges de l'emport et tout ça. Il y a des gens qui ont fait des licences master, je ne sais pas quoi. Là aussi je m'en prends mal. Les gens qui ont lu des articles de recherche ou des bouquins sur les systèmes distribués, ça donne ça. Bon, assez parlé, ok on a vu ça. Tiens on pourrait même faire ça, ça serait vachement mieux. Il y a un peu trop de choses dans mon profil là. Ok. Donc en avant pour la deuxième démo. Ce qu'on va faire dans la deuxième démo, c'est on va tout péter et puis on va voir ce qu'il se passe. Ok ? Donc toujours pareil, je prends mon cluster Service Discovery. On va commencer par faire quoi ? On va commencer par faire ça. On va lui dire, allez, sois gentil. La météo, j'en veux pas un, j'en veux 5. Et puis... Tout ça aussi, ça se fait en ligne de commande, mais c'est un peu plus visuel comme ça. Et puis le portail, j'en veux 4. Voilà. Il va faire sa petite tambouille. Il en faut 4, il faut que je trouve des instances pour les démarrer. Et au moment où ils vont démarrer, normalement ici, Fabio doit les choper et dire, tiens, il y a un nouveau portail. Quand ça veut marcher, c'est sympa. Donc là, qu'est-ce qui s'est passé ? Je lui ai dit, j'en veux 4. Il en a démarré 3. Il n'y en manque encore un, je ne sais pas pourquoi. Il n'y a peut-être plus de place. Ok, donc il va en démarrer. Elles sont déjà pleines. Il va démarrer ce qu'il faut. Il est encore pending. Voilà, quatre. Il en a démarré trois. Registrateur détecte le démarrage de ses conteneurs sur son instance. Il introspecte, il voit que le service s'appelle Portal, que c'est démarré sur le port, machin, 1, 2, 3, 4, 1, 6, 7, 8, ce que vous voulez, que l'adresse IP d'une en question, c'est x, y, z, l, d'accord, et il envoie tout ça à Consul. Et donc là, dans mon Consul, si je fais reload, je dois avoir huit. Donc cette information-là, elle est remontée à Consul. Après, il diffuse aux agents. Et comme Fabio, il écoute ça, il le voit passer. Il voit quoi ? Il voit que le container que je lui ai dit de surveiller, que j'ai tagué avec ce tag-là, je ne rentre pas trop dans les détails, vous pourrez voir ça dans la doc de Fabio. Je lui ai mis un tag et il dit, ah, ça c'est pour moi. Ce trafic Consul là, ça m'intéresse. Il s'est passé ces containers-là, ces services-là ont démarré, donc il récupère au passage l'IP, le numéro de port, et il les ajoute dans sa route. Si je me connectais, et d'ailleurs je vais le faire, je peux le faire, évidemment. Non, ils ne sont plus amusés à la place ? Bon tant pis c'est pas là. Je choque l'IP là j'ai vite fait. On va dire que c'est celle là. J'ai une chance sur 3. J'espère que je n'ai pas pris la même. Ça tombe. Voilà, sur ce, ce n'est pas le même nœud. A priori. Ça n'a pas l'air d'être le même log exactement. Donc, si je vais sur un autre Fabio, je vois la même chose. L'autre Fabio, il a vu aussi passer les événements et lui aussi, il a intégré ses nouvelles routes. Donc, c'est assez sympa ça parce que c'est à peu près zéro config en fait. Une fois que c'est en place, ça démarre, ça s'arrête. Donc tout ça c'est sympa, mais quand même ce qu'on a envie de faire c'est des âneries. Donc on va faire ça par exemple. Ah oui, alors j'ai encore des... Oui, je suis sur la VM encore, merci. 50, c'est pas assez. Je peux faire plus, je suis pas au côté. Allez. Ah oui, c'est vrai, je sais pourquoi. C'est rien. Non. Non, non, non, c'est parce qu'il faut que je le recrée proprement. Personne en Irlande ne me téléphone, c'est mieux. Pour ne rien me cacher, je pourrais tout à fait mettre 1000, mais mon quota pour l'instant c'est 100. C'est une limite arbitraire pour éviter de faire des années. Et on ne peut pas l'augmenter de 20 à 1000 en une fois. J'ai bien l'intention d'y arriver, mais c'est comme quand on fait de la planification, on remonte par palier. Bon, ben voilà, je remonte par palier. La prochaine fois que je viens, j'essaierai de faire plus. Donc là, l'autoscaling group, maintenant vous avez compris le truc, c'est toujours la même chose. Il va les démarrer par paquet de 10. Donc il va les démarrer, ça boot la EMR Linux, ça s'enregistre dans le cluster, etc. Donc on devrait voir monter le compteur là. Il faut attendre deux minutes. Pour l'instant, j'en ai toujours que trois, mais ça va partir. Je peux répondre aux questions en parallèle. Et puis, comme on a vraiment envie de faire des âneries, on va dire maintenant j'en veux 666, pourquoi pas. Et puis là j'en veux 204. Ce que je n'ai pas dit, ce qui est important aussi, c'est de bien comprendre que le mécanisme d'autoscaling et le mécanisme de scheduling des containers, ils sont décorrélés. C'est-à-dire que le placement des tâches ne va pas attendre qu'il y ait le nombre d'instances. Les deux vont bourriner jusqu'à ce qu'on ait atteint les chiffres qu'on vient indiquer. L'autoscaling, lui, il va juste popper des VM jusqu'à ce qu'il y ait le nombre. Et le scheduler, lui, il va essayer de placer les tâches jusqu'à ce qu'il n'y arrive pas. Jusqu'à ce qu'il y arrive, pardon. Et d'ailleurs, il va commencer, il va s'énerver. Il va essayer de passer sur toutes les instances une par une et il va essayer de placer. Jusqu'à ce qu'il n'y ait plus de place. On va regarder les tâches. Les tâches, ça devrait commencer à augmenter. Pardon, je ne suis pas au bon endroit. Voilà. Donc là, j'ai déjà 30 tâches. Pourquoi ? Parce que j'ai quand même de la place sur mes instances. Même si j'en ai que 3, elles n'étaient pas du tout pleines. Donc, il va commencer à remplir les instances, à remplir les instances, à remplir les instances. On va le voir là. Ça y est, maintenant il va devoir patienter parce que comme j'ai mis 100 points de CPU, je ne sais plus ce que j'ai mis dans les fichiers, mais c'est cet endroit-là. Là, j'ai bouffé tout le CPU. En tout cas, j'ai réservé tout le CPU. Il est à 0% de CPU le cluster. Vous voyez ce que je veux dire ? J'ai réservé tout le CPU. Donc là, il ne peut plus placer. Il reste de la mémoire, mais il ne peut plus placer. Donc là, il va être obligé d'appeler que les instances arrivent. Voilà une quatrième qui arrive. Voilà, ça y est, 7, ça va commencer. Et vous allez voir, c'est parti, 10, on doit arriver à 83. Et là les tâches, c'est pareil, ça va monter gentiment à chaque fois. Je vais faire mi-load. Ok, donc voilà, 20, etc. Souvenez-vous de mon jeu d'enfant que j'ai mis tout à l'heure. Là, on est d'accord, c'est une appli simple, c'est trois petits services, etc. On pourrait faire des choses bien plus compliquées que ça, des applis riches, même du style de ce qu'a montré David, des trucs compliqués avec des containers, des dépendances, etc. Vous voyez la combinatoire, c'est à partir d'une certaine échelle, c'est juste plus possible. Il faut des outils automatiques pour faire ça. Le Coursera, je ne l'ai pas précisé tout à l'heure, mais ils se servent de CS pour exécuter le code sur tous les MOOC de programmation. Ils exécutent le code des étudiants et puis le note, etc. Donc ils ont des milliers et des milliers de containers. Il y a des gens qui l'utilisent, c'est américain, c'est moins un grand que chez nous. C'est un peu comme Heroku, on développe, on héberge des applications et eux ils sont en centaines de milliers de containers. Donc à un moment, il faut des algos et il faut un orchestratif. Après on va commencer à tuer des VM et on va voir ce qu'il se passe. Est-ce qu'il y a des questions ou est-ce que je tue des VM tout de suite ? La nouvelle zone, j'ai vu qu'il y avait la 1C, c'est parce que vous avez demandé plus de machines ? Alors, tu as vu 1C ? C'est bien possible. Non, il y a un A, un B. Non, je crois qu'il n'y a que 1A et 1B. Je ne sais pas où tu as vu 1C. C'est peut-être Minecraft qui est sur 1C. Parce que là, dans mon autoscaling group, c'est 1A et 1B. En plus, je ne suis pas sûr qu'elle existe. Elle existe, oui. Il y en a eu dans un C ? On peut regarder. Ah, c'est peut-être ça. Tu as raison. Si je tape un C... Non, on va les peut-être configurer, mais il n'y a rien qui tombe là. Il y avait une autre question ? Oui. Là, tu es parti de l'image. Et si on a notre image, pour avoir Fabio, Registrator, il faut installer l'agent, c'est ça ? C'est vrai, j'oublie à chaque fois de le dire, merci de la question, l'image Amazon Linux, elle contient Docker, l'agent ECS, là, le setup qu'on a là, où on rajoute, Registrator, Consul, Fabio, c'est quelque chose qu'on a fait nous, pour la démo. Ceci étant, ce n'est pas disponible, tu ne peux pas aller choisir l'AMI, il y a tout ça aujourd'hui. Peut-être un mec qui l'a fait. Ça ne fait pas partie du produit. Maintenant, ce n'est pas compliqué de le faire. Je ne vais pas le faire là, parce que j'ai une chance sur deux. Donc ça ne marche pas. Mais je fais ça. Je vais faire une ânerie. Allez, tac. Ah non, elle est fatiguée la console. Je pique trop vite. Voilà. Voilà. Je fais ça. Et on n'est pas loin. Je reprécise, tout est dans les bonus slides. Absolument tout. Tous les liens que j'ai utilisés, ils ne manquent pas grand chose. S'ils manquent quelque chose, c'est vraiment que j'ai oublié. Envoyez-moi un mail. Un bon week-end pluvieux, neigeux, glacial. Vous reproduisez ça, mais sans problème. Vous, vous mettrez moins d'un week-end. C'est plus rapide que moi. Mais... Il y a eu des articles de blog de la WS sur ce truc. Je précise bien, Fabio, Registrator, Consul, ça ne fait pas partie de l'ECS. Mais ça s'ajoute bien sous forme de conteneur. Vous l'avez vu, il n'y a rien de caché. Il y avait une autre question là-bas. Je veux savoir si les QS sont cultifs et les QS sont en struts. Alors, excellente question. Tout le monde sait ce que c'est les spot instances ? Les spot instances, c'est une place de marché, c'est des enchères. C'est acheter des instances aux enchères. Donc on fait request spot instance et on dit tiens moi l'instance T2 micro je sais pas quoi. Il faut choisir une image. Donc on va dire, j'en veux une et je ne veux pas payer plus de temps par heure. Et donc ça permet d'avoir, parce qu'il y a toujours de la capacité qui n'est pas forcément utilisée, et il y a une page, je ne sais plus. Vous voulez, à cette heure tardive, qui montre les prix, l'historique des prix des instances spot. Donc on sait que si on met pour tel type d'instance, si on met 4 centimes, on va en avoir. Donc ça permet d'acheter des instances à des prix très inférieurs aux prix on demand. Ça a carrément divisé par 10, c'est vraiment de cet endroit-là. Alors vous allez me dire, c'est quoi le piège ? Le piège, c'est que si jamais nous, on a besoin de la capacité pour servir du handyman, on va les reprendre. On vous laisse deux minutes. Donc, vous recevez une notification dans l'instance qui dit « dans deux minutes, je te tue ». Et « je te vends plus cher ». Mais, ça veut dire quoi ? Ça veut dire que dans du spot, il ne faut pas mettre des applications qui ont un état. Il ne faut pas mettre quelqu'un qui aura envie de mettre un costeur MongoDB dans… Dans des instant spots, n'importe quel type de cluster, sincèrement, il pourrait avoir des problèmes. Donc, quoi ? Oui, mais c'est gérable. Mais c'est plutôt pour des serveurs web, c'est plutôt pour des trucs comme ça. Et ça permet d'avoir une économie terrible. Donc oui, on peut le faire. Il suffirait de créer, on peut avoir plusieurs groupes d'autoscaling. Donc, tu aurais un groupe d'autoscaling on-demand, un groupe d'autoscaling spot. Voilà, maintenant il faut être conscient que tu risques de les perdre. D'autant plus que l'expérience montre que sur certains types d'instances, moi j'ai eu des instances spot qui ont tourné pendant des semaines, c'est moi qui les ai éteints. Oui, de temps en temps il y a des pics, ça c'est qu'en Netflix, c'est quand Netflix a besoin de kiappa. C'est quand Netflix a besoin de kiappa. Ah voilà, vous voyez, j'ai pas été... Voilà, c'est rempli là. 78 instances, et j'ai réussi à tout placer, donc il me reste encore un peu de place. Pendant 0. Ok. Est-ce qu'il y a d'autres questions ? Est-ce que dans le point il ne se produit pas des données de fragmentation ? C'est-à-dire ? La mémoire libre devient trop petite pour que le contenant est dedans et qu'on se retrouve avec toutes les instances qui ont à peu près la même quantité de mémoire disponible restante et qui est insuffisante pour tout ce que tu prends. Alors, je vois ce que tu veux dire. Je pense qu'on n'a pas ce problème. Parce qu'il faut bien voir que cette allocation de mémoire qu'on fait, c'est vraiment une allocation pour le container. Après, à l'intérieur du container, est-ce qu'il bouffe tout ou est-ce qu'il ne bouffe pas tout ? Ça, je dirais que c'est le problème du container. Et je pense que David répondrait mieux. Je pense que qu'est-ce qui se passe quand un container a plus de RAM ? Il fait un OOS. Voilà, ça peut arriver. Mais une fois que le conteneur meurt ou est tué, ou s'arrête, c'est tout. La mémoire, ça reste un Linux. Ce process disparaît, la mémoire est récupérée. Donc, non, il n'y a pas ce genre de problème. Oui ? Vous avez créé un business software. Alors un cluster il est dans une région. Par contre, ça me fait penser, mon registry aujourd'hui ECR il n'est disponible que dans US East, il n'est pas encore en Europe ? Hier alors ? Ah oui d'accord. Les registries sont cross-région. Le type d'instance est fixé dans l'auto-scaling group. L'auto-scaling group a une launch configuration où tu dis je veux ce type. Il faut créer un deuxième autoscaling group qui est rattaché au même cluster. C'est la même réponse que pour les spots. Tu pourrais avoir des petits et des gros, pourquoi pas. Est-ce que l'on utilise la même A&E dans le cluster ? Tu voudrais utiliser des AMI différentes ? Oui, même réponse. L'AMI, c'est une propriété de la Launch Configuration. Attends, à force de le répéter, je vais quand même le montrer. La Launch Configuration, c'est les paramètres de l'autoscaling group. Donc, dans une launch configuration, on dit l'image qu'on utilise, l'AMI qu'on utilise, le type d'instance qu'on utilise, et est-ce qu'on fait du spot ou pas. Donc, voilà. À partir du moment où, si toi, tu veux une autre AMI, il faudrait faire un deuxième auto-scaling group qui est rattaché au même cluster. Si tu voulais changer, si tu voulais faire du spot, etc., etc. Tout ça, ça marcherait. Une dernière question. Est-ce que la réservation d'instances fonctionne pour les instances ECS ? La réservation au sens réserve d'instances ? Oui, puisque c'est des instances EC2. Donc, tu pourrais tout à fait avoir des instances réservées. C'est des mécanismes de facturation améliorés. Je ne rentre pas dans les détails. Je vais tuer deux trois trucs, je reviens. Qu'est-ce qu'on peut ? Ah ça y est Fabio s'est planté, ça c'est cool. Alors on pourrait faire... Tiens on pourrait tuer l'agent. On va commencer par ça. Donc on tue l'agent et il est revenu. Donc ça, vous voyez, j'ai même pas le temps de le tuer et qu'il est revenu. Bon, ça c'est le back-end qui marche et qui dit « Tata, tata, l'agent est mort, il catch cet événement-là et il redémarre. » Bon, donc si la jambeur, ça se passe plutôt bien. On va tuer quelques instances. Salman. Allez, tac. Allez, on va tuer celle-là. Donc là, c'est à peu près l'équivalent d'arracher la prise. Allez, on dégage ces 4 là. Donc là, l'autoscaling va y avoir un problème. Il m'en manque 4. Donc il va en redémarrer 4. Alors au passage, j'ai sûrement perdu des... J'étais à 780 tâches. Voilà. Voilà. Je suis tombé à 776 parce que je viens de perdre des instances et il est déjà en train de les relancer. D'accord ? Voilà. Ça réagit pas mal. Ça réagit pas mal. Donc, celle-là meurt, il va en redémarrer. Ok ? Allez, j'ai un dernier slide pour vous dire merci. C'est quand même important. Vous allez écouter très très gentiment. Voilà. Donc merci infiniment. C'était encore un super meet-up. J'étais bien content de revenir à Lyon. Restons en contact surtout. J'espère bien que ce n'est pas du tout la dernière fois qu'on a été le Si vous voulez rester en contact sur ce qui se passe chez nous autour des technologies de Docker, on est sponsor officiel du Meetup de Paris. Alors vous avez vu Paris, ils sont 2500. C'est vrai. C'est vrai. Non, mais à Paris ils sont 2500, ils sont 2500, ils ne sont pas loin de chez nous. Donc bref, j'y vais tout. Les mois le prochain c'est le 21. Donc c'est la semaine prochaine. Et j'ai un petit point de 5-10 minutes où je parle des news. Alors vous allez dire oui mais on ne va pas venir à Paris tous les mois. Non, je ne vous le conseille pas. Par contre je poste mes slides systématiquement dans le forum, enfin dans la page du meetup. Donc si vous voulez avoir l'actu vous l'aurez là. Je vous ferai un petit coucou. On a beaucoup d'événements qui vont avoir lieu un peu partout à Paris et bien sûr dans les régions en 2016 comme aujourd'hui et on va essayer de faire d'autres choses aussi. Le meilleur moyen pour être au courant c'est de suivre sur Twitter. Vraiment je vous incite à faire ça. Vous aurez l'info fraîche. Les meet-up ont tendance à se remplir assez vite, vous avez vu. Il faut être réactif. On a un événement, notre événement annuel le 31 mai à Paris, une journée, peut-être deux, on verra. Donc c'est une conf technique AWS, c'est gratuit. Alors pour vous, il faut prendre le TGV, mais bon, c'est pas très cher. Vous pouvez le faire à l'alerte dans la journée, il n'y a pas de souci. Vraiment, si vous vous intéressez au techno AWS, et que vous voulez progresser un grand coup, c'est une journée que vous ne gâcherez pas. Franchement, je ne dis pas ça parce que c'est un événement à vous, Ce n'est pas une conf pipo, il y a des workshops, c'est du technique, il y a toute l'équipe technique à WS France qui est là. Vraiment, vraiment, je vous le conseille si ça vous intéresse. On vient de créer un user group à Lyon, littéralement il y a 8 ou 10 jours. La page du meetup est là. Je pense que la prochaine fois que je reviendrai à Lyon, ce sera pour celui-là. Il n'y a pas encore de date, mais on va essayer peut-être de faire ça en février. Voilà, donc n'hésitez pas à vous inscrire, c'est une autre façon de rester en contact. Il y a un user group français à WS aussi. Enfin voilà, le premier qu'on crée en région, c'est chez vous, donc c'est plutôt cool. Et puis dernière chose, ça n'a rien à voir, mais si vous vous intéressez à l'Internet des objets, il y a un événement qui s'appelle le CIDO, salon de l'Internet des objets, qui a lieu en avril chez vous, là, qu'Amazon va sponsoriser, ou encore, où on sera présent avec un stand et où on parlera aussi. Donc si le sujet vous intéresse, venez parler de ça et si vous voulez nous rencontrer, à coup sûr je serai là et j'aurai d'autres collègues qui seront là, ça ne va pas être l'occasion de discuter de tout et de rien sur Adiblovest. Voilà, je vous remercie infiniment, super meetup, si il y a des questions, on peut continuer, on va peut-être boire un coup s'il y a moyen. Parce que là, je commence à avoir sérieusement soif. Et voilà. Merci et à bientôt. Merci à tous.