Kubernetes est une plate-forme Open Source pour la gestion de containers Docker. Elle permet de créer des clusters et d'y déployer, scaler et gérer des applications dockerisées. Bien sûr, il est possible d'utiliser Kubernetes sur des instances EC2, ce que nous vous présentons dans ce webinaire.
Transcript
Nous revoici. Bonjour à ceux qui nous rejoindraient peut-être uniquement pour ce webinar et merci à tous les autres d'être restés. Dans le webinar précédent, je vous ai parlé du service Amazon ECS qui permet d'orchestrer des clusters de conteneurs. Dans ce deuxième webinar, je vais vous parler d'une autre solution qui s'appelle Kubernetes, et on va essayer de faire également une petite démo le jour d'Halloween. Pour l'instant, je m'en sors plutôt bien, mais l'après-midi n'est pas terminée.
Kubernetes est un outil open source, bien que l'on pourrait dire qu'il a été développé par Google sur la base d'un projet interne appelé Borg, dont vous avez peut-être entendu parler. Je vous ai inclus le lien vers l'article qui décrit Borg, qui était une architecture interne à Google pour orchestrer des conteneurs. Sur cette base, ils ont conçu ce produit qui s'appelle Kubernetes et qui a été open sourcé. Il est assez populaire et a été lancé en mi-2015, à peu près en même temps que ECS.
Quelle est l'architecture de Kubernetes ? Rassurez-vous, on ne va pas rentrer dans tous ces mini détails, mais si vous avez assisté au webinar précédent, vous allez constater que les concepts sont relativement proches. La première chose, c'est que dans un cluster Kubernetes, on trouve des nœuds qui vont héberger et exécuter les conteneurs. À la différence d'ECS, on a un nœud maître, au moins un, on peut en avoir plusieurs pour la haute disponibilité, mais au moins un, qui va être le point d'entrée de vos commandes via une API, et des nœuds de travail, des workers. Donc, au minimum, un cluster Kubernetes, ça sera trois nœuds : un maître et deux workers.
On va également trouver un cluster HEDCD. Je ne sais pas si tout le monde est familier avec HEDCD. HEDCD est un outil open source qui vous permet de gérer un key value store distribué, un peu comme ZooKeeper et des outils de ce style. HEDCD est plus récent et plus moderne que ZooKeeper. On voit une différence déjà, une première différence d'architecture avec ECS. Dans ECS, le cluster n'était composé que de nœuds, que de workers, et le backend ECS faisait office de maître et de key value store. Ici, on va déployer l'ensemble de cette architecture.
Sur le nœud maître, on a le point d'entrée de l'API qui va nous servir à déployer les conteneurs, à piloter le cluster, etc. Puis on a le scheduler qui, un peu à l'instar d'ECS, va s'assurer que le bon nombre de conteneurs tourne conformément aux directives que vous avez indiquées. Sur les workers, on trouve ce que Kubernetes appelle un kubelet. C'est un agent qui va servir à recevoir et interagir avec le maître. Il va recevoir les commandes venant du maître et remonter l'info du nœud. On a un proxy qui va nous permettre d'invoquer des conteneurs déployés sur un nœud sans qu'ils soient visibles de manière externe. Et on trouve, évidemment, Docker, et à l'intérieur de Docker, des pods qui sont l'équivalent des tâches sur ECS.
Un pod, c'est au moins un conteneur, donc un à n conteneurs qui sont déployés de manière atomique sur un nœud, qui peuvent communiquer entre eux, etc. À l'intérieur d'un pod, les conteneurs eux-mêmes. On retrouve les mêmes concepts : c'est Docker, donc il y a toujours la notion de conteneur, il y a toujours la notion de groupe de conteneurs, Kubernetes appelle ça un pod, ECS appelle ça une tâche. On a la notion d'agent, ici ça s'appelle un kubelet, dans ECS ça s'appelait le CS agent. On a un scale et un key value store qui sont sur le maître dans Kubernetes et dans le backend sur ECS. On a une API et une ligne de commande qui s'appelle kubectl qui va nous permettre d'envoyer des commandes à tout ce petit monde.
Donc, quand on connaît l'un, on est plutôt familier de ces concepts. On va les rebalayer rapidement avant de faire une démo. kubectl, c'est la ligne de commande de Kubernetes qui va nous permettre de lancer des conteneurs, d'obtenir toutes sortes d'informations sur le cluster. Comme vous l'avez compris sur le slide précédent, ça se passe via une API qui est présente sur le maître. C'est une ligne de commande plutôt simple à utiliser, les commandes ont des noms familiers : get, create, describe, delete. En explorant un peu intuitivement, on arrive à trouver les bonnes commandes. Elle est bien faite et simple à utiliser.
Les pods, ce sont des groupes de conteneurs. Au minimum, un conteneur, mais peut-être plus. Ils vont être déployés ensemble sur le même nœud et peuvent partager différentes ressources comme des volumes. Si vous avez défini des volumes de stockage à l'intérieur du pod, ils seront disponibles sur les différents conteneurs, des propriétés réseau, etc. Bref, un ensemble de conteneurs qui sont déployés sur le même nœud et qui partagent les mêmes propriétés comme une définition de tâche.
Les labels, dans AWS, on appellerait ça des tags. Vous savez qu'on adore les tags, on peut en mettre partout. Dans Kubernetes, ça s'appelle des labels, ce sont des paires clé-valeur et leur objectif est toujours le même : c'est de pouvoir facilement trouver les ressources dont on a besoin. On peut lister des ressources, des nœuds, des pods, des conteneurs, etc., qui ont les mêmes labels. Si vous avez une application composée de 10 conteneurs différents, c'est une bonne idée d'appliquer le même label sur tous ces conteneurs pour les créer, scaler, détruire de manière simplifiée.
Autre concept dans Kubernetes, le réplica set. Le réplica set définit le nombre de copies d'un pod qui vont exister sur le cluster. Dans ECS, on gérait ça lorsqu'on créait un service. Par défaut, on créait une copie, puis on pouvait scaler avec deux, trois, quatre copies, etc. C'est exactement la même idée. Ici, quand on crée un déploiement, on peut indiquer le nombre de répliques qui doivent exister sur le cluster. On voit, par exemple, deux copies du pod web et trois copies du pod app. Ce sont des valeurs qui peuvent évoluer au cours du temps.
Les déploiements, je les ai mentionnés. Un déploiement est l'entité Kubernetes qui va nous permettre de déployer un pod et éventuellement des répliques sur un conteneur. On a une syntaxe YAML plutôt simple. Ici, on crée un déploiement qui s'appelle Enginings Déploiement. On veut trois répliques. On applique un label avec la clé "nom" et la valeur "app", et comme conteneur à l'intérieur de ce pod, on a un conteneur qui s'appelle nginx qui ouvre le port 80 et qui correspond à l'image Docker nginx 1.7.9. C'est un exemple très simple, mais on retrouve les grands éléments qu'on trouve dans des composants Docker. Les syntaxes peuvent être un peu différentes, mais il n'y a pas de grosses nouveautés.
Une fois qu'on a écrit ce fichier YAML via kubectl, on peut créer le déploiement en lui passant le fichier. Ici, on va créer les trois copies du pod contenant Nginx. Ces fichiers ont pour objectif d'être modifiés, on peut appliquer des updates et faire évoluer la configuration.
La dernière entité importante, c'est le service. Un service est un ensemble de pods déployés sur le cluster et surtout la politique qui va permettre d'y accéder. L'objectif est de rendre visible depuis l'extérieur un ensemble de pods et donc de conteneurs. Lorsqu'on crée un déploiement, certes on déploie des conteneurs sur le cluster, mais ils ne sont pas accessibles de l'extérieur. On va les rendre visibles via différents mécanismes, par exemple en assignant une adresse IP par pod, ou en ayant un load balancer, etc. On verra un exemple après. L'objectif du service est de rendre visible depuis l'extérieur un ensemble de pods et donc de conteneurs.
À l'intérieur du service, on peut faire du service discovery. Les pods peuvent se trouver entre eux, et ils peuvent être visibles de l'extérieur. Je vous montrerai comment le faire avec un load balancer, avec un ELB. On peut créer un load balancer automatiquement qu'on place devant plusieurs répliques d'un même pod. Il y a d'autres façons de le faire, on peut attribuer des adresses IP, mettre des noms DNS, etc. Ici, je le ferai uniquement avec un load balancer.
Voilà les grands concepts de Kubernetes. Je suis allé assez vite. Le but n'est pas de faire un tuto détaillé de Kubernetes. Il y a un très bon tutoriel sur le site de Kubernetes, un tutoriel interactif qui est sympa à faire. Je vous ai mis l'URL à la fin, on en reparlera tout à l'heure. Je vous conseille vraiment de l'essayer, c'est une très bonne façon de découvrir ces concepts et de les voir en action.
Nous avons vu l'architecture globale, les grands concepts, maintenant se pose la question de comment on le déploie ? Comment on déploie un cluster Kubernetes et, pour ce qui nous intéresse aujourd'hui, comment on déploie un cluster Kubernetes sur AWS ? On peut démarrer soi-même des instances EC2, tout faire à la main. Vous démarrez 3, 4, 5 instances EC2, vous décidez que l'une est maître, que les autres sont des workers, vous installez Kubernetes à la main, etc. Pourquoi pas ? Ça marche, mais c'est un peu de travail, surtout quand ça va se casser la figure ou quand la configuration va changer et qu'il faudra la modifier.
Entre cette solution où vous faites tout à la main et ECS, où tout est managé et l'infrastructure est prise en charge automatiquement, il y a peut-être un juste milieu. Pour Kubernetes, il y a un outil plutôt sympa qui s'appelle KOPS, Kubernetes OPS, qui est un projet open source et une ligne de commandes qui va vous permettre, un peu comme on l'a fait sur ECS, de déployer et gérer des clusters. Le niveau de complexité est relativement faible, vous allez voir, on utilise des commandes pas beaucoup plus compliquées que ce qu'on faisait avec ECS CLI. C'est le même genre de solution.
Ce n'est pas du tout la seule, il y en a plein d'autres. Il y a plein d'autres façons de déployer Kubernetes sur AWS. Vous verrez aussi dans les ressources à la fin, il y a une page sur le site de Kubernetes qui liste les différents outils et méthodes existantes. J'ai choisi KOPS parce qu'il est bien intégré avec AWS, il est simple et relativement proche de ce qu'on fait sur ECS. Je trouvais que c'était assez cohérent de vous en parler.
Voilà le niveau d'abstraction de cette ligne de commande. Vous voyez, c'est create, update, get, delete. On est assez vite à l'aise. Néanmoins, on peut faire des choses compliquées avec KOPS. Voilà un exemple plutôt compliqué. On crée un cluster de trois nœuds, multi-AZ, multi-master, on spécifie toutes les tailles de tous les nœuds, on spécifie des security group, etc. Enfin, vous voyez, on va loin. Les commandes qu'on va exécuter sont plus simples. Et vous voyez, ce n'est pas parce qu'on peut l'utiliser simplement que c'est un outil trivial, on peut faire des choses compliquées avec KOPS également.
Je vous propose d'attaquer ça tout de suite. Et on va prier les dieux de la démo et les esprits d'Halloween pour qu'ils soient avec nous. Avant d'attaquer le cluster à proprement parler, il faut préparer deux choses. Et ça, c'est une vraie différence avec ECS. Il me faut deux choses. Il me faut d'abord un bucket S3. Dans ce bucket S3, on va stocker l'état, en tout cas des informations sur le cluster. Donc j'ai besoin d'avoir un bucket S3 dédié. Voilà, donc vous créez un bucket, tout ce qu'il y a de plus simple. Ça c'est fait, on a créé le bucket.
Ensuite, j'ai besoin d'activer le versioning sur ce bucket. J'ai besoin d'activer le versioning parce que, évidemment, l'état de mon cluster va changer au fil du temps, l'état des services va changer au fil du temps. Et donc c'est important pour KOPS de pouvoir versionner tout ça proprement et de pouvoir gérer les différentes versions. On va grossir ça encore un petit peu. J'espère que vous arrivez à lire. C'est important d'activer ce versioning pour que tous les fichiers de configuration qui vont être stockés dans le bucket soient versionnés et qu'on puisse gérer l'historique du cluster proprement.
Je vais récupérer ça et créer cette petite variable d'environnement qui m'évitera de taper ça à chaque fois. Voilà. Ça m'économisera des erreurs. OK, donc là, j'ai mon bucket versionné et une fois de plus, il va servir à stocker l'état du cluster Kubernetes. Ensuite, j'ai besoin d'un deuxième truc. J'ai besoin d'un domaine DNS, puisque j'ai besoin, à ma connaissance, c'est à peu près la seule façon dont KOPS et Kubernetes peuvent fonctionner. J'ai besoin d'avoir un nom de domaine visible depuis l'extérieur. Parce que mon objectif est de publier des services et je peux le faire par DNS.
J'ai cherché comment faire autrement parce que je ne tenais pas forcément à vous montrer du Route 53 aujourd'hui en plus. J'ai vu des tickets sur le projet GitHub de KOPS où des gens trifouillent et arrivent à faire des choses comme ça. Je n'ai pas voulu me lancer dans ça, j'ai préféré le faire de la manière propre. Il y a sans doute des contournements, mais une fois de plus, je préférais faire une démo qui ressemble à quelque chose plutôt que de vous montrer une collection de hacks.
Donc ici, j'ai créé un nom de domaine dans Route 53 qui s'appelle julien-test.net et qui va me servir à accéder à mon cluster depuis le monde extérieur. J'ai fait ça dans Route 53 parce que pour moi c'était le plus simple. Il n'est évidemment pas du tout obligé de l'avoir dans Route 53 pour avoir un nom de domaine chez un autre fournisseur de DNS. Le truc étant que s'il est dans Route 53, KOPS sera capable de le mettre à jour automatiquement. Si votre nom de domaine est hébergé chez X, Y ou Z, à l'extérieur, vous serez obligé de faire ces modifications vous-même. Ce n'est pas hyper compliqué, mais encore faut-il avoir la main sur ces DNS et avoir envie de faire ça. Donc la bonne solution, c'est d'avoir un nom de domaine dans Route 53 et de laisser KOPS mettre les choses à jour tout seul.
Maintenant, on va pouvoir créer le cluster. Je vais aller chercher ma petite commande ici. Je vais essayer de ne pas la lancer immédiatement pour pouvoir vous l'expliquer. OK. Donc, create cluster, le nom du cluster. On va faire même encore plus simple que ça. On va faire ça comme ça. Et puis ici, il y a tout un tas de paramètres. Vous l'avez vu sur le slide. On peut spécifier toute une tonne de paramètres dans cette ligne de commande. Ici, je n'utilise que les zones de disponibilité. Donc, je lui dis, tu vas me déployer mon cluster. Par défaut, il va y avoir trois nœuds. Et tu vas me les déployer sur US East 1A, 1B, 1C. Et le paramètre Yes indique que oui, j'ai envie de le faire tout de suite. Si je ne l'indique pas, il va me créer un fichier de configuration pour le cluster que je peux ensuite consulter, modifier, etc.
Et si j'utilise le paramètre --target avec le paramètre qui va bien, il peut me créer un template CloudFormation ou un document Terraform pour les amateurs. Donc si vous avez envie juste d'utiliser KOPS pour vous générer la configuration, c'est très bien. Puis après, vous pouvez utiliser Terraform ou CloudFormation pour l'appliquer. Ici, on va faire simple et on va faire comme ça. Attention, voilà, donc ici, il va créer l'ensemble des ressources. Ça va prendre quelques minutes, le temps que je vous l'explique. Il va créer l'ensemble des ressources qui sont nécessaires pour le cluster.
Donc tout à l'heure dans ECS, on le faisait avec CloudFormation. Ici, par défaut, j'ai bien indiqué que KOPS pourrait générer un template CloudFormation que vous exécuteriez ensuite. Mais ici, on va faire des appels directs à l'API AWS. Donc on va créer les rôles IAM, les instances EC2, etc. On va regarder un peu ce qu'on arrive à voir. Il crée toute la couche de sécurité, les certificats, tout ce qui va être déployé sur les nœuds Kubernetes pour pouvoir communiquer de manière sécurisée. Il m'a pré-créé les DNS. On va regarder ça. Il faut patienter un peu le temps que tout ça avance.
On va regarder le DNS donc là dans le DNS on doit avoir une entrée pour le point d'entrée de l'API qu'on va invoquer ensuite. À ce stade, je pense qu'il n'y a pas encore de vraie IP parce que je crois que les instances ne sont pas encore lancées. On va regarder un peu et rafraîchir EC2 aussi. Voilà, donc il m'a créé des entrées DNS pour l'API et puis pour deux ou trois autres trucs.
Voilà, et pour la petite histoire, manifestement, c'est mon PC, enfin mon Mac. Ce n'est pas le réseau. Je ne sais pas ce qui se passe. Mais j'ai jugé que ce n'était pas le bon moment pour les rebooter. Donc, on va serrer les dents. Voilà, on voit les trois nœuds du cluster par défaut. Un maître et deux workers. On voit qu'ils ne sont pas tous dans la même zone de disponibilité. Par défaut, il m'a créé une C4 large pour le maître, qui doit quand même héberger un peu plus de choses. Et puis des T2 medium pour les workers. Vous avez vu tout à l'heure dans l'exemple compliqué qu'on pouvait spécifier ces tailles-là.
Il est en train de les initialiser, il est en train de les bootstraper. On va patienter gentiment. On va regarder ce que... Pour l'instant, il m'a créé les entrées, il m'a mis des adresses IP qui ne sont pas les adresses IP définitives. Il y a du DNS interne pour l'API et pour Adcidi, et puis il y a cette adresse qui va devenir une entrée publique dès que possible, dès que mes IP, dès que mes instances seront prêtes. Il faut patienter deux minutes.
Et donc, effectivement, on doit être capable de faire KOPS Validate Cluster. Et tant qu'on ne voit pas que ça marche, j'ai envie de dire que ça ne marche pas. Alors, qu'est-ce qu'il va nous dire ? Il va nous dire que ce n'est pas prêt, je pense. Et voilà, c'est bien de le faire en temps réel. On voit le temps que prennent les opérations. Et il n'y a pas de mystère. Tant qu'on est basé sur des machines virtuelles, il faut les démarrer, les initialiser, les bootstraper, et ça prend un petit peu de temps.
Il en manque plus qu'un, on n'est pas très loin. Est-ce qu'on a mis ça à jour ? Il y a toujours une qui traîne. Allez ! OK, donc là, il a mis les IP. Là, on voit ça, ce sont des IP internes à AWS. Donc ça doit être certainement l'IP du maître, on pourrait regarder ça, l'IP privée du maître, et on attend... Ah voilà, les trois ont l'air bien, on va regarder un peu où on en est sur le DNS, voilà, on va faire un petit coup de validation et on espère que c'est bon.
Évidemment, c'était beaucoup plus rapide à la maison, mais ça, c'est comme d'habitude. OK, il faut patienter. Il faut laisser notre ami faire son petit travail. Je ne sais pas ce qu'il fait encore. Les instances sont up, mais ça, c'est la vision EC2 du truc. Kubernetes doit être en train de créer le key value store. Il doit être en train de faire tout un tas d'opérations et il faut attendre. Voilà. Donc ça, là-dessus, on n'a pas vraiment la main. Et tant qu'il ne me dit pas que tout est bon, je ne peux pas continuer. Voilà. Alléluia.
OK. Donc, résumons-nous. Nous avons le cluster de trois nœuds, un maître de node. Il a l'air d'être en bonne santé. Donc on pourrait commencer à jouer un peu avec kubectl. Il faudrait que ce truc-là réponde. Voilà, donc très bien. On pourrait lui demander des informations sur les nœuds et voir ce que ça répond. Voilà, donc là, je travaille en local sur ma machine, j'ai installé kubectl, etc. Et donc là, j'appelle l'API qui est hébergée sur le nœud maître pour obtenir des informations. Donc là, je vois bien mes trois nœuds qui tournent sur Kubernetes 1.7.4, ce qui n'est peut-être pas la dernière version, mais c'est KOPS qui fait comme ça, on va le laisser faire comme ça.
On va essayer de déployer un truc. On va déployer un premier service. Et on retrouve cette syntaxe YAML. C'est assez simple. Je crée un déploiement qui s'appelle EcoDeployment. Le conteneur que je vais déployer, c'est une image préexistante qui s'appelle EcoServer, qui renvoie les headers HTTP de la requête entrante. Donc, ce n'est pas très utile, mais au moins, ça permet de vérifier qu'on a un serveur web qui répond et qui renvoie quelque chose. Donc, c'est l'image qui est là, éco-server 1.4. On va en démarrer trois. Et que dire de plus ? Eh bien, voilà.
Donc, déployer une image, ça revient à écrire ces 10 ou 12 lignes de YAML, donc ce n'est pas énorme. Alors en avant, et je crois que c'est tout. OK, donc ça, ça va envoyer effectivement le fichier ou les informations qui sont contenues dans le fichier au cluster. Il va aller télécharger l'image, il va en démarrer trois, etc. On va lui demander Get Deployment. Et un peu comme tout à l'heure, on voit le Desired, Current, etc. Donc là, il a manifestement démarré les trois pods. On va s'en assurer. Voilà, et donc je vois que j'ai mes trois pods qui tournent sur le cluster.
On pourrait avoir envie d'avoir un peu plus d'informations. On pourrait faire describe pods et là, on va avoir plein d'informations. Voilà, beaucoup trop d'informations parce que là, il y a les trois. Voilà, donc pour chacun des trois pods, on a sa date de création, le conteneur, l'image utilisée, les ports qui sont ouverts, son état, les éventuels volumes créatifs qui ont été créés. Ça, c'est bien pratique, les événements. Donc on a l'historique des événements pour ce pod, ça, je trouve ça sympa. Voilà, puis après on a les deux autres et c'est du même tonneau.
On doit pouvoir ne décrire qu'un seul. Si je l'avais dit describe pods celui-là, j'imagine. Voilà, je n'aurais que celui-là. Donc c'est une ligne de commande qui est plutôt intuitive. Ça marche à peu près la façon dont on s'attend à ce que ça marche. Il n'y a pas vraiment besoin d'aller trop regarder la doc, au moins sur les commandes de base. OK. Qu'est-ce qu'on peut faire de plus ? On pourrait... Alors on va refaire GetPods. On pourrait aller lire les logs.
Alors ici, je ne suis pas sûr qu'il y en ait, donc à mon avis, ça ne va rien répondre, mais on va quand même essayer. Voilà, bon, il n'y a pas de log. Bon, maintenant, si vous aviez des logs, s'il y avait un stdout sur cette application-là et que ça écrivait sur stdout, on verrait déjà. On peut évidemment se connecter dessus, on peut faire ce qu'on fait dans Docker. Et on peut se connecter, voilà. Donc là, j'ai un SSH sur ce conteneur. Il n'y a rien à faire ici, particulièrement intéressant, on peut sortir. Voilà, mais ce sont des petites commandes comme ça qu'on peut regarder. Les commandes qui sont même franchement l'équivalent des commandes Docker qu'on trouve sur les conteneurs.
Donc là, j'ai un déploiement. On voit bien ça, on voit bien... Si je tape n'importe quoi, évidemment, ça ne marche pas. OK, donc très bien. Maintenant, j'aimerais y accéder depuis l'extérieur. Donc là, on va passer à la deuxième étape qui est la création d'un service. Deuxième fichier de configuration. Vous allez voir, il n'est pas méchant. Je crée un service qui s'appelle « Eco-Service » qui va s'appuyer sur l'application Ecopod que j'ai créée précédemment. Avec les fameux labels que j'ai mis tout à l'heure, je peux référencer à l'intérieur des fichiers de configuration des ressources qui ont tel ou tel label. Je veux les exposer via HTTP sur le port 80 de l'extérieur. Le port interne, c'est 80-80. Les pods que j'ai créés, ils exposent en interne le port 80-80. Et j'ai envie d'avoir un load balancer. Et ici, ça va être un ELB.
Donc, je vais créer le service. Il ne faut pas le mettre en... Voilà, c'est celui-là. Ok. Alors évidemment, je peux faire ça. Magnifique. Et je vois quoi ? Je vois que j'ai un service qui s'appuie sur un load balancer et qui a une external IP bien bizarre, parce qu'évidemment, ça, ce n'est pas une external IP, c'est un nom DNS. On va essayer d'aller le trouver dans notre petite console. Si tout va bien, on doit voir ici un ELB en cours de création et en train de faire rentrer les instances du cluster.
Donc effectivement, on voit ce fameux nom magnifique qui correspond donc à ce nom DNS. Donc ça, ça va être le nom DNS de l'ELB. Je vois qu'il est accessible sur le port 80, ce qui est plutôt bien. Quant aux instances, alors ici j'ai deux instances, puisque j'ai deux workers dans mon cluster. Pour l'instant, elles sont out of service, parce que si vous utilisez l'ELB, vous avez l'habitude de ça. La première fois qu'un load balancer voit une instance, il y a un petit temps d'enregistrement.
Ici, effectivement, on voit que le service est créé, mais on doit, une fois encore, patienter que le load balancer fasse les health checks et s'assure que les services fonctionnent correctement. Voilà, j'imagine que la deuxième demande... On devrait pas tarder. On devrait déjà pouvoir le tester vu qu'on a un nœud. Alors on va le tester tout de suite. Donc on va prendre ce beau nom DNS. Et attention, magie. Ouais, voilà, ça c'est l'écho. Donc c'est super bien. Vous lui envoyez des headers et vous les renvoyez. C'est écho.
Mais au moins, ça prouve qu'il y a un serveur web qui tourne. Je vois effectivement l'URI qui est arrivée ici. On voit bien que, vu du conteneur, elle est arrivée sur le port 8080. C'est-à-dire que, vu du LB, elle arrive sur le port 8080. Et ensuite, il la redirige vers le conteneur qui lui expose le port 8080. C'est pour ça que sur l'URI, ici, on voit bien 8080.
Allez, on va vérifier que l'autre est là. Voilà, donc la deuxième est là. Ok, donc on a nos deux workers, tous les deux actifs derrière le load balancer. Est-ce qu'il y a un... je ne sais pas si on va essayer... Ah, il y a un host là. On va voir si ça change. Je ne suis pas sûr que ce soit la bonne valeur. Ouais, si, ça... Ça bouge, non ? Bon. OK, bon, il faut me croire sur parole. OK, donc on a bien réussi à créer notre service et on a bien réussi à créer le load balancer.
Et vous voyez qu'on le fait de manière plutôt simple, parce que si on réaffiche le fichier ici, on se contente d'indiquer qu'on veut un load balancer sur le port 80 en externe et sur le port 80-80 en interne, et finalement on ne rentre pas trop dans les détails. Ça reste assez au niveau. Voilà ce qu'on peut montrer rapidement sur Kubernetes. Et puis si on veut tout arrêter, allez, on va faire ça.
Ah oui, avant de faire ça, je voulais vous montrer l'IP quand même. Pardon, je m'enflamme. Voilà, mais dans le DNS, normalement, là, on doit avoir l'IP, on doit avoir la bonne IP maintenant. Histoire de recoller un peu les morceaux dans notre tête. Voilà. OK. Donc, api.julien-test.net, ça, c'est une IP publique. Donc ça, c'est l'IP publique du maître, 34.200.1.12. Voilà. Si je retourne là, sans doute je vais la voir. Alors, où est le maître ? Il est là. Voilà, elle est là. Ok. Hop, ça a disparu. J'ai cliqué trop vite. Voilà, elle est là. 34.201.12.66. Donc, on voit bien ça.
OK, donc voilà pourquoi il me faut un nom de domaine. C'est parce que j'ai besoin d'aller pouvoir adresser mon cluster, et particulièrement le maître du cluster. Donc on va tout détruire, ça va fonctionner, c'est magnifique. Et donc là, on va faire le chemin inverse, donc on va appeler les API AWS pour aller détruire toutes les ressources qu'on a créées, désenregistrer, désenregistrer, enregistrer les entrées DNS, etc. Et tout ça, ça se fait sur des appels directs. Ma préférence irait plutôt à du Terraform ou du CloudFormation, histoire d'être sûr que rien ne reste derrière. Avec les tests que j'ai faits, tout était effectivement bien effacé, mais il pourrait y avoir un problème quelconque dans ce script qui l'interrompe et qui laisse des ressources derrière, ce qui n'est pas forcément une bonne chose.
Voilà Kubernetes. On va le laisser nettoyer tranquillement. Donc, quelques ressources supplémentaires. Le tuto dont je parlais tout à l'heure, le tuto du site Kubernetes, qui est sympa, c'est le Getting Started sur AWS qui va vous lister les différentes façons de déployer sur AWS, y compris KOPS que je vous ai montré aujourd'hui. Une vidéo de reInvent l'année dernière qui parle des différentes solutions possibles pour déployer des conteneurs sur AWS, ça parle un peu de ECS, ça parle aussi de Kubernetes, de Rancher, enfin c'est une session assez intéressante qui fait un panorama de ces différents outils.
Les quelques commandes que je vous ai montrées sont extraites d'un workshop Kubernetes sur AWS qui a été rédigé par mon collègue Harun Gupta, qui est évangéliste open source aux US. Je le remercie chaleureusement d'avoir mis au point ce workshop qui est vraiment très pratique pour les gens qui veulent découvrir Kubernetes sur AWS. Il a un poste de blog que je vous ai indiqué ici qui explique dans les grandes lignes comment marche KOPS et puis surtout il a ce workshop très détaillé sur GitHub qui conviendra bien pour les débutants et pour les gens qui veulent creuser et découvrir les fonctionnalités plus avancées. Je vous conseille de le suivre sur Twitter, c'est sans doute la personne chez AWS qui connaît le mieux Kubernetes. Avant de vous répondre à vos questions, je voulais parler de CNCF, que vous connaissez sans doute, la Cloud Native Computing Foundation, qui est une organisation qui pilote un ensemble de projets open source liés au container en général, pas uniquement à Docker. Des projets comme Kubernetes, Prometheus, Linkerday ou d'autres. Rocket même, le nouveau runtime qui fera peut-être de la concurrence à Docker un jour, on verra. Et pourquoi j'en parle ? Tout simplement parce que AWS fait maintenant partie, au même titre que tout le monde, de CNCF. On est représenté là-bas par Adrian Cockroft, qui vous connaissez sans doute, c'était le chief architect de Netflix, il a rejoint AWS maintenant il y a à peu près un an, et donc il est VP cloud architecture chez AWS et donc c'est notre représentant au CNCF. Il a écrit un blog post particulièrement intéressant. Je lui ai emprunté cette image de paradisiaque. J'espère que c'est effectivement un avant-goût du fonctionnement du CNCF, l'idée étant vraiment que tous les grands acteurs collaborent pour permettre à vous tous, aux utilisateurs et aux développeurs, d'avoir une expérience assez homogène sur ces outils, en tout cas c'est vraiment notre volonté. Et c'est pour ça qu'on a rejoint ce groupe, pour permettre vraiment aux gens qui veulent utiliser Kubernetes et ses autres technos sur AWS, de pouvoir le faire le plus simplement possible. Et on travaille beaucoup pour simplifier l'intégration de ces technos sur AWS.
Pour finir, si on doit essayer de faire un petit résumé de Kubernetes et de CS, le premier point, c'est évidemment que Kubernetes, vous l'avez vu, vous devez le manager, c'est vous qui créez l'infrastructure. Alors certes, des outils comme COPS vous permettent de le faire de manière plus simple, mais ça reste un processus un petit peu plus lourd que d'utiliser ECS où finalement, en particulier, toute la gestion du back-end et de l'ordonnancement est complètement prise en charge. Il n'y a pas de master, il n'y a pas de choses comme ça. Lorsque vous déployez un cluster Kubernetes, à priori, vous allez le déployer pour vous. Vous allez devoir le scaler pour vous, etc. Dans ECS, le back-end en particulier, partagé donc on est sur un service multi tenant qui est éprouvé par un grand nombre de clients et donc avec une robustesse intéressante et puis on s'appuie sur EC2 qui a dix ans d'histoire et qui marche pas mal.
Lorsque vous créez un cluster Kubernetes, donc vous créez le ou les masters donc ce sont des instances EC2 dédiés donc vous allez devoir les payer ce qu'on appelle donc le control plane. Vous avez bien compris sur le master on n'exécute pas de containers c'est vraiment le pilotage du cluster. Dans ECS, c'est inclus, vous créez des instances EC2 que vous payez désormais à la seconde et qui sont 100% disponibles pour l'exécution de vos containers. Alors sur des très gros clusters ça fera pas une grosse différence si vous avez un 1% d'overhead, ce n'est pas grave. Sur des petits clusters de quelques nœuds, c'est quand même plus embêtant.
Sur Kubernetes, vous devez gérer les montées de version. Sur ECS, c'est fait automatiquement. Vous avez la possibilité d'utiliser CNI, qui est un des projets de réseau. C'est un point très positif. Il n'est pas encore disponible sur ECS, on est en cours d'implémentation. Et puis dernier point, la sécurité, l'intégration avec IAM qui est native dans ECS et qui ne l'est pas dans Kubernetes. Donc vous devez être prudent sur la sécurité et c'est un petit peu plus de travail. Après, vous choisissez ce qui vous plaît. Nous, notre objectif, c'est de vous offrir les deux, d'avoir ECS managé, facile, très intégré, etc. et puis Kubernetes plus flexible, plus configurable mais au prix d'une complexité sans doute accrue. Donc c'est vous qui décidez, nous on essaie de faire en sorte que les deux marchent bien.
Voilà, dernière chose avant de répondre aux questions, je vous rappelle qu'on a une série d'événements en France au mois de novembre, regroupés sous le nom de Transformation Day. D'abord à Paris le 8 novembre, donc événement d'une journée. Adrian Cockroft que j'ai mentionné sera en keynote, donc voilà à ne pas rater. Je crois que de mémoire c'est la première fois qu'il intervient pour nous en France, donc on est content de l'avoir. Et puis comme d'habitude des sessions techniques et métiers l'après-midi avec des témoignages clients et on décline cet événement à Lyon, Toulouse, Nantes et Lille pendant la deuxième et la troisième semaine de novembre. Je ne vais pas vous dire les dates de tête, je vais me tromper, mais je crois que c'est 14, 16, 21 et 23. Hugo me dit que c'est ça. Donc voilà, 14, 16, 21, 23, c'est le quartet dans le désordre. Si vous êtes à Lyon, à Toulouse, à Nantes, à Lille, venez nous voir. On aura une bonne partie du contenu de la journée qui sera disponible pour vous. Et puis une partie de l'équipe, bien sûr, qui sera là et qui répondra à vos questions. On espère vous voir, surtout en province. Je sais que vous êtes nombreux à nous attendre. Nous voilà, donc ne nous ratez pas.
Voilà, j'ai fini. Je vous remercie beaucoup de m'avoir écouté. J'espère que ces deux webinars sur Kubernetes vous ont intéressé. Deux approches un peu différentes, mais qui ont toutes les deux des bénéfices, des avantages et des inconvénients. Et on aurait pu parler encore d'autres orchestrateurs, mais le temps me manque. Et vraiment, l'objectif, c'est de vous fournir des solutions qui marchent bien, qui correspondent à votre niveau d'expertise, à votre niveau de connaissance de la plateforme et qui vous permettent de bâtir et de déployer vos applications Docker. Très bien, j'en ai terminé. Je pense qu'on va peut-être faire le sondage. Comme d'habitude, Hugo va afficher le sondage. Hugo est là, on ne l'entend pas, il est d'une discrétion exemplaire, mais il est toujours là. Merci beaucoup Hugo. Et donc vous connaissez ça, maintenant que vous avez l'habitude, vous votez 5, vous êtes très content. 1, vous n'êtes pas content du tout. On vous laisse une trentaine de secondes pour voter. Ensuite, on va répondre aux questions. Encore quelques secondes. Tout le monde n'a pas voté. Allez, votez, votez, votez. Même si vous n'êtes pas content. Vous avez l'air content. Ça va. Si vous êtes content, on est content. Bon. Merci beaucoup. Les questions ?
Ah, les questions. Ah bah oui, non mais ils viennent avec leurs questions, moi je viens avec mes réponses. Ça rappellera quelque chose aux plus anciens d'entre vous. Alors... Hugo, si tu joues avec l'écran, on va pas y arriver. Jusque là, t'avais été irréprochable. Ok. Allez, c'est parti. Non, c'est pas parti. C'est Halloween. C'est Halloween. Alors, en avant... Je vais prendre dans le désordre, parce qu'il y a pas mal de questions. Alors, question de Claudine. La facturation à la seconde existe maintenant pour toutes les instances EC2 ? Oui. Donc la facturation à la seconde, depuis début octobre, elle s'applique sur EC2, EBS, ECS. Alors, à ma connaissance, et j'espère ne pas dire d'ânerie, pas encore EMR. Donc si vous faites du élastique marron, je crois qu'on n'y est pas encore, ça va venir. Mais en tout cas, oui. EC2, ECS, oui, c'est à la seconde. EMR aussi ? D'accord, très bien. Vous voyez, j'avais raté ce coup-là. Merci Hugo. Donc EMR aussi. Oui, c'est arrivé quelques jours après. C'est pour ça que j'ai dû rater la once. Donc OK, EC2, ECS, EMR, c'est bon.
Question de Mohamed. Est-ce qu'on peut choisir l'AMI des instances ou est-ce que c'est une AMI déjà préparée ? Ah super question merci Mohamed j'ai oublié de le dire alors quand vous utilisez ECS CLI vous avez vu j'ai pas spécifié d'identifiant d'AMI donc on utilise une AMI qu'on vous fournit qui s'appelle ECS Amazon ECS Optimized AMI. Donc c'est un Amazon Linux plus Docker plus l'agent. Donc si ça vous va c'est très bien, si vous voulez utiliser vos propres AMI, il n'y a pas de problème, à partir du moment où vous mettez Docker dessus et l'agent, vous packagez votre AMI et puis vous pouvez lancer les clusters avec cette AMI-là. Donc absolument vous avez la liberté de faire et j'avais fait d'autres démos comme ça sur CoreOS ou Rancher et c'est comme ça que j'avais fait.
Alors, question de Wilfried. Est-ce qu'on peut modifier le type d'une instance dans un cluster, en particulier dans le cas d'instances intégrées manuellement ? Tout à fait, on n'est pas du tout obligé d'avoir des instances homogènes dans le cluster. Une fois de plus, là, je l'ai fait avec ECS CLI parce que c'est simple et comme vous découvrez, je ne voulais pas vous perdre. Mais je pourrais tout à fait rajouter des instances supplémentaires dans le cluster, y compris à la main. Donc, je pourrais démarrer des M4 large. À partir du moment où elles ont l'agent et où dans le fichier de configuration de l'agent, j'ai mis le nom du cluster, quand je démarre l'agent, elles vont rejoindre ce cluster-là. Donc, on peut complètement avoir des instances de tailles différentes. Et du coup, la conséquence, c'est qu'elles auront évidemment une taille mémoire différente et un nombre de points CPU différents. Et ce qui permet d'avoir des stratégies de placement différentes. Vous pourriez avoir 10 nœuds M4 large et puis 3 nœuds GPU parce que vous avez besoin d'avoir des containers GPU. Donc absolument on peut faire ça.
Alors il y a plusieurs questions. Quels sont les avantages ou les inconvénients de Kubernetes par rapport à ECS ? J'en ai dit un mot à la fin et mon objectif n'est pas de déclencher une guerre de religion. Moi quand je parle à des clients, ceux qui utilisent ECS me disent qu'ils utilisent ECS parce qu'ils voulaient un service managé, ils veulent pas passer de temps à gérer le cluster, ils veulent simplement une infrastructure sur laquelle déployer leurs containers et c'est tout et donc ECS leur va très bien. Ce n'est pas forcément des gens peu sophistiqués, c'est des gens qui ont des grosses plateformes. Je ne peux pas citer la boîte en question mais je pense à une grosse boîte du CAC 40 qui fait ça. Il y a peut-être des gens qui m'écoutent et ils vont se reconnaître mais je ne peux pas en dire plus. Mais voilà donc ce n'est pas des gens qui... ce n'est pas des débutants, ce n'est pas des noobs, c'est simplement des gens qui disent moi j'ai besoin d'une plateforme Docker scalable, hautement disponible etc mais je ne veux pas m'en occuper donc je démarre mes noeuds ECS, je déploie mes containers et ça vit sa vie et ça marche très bien. Donc il y a des gens pour qui c'est amplement suffisant et puis il y a des gens qui préfèrent comme souvent avoir le contrôle complet de tous les petits réglages et qui pensent alors à tort ou à raison c'est pas à moi de le dire une fois de plus je suis pas là pour pour débattre du bien fondé de ce truc là qui pensent à tort ou à raison que tel petit feature ou telle fonctionnalité de Kubernetes va leur donner un avantage compétitif quitte à gérer manuellement bon c'est leur choix moi j'ai pas à me mêler de ça. Il y a certaines architectures réseau complexes qu'on peut faire avec Kubernetes, qu'on peut sans doute pas encore faire avec ECS. Si les gens décident que c'est important pour eux de faire ça et que ça leur donne un avantage, très bien, ils font ça. Simplement, ça se fait, de mon point de vue, au prix d'une charge opérationnelle plus lourde. Maintenant, si c'est important pour eux, c'est qu'ils sont aussi prêts à payer le prix de l'exercice de la maintenance et du maintien en condition opérationnelle du cluster. Après, on peut débattre à l'infini du micro-feature machin versus le micro-feature bitonio, qui est un terme technique, Hugo. Mais je pense que ce n'est pas l'intérêt. L'intérêt, c'est vraiment de dire, est-ce que vous voulez un service manager qui fait 90% du boulot à votre place et ça vous va ? Ou que vous jugez que c'est important de tout contrôler finement et tout faire vous même auquel cas faites le vous même. Voilà donc j'ai répondu à un ensemble de questions je m'excuse de pas vous citer individuellement il y avait voilà Jérôme me disait est ce que c'est contre indiqué d'utiliser Kubernetes sur AWS non pas du tout il n'y a pas de contre-indication il ya beaucoup de gens qui font du Kubernetes sur AWS je serais très curieux d'avoir des chiffres du Kubernetes sur AWS versus Kubernetes sur Google. Je pense qu'il n'est pas exclu qu'on ait des surprises. Je n'ai pas ces chiffres, peut-être qu'on les donnera un jour, mais je pense qu'il pourrait y avoir des surprises. Donc vous faites comme vous voulez. Si vous avez des problèmes d'utilisation de Kubernetes sur AWS, vous les remontez, vous les remontez via le support, vous les remontez, etc. et ils seront pris en compte. Une fois de plus, notre objectif, c'est que les clients aient le choix et que toutes les solutions fonctionnent bien. Donc il n'y a pas d'objectif que ECS marche très bien et Kubernetes ne marche pas. L'objectif, c'est que les deux marchent très bien. Donc si vous avez des problèmes, vous les remontez. Vous les remontez dans les forums, vous les remontez dans le support et je vous garantis que les équipes vont regarder.
Alors, question... que j'ai vu... Alors, il y a Vincent qui demande est-ce que c'est partagé ? Alors, est-ce que je partage la démo, les sources ? Alors, en fait, le plus simple, honnêtement, pour la partie Kubernetes, je vous renvoie au workshop d'Haroon où vous trouverez mille trucs. Je vais remettre le fameux workshop, on va quand même le mettre. Dans le workshop d'Aaron, vous trouvez beaucoup de trucs. Et si vraiment vous voulez les commandes ECS, mais qui n'étaient pas très sophistiquées, qu'est-ce que j'ai tapé comme commande ? vraiment les commandes qui sont dans les slides donc voilà je vous renvoie à ça voilà le workshop down puis vous s'il ya des problèmes vous me piquez sur Twitter si vraiment il vous manque un truc contactez moi sur Twitter je voulais repartagerais alors on a des fans de nomades alors nomades nomades dachicon Pour ceux qui connaissent ça, c'est Jérôme. Jérôme a l'air d'être un fan de Nomade, donc très bien. Honnêtement, je n'ai rien fait de suffisamment intelligent là-dessus pour avoir un avis pour l'instant. Je ne me défile pas. J'ai vraiment joué avec de manière assez anecdotique et j'ai pas d'avis. Donc le jour où j'en ai un, on fera un webinar, mais effectivement c'est une autre solution qui est intéressante. HICorp fait de manière générale de très très bons outils. J'ai parlé de Terraform, moi j'aime bien Terraform, donc pas de raison de penser que Nomad ne soit pas bien, mais honnêtement j'ai pas joué avec, donc si c'est pour dire des banalités, je vais préférer m'abstenir. Mais voilà, voilà un troisième truc à tester. Merci Jérôme d'attirer honnêtement d'attention là-dessus.
Alors Claudine me dit, vous dites qu'il n'y a pas de problème Kubernetes sur ECS, que pensez-vous de Kubernetes sur plusieurs comptes de production AWS ? Ah mais je pense, j'en pense le plus grand bien. Je connais plein de clients qui font du Kubernetes à l'échelle sur AWS et quelque chose me dit qu'on aura des sessions là dessus je pense que à ma connaissance on n'en a pas eu l'année dernière c'était peut-être un peu tôt mais je suis à peu près convaincu qu'on va en avoir cette année il faudrait vérifier l'agenda donc ça sera intéressant de voir ce que font nos clients sur ce que font nos clients sur Kubernetes et AWS mais oui il y a plein plein de gens qui font du Kubernetes à l'échelle sur AWS et ça marche très bien pour eux aussi il n'y a pas de problème.
Alors, qu'est-ce qu'il y a d'autre ? Alors, il y a Johnny qui me demande, je n'ai pas compris comment fonctionne l'équivalent des services dans ECS. Ah oui, alors, est-ce que c'est l'application Load Balancer ? Donc, effectivement, ce que je vous ai montré dans COPS, c'est comment créer un service Kubernetes en déclarant un load balancer devant. Donc effectivement, pour faire la même chose dans ECS, il faudrait... On pourrait faire la même chose dans ECS, c'est-à-dire qu'on pourrait créer un load balancer. On pourrait même le faire avec un ELB. Dans l'exemple que j'ai fait, les containers tournaient tous sur le port 80. Donc on aurait pu avoir un ELB, on aurait créé un ELB, on lui aurait attaché les trois instances ECS qui étaient dans le cluster et puis il aurait fait les health checks sur le port 80 des containers et il aurait détecté le truc. Donc ça c'est l'ancienne façon de le faire à l'époque où on n'avait pas de load balancer capable de balancer sur des ports aléatoires. Donc maintenant, avec l'ALB, on a cette capacité-là. Donc on est capable de démarrer des containers, plusieurs copies du même container sur des ports aléatoires et de faire du load balancing de niveau 7. Donc on ne balance plus sur les ports, on balance sur les routes, donc sur les URL. Et ça, c'est l'application Load Balancer. Donc, oui, Johnny, il faut regarder l'application Load Balancer. Et ça marche parfaitement bien sur ECS et on fait exactement le même genre de choses.
Alors qu'est-ce qu'on a d'autre ? Alors Claudine me demande que veut dire la mise à jour du 22 septembre ? C'est le feature du 22 septembre ? Alors on va revenir dans les slides. Ah oui. On voit mon écran là, Hugo ? Oui. Alors, le feature du 22 septembre, en fait, c'est... On a la capacité, donc les Linux capabilities, alors ça, j'admets que c'est un truc important, peu obscur, ce sont des permissions système qu'on peut attribuer à une application. Donc on peut autoriser une application qui tourne sur Linux à accéder à, pour faire simple, des fonctionnalités du noyau un peu spécifiques. Et donc on peut maintenant faire ça sur les containers. Donc on peut autoriser un container à accéder de manière directe à telle ou telle donnée ou à telle ou telle fonctionnalité du noyau Linux, qui sont des trucs très privilégiés auxquels on n'a pas accès quand on est une simple application. Je vous renvoie vers la doc, c'est très spécifique, c'est de la Linuxerie pure et dure, mais ça nous manquait. On avait la possibilité de le faire sur des agences linux qui tourne sur EC2 traditionnel mais pas encore sur les containers donc maintenant c'est le cas.
Alors Guillaume me dit faudrait prévoir un autre webinar sur les outils d'exploit autour de l'orchestrateur gestion de logs métrologie supervision c'est pour quand la seconde session ? Comme vous y allez Guillaume oui, c'est vrai, c'est vrai qu'il n'y a pas que ça, on est bien d'accord. Il n'y a pas que l'orchestrateur, mais il faut bien commencer par ça. Mais ceci dit, oui, c'est une bonne remarque. L'orchestrateur, c'est une chose, et puis après, on pourrait même parler de la chaîne de développement. Moi, j'étendrai même ça au CI-CD. Qu'est-ce que c'est du CI-CD ? sur Docker et comment est-ce qu'on le fait. Alors, on peut le faire avec nos outils CodePipeline, etc., dont j'ai déjà parlé. On peut déployer des containers Docker sur ECS. Effectivement, ça mérite une deuxième et sans doute une troisième session. On va y réfléchir. On n'a pas fait l'agenda 2018, mais voilà. Guillaume pense sans doute que je n'ai pas assez de travail. Ça doit être ça, je dirais. Je dois avoir le teint trop frais encore. Il faudrait que j'arrête de dormir. Non, mais on va essayer, on va essayer, Guillaume. Promis ou pas promis, mais on va essayer.
Question de Mohamed. Ça sera peut-être une des dernières, je ne sais pas quelle heure il est Hugo. On a vu qu'on peut caper le CPU et la mémoire. Est-ce qu'on peut créer dans le container une custom métrique et l'envoyer à CloudWatch ? Oui, tout à fait, il n'y a pas de souci. À partir du moment où vous avez installé les outils nécessaires à l'intérieur du container, oui, vous pouvez utiliser la ligne de commande AWS ou que sais-je pour faire un putt métrique et l'envoyer à CloudWatch. Il n'y a pas de souci, ça doit marcher. Je ne l'ai pas testé personnellement, mais il n'y a aucune raison que ça ne marche pas.
Question de Romain. Est-ce à nous de créer les instances exécutant les containers ? Alors, je ne sais pas si on parle de ECS ou de Kubernetes. On va le faire dans les deux cas. Dans ECS, si vous utilisez ECS CLI, non. Vous avez vu, on crée le cluster et les instances montent toutes seules. Vous pouvez choisir la taille. Si vous utilisez l'AMI ECS Optimized, elle a déjà l'agent, etc. Mais vous pourriez prendre 5 instances EC2 qui existent déjà, que vous avez déjà créées pour autre chose, installer Docker dessus, installer l'agent, et créer un cluster à partir de cette infrastructure-là. Vous utilisez Une fois de plus, ce sont des instances EC2. Donc, à partir du moment où elles ont Docker, à partir du moment où elles ont l'agent, vous pouvez les ajouter à un cluster. J'espère que ça répond à la question. Vous avez le choix de créer à la demande ou de réutiliser ou de faire un mélange des deux. Comme je le disais tout à l'heure, si vous avez un cluster et qu'il vous faut une instance GPU ou 2 à l'intérieur, vous les créez à la main et vous les ajoutez dans le cluster et c'est bon.
Alors, il y a une question de Hirofumi en anglais. Je vais répondre en français, mais j'ai fait tout le webinaire en français. Hirofumi, j'espère que vous me comprendrez. La question est, sur Kubernetes COPS, est-ce qu'on peut faire de l'autoscaling de la même façon que sur ECS ? C'est une excellente question. Et je n'ai pas de réponse là-dessus. Je ne connais pas assez bien COPS. Voilà. Donc je ne sais pas. Il faudrait fouiller dans... Il faudrait fouiller dans COPS. Pour faire de l'autoscaling, il faudrait définir une métrique. C'est une bonne question, je ne sais pas. Je vais regarder. Merci, j'aime bien les questions auxquelles je n'ai pas la réponse. Ça me permet d'apprendre des trucs. Jérôme dit qu'on peut. Ok, bon. Je vais regarder Jérôme. Voilà, donc Hirofumi, de vous demander à Jérôme, il va Non, mais je n'ai pas suffisamment joué avec COPS dans ce niveau de détail. Dans ECS, ce n'est effectivement pas très difficile à faire parce que comme ça s'appuie sur un groupe d'autoscaling, on peut définir des métriques. On a les métriques du cluster, on a les métriques des containers. Donc, on fait de l'autoscaling comme on fait de l'autoscaling sur EC2. Sur COPS, je n'ai pas suffisamment joué avec et je n'ai pas fait de production dessus, donc je ne sais pas. Alors...
Boubecker me pose la question que j'attendais. C'est pour quand la région France ? Alors je peux vous donner la date. J'ai le droit. J'ai le droit aujourd'hui. On est d'accord Hugo ? Je vais vous dire la date. Attention. C'est avant le 31 décembre. Voilà. Vous pouvez tweeter. J'espère ne pas être viré pour avoir révélé la date. Donc c'est avant la fin de l'année. Donc on est comme vous, on compte les jours. Je ne vous cache pas qu'on On est assez impatients et on attend que ça arrive et nos clients aussi. Croyez-moi, on est aussi impatients que vous, je vous promets. On a encore du temps ? Encore une ? Allez, une petite dernière. Parce que c'est Halloween quand même. C'est pas tout ça, mais il faut aller faire peur aux gens dans mon village après. Donc...
Qu'est-ce qu'on a encore ? À quoi je pourrais répondre ? Non, il n'y a plus grand-chose qui m'inspire, sincèrement. Il y a soit des questions trop compliquées. Ah oui, il faut choisir... Il faut choisir un gagnant. Deux ! Ah là là là là là là ! C'est le moment où je ne me fais pas d'ami, c'est ça ? Bon, on va faire gagner Jérôme alors déjà. Parce que Jérôme nous a parlé des choses intéressantes, nomades et tout ça. Donc merci Jérôme d'avoir complété... Et puis... Ah là là... Oh, et puis on va faire gagner Claudine. J'ai décidé qu'on aurait la parité. Donc c'est scandaleux, parce que je pense que proportionnellement, il y a tellement moins de participantes qu'elles ont une chance statistique élevée de gagner. Voilà. Bon, Romain... C'est ça ? Non, pardon. Jérôme et Claudine, vous avez gagné. Qu'est-ce qu'ils ont gagné ? Ils ont gagné des goodies à WS que je vais devoir aller chercher dans ma grotte. Il reste des chaussettes lambda, je crois. Est-ce que vous voulez des chaussettes lambda ? On va vous faire un petit paquet. Voilà, allez, je pense qu'on a fait le tour pour aujourd'hui. Une fois de plus, je vous remercie de participer à ces webinars, on s'amuse beaucoup. Vous avez l'air contents aussi, au vu du sondage, donc c'est super. J'espère que vous avez découvert pas mal de choses. Effectivement, on a fait qu'effleurer le sujet des containers qui est très très large, il y aura un certain nombre d'autres sessions. Et donc en attendant, je vous souhaite une bonne soirée, un bon Halloween pour ceux qui le fêtent. Et je vous donne rendez-vous le mois prochain pour un sujet qui n'est pas défini, puisque je serai à Réinvent, dans un état probablement pitoyable, avec le décalage horaire, mais on verra. Ça sera live de Las Vegas. Je ne sais pas ce que ça va donner, mais on va essayer de faire un truc rigolo. Et en tout cas, il y aura certainement beaucoup d'actualités à couvrir. Voilà, merci beaucoup. Rendez-vous le mois prochain et bonne soirée.