Paris container Day 2017 Advanced container scheduling on Amazon ECS with Blox Julien Simon AWS

Transcript

Bonjour à tous. Merci au Container Day de m'inviter et de m'accueillir pour la deuxième année. C'est un plaisir de revenir. Je suis content d'être arrivé à peine plus en retard que vous, donc ça ne s'est pas vu. C'est très bien. Je m'appelle Julien Simon, je suis évangéliste technique chez AWS. Je travaille depuis à peu près un an et demi. Peut-être on s'est vu l'année dernière, c'est possible. Et avant de rejoindre AWS, j'ai passé une dizaine d'années en tant que CTO et VP Engineering dans des startups du web. Notre sujet aujourd'hui, c'est l'ordonnancement de containers Docker sur Amazon ECS. Alors l'année dernière, j'avais présenté Amazon ECS. Je crois que la vidéo est en ligne toujours. Je vais faire quelques rappels. Aujourd'hui on va vraiment zoomer sur la partie orchestration, ordonnancement, contraintes, etc. Et puis on finira avec une démo d'un projet open source qui a été initié par AWS qui s'appelle Blocks et qui vise à bâtir des briques de scheduling sur ECS. ECS, c'est un orchestrateur de containers qui va gérer le placement de containers Docker sur un cluster composé d'instances EC2 qui font tourner une image Linux avec Docker, un agent, etc. C'est un service qui a été lancé en 2015 et qui a le bon goût de ne rien coûter. Donc l'utilisation de ECS ne coûte rien. Vous ne payez que pour les ressources que vous créez, les instances, les load balancers, etc. On l'a complété ensuite avec un service qui s'appelle ECR, qui est un registry privé, qui vous permet d'héberger au sein de votre infrastructure, enfin au sein de votre infrastructure dans AWS, d'héberger vos containers. L'avantage étant que si vous faites par exemple du déploiement continu, vous avez vos images au plus près de votre infra et donc vous avez des temps de déploiement qui sont bien meilleurs que si vous déployez via internet depuis un hub quel qu'il soit qui peut d'ailleurs être cassé de temps en temps. Ça arrive, c'est désagréable. Si votre CI CD est bloqué, parce que ça nous est tous arrivé, c'est comme quand GitHub tombe, c'est désagréable. Donc là avec ECR, vous avez une protection contre ce genre de problème. Et les deux services sont disponibles dans pas toutes les régions mais une grande partie des régions et en tout cas en Europe. C'est un service qui a deux ans, il y a une bonne adoption sur ECS. C'est une étude qui a été faite par Datadog, que vous connaissez sans doute, qui est une super plateforme de monitoring professionnelle. Ils ont constaté deux choses donc ils ont regardé tout ce que faisait tous leurs clients finalement ils en ont pas mal et donc ils constatent et deux choses que plus l'infrastructure de leurs clients était complexe plus ils utilisaient ces services et donc plus avait un nombre d'images important que c'est un et que plus l'infrastructure de leurs clients était grosse plus la taille des clusters Docker était importante plus l'utilisation d'ECS était forte. Vous voyez qu'on arrive, ça c'est des chiffres qui datent de novembre 2016, qui sont encore relativement frais, donc ECS sur des déploiements de plus de 100 nœuds est à quasiment 40% de parts de marché, appelons ça comme ça. Donc on peut supposer qu'il est numéro 1 sur les gros déploiements. Voilà, ça doit prouver un ou deux trucs sur la robustesse d'ECS. C'est une session assez technique aujourd'hui, donc pour une fois, je ne vais pas rentrer dans les détails des clients. Mais voilà, on a plein de clients, on a énormément de références sur ECS. Si vous voulez des détails, n'hésitez pas à me poser des questions. Il y a toute une série de témoignages qui ont été faits à re-invent aussi, vous trouverez les vidéos sur YouTube. Donc si vous voulez des cas concrets d'utilisation de ECS chez nos clients et voir ce qu'ils font avec, n'hésitez pas à me demander, je vous enverrai les liens. Il y a de tout, des startups, des grosses boîtes. On a même des clients en France assez importants, qui ne sont pour l'instant pas des références publiques. J'y travaille, mais pour l'instant, je ne peux pas en parler. Mais il se passe de belles choses. On a aussi tout un ensemble de partenaires autour de CF, bien évidemment Docker, mais aussi des boîtes comme CoreOS, comme Rancher, etc. qui fournissent des AMI qui tournent parfaitement bien sur ECS. J'ai eu l'occasion de faire ces démos là. Donc tout ça s'intègre bien. Il est probable que tous ces partenaires que vous utilisez certainement soit en fournisseur de techno, soit en fournisseur d'outils, les CircleCI, CloudBiz, etc. Il y a un Datadog aussi. Qui sont présents dans la chaîne d'outillage autour des containers, et que vous utilisez certainement déjà aujourd'hui, et bien ils s'intègrent bien aussi avec ECS et avec nos technos. Donc l'avantage c'est que vous pouvez utiliser ECS en tant qu'orchestrateur sans avoir à casser tout votre outillage de déploiement, de monitoring, etc. Alors parlons maintenant, rentrons dans le vif du sujet, le scheduling. J'aimerais juste redéfinir le problème pour qu'on parle bien de la même chose. Qu'est-ce que ça veut dire ordonnancer des containers sur un cluster ? Ça veut dire, étant donné la capacité CPU totale du cluster et la capacité mémoire du cluster, et puis d'autres ressources quand même, les ports réseau, etc. Étant donné tout ça, Comment est-ce qu'à chaque instant, on est capable de prendre la bonne décision, de choisir le bon nœud pour exécuter tel ou tel conteneur ? C'est exactement ce problème-là. Sauf que là, le problème est facile parce que la grille fait 3 par 3. Maintenant, imaginez que votre grille fait 100 par 100. Vous avez des centaines de nœuds Docker en production. Vous placez des dizaines d'applications différentes en microservices, qui chacune sont composées de containers différents, avec des exigences différentes, etc. Vous avez des problèmes d'affinité entre containers, vous avez des problèmes de haute disponibilité. Vous voyez, l'ensemble de... Une fois qu'on a soufflé sur la jolie fumée rose de « j'ai une plateforme dockerisée en microservices » et qu'on commence à rentrer dans les vrais problèmes... Comment est-ce qu'on automatise tout ça ? Comment est-ce qu'on le fait à l'échelle ? Comment est-ce qu'on le fait sans se lever la nuit parce que j'ai reçu un SMS d'alerte et que c'est cassé ? C'est ça le problème qu'on essaie de résoudre. Un bref rappel sur ECS. Je l'ai dit, ECS, c'est avant tout un back-end qui va faire essentiellement deux choses, qui va connaître de manière très précise l'état du cluster et l'état des containers sur le cluster. Donc il y a un key value store qui en temps réel sait précisément qu'est-ce qui se passe, sur quel nœud, quelles sont les ressources disponibles, quels sont les containers qui tournent, quelles sont les décisions qu'il faudrait prendre éventuellement. Et donc il y a une deuxième brique qui va vraiment être la brique d'ordonnancement, qui en fonction des paramètres que vous lui aurez donné, en fonction du nombre de containers que vous lui aurez demandé de garder vivant sur le cluster à chaque instant, etc. En fonction des contraintes qu'on va placer, on verra tout à l'heure, il va travailler en permanence pour s'assurer que tout ça est respecté. Si un nœud tombe, il va en relancer un autre, il va relancer les containers qui étaient sur ce nœud, etc. Donc l'idée c'est vraiment d'avoir un certain qui vous décharge de la gestion de l'infrastructure et qui vous décharge de la plomberie, qui vous permet de vous concentrer sur votre appli. Donc sur chaque nœud du cluster, on a évidemment Docker installé. On a un agent, ce qu'on appelle l'agent ECS, qui est open source, qui n'est pas très gros, et qui sert essentiellement à une chose, qui sert à communiquer, qui sert au back-end, pour connaître l'état du nœud, et lui envoyer des ordres de lancement ou d'arrêt de conteneurs à chaque fois que c'est nécessaire. Et voilà, en gros c'est tout. Et puis devant, si on a envie de mettre des lots de balancer et de faire des choses comme ça, très bien. Donc ça c'est possible. Ça c'est ECS tel qu'il est sorti. On a eu une bonne adoption d'emblée. Maintenant si on se repose la question, du scheduling, avec cette architecture-là, il y a deux solutions finalement. Soit on laisse ECS faire tout seul, c'est-à-dire on crée ce qu'on appelle des services. Donc un service, c'est une abstraction sur le cluster qui contient ce qu'on appelle une task definition. Donc c'est l'équivalent ECS d'un compose file, c'est une liste de containers, une liste de ports réseau, une liste de volumes, etc. Donc c'est toutes les métadonnées autour de l'image. On peut la versionner, etc. Donc on lui dit, voilà, ça c'est ma task definition, donc tu me lances un NGINX plus, je sais pas, un Redis, et puis à tout instant j'en veux cinq qui tournent sur le cluster. Et donc il va se débrouiller avec ça, il va trouver des ressources, il va les lancer, si des containers meurent, il va les relancer, si un nœud meurt, il va les relancer, etc. Donc finalement, ça c'est la partie, c'est la façon la plus simple de faire, la plus automatique, mais c'est pas celle qui offre le plus de contrôle, finalement. Vous déchargez complètement du boulot, vous laissez faire ECS. La deuxième solution, c'est d'utiliser l'API d'ECS, comme tous les services AWS, il y a évidemment une API sur ECS, donc Vous pouvez, via des API REST, décrire l'état du cluster, décrire la liste des containers qui tournent. Vous pouvez avoir une vue précise de ce qui se passe. Rien ne vous empêche d'utiliser cette API pour construire votre propre scheduler. On a un client qui a fait ça, qui s'appelle Coursera, que vous connaissez, la plateforme de MOOC. Il y a une belle vidéo de re-invent là-dessus, où très tôt, la sortie du produit, ils avaient des besoins d'ordonnancement spécifique et avec l'API AWS ils ont codé leur logique de placement. Donc ils décident que tel conteneur doit aller sur tel type de nœud, telle taille de nœud, etc. Donc tout ça c'est possible, maintenant voilà c'est du travail, c'est du code, c'est du code à faire en plus et donc on nous a demandé de fournir davantage de fonctionnalités et la première dont je vais parler aujourd'hui, ce qu'on appelle le moteur de placement. Je vais essayer de ne pas faire trop de jargon. L'idée, c'est justement de donner davantage de contrôle aux développeurs sans leur imposer le développement d'un outil spécifique basé sur notre API. C'est une brique supplémentaire dans le back-end de ECS sur laquelle on va pouvoir appliquer ce qu'on appelle des contraintes et des stratégies. On va définir des règles de placement de containers que l'ordonnanceur va prendre en compte lorsqu'il aura besoin de lancer les containers. Quelques exemples. On peut définir des contraintes sur l'AMI, l'Amazon Machine Image. On pourrait dire que tel type de container a besoin de tourner sur tel AMI. Parce que c'est votre AMI maison, à l'intérieur vous avez déployé vos propres librairies, ou vous avez une version spécifique de Java, PHP, Ruby, ce que vous voulez. Bref, vous voulez placer spécifiquement un container sur une AMI, donc vous pouvez le faire. Vous pouvez choisir aussi une zone de disponibilité. Vous pouvez dire, ce container là, je veux le démarrer dans tel AZ, celui-là dans une autre. Si vous voulez gérer votre disponibilité à la main et étaler vos containers sur plusieurs AZ, vous pouvez le faire. Vous pouvez choisir le type d'instance. Un exemple qui vient tout de suite à l'esprit, c'est par exemple, vous avez des instances GPU, vous déployez des jobs de machine learning ou de deep learning qui ont besoin d'avoir un GPU, il faut déployer ces containers sur des nœuds qui ont un GPU, sinon ça n'a pas marché, comme dirait l'autre. On peut tout à fait faire ça. On peut définir des instances distinctes. On peut dire que ces containers-là, tu me les étales sur le plus d'instances possible. Toujours sans doute pour des raisons de haute disponibilité. Et puis il peut y avoir des attributs custom. Vous pouvez définir vos propres tags en disant Là par exemple j'ai des containers de prod ou des containers de dev et puis je les place de manière spécifique sur telle ou telle machine. Donc ça vous donne pas mal de contrôle. Alors voilà un petit exemple. Dans l'exemple du haut, on cherche les instances du cluster qui sont de type T2 étoile, les petites instances. Et puis dans la liste du bas, on fait un filtre sur T2 small, une taille précise d'instance. On peut interroger le cluster et lui dire, moi je ne veux placer que sur des T2 ou un cluster ou que sur des t2small ou que sur tel type d'AMI. Là on voit les contraintes qui sont utilisées par l'API list mais on peut évidemment les utiliser pour le placement des containers. C'est juste pour vous montrer la syntaxe. Là on va avoir une contrainte sur la zone de disponibilité. Dans le cas du O, on va afficher toutes les instances qui tournent dans toutes les AZ de US East One et puis en bas on affiche les instances qui tournent uniquement dans US List1A. Donc voilà, là aussi, c'est une syntaxe qui n'est pas très compliquée, que vous pouvez utiliser dans vos stratégies de placement. On peut évidemment les combiner. Donc là, on veut la liste des nœuds qui sont en bas, qui sont soit T2 Small, soit T2 Medium, ou G2, donc les instances GPU, et qui ne sont pas dans la zone de disponibilité indée. Bon, après, je ne suis pas sûr que ça ait un sens de faire ça en prod, mais c'est pour vous montrer que c'est un petit langage tout simple pour faire finalement des requêtes et être capable de filtrer les instances qui sont candidates à l'exécution de tel ou tel container. Donc ça, c'est les contraintes. Donc c'est plutôt pour sélectionner ou interdire finalement d'exécuter des containers dans telle ou telle condition. Après, la deuxième fonctionnalité qu'on a ajoutée, c'est les stratégies de placement. Donc ça, les stratégies, ça vient en deuxième. Donc une fois qu'on a sélectionné des instances qui peuvent accueillir nos containers, en fonction de ce qu'on a vu juste avant, comment est-ce qu'on veut déployer les containers sur ces instances. Donc là on a quatre politiques, bin packing, c'est c'est d'entasser le maximum sur la même instance. En termes de disponibilité, ce n'est pas extraordinaire, par contre en termes d'optimisation des coûts c'est plutôt pas mal. Je veux que l'utilisation de mon cluster soit maximum, je veux que mes nœuds soient très chargés parce que je veux peut-être le minimum de nœuds possible pour payer le moins possible. Ensuite on a Spread, donc Spread on va les étaler, un peu en rang de robin. On a Affinity, où on va pouvoir rapprocher des containers l'un de l'autre. Donc je sais pas, ça peut être un web et un cache, un truc comme ça. Des choses qui ont besoin d'être sur le même, sur le même nœud. Et puis Distinct, qui est là tu, non je n'en veux qu'un par Je n'en veux qu'un par instance. Là aussi, on peut les chaîner. Par exemple, on peut dire que tu me les étales entre les zones de disponibilité, mais par contre, à l'intérieur d'une zone, tu me binpacks. C'est un peu comme tout à l'heure, ce n'est pas fromage ou dessert, c'est fromage et dessert. On peut combiner ces règles pour avoir des stratégies de placement assez sophistiquées. Regardons quelques exemples. Déjà, comprenons bien comment ça marche. Déjà, il y a les contraintes du cluster. Il y a l'ensemble des nœuds qui composent le cluster. Le CPU disponible, la mémoire disponible, les ports réseau disponibles. Ça, c'est intangible. Si vous en voulez plus, il faut rajouter des nœuds. Ensuite, on a les contraintes, ce qu'on a vu tout à l'heure. filtrer sur le type d'instance, filtrer sur l'AMI, filtrer sur les AZ, etc. Donc ça commence déjà à restreindre la quantité d'instance disponible. Ensuite, une fois qu'on a ce jeu d'instance, on applique la stratégie de placement, donc spread, bin pack, etc. Et puis ensuite, on fait le placement. Ok ? Alors, on va faire quelques exemples. Avant de faire ça, je dois lancer une ou deux choses pour la démo de tout à l'heure. Parce que j'ai l'incorrigible habitude de faire des démos live, je m'excuse. Je vais en profiter pour vous montrer comment on crée un cluster sur ECS. Voilà. J'utilise une ligne de commande qui s'appelle ECSCLI. Là, tout simplement, ce que je lui dis, c'est que je vais lancer un cluster qui s'appelle WebCluster dans la région Irlande. Pour l'instant, ça a juste configuré ça. Et ça, ça va faire le lancement. Je vais lancer un cluster avec cette paire de clés SSH pour que je puisse me connecter dessus. Il va y avoir trois nœuds qui sont des T2 large. Voilà donc ça normalement, si les dieux sont avec moi aujourd'hui, ça démarre. Voilà ok. Et donc ça ce que ça fait, je vais très vite mais c'est un rappel, c'est que en fait ça lance un template cloud formation qu'on voit là, c'est pas trop petit, ça va. Un template CloudFormation qui va créer, alors en l'occurrence ici, il va tout créer. Il va créer un VPC, il va créer les subnets, il va lancer les instances EC2 à l'intérieur avec la bonne AMI Docker, etc. Donc on va laisser ce truc-là tourner deux minutes. Ça va prendre un peu plus que deux minutes. Et puis, je vais en lancer un deuxième. C'est pour ma démonstration. Je lance juste et puis je l'expliquerai après. Je reviendrai sur ça tout à l'heure. Quelques exemples. Là, on fait runTask. On veut en placer 5 avec comme contrainte le type d'instance doit être G2 2xlarge. Vous avez compris ce qui va se passer. On va les placer... On va les placer comme on peut. Donc là, on n'a pas mis de stratégie particulière. Donc là, on va placer en round-robin sur les instances qui sont bien de ce type-là. Donc pas T2 small. Alors, un peu plus compliqué. Donc là, on en a toujours cinq. Les contraintes sont... Il faut que l'instance soit T2 small ou T2 medium et qu'on ne soit pas dans la zone de disponibilité indée. Donc on va éviter évidemment tout ce qui n'est pas small ou medium. Donc on commence à placer comme ça. Voilà, là on n'a pas le choix, on est obligé d'éviter le 1D. Donc on place en rond de robin à l'intérieur de 1A. Ensuite, là on en a 9. Là on veut donc placer... Là, on n'a pas donné de type d'instance. Par contre, on veut étaler sur les AZ. Et on en a trois. Trois AZ, neuf containers. On va voir ce qui se passe. Donc là, à priori, on va faire un peu de round robin. On fait du round robin sur les AZ. Comme on n'a pas donné de contraintes sur le type d'instance, qu'on n'a pas mis de stratégie sur le type d'instance, etc., bon ben là on les place, le type d'instance n'a pas d'importance. Oui vas-y ? Alors c'est une bonne question, donc la quasi-totalité des services AWS sont régionaux, ce qui veut dire qu'ils n'opèrent qu'à l'intérieur d'une région. Un cluster ECS, il s'exécute dans une région donnée. Tu n'as pas de cluster multi-régions. Non, ça, c'est trois zones de dispo. C'est trois zones de dispo dans la région US East 1. Donc là, on lui a dit de faire un spread sur l'attribut qui est la zone de dispo. D'accord ? Le attribute availability zone s'applique au spread. Donc c'est tétale en fonction de cet attribut-là. C'est bon ? OK. Pas de soucis. Alors on continue. Dans celle-là, on en a toujours neuf. Et là, on fait spread sur les zones de dispo, mais par contre, on binpac sur la mémoire. Alors ça, ça donne quoi ? Essayez de deviner. Il a commencé par étaler sur les zones de dispo et après il fait du bin pack sur les plus petites instances. Vous voyez, il a pris dans un A et un C, il a pris la T2 micro, ce n'est pas un hasard. Il a pris celle-là parce que c'est celle qui va être la... C'est celle dont il va maximiser l'utilisation. Comme c'est la plus petite instance dans le lot, en mettant les trois containers dessus, on fait un bon usage, le meilleur usage possible finalement des ressources disponibles. OK ? Alors encore un autre. Affinité et anti-affinité. Alors, là on a donc deux containers différents. On veut en placer trois de chaque. Le premier, on veut le placer sur les nœuds qui sont tagués avec l'attribut « web server », quelque chose qu'on aura défini par ailleurs. Et dans l'autre, par contre, on veut faire « not web server ». Alors, en avant... Et l'autre. Voilà. Ok ? Donc si j'ai tagué par exemple une instance précise avec ce tag-là, je peux m'assurer que les containers qui ont cette affinité-là arriveront toujours au même endroit, et à contrario, que les containers qui ont l'anti-affinité iront à un endroit différent. On aurait pu faire On aurait pu faire une affinité entre le jaune et le violet et dire « tu me mets un jaune et un violet par nœud et tu te débrouilles ». Encore un exemple. Là, on a cinq jaunes et six violets. On fait « bin pack mémoire » sur le premier et « spread az » sur le deuxième. Donc le bin pack mémoire, on choisit la plus petite instance et on bourre. Jusqu'à ce qu'il n'y ait plus de place. Là, on se dit que les cinq rentrent. Très bien. L'autre, on lui a dit que tu t'étales sur les AZ. Donc il va essayer d'étaler au maximum les Alors là, vous voyez, par exemple, sur le dernier placement, les deux violets de 1D sont sur le même nœud, parce que sans doute il n'y a plus la place sur T2 Small. Donc vous voyez un peu le niveau, on peut aller assez loin. Alors encore un. Ah oui, là il y a les instances GPU. Sur les jaunes, on va chercher une instance GPU, enfin G2, mais avec une contrainte distincte. Sur le deuxième, on va chercher T2 Small ou T2 Medium avec aussi une contrainte distincte. Donc là, on devrait avoir distincte, souvenez-vous, ça veut dire un seul container par instance. Donc, il a placé les deux jaunes sur les deux instances GPU qui étaient disponibles. Il ne peut pas placer le troisième. D'accord ? Puisque ça violerait la contrainte sur la distincte. Et puis pareil pour les violets. Il avait neuf containers à placer, il n'y avait que quatre instances. Alors bien sûr si je relance des instances, ensuite je vais réussir à satisfaire mes contraintes. On pourrait d'ailleurs l'automatiser ça. pourrait détecter qu'une contrainte n'est pas complètement satisfaite et démarrer automatiquement des nœuds, etc. Voilà quelques exemples rapides de ce qu'on peut définir. On a quand même pas mal de flexibilité, à la fois sur la sélection des instances et sur la façon dont on exécute les contraintes. sur les instants sélectionnés. Donc on arrive à faire à peu près ce qu'on veut, je pense. Voilà pour cette première extension sur ECS, qui est bien plus flexible que ce que je décrivais au début, où soit on laisse ECS tout faire tout seul, soit on utilise l'API et on se code un scheduler, comme Coursera. Là, sans coder, finalement, juste en définissant un ensemble de règles avec une syntaxe qui ne fait pas très mal à la tête, vous arrivez à implémenter des stratégies relativement complexes. On a continué à travailler là-dessus. Je vais jeter un œil à mes templates. Parfait. Ça ne veut pas dire que ça ne va pas ne pas marcher après, mais c'est déjà une bonne étape. Donc ça c'est sympa, ce qu'on vient de voir, les contraintes et les stratégies. Maintenant, ça ne répond pas à comment j'agis en temps réel sur les événements qui se passent sur mon cluster. Il se passe un truc sur mon cluster, je veux le savoir tout de suite et je veux réagir tout de suite. Donc on a rajouté, donc ça, le placement engine, on l'a vu, on a rajouté un autre module qui s'appelle le flux d'événements. Et comme son nom l'indique, c'est un... Oh là là, je savais qu'on avait l'élite des utilisateurs de Docker aujourd'hui. Donc ce flux, en fait, il va tout simplement, à chaque fois que... quelque chose se produit sur le cluster, il va remonter des événements en temps réel. On va voir comment et surtout on va voir ce qu'on en fait. Par exemple ici, il y a un nœud qui a démarré, des containers qui ont été lancés, ça va envoyer une rafale d'événements. On relance un autre nœud encore avec des containers, paf, nouveaux événements. Donc l'idée maintenant, c'est ces événements, c'est de les attraper et de les traiter. Donc comme beaucoup de choses dans AWS, ces événements vont être envoyés vers CloudWatch Events. CloudWatch, c'est la technologie de monitoring d'AWS, qui permet de faire du monitoring classique, des graphes, des alertes, des métriques, tout ça, et dans lequel il y a un sous-service qui s'appelle CloudWatch Events, qui lui capte des événements d'infrastructures qui se produisent sur votre plateforme. Et surtout, qui permet ensuite de déclencher une action sur tel ou tel type d'événement. C'est ça qui va nous intéresser. Donc voilà, là il y a un nœud qui tombe, ça n'arrive jamais. C'est parce que vous l'avez tué. Donc paf, il y a une série de containers qui se cassent la figure. Là aussi, ça envoie une rafale. à l'événement et on va les envoyer à CloudWatch Events. Donc à chaque fois qu'il va se passer un truc sur un container ou sur un nœud, on va avoir des événements. Et bien sûr, l'idée, ça va être d'agir. Alors vous pourriez le faire vous-même, vous pourriez implémenter vous-même des logiques. CloudWatch Events, aujourd'hui, il est capable de déclencher des fonctions lambda, il est capable de déclencher des notifications, SNS, des choses comme ça. Mais on s'est dit, allez, on va essayer d'aller encore un cran plus loin. On va essayer de fournir un, pas tout à fait un service en tout cas, mais via un projet open source qui s'appelle Blocks, on va essayer de fournir un ensemble d'outils qui vous permettent de commencer à agir sur ces trucs-là. Et donc le fonctionnement ici, c'est celui que j'ai décrit. Donc vos clusters, il se passe des trucs dessus, Des événements sont envoyés à CloudWatch Events. On a des événements, on reçoit un petit événement, des événements en JSON. On va définir des règles et on va dire, je ne sais pas, quand il se passe tel type d'événement, par exemple quand un container est démarré, tu fais ça. Quand un container est arrêté, tu fais ça. On peut gérer différents types d'événements. On va envoyer, on va poster ces événements dans une file, alors ce magnifique logo que vous voyez là, vous voyez ma souris ? Voilà, ça là, ce magnifique logo c'est SQS, donc on va pousser ces événements dans une file de messages et on va avoir un ensemble de briques, ici, qui vont écouter finalement ces événements et agir dessus. Donc Blocks, le template que j'ai lancé tout à l'heure, le template CloudFormation que j'ai lancé, il construit il construit tout ça. Il construit tout ce machin-là. On va en reparler. Mais l'idée, c'est ça. L'idée, c'est de s'appuyer sur des briques qui vont recevoir un flux d'événements via messages et qui vont prendre des décisions. Et donc, à l'intérieur de Blocks, il y a un NetCD qui gère l'état du cluster, l'état des notifications, sur le cluster plus exactement. Et puis il va y avoir une brique de scheduling qui va pouvoir décider de lancer tel ou tel type de serveur, tel ou tel type de conteneur ou en tout cas faire telle ou telle action de scheduling. Ok donc, en fait ça permet d'avoir finalement un accès assez direct aux décisions d'ordonnancement de ECS. On l'a vu tout à l'heure, vous pouvez le laisser faire tout seul, mais vous pouvez aussi maintenant recevoir les événements et implémenter votre propre logique d'ordonnancement des containers, en temps réel, sur tout ça qui est sympa. Celui que je vais vous montrer, dans Blocks, aujourd'hui, il y a... Donc il y a ce cluster state service, vous le trouverez sur GitHub, c'est blocks.io. Donc il y a une gestion du service, et aujourd'hui il y a un scheduler qui s'appelle le daemon scheduler. C'est un exemple d'implémentation de scheduler, tout simple, mais ça permet d'avoir un point de départ. Et donc en fait le daemon scheduler, il va s'assurer que... votre container, que vous avez une copie de votre container qui tourne sur chaque nœud. C'est tout ce qu'il fait. Ce n'est pas hyper intelligent, mais ça vous montre comment faire mieux et comment utiliser les API de ECS et les API de Blocks. Voilà comment ça va marcher. On va passer à la démo. Je pense qu'il me reste du temps. Donc ça c'est ce que j'ai fait tout à l'heure. J'ai créé via un template CloudFormation, j'ai créé tout l'environnement Blocks. Je crée ma file SQS, je configure ce qu'il faut configurer dans CloudWatch Events, etc. Et je crée un petit cluster ECS. qui ne sert pas à exécuter votre application, qui ne sert qu'à exécuter blocks, le scheduler, etc. On va le voir après. Et puis ce cluster va exposer une API REST qu'on va pouvoir utiliser pour le scheduling. Et puis j'ai créé un deuxième cluster, cette fois le fameux web cluster, qui lui est le cluster qui va être managé par blocks. Et je vais utiliser, donc il y a aussi dans le projet, il y a une ligne de commande qui s'appelle Demo CLI, qui n'est pas du tout prête pour la production, mais qui est sympa aussi juste pour faire des démos, qui va me permettre d'envoyer, justement de configurer tout ça et d'envoyer des ordres. Alors allons-y. On va regarder rapidement que tout s'est bien créé. Ah, j'ai perdu ma souris, c'est amusant. Ouh, voilà. Ok, donc ça c'est mes deux stacks, ça a l'air pas mal. Je dois les voir dans la console ECS. J'ai un cluster, j'ai le cluster Blocks, qui ne compte qu'une seule instance, parce que tout ce qu'il fait c'est d'exécuter Blocks, donc c'est pas là-dessus que je vais déployer. Si je regarde les tâches qui sont dessus, je vois juste Blocks qui tourne. Et sur mon deuxième cluster, j'avais décidé d'avoir trois nœuds, et là il n'y a rien qui tourne. C'est sur celui-là que je vais déployer. Alors en avant. Je vais reprendre mes commandes. Donc je vais décider de ce que j'ai envie de déployer sur mon cluster. Je vais lui demander de me lister, donc là je demande à ECS de me lister les task definitions qui existent. avec quoi j'ai déjà travaillé. Là il y a Blocks parce que je viens de créer un cluster. Et puis j'ai une task definition avec une appli PHP tout à fait révolutionnaire. Donc je me dis tiens une appli web, donc je vais faire ça. Donc en avant. Donc ensuite toujours en utilisant cette démo CLI Donc je vais lui dire, écoute, on va expliquer les paramètres. Donc, tu vas sur le cluster qui s'appelle WebCluster, tu vas me créer un environnement. Un environnement, c'est simplement l'entité que Blocks va gérer, tout simplement. C'est lui dire, voilà, tu vas... cet environnement sur ce cluster, je veux avoir les containers qui sont dans cette task definition. Et qu'est ce qui manque ? Voilà et puis là il manque juste ça. Donc ça c'est ma façon de déclarer finalement que le web cluster passe sous management de blocks et qu'il va falloir lancé cette task definition, tout simplement. Et que ça, ce que je décris là, ça s'appelle WebEnvironment. Donc là j'appelle l'API de Blocks, qui va enregistrer ce que je viens de lui dire. Et ensuite, je vais faire le déploiement à proprement parler. Ah oui, il faut qu'il me retourne le token, pardon. Donc là, il a dit « Ok, HTTP 200, c'est bien. » Donc ok, j'ai compris qu'il va falloir que je manage le cluster WebCluster. Voilà. Maintenant, donne-moi l'ordre. Et je vais le manager avec le Demon Scheduler, parce que c'est ça que j'ai déployé. Donc maintenant, je vais faire le déploiement à proprement parlé. Voilà. En reprenant ce token-là, qui est une espèce d'identifiant associé à l'environnement, et je reprends ça. Donc là, je lui dis « Ok, maintenant, tu déploies l'environnement que je t'ai déclaré avec la commande précédente. » Ok ? Bon, pas d'angoisse. Donc HTTP 200, ok, pending, et donc là maintenant, si je regarde ce qui se passe sur mon cluster, voilà, donc ça c'est mon web cluster, qu'est-ce que je vois ? Je vois trois containers qui sont en train d'être lancés et qui doivent être lancés maintenant. Voilà, le temps qu'il télécharge l'image. Je crois qu'elle est dans... Non elle doit être dans ECR pour le coup. J'ai trois instances ECS dans ce cluster, c'est ce que j'ai fait tout à l'heure. Et donc j'ai trois... on voit que les containers tournent. On va vérifier. Toujours vérifier. Donc on va prendre l'IP de cette machine-là. Voilà à peu près l'étendue de mes talents PHP. C'est pour ça que je fais du back-end. C'est magnifique. Donc voilà. Je vais revenir sur mon cluster. Je vois mon cluster qui a reçu l'ordre d'exécuter un container de ce type-là par nœud. Et ça, c'est le daemon scheduler. Si on réembobine un tout petit peu, je remets juste le schéma, ce qui s'est passé là-dedans, donc j'ai configuré mon déploiement, puis après je lui dis, vas-y maintenant, fais le déploiement. Et donc là, il reçoit l'ordre de déploiement, il voit qu'il y a trois nœuds dans le cluster, on lui a dit que cette task definition-là, elle doit tourner une fois par nœud, donc il démarre les containers. Donc ça, c'est l'initialisation. Ça va ? Maintenant, il faut faire des trucs. Qu'est-ce qu'on pourrait faire d'idiot ? Ce ne sont pas les idées qui manquent. On devrait voir nos containers. Ah non, pas le Wifi. Donc là, je vois mes trois containers et je vois bien qu'ils sont sur trois instances différentes. Alors, on va faire un truc idiot. On ne va pas faire de délai de cluster tout de suite. Mais on pourrait tuer une instance pour voir. Non, on ne va pas faire ça tout de suite. On va faire ça après. D'abord, on va scaler. Bon, donc on va rajouter des instances. Oui, restons disciplinés. Donc maintenant, je scale mon cluster. On s'indisciplinera à la fin. Donc mon web cluster, maintenant, je le passe à six nœuds. Donc je réutilise ma ligne de commande ECS CLI. Je dis maintenant, tu me mets six nœuds, s'il te plaît. Donc normalement, je dois avoir l'update... Voilà, je vois update in progress dans mon CloudFormation. Donc qu'est-ce qu'il va faire là ? Il va redémarrer trois nœuds, il va les joindre au cluster, etc. Donc on devrait voir d'ici deux minutes, on va avoir trois instances supplémentaires qui vont arriver dans le cluster. Donc on va leur laisser le temps de faire ça. Ça, c'est évidemment un événement, au sens événement de cycle de vie du cluster. Donc, il y a un événement ECS qui va partir vers CloudWatch Events. CloudWatch Events va le copier dans la file SQS. Il va arriver à Blocks, qui va dire, tiens, il y a des nouveaux nœuds, magnifiques, parce que moi, mon travail, c'est sur un nœud, je veux m'assurer qu'il y a la magnifique appli PHP qui tourne. Donc les nœuds sont là, mais il n'y a pas d'appli PHP, ce n'est pas grave, je fais run task et je les démarre. Et donc là, je vois une quatrième instance qui est arrivée. On va voir les deux autres qui se pointent. Voilà les six, et on voit running task, vous voyez là, elles sont à zéro. Donc elles ont démarré. Mais Blocks n'a pas encore fait son travail. Voilà, il est en train de le faire. Donc, voilà un exemple. Une fois de plus, c'est un ordonnanceur, c'est l'ordonnanceur le plus simple du monde. C'est garanti qu'il y a un truc qui tourne sur mon cluster, s'il te plaît. Voilà, donc le temps que ça démarre. Et là, maintenant, j'en ai bien six. Et si je réagisse... affiche ma liste. Je ne sais pas combien je vais en voir, 5, 6, on va voir. Voilà, on voit les 6, et on voit les 6 aussi. Et c'est bien 6 instances différentes. Ok ? D'accord ? Donc maintenant on va commencer à faire des âneries. On va imaginer qu'il y a un problème. Alors elles sont là mes instances ECS, on va les filtrer et on va décider que, je sais pas, celle-là et celle-là meurent. State, je n'ai pas les yeux en face des trous. Donc je vais faire terminate. Donc elles vont disparaître assez rapidement de ça. Pour l'instant, elles ne sont pas encore tout à fait mortes. Voilà, ça y est, on les a perdues, il y en a quatre. Donc, ça, ça va déclencher normalement plein de choses. Parce que mon ami ici, celui-là, je lui ai dit j'en veux six. D'accord ? Donc là, je viens d'en perdre deux. Donc, il va en relancer deux. D'accord ? Qui va se dépêcher de me relancer deux instances, d'ici une minute. Ces deux instances vont démarrer, elles vont rejoindre le cluster. Ça va provoquer l'envoi d'événements vers CloudWatch Events, vers SQS, vers Blocks. À nouveau, il va me redémarrer des containers sur ces deux nouvelles instances. OK ? Voilà. Bon, ça va arriver dans deux minutes. Mais voyez la logique d'automatisation. Une fois de plus, ici, on a un scheduleur qui est très simple, mais le code est dispo, et il n'y a rien qui empêche de repartir de ça et de construire quelque chose de plus sophistiqué. L'idée étant toujours la même, c'est de dormir la nuit, et que votre système se répare tout seul, jusqu'à un certain point, il se calme, tout seul et vous venez le lendemain matin au bureau et vous dites tiens il s'est passé ça cette nuit. Ok bon parfait mais pas de difficulté. Un cluster Docker ça peut être un château de cartes, on fait tout bien à la main et puis un incident et puis après qu'est-ce qui se passe ? Après comment est-ce qu'on replace les containers ? Est-ce que vous faisiez tout à la main ? Est-ce que c'était statique ? Est-ce que c'est dynamique mais est-ce qu'il est revenu dans le même état qu'auparavant. Avec ces règles qu'on a vues, les contraintes, les stratégies, vous pouvez vous assurer que vos règles métiers ou techniques sont réellement appliquées et vous pouvez avoir un scheduler comme ici qui va les appliquer en permanence à votre place et qui vous laisse faire le travail intéressant. J'ai laissé dans les slides les fameuses commandes, mais bon, c'est pas très compliqué, vous les avez vus. Si vous voulez creuser un petit peu plus, alors sur ECS, il y a trois articles qui commencent un peu à dater maintenant de Werner sur ECS, mais qui sont une bonne introduction à ECS, si vous le connaissiez mal. Donc le site de Blocks, et puis les dernières vidéos sur ECS de ReInvent, qui a eu lieu en décembre, donc qui sont encore relativement fraîches. Si vous voulez voir un peu ce qui s'est passé d'autre sur ECS, et puis surtout les sessions avec nos clients, les témoignages clients sur ECS, vous les trouverez là. Et je partagerai les slides sur Twitter tout à l'heure, donc vous les aurez. De toute façon, je ne suis pas très difficile à trouver. Si vous les manquez, vous savez où me trouver. Voilà, merci beaucoup, merci encore au Container Day. Applaudissements. Thank you.