Deployer et scaler des clusters Docker avec Amazon ECS

Transcript

Bonjour à tous, merci beaucoup à Xébia de me donner l'opportunité de vous parler aujourd'hui. Je m'appelle Julien, je suis évangéliste technique chez AWS et je travaille de temps en temps dans le bureau de Paris. Et le reste du temps, je me promène beaucoup. Ça fait du bien d'être à Paris pour changer, je crois que c'est la première présentation que je fais à Paris vraiment depuis quelques jours, quelques semaines. Donc ça fait du bien de ne pas avoir de trajet. On va pendant une demi-heure, ou 24 minutes, parler de l'orchestration de containers Docker sur AWS. Je fais la présentation en français, mais est-ce que tout le monde parle français dans la salle ? Ouais ? Ok, très bien. Si quelqu'un ne comprend pas, il lève la main. Je peux changer à l'anglais si quelqu'un veut. Quelqu'un veut que je parle en anglais ? Juste un ? Non, allez. C'est une blague. Bon, en français alors. Je pense que vous avez déjà entendu cinq ou six fois la problématique des containers, donc je ne vais pas du tout parler de pourquoi c'est bien de faire des containers. Je pense qu'on serait pas là, il n'y aurait pas autant de monde dans cette salle aujourd'hui si on n'avait pas un petit intérêt pour les containers. Par contre, ce qui mérite peut-être d'être discuté 30 secondes, c'est quel est le problème qu'on essaie de résoudre à l'échelle ? Quel est le problème qu'on essaie de résoudre avec un orchestrateur ? Et en fait, le problème qu'on essaie de résoudre, c'est exactement celui-là. Sur une grille qui nous offre des emplacements CPU, des emplacements RAM, on va essayer de placer de manière optimale un grand nombre de containers provenant d'un grand nombre d'applications. Et bien sûr, sur une grille de 3 par 3, ce n'est pas une difficulté, et un enfant de 3 ans doit y arriver. Et idem, si vous avez 9 containers à placer sur une machine ou sur deux machines, ce n'est pas vraiment une difficulté. C'est un environnement relativement maîtrisé, statique, et il n'y a pas besoin d'avoir un orchestrateur. Maintenant, imaginez que cette grille fasse 1000 x 1000, ou 10 000 x 10 000, même avec des cubes de couleurs, le problème devient un petit peu plus compliqué. Et donc le but d'un orchestrateur, ça va être exactement ça. Ça va être d'être capable, en temps constant, quelle que soit la taille de la grille, quel que soit le niveau d'occupation de la grille, de trouver le bon emplacement pour le bon container. C'est exactement ça qu'on essaie de résoudre avec Amazon ECS en particulier. Ok ? Voilà. On a deux produits complémentaires. On a ECS, qui est l'orchestrateur de containers en tant que tel, qui a été lancé il y a un peu moins d'un an maintenant, qui est disponible dans les deux régions européennes, dans les autres aussi. J'ai juste donné les informations pour l'Europe, mais si vous avez des questions sur les autres régions, venez me voir à la fin, je regarderai. En tout cas, ECS est disponible dans les deux régions européennes. Son utilisation est gratuite, donc vous ne payez pas pour l'utilisation d'ECS, vous payez pour l'utilisation des ressources qui vont être créées par ECS, donc les instances, etc. Mais le service lui-même ne coûte rien. Il est complété par ECR, qui est un registry Docker managé au sein d'AWS, qui a été lancé en fin d'année, qui est disponible uniquement dans la région ouest pour l'institution. Il n'est pas encore disponible dans la région allemande. Et donc l'idée, ça va être d'héberger vos images Docker dans ce repository, ce qui a plusieurs intérêts. Un, c'est qu'ils vont être plus près de votre infrastructure, donc en termes de latence, en termes d'accès entre ECR et ECS, ça sera plus efficace que si vous allez les chercher sur un registry hébergé ailleurs. Et puis surtout, c'est un service managé, donc on vous garantit la sécurité, on vous garantit la haute disponibilité et vous n'avez pas à le gérer vous-même. C'est bien d'avoir des infrastructures dockerisées, mais quand le registry est en panne, c'est un peu embêtant. C'est comme quand GitHub est en panne, c'est un peu embêtant. Donc là c'est un service qui est facturé au stockage, donc 10 cents par giga par mois et puis un petit peu pour le trafic sortant aussi. Mais au final c'est un service qui est assez économique. Alors en fait, j'ai envie de dire que ça devient une habitude, une heure avant la présentation il y a une annonce AWS et je suis obligé de modifier mes slides. Donc en fait on a annoncé ce matin, tôt, ça tombe bien je me lève tôt, on a annoncé ce matin la disponibilité générale d'Elastic File System qui est disponible dans trois régions AWS dont la région AWS. E-West One. Pour vous, c'est une bonne nouvelle. Et qu'est-ce que c'est que ce service ? C'est tout simplement un serveur NFS managé. Vous êtes maintenant capable de créer des volumes NFS que vous pouvez monter et partager sur vos instances. En utilisant les outils NFS traditionnels, je l'ai fait ce matin, vous créez le volume en deux clics ou en un appel d'API et puis vous faites mount et vous avez un volume NFS. L'avantage de ce service c'est que une fois de plus c'est un service managé donc vous ne gérez rien, vous ne faites que créer les volumes et les montées. On va scaler la capacité automatiquement à la hausse et à la baisse donc il n'y a pas à provisionner des volumes de centaines de gigas si vous ne les utilisez pas. C'est un peu comme sur S3, vous consommez ce que vous avez besoin et vous êtes facturé uniquement sur la base de ce que vous consommez. Voilà et ça coûte 33 cents par giga par mois. C'est un service qui était attendu depuis longtemps par notre communauté technique, on est content de l'annoncer. Et pourquoi j'en parle ce matin ? C'est parce qu'on est content de l'annoncer, un, et deux parce que en particulier pour partager des données entre des instances qui exécutent des containers Docker, pour partager des volumes Docker, c'est la solution qu'on attendait. C'est vraiment la bonne solution pour le faire. Donc voilà, EFS est là. Autour de ces solutions, autour de ces produits, on a aussi un ensemble de partenaires qui nous permet d'étendre l'offre. Alors évidemment, il y a Docker, il y a Mesosphère, il y a Weave, il y en a plein d'autres. Je ne vais pas tous les citer, vous les connaissez pour la plupart, CoreOS, Rancher, tous ces gens-là. Qui vous permettent, qui permettent à nos clients de déployer des images avec des dockers préinstallés, avec des outils type Rancher, qui sont assez séduisants, c'est le moins qu'on puisse dire. Il y en a un autre qui mérite d'être mentionné, c'est Convox, qui est plus récent, qui a bâti une plateforme PaaS, c'est des anciens ingénieurs d'Heroku, qui ont décidé de refaire un Heroku en mieux, donc c'est plutôt intéressant, et qui le font sur la base de Docker au-dessus d'AWS. Si vous êtes intéressé par ces sujets-là, je vous conseille de jeter un œil. Ils ont sorti quelque chose de vraiment super simple à utiliser. Et puis on a tout un tas de partenaires autour de l'intégration continue, du déploiement continu que vous voyez là, CircleCI, Shippable, etc. Datadog pour le monitoring et Twistlock pour la sécurité des containers qui, de mon point de vue, reste un vrai sujet. Pas tellement à cause des bugs de Docker, mais à cause de ce qu'il peut y avoir dans les containers. Je fais juste une parenthèse, mais c'est très bien d'avoir des devs qui font des containers et qui veulent les envoyer en prod directement. Mais moi, si je suis patron de prod, j'ai envie de savoir ce qu'il y a dans les containers avant de les ouvrir à la production. Donc Twistlock en particulier permet de faire un scan de vulnérabilité à l'intérieur des containers, de vérifier qu'il n'y a pas de trou béant, et si c'est le cas, de proposer des remédiations. Je ferme la parenthèse sur la sécurité. Si on regarde rapidement l'architecture de ECS, elle est relativement simple. Elle va se composer d'abord d'un back-end, qui est la partie que vous voyez en bas. Le back-end ECS va être chargé de gérer l'état du cluster, de connaître l'état distribué du cluster, de savoir quelles ressources sont disponibles où, quels conteneurs tournent où et de faire tout ça avec la vision le plus temps réel possible. On sait que gérer des états distribués c'est des problèmes compliqués, surtout à l'échelle. C'est toujours pareil, sur deux nœuds sur trois nœuds tout est facile, sur 500 nœuds sur 1000 nœuds c'est une autre histoire. Donc il va y avoir une couche de communication qui va interagir avec un ensemble d'instances, donc qui sont des instances EC2 classiques, des serveurs, des machines virtuelles classiques, qui vont avoir un environnement Docker préinstallé, qui vont avoir donc un agent préinstallé, et sur lesquels vous allez pouvoir déployer vos containers. Donc quand on va créer un cluster, on va créer un ensemble d'instances, et vous aurez donc cet environnement là qui sera entièrement disponible. Et tout ce qu'il suffira de faire c'est de déployer vos containers dessus. Bien sûr, devant les containers si vous avez envie de mettre des load balancer, si vous avez envie de faire des choses comme ça, on verra ça à la fin de la présentation, c'est tout à fait possible. Pour info, les sources de l'agent sont disponibles, elles sont sur GitHub, c'est de l'open source, c'est du Go si vous voulez aller voir comment ça fonctionne. Si vous avez envie de l'intégrer sur vos propres images, vous pouvez tout à fait faire ça, vous n'êtes pas obligé d'utiliser l'image préconfigurée d'ECS, vous pouvez intégrer ça dans vos AMIs directement. Donc une architecture assez simple, assez compréhensible et surtout le point important c'est qu'elle s'appuie sur EC2 donc toute la robustesse de ces deux, tous les mécanismes de ces deux qui existent depuis dix ans, l'auto scaling, le load balancing, tous ces mécanismes là ils servent de fond à ECS donc c'est pas un service qui sort de nulle part. Alors j'aimerais bien vous donner la main pendant les quelques minutes qui viennent pour quelques exemples d'utilisation parce que sinon on tourne en rond, on répète tous la même chose sur les containers, c'est bien, les orchestrateurs c'est bien. Moi ce qui m'intéresse surtout c'est de voir ce que les gens font avec. Il y a un client qui s'appelle Coursera, je vais éviter de le présenter pour gagner 30 secondes, je pense que tout le monde connaît Coursera, la plus grosse plateforme de MOOC. Et en fait, il y a une présentation, la vidéo YouTube qui est là, c'est un témoignage à ReInvent, à notre conférence, qui est très détaillé, qui est intéressant. Et ils ont publié aussi plein de contenus sur Slides. Donc si vous cherchez Coursera ECS, vous allez trouver ça. Et donc ils ont énormément de jobs de batch à faire tourner sur leur plateforme, qui peuvent servir à des choses traditionnelles du reporting, etc. Mais il y a un cas d'usage que je trouve super intéressant, c'est qu'ils se servent de batch pour noter les exercices de programmation. Si vous avez déjà fait un MOOC dans un langage quelconque sur Coursera, vous connaissez votre code sur Coursera et puis ils passent une batterie de tests unitaires. Dans mon cas, ils me disent que je suis nul, dans votre cas il doit y avoir moins de fautes. Et puis après j'essaie de corriger mes bugs. Ce que ça veut dire c'est que le code que vous upload dans Coursera va s'exécuter dans leur plateforme et on va passer des tests unitaires dessus. Et évidemment, de leur point de vue, c'est un énorme risque sécuritaire. On pourrait dans leur présentation il explique ce serait tout à fait possible d'uploader du code pour miner des bitcoins et qu'ils veulent pas se transformer en ferme de bitcoin. Donc en termes de sécurité, de stabilité, ils sont obligés d'isoler ces jobs. Donc ils ont une assez bonne solution pour le faire, l'isolation que fournit Docker. Maintenant le problème c'est qu'ils sont à l'échelle et qu'ils ont des milliers de jobs à faire tourner en permanence. Comment on fait ça de manière efficace, comment on place ces jobs sur une grille de calcul ? Donc ils ont essayé différentes solutions, je les mentionne pas parce que ça sert à rien, si vous voulez savoir lesquels ils ont essayé, vous irez voir la présentation. Moi je suis là pour parler de AWS et ils ont choisi ECS pour des raisons de facilité d'usage, des raisons de scalabilité. Et ils ont même développé leur propre scheduler au-dessus de ECS, donc ils ont un outil qui a un nom imprononçable, donc je ne le prononcerai pas, qui leur permet de scheduler les jobs pour que les jobs, en particulier de notation, soient privilégiés, soient en temps réel, ou quasi temps réel, par rapport à des jobs internes à la plateforme de reporting, ou autre chose comme ça. Donc voilà, c'est un cas d'usage assez intéressant, puis sur une assez grosse plateforme. La prochaine fois que vous ferez du Coursera, vous penserez un peu à ECS. Deuxième exemple, un petit peu différent, c'est une société qui s'appelle Remind, qui est une plateforme de messaging entre les enseignants, les parents d'élèves et les élèves. Ils ont 35 millions d'utilisateurs aux US, adoptés par la moitié des écoles publiques aux US, grosse plateforme. Ils ont déjà envoyé plus de 2,5 milliards de messages, enfin ils sont sur un rythme de plusieurs dizaines de millions, voire une centaine de millions de messages par mois. Ce qui est intéressant dans ce cas-là, c'est que, comme évidemment c'est lié au monde scolaire, on imagine bien que leur courbe de trafic, c'est pas la courbe de trafic traditionnelle. On imagine bien que pendant les vacances, ils se passent à rien, très peu de choses, et puis qu'en période de rentrée scolaire ou en période de conseil de classe, ça doit s'agiter un petit peu plus. Et donc ils ont des problèmes de scalabilité qui sont assez importants, et une fois de plus des profils de trafic qui sont très très irréguliers. Donc ils avaient développé une plateforme microservices, belle architecture, très intéressante, je vous conseille la vidéo de ReInvent, ils ont utilisé l'Etoile Factor Apps, enfin c'est bien fichu, et donc ils ont d'abord déployé ça sur Heroku. Je pense que tout le monde connaît Heroku aussi. Et donc pourquoi pas, sauf qu'ils constataient sur Heroku, vous voyez sur un de leurs services en particulier, voilà les graphes de latence, donc vous avez la latence moyenne et la latence à 95% et la latence à 99%, et donc ce qu'on voit c'est que la moyenne on va dire ça va à peu près, c'est relativement stable, par contre au 95e et 99e pour percentile il y a des coups de bourre qui sont extraordinaires, qui sont extraordinairement mauvais. Et donc ils essayent de régler ce problème en disant comment est-ce qu'on peut adapter notre infrastructure à la charge de manière plus dynamique en ayant des temps de réponse plus intéressants. Et donc ils ont migré de Heroku vers ECS après aussi avoir considéré d'autres solutions et vous voyez le graphique donc il y a avant après donc Heroku à gauche et ECS à droite sur le même trafic et donc on voit que non seulement la latence moyenne a été divisée par à peu près par deux mais surtout que les latences marginales sont beaucoup beaucoup plus proche de la moyenne et que donc ça veut dire que pour quasiment 100% de leurs internautes de leurs utilisateurs ils ont une qualité de service qui est extrêmement bonne et ça c'est lié à quoi c'est lié à au côté hyper dynamique hyper réactif de ECS qui permet de scheduler des nouveaux containers des nouvelles instances à chaque fois qu'on en a besoin. Un troisième exemple, c'est Halo, qui est un concurrent du beurre en Grande-Bretagne, d'une assez bonne taille. Idem, plateforme de microservices basée dans plusieurs régions. Et un peu la même histoire, besoin de scheduler, besoin de monter en charge. C'est pareil, les trafics de taxis, à 2h du matin, on se doute que c'est assez calme. Et puis à la sortie des bureaux, le samedi soir, c'est de la folie. Donc il faut être capable de réagir et il faut être capable de scheduler et de scaler rapidement. Donc, idem, ils se sont appuyés sur ECS, et eux aussi ont développé un scheduler. Ça montre à chaque fois la scalabilité de ECS, ça montre la capacité même à le customiser quand vous en avez besoin. Le dernier exemple que je vais vous donner, c'est une société qui s'appelle Segment, qui travaille dans le monde de l'analytics. Alors, eux avaient une plateforme traditionnelle monolithique, avec les avantages et les inconvénients. Ils l'ont découpé et dockerisé. Et après avoir fait le tour du marché, ils ont eux aussi choisi ECS, avec une architecture qui ressemble à ce que je vous ai montré tout à l'heure, des load balancers, du DNS, etc., du service discovery entre les microservices. Et donc, finalement, la conclusion, la citation client, c'est presque toujours la même. J'aimerais en trouver des différentes mais à chaque fois on tombe sur la même chose qui est de dire en fait en utilisant ECS on s'est simplifié la vie, on a fait moins de plomberie, on s'est concentré sur l'application pas sur les détails techniques, etc. Je pense c'est vraiment ce qu'on entend tout le temps sur ECS donc il doit y avoir un petit fond de vérité. Si on rentre un tout petit peu dans les détails techniques, voilà un exemple de ce que ça pourrait donner. Imaginez que vous avez une application avec trois services qui exposent un port public dans les trois cas. Donc on pourrait avoir une configuration comme ça avec trois instances, avec des load balancers, etc. Le problème de cette configuration, le problème, vous le connaissez sans doute, d'utiliser des ports fixes sur vos instances, Docker, c'est que port 80, il n'y en a qu'un par nœud. Et que donc si vous voulez trois copies du service 1, nécessairement il faut qu'elles tournent sur trois instances différentes. Si j'avais envie d'en rajouter une quatrième, j'aurais une quatrième exemplaire de service 1, il faudrait que je crée une nouvelle instance ECS et que je déploie mon container dessus. Pour des services qui sont, pour des plateformes qui sont, on va dire, soit assez statiques, soit de petite taille, ça peut se concevoir si vous ne déployez pas et si vous ne scalez pas vos containers toutes les deux minutes. On peut imaginer qu'on ait un déploiement statique comme celui-là et que ça convienne très bien. Il y a plein de gens qui font ça. Le problème, c'est que quand on a une architecture telle que celle que j'ai présentée juste avant, les Coursera, les Segment, les Remind, qui ont eux des grosses montées en charge et des problèmes, pour le coup, des processus, problème de gérer des dizaines de nœuds, voire des centaines, une architecture comme ça ne peut pas convenir. Et donc, on est sur une présentation assez courte aujourd'hui, mais je pourrais répondre aux questions après. On est capable de bâtir ce genre d'architecture. Je vais vous la montrer très très brièvement à la fin, où toujours sur la base de plusieurs instances, donc les gros blocs orange, je vais être capable de bâtir une architecture complètement dynamique où tous les containers vont être lancés sur des ports aléatoires. Donc là c'est une application qui est composée de trois microservices, vous les verrez tout à l'heure, donc trois briques blanches, j'expliquerai après ce qu'elles font. Donc je suis capable de les lancer où je veux sur des ports aléatoires. Le démarrage de ces containers est détecté par un outil qui s'appelle Registrator, je pense qu'il y a des gens qui connaissent ça, qui va donc détecter le démarrage du container Docker et qui va envoyer l'information de démarrage, le numéro du port, etc. à un serveur Consul qui tourne à côté. Et donc c'est le serveur Consul qui va gérer cet état distribué. Sur chaque nœud, on va avoir un agent Consul qui va servir à faire les résolutions DNS, puisque le service discovery entre les microservices va se faire en DNS. Et donc, reste à résoudre un seul problème qui est comment je fais le load balancing en frontal de cette architecture. Je mets un load balancer certes et derrière je vais tourner un composant qui s'appelle Fabio qui est un truc qui doit dater d'à peu près d'un an maintenant, qui est un routeur HTTP, HTTPS, c'est un projet open source qui est zéro configuration, qui est capable d'espionner le trafic Consul pour détecter le démarrage des containers front et de construire sa table de routage, etc. Je vais très très vite, j'ai une présentation plus détaillée que je pourrais vous partager. Et donc on est capable de bâtir une archi comme ça où finalement on n'a plus cette restriction des ports fixes. Il y a d'autres solutions pour le faire, avec Weave on peut faire des choses comme ça aussi. Mais là on l'a fait avec Fabio. On espère qu'un jour on aura des load balancers un petit peu plus intelligents, qui sont capables de faire tourner des services sur des ports aléatoires. Bon, pour l'instant, ce n'est pas le cas. Qui sait ? Ça pourrait venir. Alors, on va peut-être regarder à quoi ça ressemble. Il me reste 3 minutes 45, c'est parfait. Alors... Désolé, si j'avais mon Mac, je serais déjà logué. Tout le monde a activé le multifactor sur son compte AWS ? Non, mais vous devriez. Est-ce que vous arrivez à lire ou est-ce que c'est un peu petit encore ? Ça va ? Ouais ? Si vous ne hurlez pas, c'est que vous arrivez à lire. Donc là, j'ai un cluster que j'ai créé, qui a trois instances. Voilà. C'est peut-être bien comme ça. Qui a trois instances. Et donc, qui sont là. D'accord ? Donc c'est trois instances EC2 avec Docker installé, etc. Ok, donc sur ces instances, j'ai déployé 3 services qui constituent mon application. D'accord ? Un qui est un portail, qui est juste le frontal web. Et ce frontal web, il va appeler 2 services back. Un qui va aller chercher les cours de bourse et un qui va afficher la météo. Ok ? Donc on va regarder à quoi ça ressemble. Et j'ai mis un load balancer devant, évidemment. Et donc il me faut juste le nom du load balancer. Qui est là ? Hop. Voilà. Ok donc là, je rentre, si vous avez mon schéma antérieur en tête, je rentre sur le load balancer qui va aller envoyer vers un des Fabio en round-robin et ce Fabio là, il va aller chercher un des microservices portal n'importe lequel et ce microservice portal, il va faire une résolution DNS locale pour trouver un service stock n'importe lequel et un service weather n'importe lequel et il va afficher cette page. Donc on va regarder un peu les cours de la bourse même si c'est déprimant en ce moment. On va avec ces personnes. Voilà, ça va ? Personne n'est ruiné ? Bon et puis on va regarder la météo. Donc là ça c'est appuie sur des API publics. Donc ce que je fais à chaque fois, l'application elle-même est évidemment toute simple, l'objectif c'est pas ça, l'objectif c'est de comprendre que j'ai une architecture qui est complètement dynamique à ce niveau-là. Alors si je voulais la scaler, je vais retourner dans mon gestionnaire ici. Donc là je vois que j'ai trois copies de chaque. Vous allez me dire que j'ai trois instances donc c'est facile finalement, là je n'ai pas pris de risque. Bon si je voulais plus de services, je pourrais dire tiens là j'en veux 40, et puis là j'en veux... Bon évidemment on peut faire ça en ligne de commande mais j'ai choisi de vous épargner la ligne de commande aujourd'hui. C'est mon jour de bonté. Voilà. Et donc, on voit que, assez vite, il commence, donc on a 9 containers qui tournent, bon, assez vite, il va commencer à en démarrer, voilà, il va commencer à en démarrer plein. D'accord ? Et on va voir, voilà, le running, le nombre de running tasks qui commencent à monter, donc il va chercher de l'espace sur mes instances, et puis il va placer les containers là où il peut les placer. D'accord ? Et il fait ça en temps constant, quelle que soit la charge du cluster. Donc évidemment, il va très très vite arriver un moment où mes instances vont être pleines. Voilà, donc j'ai plus de mémoire, j'ai quasiment plus de CPU. Et donc là, on n'a pas le temps de le voir aujourd'hui, mais qu'est-ce qui se passe ? J'ai des alertes CloudWatch qui vont déclencher de l'autoscaling, qui vont rajouter des instances, etc. Donc on peut automatiser à la hausse ou à la baisse le scaling initial, le scaling du cluster, comme on le ferait avec des fermes de serveurs EC2. Et donc il fait ça tout seul, il se débrouille pour trouver de la place, et puis si une instance meurt, il la relance. Tous les mécanismes type que vous pouvez connaître sur EC2, vous allez aussi les retrouver avec ECS. C'est très bref, je suis désolé, mais c'est une présentation courte, n'hésitez pas à venir me voir après. Et je reviens là. Voilà. OK. Donc voilà, ce qu'on voit là, ce qu'il faut retenir de ça, c'est que j'ai que trois instances, mais j'arrive à démarrer des dizaines, voire des centaines de containers, quels que soient leurs ports. Je n'ai aucun problème de placement en termes de ports réseau. OK. Voilà, si vous voulez en savoir plus sur ECS et ECR, etc. Il y a évidemment pas mal de docs en ligne, mais en particulier il y a trois articles de Werner, du CTO d'Amazon, où il rentre un petit peu plus dans les détails du back-end et où il explique les choix de design, c'est assez intéressant. Et puis comme je l'ai dit, il y a les vidéos des clients à re-invent, et également nos propres vidéos techniques sur ECS à re-invent.