Gerez vos containers avec Amazon ECS sur AWS

Transcript

Bonjour à tous, je suis très heureux de vous retrouver pour un nouveau webinar AWS. Au programme aujourd'hui, nous allons parler de containers, un sujet que nous n'avons pas encore abordé et que j'ai jugé qu'il était temps de le faire. Comme d'habitude, nous ferons deux webinars. Le premier sera consacré à un service qui s'appelle Amazon ECS, Service Manager. Et le second sera consacré à une solution open source que vous connaissez certainement, qui s'appelle Kubernetes. Nous verrons comment déployer Kubernetes sur AWS. Je vais commencer par Amazon ECS. Je vais vous présenter les grands concepts. On fera ensuite une démo et puis on en fera de même pour Kubernetes dans le deuxième webinar. Et comme c'est la journée d'Halloween, on verra si les démos réussissent à bien se passer. J'ai essayé de conjurer le mauvais sort, mais je pense qu'on n'est pas à l'abri d'un certain nombre de surprises. On verra. Allons, restons optimistes en avant. Alors avant toute chose, quel est le problème que nous essayons de résoudre ? Quel est finalement l'objectif d'un outil comme Amazon ECS ou Kubernetes ou d'autres ? Le problème est relativement simple à formuler. On dispose d'un ensemble de ressources matérielles, d'un ensemble de serveurs, d'un ensemble d'instances qui ont chacun une capacité processeur, une capacité mémoire. Sur cet ensemble de ressources, ce cluster, on va essayer de placer de manière la plus efficace possible un ensemble de containers Docker, donc un ensemble d'applications qui ont été dockerisées, qui ont chacun une taille mémoire, qui ont chacun une exigence en CPU. Le but est de trouver le bon endroit pour placer la bonne forme en fonction des ressources disponibles sur le cluster. Évidemment, si on se base sur neuf containers et neuf emplacements comme sur le petit jeu, le problème est assez simple et on n'a sans doute pas besoin d'un orchestrateur et d'un ordonnanceur de containers. On peut placer ces containers avec des scripts, mais en tout cas les placer de manière statique et dire que les containers 1, 2, 3 vont sur le premier serveur, 4, 5, 6 sur le deuxième, etc. Le problème devient plus compliqué lorsqu'on passe à l'échelle. Imaginez maintenant que vous devez placer des dizaines de containers différents, chacun en plusieurs exemplaires pour avoir de l'équilibrage de charge, de la redondance, et sur 10, 20, 30, des dizaines de nœuds. Ajoutez à tout ça peut-être un pipeline de déploiement continu avec des équipes qui travaillent en parallèle, qui déploient de manière indépendante chaque container, etc. Ajoutez quelques petits incidents, quelques nœuds qui reboot, quelques containers qui meurent, etc. On voit vite que ce qui était facile à très petite échelle devient particulièrement compliqué, particulièrement insoluble, finalement, de manière manuelle et même de manière programmatique. Et donc il va nous falloir un outil, un service qui va prendre ça en charge pour nous. C'est l'objectif d'un service comme ECS et d'un projet comme Kubernetes. Alors on a dit qu'on commençait par ECS. ECS, c'est un service qui a été lancé en 2015, qui est donc un orchestrateur de containers. Ce service a l'avantage de ne rien coûter. Comme CloudFormation ou Elastic Beanstalk, ce sont des services qui ne coûtent rien à l'usage. Vous ne payez que pour les ressources que vous créez, mais pas pour le service lui-même. C'est un service dont on va voir les principales fonctionnalités tout à l'heure qui va vous permettre de démarrer des containers, de préciser combien de containers d'un certain type doivent fonctionner, qui va vous permettre de relancer automatiquement des containers si jamais ils sont morts ou si le nœud qui les hébergeait est mort, etc. L'objectif est de placer en permanence le bon nombre de containers sur les meilleurs nœuds possibles. ECS a un compagnon qui s'appelle ECR, lancé un peu plus tard dans l'année, qui est un service de registre de containers. Il va vous permettre d'héberger vos images Docker au sein de l'infrastructure AWS. Pourquoi est-ce qu'on a envie de faire ça et pourquoi est-ce qu'on préférerait faire ça plutôt que de le mettre sur le Docker Hub ou sur un serveur privé ? Plusieurs raisons. La première raison est que ce service sera hautement disponible. Vous n'avez pas à craindre que vous ne puissiez pas déployer vos images parce que le Docker Hub est en panne ou votre propre serveur est en panne. Vous avez, comme d'habitude dans AWS, la haute disponibilité, la sécurité et donc la capacité à déployer en permanence. Le deuxième point qui est intéressant, c'est que comme ce registre est au plus près de votre infra, vous aurez des temps de déploiement des containers particulièrement courts. Entre ECR et ECS, la proximité réseau est extrêmement forte. Donc, une fois de plus, si vous faites du déploiement continu ou si vous avez une plateforme très dynamique, que vous passez votre temps à mettre à jour vos images, etc., vous allez pouvoir les déployer, les télécharger de manière extrêmement rapide, plus rapide que si vous deviez aller faire appel à un service externe, passer par Internet, etc. pour potentiellement télécharger vos images. Voilà quelques raisons qui pourraient conduire à utiliser ECR, d'autant plus qu'il est assez économique. Il y a un free tier qui vous permet de le tester, et puis ensuite vous payez au stockage par gigabit par mois. En termes de disponibilité des services, les deux sont disponibles dans la quasi-totalité des régions. Aujourd'hui, on a 16 régions plus d'autres prochainement, et donc ces deux services sont disponibles dans 13 régions, donc on va dire à peu près partout, et donc en particulier en Europe, vous pouvez bien sûr les tester, les utiliser et les adopter. ECS et ECR sont des services qui ont un cycle de vie assez rapide. J'ai pris quelques-unes des dernières nouveautés depuis le mois de juin que vous pourrez trouver sur aws.amazon.com/ecs/new. Comme vous pouvez voir, il y a régulièrement, tous les mois, de grosses nouveautés sur ECS. Je ne vais pas toutes les lister, mais il y en a une qui est très importante, celle du mois de juin, qui supporte l'intégration des instances Spot directement dans la console. Maintenant, lorsque vous créez un cluster ECS dans la console, vous pouvez directement demander à le créer avec des instances Spot. Je rappelle pour ceux qui ne seraient pas familiers, les instances Spot sont des instances que vous payez à un prix extrêmement réduit, généralement 70-80% moins cher que le prix on-demand, et il y a un mécanisme d'enchaînement. Donc vous pouvez construire de gros clusters avec des instances Spot à un prix particulièrement intéressant. D'autres features, peut-être le scheduling, donc vous avez maintenant celle du 7 juin, vous avez la possibilité d'exécuter des tâches programmées, vous pouvez lancer des containers à intervalles réguliers, à heure précise, etc., pour des batchs, pour des travaux différents, de monitoring, de collecte de logs, enfin on peut imaginer un million de choses. Voilà, c'est très facile à faire maintenant. La feature du 7 septembre est vraiment importante, on a lancé un nouveau type de load balancer. Jusqu'à présent, on avait les ELB, le load balancer classique, les ALB, donc Application Load Balancer Niveau 7. Et donc depuis quelques mois maintenant, les Network Load Balancer, qui vous permettent d'atteindre de très gros débits, donc des centaines de milliers, voire des millions de connexions par seconde en TCP. Ce nouveau Load Balancer a été intégré avec ECS, et donc maintenant vous pouvez établir des connexions TCP directes avec des débits très élevés directement entre vos applications et vos containers. D'autres fonctionnalités, et surtout une fonctionnalité qui va tous nous intéresser, c'est que depuis début octobre, on a la facturation à la seconde sur les instances EC2 et sur les volumes EBS. Comme on va le voir dans un instant, ECS est basé sur des instances EC2, et par conséquent, la facturation d'ECS, en tout cas de la facturation des instances créées dans le cadre de cluster ECS, se fait désormais à la seconde. Ce qui est intéressant puisque vous pouvez aussi démarrer, vous pourrez presque répercuter finalement cette facturation à la seconde sur vos containers. Là où avant la facturation se faisait à l'heure et où peut-être le reporting applicatif était un peu plus compliqué. Donc maintenant vous avez la facturation à la seconde pour les instances, donc ça pourrait tout à fait se propager de manière assez simple à vos containers. L'écosystème Docker est assez riche, donc comme toujours, nous avons un grand nombre de partenaires Docker et bien sûr plein d'autres qui vont vous fournir des outils et des solutions qui vont s'intégrer de manière simple avec ECS. J'en cite quelques-uns, par exemple CoreOS ou Rancher, ce sont des AMI qui sont disponibles sur la marketplace, et donc vous pouvez facilement démarrer par exemple des instances EC2 qui tournent sur RancherOS et qui vont s'intégrer facilement dans un cluster ECS. Les outils de déploiement continu comme CircleCI, CloudBees et les autres qui supportent les chaînes de développement Docker vont aussi bien fonctionner avec ECS. Et puis d'autres partenaires, Datadog pour le monitoring, et puis Twistlock qui est un partenaire intéressant qui va être capable d'auditer, de détecter des vulnérabilités de sécurité à l'intérieur de vos containers, ce qui est un sujet évidemment essentiel. Voilà donc tout un ensemble de partenaires, infrastructures ou services qui vont pouvoir fonctionner correctement avec ECS, ce qui est important parce que vous utilisez sans doute, quelle que soit la solution Docker que vous avez aujourd'hui, vous utilisez déjà certainement l'un ou l'autre de ces partenaires et vous pourrez continuer à le faire. Bien sûr, nous avons un grand nombre de références clients. L'adoption sur ECS a été assez rapide et très bonne. Je peux citer quelques exemples, comme par exemple MyTaxi. Si vous voyagez souvent en Allemagne, vous connaissez forcément cette société. MyTaxi, c'est l'application mobile qui sert pour tous les taxis allemands. Ils ont 10 millions d'utilisateurs, quasiment 50 000 taxis. Donc ils opèrent en Allemagne et dans d'autres pays. Et en fait, la quasi-totalité de leur plateforme fonctionne sous Docker, d'ailleurs avec une utilisation massive des instances Spot. Cela permet d'avoir les bénéfices de Docker, la capacité à scaler rapidement, à démarrer rapidement des containers et des nœuds, tout en contrôlant leurs coûts. Je pourrais donner un deuxième exemple qui est Mapbox. Mapbox, c'est un concurrent de Google Maps, on peut dire ça comme ça. Ils ont 200 millions d'utilisateurs actifs par mois et plus d'un milliard de requêtes par jour. Un trafic énorme. Et ils utilisent aussi massivement ECS, aussi bien pour la partie front que pour la partie back. Un autre exemple qui n'est pas sur ce slide, je pourrais parler de Coursera, la plateforme de cours en ligne que vous connaissez. Coursera utilise aussi beaucoup ECS, en particulier pour exécuter toutes les tâches liées à du code écrit par les étudiants. Donc à chaque fois que vous écrivez du code sur Coursera et que vous l'exécutez sur la plateforme de Coursera pour qu'il soit noté, il va être exécuté sur un cluster ECS. Ce qui leur permet bien sûr d'isoler ce code du reste de la plateforme. Il ne faudrait pas que quelqu'un, via du code malicieux, arrive à détourner la plateforme de Coursera. Et puis ça leur permet de scaler rapidement, si un cours est très populaire, que le nombre d'étudiants augmente, qui a beaucoup de jobs à exécuter en parallèle, ils peuvent démarrer davantage de containers, davantage de nœuds, et gérer tout cela de manière simple. Le point commun qu'on trouve chez tous ces clients, c'est toujours le même, c'est la nécessité de scaler, surtout lorsqu'ils ont des infrastructures microservices, ce qui est le cas de plusieurs de ces clients, comme Expedia également, qui déploie sur ECS. La capacité à scaler un microservice indépendamment des autres, donc démarrer davantage de containers, trouver des ressources disponibles sur le cluster et le faire de manière extrêmement rapide. Le temps de démarrage de containers est plus rapide que le temps de démarrage d'instances, donc c'est un avantage. Vraiment cette rapidité de déploiement, cette scalabilité, sans parler des avantages de Docker en général pour le cycle de déploiement. Tout ça, ce sont des choses qu'on retrouve souvent chez nos clients. Voilà, quelques autres exemples, je vous laisserai les lire, je préférerais avancer et parler de l'architecture. J'ai déjà donné quelques exemples de clients. L'architecture d'ECS, la voici. Comme je l'ai dit tout à l'heure, ECS, un cluster, le cluster ECS, c'est avant tout un cluster d'instances EC2. Ici, on voit sur ce schéma, on a trois instances, deux dans la zone de disponibilité 1 et une dans la zone de disponibilité 2. Chacune de ces instances EC2, pour devenir une instance ECS, a besoin de différentes choses. Elle a besoin d'avoir Docker installé, ça paraît une évidence, et deuxièmement, elle a besoin d'exécuter l'agent ECS. L'agent ECS est un agent qui est open source, que vous trouverez sur GitHub, et qui va connecter cette instance au back-end ECS. Tous les nœuds d'un cluster sont équivalents, il n'y a pas de maître, ce sont vraiment tous des nœuds qui sont dédiés à l'exécution des contrats, mais ils ont tous un agent qui va dialoguer avec le back-end. C'est le back-end qui connaît l'état distribué du cluster, c'est le back-end qui reçoit les ordres de placement de containers, les directives que vous allez lui envoyer, et c'est le back-end qui va s'assurer qu'à tout instant on a le bon nombre de containers qui tournent sur le cluster. L'agent sert juste à la communication, c'est vraiment le back-end qui prend les décisions. Sur chaque nœud, sur chaque instance, on va trouver Docker et on va exécuter sur chaque instance des containers qui vont être décrits, on verra cette abstraction tout à l'heure, dans ce qu'on appelle des task definitions. Une task definition, c'est un fichier de configuration en YAML qui va décrire au moins un mais potentiellement plusieurs containers qui doivent être placés à l'intérieur de la tâche. Comme vous verrez tout à l'heure, la syntaxe est extrêmement proche des compose files de Docker. Donc si vous êtes à l'aise sur les compose files, vous allez vite être à l'aise sur les task definitions. Une task definition, c'est un ou plusieurs containers qui doivent être exécutés sur le même nœud, et puis on va trouver ce qu'on trouve d'habitude, c'est-à-dire potentiellement la définition de volume, la définition de port réseau, etc. On va définir ces tâches, on va les lancer, et le back-end va s'assurer que le bon nombre de tâches tourne sur l'ensemble du cluster. Si une tâche meurt, elle sera relancée automatiquement par le back-end. On fera des tests là-dessus tout à l'heure. Et puis en frontal, on peut avoir évidemment des load balancer, sous réserve d'avoir ouvert des ports réseau dans les containers. On peut mettre des load balancer, soit des Application Load Balancer, soit des Network Load Balancer, qui eux-mêmes seront visibles depuis Internet et qui vous permettront de recevoir du trafic venant de vos utilisateurs. Ce qu'il faut retenir de ce schéma, c'est que deux ou trois choses. Un cluster ECS, c'est un ensemble de nœuds EC2 sur lesquels Docker est installé, sur lesquels l'agent ECS est installé. Cet agent communique avec un back-end qui connaît l'état distribué du cluster, qui reçoit les directives que vous lui envoyez et qui va s'assurer qu'à tout instant, le bon nombre de tâches tournent sur le cluster et qu'il les relance lorsqu'elles meurent ou lorsque des nœuds meurent. On va voir tout ça plus en détail pendant la démo. Alors comment est-ce qu'on utilise ECS ? Bien sûr, on peut l'utiliser dans la console, je vous montrerai rapidement la console tout à l'heure. Mais l'objectif est plutôt d'utiliser une ligne de commande et d'automatiser et de scripter. Pour ceux qui ont envie de faire du CloudFormation, bien sûr, on peut faire du CloudFormation aussi, j'en parlerai pas trop aujourd'hui. Cette ligne de commande est spécifique. Vous avez des commandes ECS dans la ligne de commande AWS qu'on connaît tous. Vous voyez les commandes en bas ici, AWS ECS List Cluster, Describe Cluster, etc. Mais comme souvent sur cette ligne de commande, ce sont vraiment des commandes d'infrastructure, c'est plutôt des commandes de bas niveau. Elles sont utiles, mais elles sont plutôt utiles pour gérer le cluster lui-même et pas tellement pour gérer les applications qui vont tourner sur le cluster. Un peu à l'image de ce qu'on fait sur Elastic Beanstalk, où on a cette ligne de commande EB, ici on a une ligne de commande ECS-CLI qui est open source, que vous pouvez récupérer sur GitHub, qui est une ligne de commande séparée qui va vous permettre de manière super simple de créer un cluster, de lancer des services, etc., de les arrêter, de les scaler, et littéralement ce sont les commandes que vous voyez à l'écran. C'est vraiment le même esprit qu'Elastic Beanstalk, on essaie d'avoir une ligne de commande AWS, infrastructure plutôt orientée Ops, etc., et on a une ligne de commande ECS-CLI plutôt orientée, franchement orientée en leur donnant la capacité de créer des clusters très simplement et de gérer les services très simplement en se souciant finalement très peu de ce qui peut se passer en dessous. Ce que je vous propose, c'est d'enchaîner sur une démo et de voir un peu ce que ça donne. Je vais quitter les slides. Voilà, je vais zoomer un peu là-dessus. Voilà, je pense que ça doit être... Je vérifie mon écran, oui. Bon, ça va, ça doit être bien lisible. Alors, on va jeter un petit coup d'œil juste à la console pour commencer. Donc la console ECS, la voilà. On va zoomer un peu aussi. Voilà. Pour l'instant, évidemment, elle est vide, puisque je n'ai pas créé de cluster. On va la mettre comme ça. Et puis, on va voir ce qui se passe au fur et à mesure. OK. Donc, on a besoin de cette ligne de commande. Alors, évidemment, moi, je l'ai déjà installée. OK. Donc, elle est là. C'est un outil que vous pouvez télécharger et installer sur votre machine locale. Ici, je travaille en local sur mon Mac. Donc la première étape, ça va être de configurer un cluster. Donc on va... Alors on peut le faire... Ça va être cette commande-là. Voilà. Où on va lui dire tout simplement... je vais travailler avec un cluster qui s'appelle... Allez, on ne va pas être original. On va l'appeler Webinar Cluster. Donc là, à ce stade, on n'a rien créé. On a juste défini le nom du cluster avec lequel on va travailler. Donc maintenant, si on veut créer un cluster, on peut préciser la région. On va préciser la région. Des fois qu'il a envie de me le créer à un endroit exotique. Ensuite, on va créer le cluster. Ça va être cette deuxième commande que vous voyez là. ECSCLI-UP. On va indiquer le nom d'une paire de clés SSH pour pouvoir se connecter sur les nœuds si on en a envie. Capability IAM, parce qu'il va créer un certain nombre de ressources IAM dont on a besoin. Et puis, la taille du cluster. Donc, allons-y. Alors, Capability IAM, la paire de clés, le... le nombre de nœuds et on pourrait rajouter la taille de l'instance si on voulait. Par défaut, il va me faire du T2 micro. On va rester sur ça. Donc là, vous voyez cette simple commande suffit à créer un cluster. Alors, je n'ai pas spécifié de VPC, je n'ai pas spécifié de security group, je n'ai pas spécifié de subnet, etc. Donc ici, ce qui va se passer, c'est qu'il va me créer un nouveau VPC et il va m'héberger le cluster à l'intérieur du VPC. Donc, dans certains cas, c'est exactement ce qu'on veut faire. Si on veut isoler des devs les uns des autres, c'est une très bonne approche. Si on a envie de lancer le cluster dans un VPC existant, en spécifiant des subnets, les security group, enfin en donnant plus de détails, on peut aussi le faire. Il y a des options supplémentaires sur ECS CLI pour le faire. Bon, ici, j'essaie de... de rester sur une démo plutôt simple. Donc, qu'est-ce qu'on voit ? On voit que très vite, il me dit cloud formation stack status create in progress, donc il vend un peu la mèche puisque effectivement ce CS CLI va déclencher la construction du cluster via CloudFormation. Donc, si je vais voir dans la console de CloudFormation, normalement, je dois avoir une stack en cours de création. Et si je regarde en attendant ce qui se passe là, qu'est-ce que je vois ? On va rafraîchir ça. Voilà, donc il est en train de me créer mon Webinar Cluster. Et si j'arrive à avoir CloudFormation un jour... Merci. Il va falloir que j'upgrade le modem. Mon Dieu. On est au bureau, je vous rassure. On est sur un accès réseau au bureau. C'est Halloween. Voilà. Ok, donc qu'est-ce que je vois ? Je vois qu'effectivement, j'ai... J'ai ma stack en cours de création. Alors là, je vous le montre parce qu'on est curieux, mais on n'est pas du tout obligé d'aller voir ça. Et si on regarde dans les événements, on va voir qu'il est en train de créer toute la plomberie qu'on s'attendrait à voir, c'est-à-dire, il crée un VPC, il crée un Internet Gateway, il va créer les objets IAM nécessaires, il va créer des subnets, etc. Donc, là, il va créer vraiment l'intégralité d'un VPC accessible depuis Internet. Et puis, il va évidemment créer les instances EC2. Donc, ça prend peut-être 5-6 minutes, parce qu'il faut qu'il crée tout ça. Donc, c'est aussi une des raisons pour lesquelles on peut avoir envie, évidemment, de lancer son cluster dans un VPC existant. On va économiser tout ce temps de création. Bon, mais ici, je voulais vous montrer l'ensemble. Alors, on voit qu'il est en train de créer un groupe d'autoscaling, on va y revenir tout à l'heure, on verra pourquoi on a besoin d'autoscaling dans cette histoire. Mais une fois que ça c'est fait, assez vite, on devrait voir des instances EC2 arriver. Donc, allons voir ce qui se passe dans le C2. Je pense qu'il est encore un peu tôt pour les voir ici. Je crois que je vais passer en 4G pour le deuxième webinar, ça marchera mieux. Ah là là ! Bon, enfin. Alors, qu'est-ce qui se passe ici ? Ok, on voit que les instances commencent à arriver. Lentement mais sûrement. Il y a beaucoup de choses ici. On va filtrer un petit peu. Voilà. Donc là, je vois mes trois instances. Elles ont un nom qui a été attribué par la Stack CloudFormation. Elles ont le nom du cluster aussi dedans. Donc, si vous voulez filtrer, vous pourrez filtrer sur Webinar et on est trop vrai. Donc, on voit que ce sont des T2 micro, on voit qu'elles sont dans des zones de disponibilité différentes. Voilà, donc elles sont dans un VPC isolé. Et donc, voilà, ça c'est la partie EC2, mais une fois de plus, on n'est pas obligé de voir ça. Ce qui nous intéresse, c'est plutôt ça. On voit que j'ai mon cluster, j'ai trois instances. Pour l'instant, je n'ai aucune tâche dessus, puisque je n'ai rien démarré. Tout ça est vide. Maintenant, je vais pouvoir démarrer un service. Aucune tâche disponible. Enfin, aucune tâche démarrée, plus exactement. On voit ici les fameuses « scheduled tasks » dont je parlais tout à l'heure. Donc, les tâches programmées que vous pouvez lancer. Et puis, on a aussi des graphes CloudWatch qui ici ne vont pas nous dire grand-chose parce qu'on vient de démarrer. Comme d'habitude, on a des métriques, mais pour l'instant, rien dessus. Alors maintenant, comment est-ce qu'on démarre un container là-dessus ? Ou des containers ? Donc, on va créer ce que j'ai mentionné tout à l'heure, c'est-à-dire une task definition. Donc, ici, j'en ai une qui est très simple. Si vous êtes familier des compose files Docker, vous allez retrouver vos petits. Donc, ici, je crée une task definition, ça s'appelle phpDemo. L'image est hébergée dans ECR, donc j'ai créé un repository qui contient mon image. J'ai oublié de le préciser tout à l'heure, mais évidemment, vous accédez à ces repositories avec les outils Docker classiques. Vous faites AWS ECR, Create Repository, blablabla, pour l'initialiser. Et puis, ensuite, vous faites Docker Login, Docker Push, Docker Pull, etc. On a ensuite deux champs qui sont un peu spécifiques, qui sont cpu shares et même limite. Même limite, c'est 128 mégas ici, c'est la mémoire maximum que le container a le droit d'utiliser avant d'être tué. Donc, si on dépasse 128 mégas, Docker le dégagera automatiquement. C'est amplement suffisant pour ce qu'il y a dans ce container. CPU shares, c'est un paramètre qui est une indication du poids CPU de ce container. J'ai dit tout à l'heure que le problème qu'on essayait de régler, c'était de placer au mieux les containers sur le cluster. Si vous avez vu ici, sur mon container, j'ai trois instances, ce sont des T2 micro et elles ont 1024 points de CPU. Et elles ont un peu moins d'un giga de mémoire disponible. 1024 points de CPU sont les valeurs qui sont arbitraires et définies par nous, et donc en fonction de la taille de l'instance, plus l'instance est puissante en termes de CPU, plus elle aura de points de CPU. Ça vous trouverez les décomptes exacts dans la doc. Par exemple, ce container que je vois là, quand je vais démarrer un container ici qui contient un Apache et une mini application, je vais consommer 100 points de CPU. Donc, à quoi ça sert de faire ça ? Et bien, ça vous permet de régler finalement le nombre de containers que vous voulez avoir par instance. Si ce container était extrêmement intensif en calcul, on pourrait lui dire, ce container a 1024 points, donc il a besoin de tourner tout seul sur cette instance. A contrario, ici, s'il a une utilisation CPU faible, on va pouvoir en empiler un grand nombre sur les mêmes instances et ça ne posera pas de souci. Donc, c'est vraiment une indication que vous donnez à l'ordonnanceur en lui disant voilà le poids, voilà la part de CPU que ce container doit réserver. Ensuite, il l'utilise ou il ne l'utilise pas, mais une fois de plus, ça vous permet de régler le poids respectif et l'allocation respective de CPU que vous voulez donner à ces containers. Au passage, on voit la version de l'agent ECS, on voit la version de Docker, on voit tout ça. Donc, ici, même limite. Et puis, le reste, ce sont des directives Docker standard. Donc, ici, je vais ouvrir le port 80, interne et externe, et puis je vais démarrer Apache au démarrage du container. Donc, comment est-ce qu'on démarre ça ? Tout simplement, on fait ECSCLI compose service. Par défaut, il va aller chercher un fichier qui s'appelle docker-compose.yaml, fichier que vous venez de voir. Donc, vous voyez ce qu'il est en train de faire. Il prend ce fichier, il le transforme en task definition. Si je regarde, si je reviens là et que je consulte les task definitions, je vais voir cette task definition apparaître. Il y aura peut-être d'autres choses parce que... Donc, là, voilà. Donc, ça c'est le produit de ce fichier qui est donc chargé sur le cluster. Elles sont versionnées évidemment. Ici, on va retrouver la version 11, c'est ça ? La version 11 que je viens de créer. Et donc, je vais voir ici le contenu de la task definition et on va retrouver exactement la même chose, c'est-à-dire CPU shares, même limite, le chemin de l'image, et puis, les ports réseau, on retrouve exactement la même chose. Donc, la task definition, c'est ce qui va permettre d'instancier le service sur le cluster. Donc, qu'est-ce qu'on voit d'autre ? Ici, je n'ai pas indiqué combien j'en voulais de copie. Donc, par défaut, il va m'en débarquer. Démarrer 1. Donc, je vois ici, desired count 1. Et puis, très vite, je vois qu'il démarre une tâche, donc il va télécharger l'image depuis ECR et puis démarrer sans doute ce container. Et donc, ici, je vois desired count égale 1, running count égale 1, donc il a fait le boulot. Et si maintenant je vais sur mon cluster et que je regarde ma liste de tâches, voilà, donc je vois une running task et je dois pouvoir la consulter dans le cluster et je peux aussi la consulter ici en faisant ça. Voilà, donc je vois qu'effectivement PHP démo a été démarré. Voilà l'adresse IP de la machine. D'ailleurs, si je prends cette adresse-là et que je l'ouvre, donc là, on va voir les tâches. C'est abominablement lent. Non, on va faire la suite en fonction. On essaie en wifi ou en 4G à la pause, c'est trop long, c'est beaucoup trop long, désolé pour ça. Donc, ici, je vois, je me connecte bien sur le port 80 et j'ai bien ma page PHP qui tourne dans mon Apache. Voilà, donc je la vois ici, on va voir les mêmes choses évidemment dans la console. Donc, vous voyez finalement, en une commande, on démarre un cluster, une deuxième commande, ici, on lance un service et on ne s'est pas trop soucié du tout même d'infrastructure. Alors, si j'ai envie d'en démarrer plusieurs, j'ai trois nœuds, donc on pourrait dire qu'on veut trois exemplaires de cette tâche. Donc, on va avoir un desired count qui devrait passer à 3 et un running count. On va regarder ici ce que ça donne. Voilà. Donc, je le vois là, c'est intéressant. Donc, on voit, j'en ai une deuxième qui a déjà démarré. J'en ai deux runnings. Et j'en ai une troisième pending. Enfin, là, j'imagine que maintenant, ça fait trois. Voilà, non, pas encore. Ce sont des petites instances. T2 micro, faire du Docker sur T2 micro, c'est un peu excessif. Mais bon, l'avantage, c'est que vous pouvez tester tout ça dans le free tier et ça ne vous coûte rien du tout. Sur des vraies instances de production, tout ça est évidemment instantané. Et donc, maintenant, je vois si ce troisième container veut bien démarrer. Allez, un effort. Voilà, ça doit être bon. Donc, maintenant, si je refais ça, voilà, je vois mes trois containers qui ont démarré et je vois qu'ils sont bien sur trois nœuds séparés tout simplement parce que j'ai cette contrainte du port 80 qui m'obligent à ne démarrer qu'un container par nœud, il n'y a qu'un port 80 par nœud et donc je ne peux pas ici les mettre sur le même nœud. Si je voulais avoir plusieurs copies de ce container sur le même nœud, il faudrait que je les démarre sur des ports aléatoires. Donc, je laisserai Docker assigner un port aléatoire en sortie et puis devant avec un application load balancer par exemple, je pourrais avoir un target group qui détecterait ces différents containers et qui saurait les load balancer quel que soit leur port. Si vous n'êtes pas familier de ça, je vous renvoie à l'application load balancer, au target group, etc. Bon, voilà, on va essayer un deuxième pour la forme. Allez, on va essayer celui-là, alors on va afficher la page magique pour avoir l'identifiant du container, ok, on va vérifier que c'est pas le même. Donc, là, on a quoi ? Là, on a E4, EA, etc. Ah, et ça ne marche pas. Qu'est-ce qui se passe ? C'est intéressant. Qu'est-ce que j'ai fait ? Ah oui, c'est la mauvaise adresse. C'est assez bizarre de voir ce qui s'affiche d'ailleurs. Voilà. Ok, donc là, on a 1, B, D, C, etc. On pourrait mettre devant un load balancer, etc. Après, on revient dans les mécanismes traditionnels de ces deux. Juste peut-être pour finir, on pourrait rajouter... Je voulais vous montrer l'autoscaling group. Pourquoi on a un autoscaling group ? Tout simplement parce que... Allez, on va faire une ânerie, on va tuer une instance. Pourquoi il ne veut pas ? Ah oui, il faut peut-être que j'en sélectionne une. Ce serait mieux. On va tuer une instance et on va voir ce qui se passe. Ok. Voilà. Donc terminate. Bon, là c'est violent, évidemment c'est pas un arrêt propre, c'est pas comme si on avait downscalé le cluster, là on la tue violemment. Et donc si on va voir dans l'autoscaling group, en fait quand j'ai créé le cluster, et que je lui ai dit je veux trois nœuds, pas deux, pas quatre, juste trois, ce qui se passe, c'est qu'il crée un autoscaling group avec le min à trois, le max à trois, et donc sans surprise, il va y avoir trois nœuds dans l'autoscaling group. Et donc là, comme je viens de tuer une, les contraintes de... Voilà mon autoscaling group, vous voyez. Donc, min... Desired 3, voilà. Là, on en a perdu une. Et donc, il va la relancer. Donc, si je vais regarder ce qui se passe là, est-ce que j'en vois deux ou est-ce que j'en vois trois ? On va voir. Voilà. Mais voilà pourquoi il y a un autoscaling group qui est caché dans le template CloudFormation. C'est pour garantir qu'on a toujours le bon nombre d'instances. Si j'arrive à cliquer... Voilà, donc là, je n'ai plus que deux instances. Il y en a bien une qui est morte. Par contre, si je regarde dans la console EC2, il est probable que j'envoie une troisième en cours de démarrage. Donc ça, c'est vraiment un mécanisme important dans ECS. Vous voyez que vous n'avez pas à vous soucier de la haute disponibilité du cluster si vous lui demandez trois nœuds, quatre nœuds ou cinq nœuds. C'est l'auto-scaling qui va s'assurer qu'on a toujours le bon nombre de nœuds. Si un nœud disparaît, alors on va lui demander juste ECS. Si un nœud disparaît, eh bien il va le relancer. C'est ce qu'on est en train de voir là. Donc on voit celle qui a été terminée tout à l'heure, et on voit que là, l'autoscaling, on a redémarré. Donc elle va redémarrer, elle va se reconnecter au cluster, ok ? Idem si on regarde les tâches, on n'a que deux tâches qui tournent puisqu'on a perdu une tâche en arrêtant l'une des instances. Donc le scheduler de ECS dès que cette troisième instance va être disponible et joint au cluster, il va pouvoir démarrer la troisième copie du container. Donc vous voyez là on est sur un cas très simple avec un tout petit nombre d'instances, un tout petit nombre de containers, mais imaginez une plateforme où vous avez des dizaines de containers différents, des dizaines de nœuds et où à chaque fois qu'un nœud tombe ou un nœud reboote, vous n'avez pas envie de faire ça manuellement, c'est impossible. Donc il faut laisser ECS faire son boulot. Voilà donc la troisième instance est arrivée, ok, et d'ici quelques secondes on va voir un troisième... Le scheduler de ECS va détecter que cette instance, qu'une troisième instance est à nouveau disponible et il va démarrer le troisième container. Donc vous voyez là on est sur un cas très simple avec un tout petit nombre d'instances, un tout petit nombre de containers, mais imaginez une plateforme où vous avez des dizaines de containers différents, des dizaines de nœuds et où à chaque fois qu'un nœud tombe ou un nœud reboote, vous n'avez pas envie de faire ça manuellement, c'est impossible. Donc il faut laisser ECS faire son boulot. On voit le troisième container qui est démarré. Une fois de plus, sur des instances de production, tout ça va beaucoup plus vite. Ici, on est sur du T2 micro. Automatiquement, on a récupéré une instance ECS, on a récupéré les containers qui tournent dessus. En quelques minutes, on se retrouve avec un cluster qui est à nouveau opérationnel, sans que vous ayez eu à faire quoi que ce soit. Donc à la limite, vous dormez la nuit, le lendemain matin vous vous rendez compte qu'il y a peut-être eu un reboot, il y a peut-être eu un incident pendant la nuit, mais avec probablement aucun incident sur la qualité de service. Et donc ici on voit bien, on voit qu'on a récupéré, donc ça c'est le vieux container qui n'a pas encore disparu, et donc on voit que 34.253 est morte et qu'on a démarré 34.241.65. Donc tout ça se passe automatiquement, vous ne vous souciez pas de ces sujets-là et vous vous concentrez sur la réalisation de l'application. Et si on voulait rajouter des nœuds, on ferait tout simplement ECS. On peut scaler le cluster avec ECS CLI, rajouter des nœuds, etc. Vous voyez, les différentes commandes dans la liste sont plutôt faciles et on est vraiment sur un outil pour les développeurs. C'était quoi la commande ? Non, ce n'est pas 5, c'est moins moins size 5. Et donc là, je vais rajouter automatiquement deux instances dans le cluster. Une fois de plus, on va mettre à jour l'autoscaling, on va démarrer deux instances supplémentaires, elles vont se rajouter au cluster, etc. Ça marche à la hausse, ça marche à la baisse. Et on peut comme ça créer ces clusters, les manager de manière super simple. Voilà les grandes fonctionnalités que je pouvais vous montrer. Il y a plein d'autres choses sur ECS mais peut-être qu'on fera un webinar avancé. On peut définir des contraintes de placement sur les containers. Par exemple, si vous avez envie qu'un container soit toujours placé sur un type d'instance donné, pourquoi pas une instance GPU, vous avez un container qui a besoin d'un GPU donc il faut qu'il soit sur une instance GPU, vous pouvez, dans la task definition, indiquer des contraintes de placement, donc par type d'instance ou par zone de disponibilité. Vous pouvez mettre des labels sur les instances. Vous pouvez lui dire d'éviter certaines instances avec tel label ou au contraire de ne se placer que sur des instances avec tel label. Vous pouvez définir des affinités, des anti-affinités entre containers. Vous pouvez choisir d'optimiser le placement pour avoir l'utilisation de mémoire la plus efficace, ce qu'on appelle le bin packing. Donc vous pouvez lui dire, ok, peut-être il y a trois nœuds, mais tu remplis le premier nœud complètement, et puis ensuite tu rempliras le deuxième, et puis ensuite tu rempliras le troisième. Si vous voulez optimiser les coûts et avoir des clusters de la plus petite taille possible, ça peut être une bonne stratégie. Ou au contraire, vous pouvez avoir une stratégie du type spread où vous allez étaler au maximum les containers sur des instances différentes. Donc là, ça va plutôt être une stratégie d'équilibrage de charges, de haute disponibilité, etc. Voilà, donc ça, c'est tout ce qu'on appelle les stratégies de placement, les contraintes. Vous trouverez tout ça dans la doc de ECS. On va juste vérifier que nos instances sont en train d'arriver. Sans doute que oui. On voit les cinq instances sont arrivées, l'auto-scaling a fait son boulot. Je dois les voir ici. À nouveau, je pourrais démarrer davantage de containers. Maintenant, si j'ai envie de tout arrêter, j'ai fini de bosser, si je fais ça, on ne doit pas être loin de la réalité. Et donc cette fois, si je vais dans CloudFormation, je vais voir sans surprise ma stack en cours d'effacement. Et donc je vais tout simplement démonter mon cluster, démonter mon VPC, et tout effacer proprement. Donc c'est vraiment, cette automatisation-là est sympa lorsqu'on est en cycle de dev et qu'on a envie d'avoir un cluster pour faire des tests ou deux ou trois ou huit. Bon, on peut les créer facilement, on peut les détruire facilement. Même vous laissez vos développeurs faire ça dans un VPC dédié à cet usage-là. Et puis vous êtes tranquille, vous savez que ça ne va pas déborder, vous savez que ça va être nettoyé proprement, etc., etc. Et donc cette ligne de commande là est vraiment sympa pour les développeurs. Vous voyez qu'on n'a pas à fournir d'informations, d'infrastructures particulières. Voilà, on va laisser le cluster se nettoyer tranquillement. J'avais deux ou trois petites choses encore à vous dire. Voilà, je crois qu'on a vu à peu près toutes ces commandes là. Alors si vous voulez en savoir plus, si vous voulez en lire un petit peu plus, à la sortie du service Werner a écrit une série d'articles qui sont intéressants, qui donnent quelques informations supplémentaires sur les grands principes d'architecture, les grands choix d'architecture faits autour de ces. De mémoire, il y a aussi un benchmark de scalabilité où on monte un cluster à plus de 1000 nœuds et où on voit que les temps de placement, les temps d'ordonnancement restent plats et que ECS est capable de prendre des décisions de placement en temps constant, quelle que soit la taille du cluster. C'est assez intéressant. Il y a aussi tout un tas de vidéos de reInvent de 2016 que vous pourrez consulter sur l'adresse que j'ai indiqué là. Alors le reInvent 2017 est dans un mois maintenant donc en attendant les futures vidéos ECS vous pouvez regarder celle là. Il y a des vidéos techniques et puis il y a beaucoup de témoignages clients donc si vous cherchez des informations sur comment les clients AWS utilisent ECS, vous trouverez pas mal d'exemples. Si vous voulez rester en contact et voir un peu quelles sont les nouveautés qui arrivent régulièrement sur ECS, vous pouvez aller à l'URL que j'ai déjà mentionné, amazon.com.ecs.new. Et puis il y a aussi régulièrement des articles sur le blog Compute d'AWS, régulièrement des articles techniques ou des cas d'usage client sur Amazon ECS. Deux bonnes adresses. Et puis, j'ai des collègues qui sont dédiés à ECS, que vous connaissez peut-être déjà, puisqu'ils tournent pas mal dans les conférences. Et si vous voulez rester au plus près de l'actualité d'ECS, vous pouvez les suivre. Donc, Abby, Nathan et Tiffany, qui sont tous les trois aux US, mais qui viennent de temps en temps en Europe pour des conférences. Ils sont spécialisés sur ECS et les containers et donc sont aussi des bonnes sources d'informations sur ECS et sur les containers en général. Si vous êtes un fan de containers, je pense qu'ils trouveront, vous trouverez chez eux de quoi vous alimenter. Voilà j'en ai fini pour ce premier webinar. Je pense qu'on est à peu près dans les temps. On va faire une petite pause le temps que je reconfigure deux ou trois trucs. Et puis, on va ensuite basculer sur Kubernetes. Et ensuite, on répondra à toutes vos questions. Ne quittez pas, prenez un petit café. Et je reviens dans cinq minutes pour vous parler de Kubernetes. Et on répondra à vos questions. Il n'y en a déjà pas. Merci beaucoup, à tout de suite.