Deploiement continu avec Amazon Web Services

Transcript

Bonjour à tous, très content de vous retrouver pour une nouvelle après-midi de Webinar AWS en compagnie d'Hugo Omanet. Merci beaucoup Hugo pour l'organisation. Aujourd'hui nous allons parler du sujet DevOps avec une première session sur les outils de déploiement continu et une deuxième session sur les outils d'infrastructure ASCODE avec CloudFormation et compagnie. Alors avant, pour commencer cet après-midi, on voudrait d'abord vous faire un tout petit sondage très rapide. Donc Hugo va vous afficher la fenêtre pour savoir quel est votre niveau de familiarité avec le DevOps. Voilà, je vous laisse quelques secondes pour répondre. L'objectif pour nous, c'est de savoir à quelle vitesse on doit aller sur la partie introduction et combien de temps il faut passer sur quelques concepts avant de plonger dans la partie technique à proprement parler. On va vous laisser encore 30 secondes et Hugo me donnera le résultat. Ok, d'accord. Donc la plupart, à peu près une moitié d'entre vous, ont entendu parler mais ne pratiquent pas. Un quart fait de l'intégration continue et pas plus. Et voilà, on va dire moins de 20% font du déploiement continu et de l'infra. Ok, donc on a quand même une bonne familiarité. Et pour les quelques personnes qui n'en ont pas entendu parler du tout et pour qui c'est un mystère complet, pas de souci, on va rappeler rapidement les concepts importants. N'hésitez pas à tweeter à propos de ce webinar pendant ou après, ça nous fait toujours plaisir de lire les commentaires et de voir de l'activité sur Twitter au sujet de ces webinars. Vous pouvez utiliser mon compte, le compte officiel AWS, et puis des hashtags comme AWS et Twitter. Voilà, n'hésitez pas, c'est sympa, on apprécie ça. L'agenda de cette première session. Donc quelques définitions rapides sur l'intégration continue, le déploiement continu, etc. Ensuite, on va parler rapidement de l'histoire du DevOps chez Amazon.com. Vous verrez que c'est assez intéressant. Ils ont rencontré des problèmes que vous rencontrez sans doute encore et surtout les outils dont nous parlerons ensuite sont nés de cette histoire. Ensuite nous parlerons des services que j'appelle les services code étoiles, code commit, code pipeline, code build, code deploy, etc., qui sont donc les outils destinés aux développeurs. Ensuite on fera deux démonstrations. Une première démonstration sur un déploiement d'une librairie en C. Vous ne pensiez pas avoir du C dans un webinar AWS, j'ai gagné mon pari, j'ai réussi à en mettre. Et une deuxième démo avec une application web, un top 4, une application que vous pourrez tester et qui sera également déployée avec un pipeline. Et puis bien sûr, à la fin, on répondra à vos questions comme d'habitude. Et je vous rappelle que les deux mails de chaque webinaire gagnent un cadeau. N'est-ce pas Hugo ? Merci. Très bien. Alors quelques définitions pour rappeler de quoi on parle et être bien précis. Donc il y a différents concepts qui sont évidemment liés mais différents. Le premier concept que vous pratiquez pour la moitié d'entre vous déjà, si j'en crois le sondage, c'est l'intégration continue. L'intégration continue, c'est un processus technique qui va permettre de compiler, de déployer et de tester sur un environnement de test chaque changement de code. Soit chaque changement réellement, chaque commit, c'est l'idéal de pouvoir à chaque commit construire l'application et lui faire passer tous les tests unitaires. On peut aussi imaginer qu'on le fait une fois par heure, toutes les deux heures, etc. Mais ce fait de dire au fil du process de développement, au fil de la journée, plusieurs fois par jour et peut-être même à chaque commit, on va construire l'application et lui faire passer tous les tests, c'est ce qu'on appelle l'intégration continue. Mais ça reste dans un environnement de développement. On ne fait que qualifier une version de dev. Ce qu'on appelle le continuous delivery, on va déjà un cran plus loin, c'est la livraison en cycle court de votre application. On peut imaginer qu'un cycle court est toutes les quatre heures, 24 heures, deux fois par semaine, mais en tout cas c'est certainement pas tous les trois mois et encore moins une fois par an. C'est le fait de dire qu'on amène en production son application régulièrement et qu'on sait le faire de manière fiable. Parce que, évidemment, s'il s'agit de la déployer pour qu'elle ne marche pas, tout le monde peut y arriver. L'aboutissement du Continuous Delivery, de la livraison continue, c'est ce qu'on appelle le Continuous Deployment, où chaque changement, chaque commit, chaque modification de code va être automatiquement et systématiquement aboutir à un déploiement en production, en ayant évidemment passé l'étape d'intégration continue. Donc c'est ce qu'on va voir aujourd'hui. On va faire du Continuous Deployment où à chaque fois qu'on va faire un changement dans une application, sur un repository, à chaque commit, on va dérouler via un pipeline une intégration continue et un déploiement en continu. Et qu'est-ce que c'est que le DevOps du coup ? L'intégration continue, le livraison continue et le déploiement continue, ce sont vraiment des pratiques techniques qui s'appuient sur des outils et des process techniques. Le DevOps, c'est une approche plus large qui concerne des aspects techniques, mais aussi des aspects humains et des aspects d'organisation où on va organiser l'entreprise, on va organiser le process de développement autour de la collaboration et de la communication de toutes les parties prenantes, les développeurs, les gens des Ops, éventuellement les gens de la sécurité, etc. Donc on va vraiment faire travailler tout le monde en même temps et en ayant une obsession de l'automatisation, en utilisant l'intégration continue et le déploiement continue. Donc trois pratiques techniques et puis une approche, le DevOps, une approche technique et organisationnelle pour arriver à un processus de développement complètement automatique. Comment est-ce qu'Amazon en est venu à faire du DevOps ? Il était une fois Amazon au tout début des années 2000 et Amazon avait déjà connu une croissance très robuste, était déjà pour ceux qui s'en souviennent un très gros site e-commerce et avait donc développé son site de manière rapide et se trouver confronté à des problèmes d'application monolithique. Alors il ne faut pas caricaturer, il ne faut pas penser que toute l'application Amazon.com était un seul livrable monolithique. Néanmoins elle était quand même assez monolithique et elle souffrait de dépendances extrêmement fortes entre ces différentes briques et par conséquent il était difficile de déployer réellement des petits bouts de l'application. Vous imaginez qu'à l'échelle d'Amazon c'est un gros problème. C'est un problème assez classique qu'on a tous rencontré et qu'on rencontre encore de dire bon j'ai une application et à chaque fois que je change une ligne je suis obligé de tout déployer et je ne maîtrise pas forcément les effets de bord et je ne maîtrise pas forcément la qualité de ce qui est produit. Et du point de vue organisation, ça ressemble souvent à ça, c'est-à-dire des équipes de développement qui travaillent probablement en parallèle, qui font l'intégration sur une seule appli, qui essaient de résoudre au mieux les conflits, les dépendances, les effets de bord, et puis qui vont pousser ce monolithe dans un pipeline où l'application va être construite, testée, réalisée, en espérant qu'elle arrive au bout dans un état correct. Mais on sait que malheureusement c'est compliqué à faire. Et souvent le processus de release, dans ces cas-là, il ressemble à ça. Une situation que j'ai souvent vécue où on fait de son mieux, on essaie de livrer ce monolithe en production, mais on ne peut pas dire qu'on maîtrise vraiment ce qui se passe. On ne peut pas dire que si l'application marche c'est parce qu'on a vraiment fait de bons tests, c'est peut-être juste un coup de bol. Et à contrario il y a peut-être des effets de bord qu'on n'a pas vus et qui vont venir nous exploser à la figure deux jours après, une semaine après. Donc l'objectif c'est évidemment pas de faire ça, l'objectif c'est de changer complètement l'approche, c'est ce qu'a fait Amazon, un grand saut dans l'hyperespace. Et donc l'architecture a été complètement refondue et le graphe que vous voyez là c'est un graphe réel qui date maintenant et qui représente les centaines pour pas dire les milliers de services qui constituent le site d'Amazon. Donc cette architecture, une architecture orientée autour de services qui ont chacun un seul objectif, donc des petits services qui remplissent une seule fonctionnalité, qui communiquent par API, qui sont totalement isolés les uns des autres et aujourd'hui c'est ce qu'on connaît tous sous le terme de microservices. Mais je l'ai dit tout à l'heure, le DevOps ce n'est pas seulement une approche technique, c'est aussi une approche d'organisation et en parallèle de ce changement d'architecture, Amazon a réorganisé aussi ses équipes de développement et a construit ce que vous avez peut-être entendu sous le terme de pizza teams. Donc les pizza teams c'est des équipes qui sont suffisamment grosses ou suffisamment petites en l'occurrence pour que deux pizzas suffisent à les nourrir. Alors bon, il s'agit de pizzas américaines pour ceux qui ont déjà pratiqué ça. Donc il y en a parmi vous qui seraient capables de manger deux pizzas c'est certain, mais deux pizzas américaines c'est moins sûr. Donc voilà, on va dire, en plaisanterie à part, on parle d'équipes de 6, 8, au maximum 10 personnes. On est petites équipes, agiles, capables de concevoir, de livrer et d'opérer le service. Donc pas de distinction entre les gens qui développent et les gens qui opèrent. Vous le développez, vous l'opérez. Ça permet d'être totalement responsable de la qualité du développement. Ça permet d'aligner les gens sur un même objectif qui est il faut que le service soit livré et il faut qu'il marche. Voilà et c'est ce qu'on appelle tous maintenant du DevOps, donc des équipes pluridisciplinaires qui vont aller vraiment de la conception jusqu'à la livraison et au support du service. Il y a vraiment ces deux aspects à chaque fois dans la discussion, il y a l'aspect architecture et il y a l'aspect organisation de l'équipe pour faire en sorte que la modularité de l'architecture se traduise aussi par une modularité des équipes. Une fois qu'on a fait ça, on arrive à des équipes pluridisciplinaires qui travaillent en parallèle, qui travaillent chacune sur un bout de l'architecture, sur un petit bout de service, pour le coup formellement indépendant du reste, puisqu'il y a des API, il y a un coût contrat entre ce service et le reste de la plateforme et tant qu'on ne touche pas au contrat, on peut livrer ce service indépendamment des autres. Néanmoins, ça ne répond pas encore à la question de comment est-ce qu'on livre ces services, comment est-ce qu'on fait en sorte que ces équipes de développement puissent réellement pousser la nouvelle version de chaque service en production indépendamment les unes des autres et que la qualité soit rendue. Donc Amazon a travaillé sur de nouveaux services avec quelques prérequis importants. Alors bien sûr le self-service, il faut que chaque équipe soit totalement indépendante, il faut qu'elle puisse travailler en n'ayant pas besoin de qui que ce soit d'autre, qu'elle puisse livrer son service quand elle en a besoin. Il faut que le service ne soit pas lié à une technologie en particulier. Les équipes de développement Amazon peuvent travailler avec différents langages et techno et il faut que les outils s'adaptent à chaque fois. Il faut que les outils encouragent les bonnes pratiques. C'est bien de prêcher les bonnes pratiques mais c'est encore mieux quand les outils vous les imposent. Donc la capacité à appliquer des tests, la capacité à faire un rollback s'il y a un problème, etc. Donc vraiment à coder des outils qui vont ne pas dévier des bonnes pratiques. Et puis surtout des outils qui sont un petit peu comme dans la logique microservices, des outils qui sont simples, qui font une seule chose, qui font soit du déploiement, soit du pipeline, mais pas d'usine à gaz, pas d'outil multifonction qui sait tout faire, mais mal. Et cette réflexion a mené au développement de différents outils, dont le premier est Apollo, Apollo c'est le déployeur d'usine utilisé par les équipes de développement Amazon. C'est un déployeur qui marche sans aucun downtime, qui va être capable de déployer en continu des changements sur une infra en production sans créer de problème. C'est un service qui va surveiller la qualité du déploiement en vérifiant que les instances sur lesquelles on déploie continuent à fonctionner. On va gérer les versions et bien sûr on va être capable de gérer les rollbacks pour revenir à un état stable si jamais on a un problème. Le deuxième outil qui a été déployé, c'est un outil qui s'appelle les Pipelines et comme son nom l'indique, c'est un outil de déploiement, de livraison en continu qui va permettre aux équipes de développement de construire des process de développement complètement automatisés qui du commit jusqu'au déploiement en processus vont passer les étapes de validation du pipeline, une par une, toujours dans le même ordre, sans intervention humaine, sans risque d'erreur humaine et de manière complètement automatisée, plus vite que ce qu'une équipe humaine pourrait faire. Cet outil aujourd'hui est utilisé par plus de 90% des équipes de développement Amazon, on a vraiment réussi à le généraliser et à faire utilisées par tout le monde, ce qui est l'objectif puisque si la moitié de vos équipes n'utilisent pas d'outils de déploiement continu, vous avez beau avoir une architecture en microservices, vous allez avoir des problèmes d'intégration et des problèmes de livraison. Et donc une fois ce problème d'outillage réglé, maintenant on arrive vraiment à une organisation de développement avec de la conception jusqu'à la livraison, la capacité à livrer complètement en parallèle, complètement indépendamment des autres services, en ayant des tests à chaque étape et donc une agilité de développement et une qualité de développement très supérieure à ce qu'on avait auparavant. Ce qui donne quoi chez Amazon ? Avec des milliers d'équipes et une architecture en microservices et donc de la livraison continue et bien sûr différents environnements de dev et de tests et de prod etc. On arrive à un chiffre de 50 millions de déploiements par an ce qui fait à peu près un déploiement et demi par seconde ce qui veut dire que voilà entre maintenant et le moment où je vais finir cette phrase il aura eu à peu près 5 à 6 déploiements sur le site e-commerce Amazon. C'est un chiffre qui est relativement récent, je suis sûr que maintenant on l'a encore dépassé, mais vous voyez à quelle échelle on est capable de scaler les processus de déploiement lorsqu'on a la bonne organisation et surtout les bons outils. Alors ce chiffre là, il est assez ahurissant, on a l'impression que le site Amazon ne change pas tant que ça finalement depuis des années et en fait toutes les secondes quasiment vous avez une modification qui a été faite sur une page quelque part ou sur un backend quelque part. À chaque seconde il y a une modification sur les sites retail. Donc c'est dément et c'est impressionnant. Maintenant la question c'est comment on peut amener ce niveau d'agilité et ce niveau de qualité à tout le monde ? Tout le monde n'est pas Amazon, tout le monde n'a pas le nombre de développeurs qui est Amazon. Et donc l'idée vraiment d'AWS, ça a été de se dire on voudrait faire profiter tous nos clients, de la plus petite organisation à la plus grosse organisation, on veut les faire profiter de ces outils et de l'agilité et de la robustesse qu'ils proposent. Donc on est reparti d'une certaine manière de l'expérience d'Amazon et on a développé un certain nombre de produits dont je vais parler aujourd'hui qui s'appelle CodePipeline pour construire des pipelines, composé de différentes étapes. Donc une étape source où on va aller chercher des sources, les sources de l'application tout simplement. Et là on a développé un service qui s'appelle CodeCommit, qui va permettre d'héberger vos sources. Un deuxième service qui va construire l'application, la Builder, qui s'appelle CodeBuild, qui est relativement récent, qui a été annoncé à reInvent en décembre. Et puis CodeDeploy qui va faire le déploiement sur vos instances. Bien sûr, ça serait présomptueux de penser que seuls ces services seront utilisés. On sait très bien que vous avez déjà des outils d'intégration continue, de déploiement continu. Pas forcément complètement intégrés à 100%, mais vous avez déjà évidemment GitHub, vous avez déjà Jenkins, vous avez déjà CircleCI, etc. Et tous ces outils qui sont présents à l'écran sont intégrables dans les pipelines de déploiement, de code pipeline. On verra tout à l'heure dans ma démo que je vais chercher mes sources dans GitHub, que je les build avec Jenkins et que je fais le déploiement avec CodeDeploy. Donc, vous pouvez faire, si vous partez de zéro, vous pouvez, pourquoi pas, utiliser la suite complète d'outils AWS. Et si vous avez déjà des serveurs d'intégration continue et de déploiement continu, vous pourrez les intégrer dans les pipelines. C'est important de vous laisser, évidemment, cette liberté et de ne pas vous obliger à tout reconstruire. Alors quelques mots sur les services avant de passer à la démo. CodeCommit, c'est tout simplement un environnement Git managé. Donc avec CodeCommit, vous pouvez créer des repositories Git à l'intérieur de votre infra AWS. Les données et les objets vont être stockés dans S3. Ils vont être chiffrés avec KMS. Et bien sûr vous profitez de la scalabilité, de la haute dispo et de la durabilité d'S3. L'avantage de CodeCommit c'est que vos repositories vont être au plus proche de l'infra, vous avez de la haute disponibilité ce qui n'est pas forcément le cas d'autres repositories qu'ils soient en SaaS ou qu'ils soient hébergés sur votre infra et c'est quand même important d'avoir de la haute dispo sur ses sources si on veut déployer à partir de là. CodeCommit va vous amener ça, le côté fiable, hautement disponible et très sécurisé au sein de votre infra et donc vous pourrez faire vos déploiements directement à partir de CodeCommit. Le deuxième service est CodeBuild, donc je l'ai dit il a été lancé à reInvent. Pour l'instant, il ne propose que des environnements de build Linux. Il est fort probable qu'on supporte des environnements Windows dans un futur proche. Ce sont des environnements qui sont complètement managés. On le verra tout à l'heure. Vous n'avez pas à créer votre propre infrastructure. Vous n'avez pas à démarrer l'instance EC2 pour faire le build. Vous créez un environnement de build et puis le service lui-même va provisionner tout ce qui est nécessaire. Vous pouvez récupérer vos sources dans GitHub, dans S3, directement, affiché zip ou dans CodeCommit. Vous pouvez builder avec une image qu'on vous fournit dans différents environnements, Java, etc. On va voir la liste. Ou si cette image ne vous convient pas et que vous avez un process de build particulier, vous pouvez fournir un container Docker que CodeBuild va utiliser pour construire votre application. Comment est-ce qu'on fournit les commandes de build ? Soit vous les donnez en ligne, c'est-à-dire que vous pouvez créer un environnement de build dans la console directement et rentrer vos commandes, soit vous les donnez dans un fichier de configuration que vous allez comiter dans vos sources et qui va être lu par CodeBuild pour effectuer le build. C'est cette solution là qu'on utilisera tout à l'heure. C'est un service donc un service manager où le prix se fait à la minute de build. On commence à 1,5 cent par minute, il y a différentes tailles d'environnement mais vous voyez bon c'est évidemment plus économique que de maintenir plusieurs instances EC2 pour gérer vos propres environnements de build. CodeDeploy comme son nom l'indique c'est le déployeur donc il va prendre des applications versionnées, on verra comment on les intègre dans le pipeline tout à l'heure, des artefacts versionnés et puis il va les déployer sur ce qu'on appelle des groupes de déploiement qui vont être un ensemble d'instances EC2 qui peuvent être sous Linux ou sous Windows et on peut également faire du déploiement sur des serveurs externes sous réserve d'y avoir installé l'agent. Vous pourriez utiliser CodeDeploy pour faire du déploiement sur vos serveurs on-premise. CodeDeploy supporte également les groupes d'autoscaling. Vous pouvez soit déployer sur des instances EC2 créées on-demand de manière traditionnelle, soit sur un groupe d'autoscaling. Ce qui est intéressant, puisque vous ne connaissez pas forcément à l'instant T la taille du groupe d'autoscaling, mais voilà, CodeDeploy va se débrouiller, il va trouver toutes les instances qui font partie du groupe et les déployer. Qu'il y en ait deux ou qu'il y en ait 50, il les trouvera toutes et il les déploiera toutes. Depuis peu, on est capable de faire des déploiements Green-Blue, qui est une technique de déploiement assez populaire, qui consiste en gros, au lieu de faire une Rolling Upgrade, au lieu de faire un déploiement instance par instance, on va dupliquer le groupe de déploiement. On va créer un deuxième groupe de déploiement qui fera la même taille. On va déployer sur ces nouvelles instances la nouvelle version. On va vérifier que tout marche correctement. Et si tout marche, on basculera finalement la production vers ce nouveau groupe. Et puis on détruira l'ancien groupe. Donc ça maintenant, c'est intéressant dans CodeDeploy et c'est plutôt une bonne nouvelle. Et puis l'autre bonne nouvelle c'est que ce service ne coûte rien, en tout cas lorsque vous déployez sur EC2, il ne coûte rien, vous pouvez l'utiliser sans avoir quoi que ce soit sur votre facture. Et puis le dernier service dont je vais parler avant la démo c'est CodePipeline, comme son nom l'indique il va vous permettre de relier toutes les étapes qu'on a vues auparavant, vous allez créer un pipeline avec différentes étapes, une étape source qui va récupérer les sources et qui va les copier dans S3, dans un bucket que CodePipeline va créer automatiquement, une étape de build qui va compiler l'application ou la packager et puis dérouler les tests et remettre cet artefact de build dans S3 et puis CodeDeploy ou votre déployant va ensuite déployer sur un environnement de bêta, un environnement de test sur lequel vous ferez d'autres tests. On peut ajouter une étape d'approbation, je le ferai dans la deuxième démo, une étape d'approbation manuelle, ce qui peut être indispensable dans certains environnements. Et puis ensuite, on pourrait après cette étape d'approbation manuelle, faire un déploiement en prod sur un groupe de déploiement qui compose votre production. Voilà donc différentes étapes, source, build, test, deploy, invoke, on peut appeler des fonctions lambda également pendant le pipeline, et puis approuv. Donc vous pouvez utiliser soit les outils code étoiles, soit vos fameux outils externes, vos Jenkins, GitHub, etc. L'avantage du pipeline c'est que vous allez avoir un process de déploiement qui est rapide, il est entièrement automatisé, il n'y a pas d'intervention humaine, bon, hors éventuellement approbation manuelle, mais a priori pas d'intervention humaine. Il va être cohérent, vous ferez la même chose à chaque fois, et puis il va être traçable, vous avez des logs et vous savez ce qui s'est passé. Donc vous avez un process qui est complètement répétable, release après release, et qui garantit que toutes les étapes ont bien été respectées dans le bon ordre. Et évidemment, si une étape échoue, le pipeline s'arrête. Voilà. Ça sert de point central pour déposer les sources et pour déposer les artefacts. Combien ça coûte ? Pas très cher de mon point de vue, ça coûte 1$ par pipeline actif par mois. Comparer ça, idem, avec des solutions où vous avez une instance EC2 qui fait tourner un scheduler ou un outil qui va piloter vos pipelines, qui va orchestrer, c'est évidemment assez économique. Très bien, on va passer à la première démo. Donc la première démo, c'est un pipeline tout simple qui est 100% basé sur les solutions AWS. Donc j'ai un repository qui contient des sources en C, je vais vous montrer, qui contient également le fichier de configuration pour code build, un fichier YAML qui s'appelle build spec, où on va donner tout simplement les commandes de build, un fichier de config pour code deploy, qui s'appelle app spec, qui explique comment on va faire le déploiement. Si vous voulez voir tout ça, les sources sont dans mon repo CodeCommit mais elles sont aussi sur GitHub. Donc vous pouvez aller voir tout ça. Donc ça c'est l'étape de source. L'étape de build, c'est CodeBuild qui va récupérer les sources, se baser sur les commandes qui sont dans la build specification et construire la librairie. Puis dérouler les tests unitaires qui sont faits avec CUnit, qui est une librairie de tests unitaires en C classique. Puis si le build est réussi, on va faire le déploiement avec CodeDeploy. Pour rester simple, je vais déployer sur une seule instance et je vais déployer mes binaires dans USR local libre. On va quitter les slides. On va passer là. J'espère que la police est suffisamment lisible. Si ce n'est pas le cas, n'hésitez pas à le dire. À Hugo et je j'augmenterai la taille. Je commence et puis si c'est trop petit vous me direz ok très bien donc ça va ok merci pour les infos ça a l'air d'aller. Oui pardon peut-être juste avant ça je vous montrer le repo. On va regarder rapidement, on va faire comme ça, ça sera plus facile. Code commit, code deploy, code build, on regardera S3 rapidement et il m'en manque évidemment. Et on est bien dans la région Irlande. Donc là j'ai mon repo dans le code commit. J'ai mes sources, en C, et puis j'ai mes deux fichiers de configuration qui sont les deux points importants ici. Donc j'ai mon buildSpec.yaml qui est assez simple. Là je pars sur un environnement de build qui est un environnement Linux de base ou Ubuntu, j'ai pas besoin de plus. J'installe ma librairie de tests unitaires et puis j'ai mon étape de build. Mon étape de build, tout simplement, elle va utiliser un makefile qui est contenu dans les sources, elle va construire la librairie stable et la librairie dynamique, puis elle va compiler les tests unitaires. Ensuite j'ai une étape post build qui va exécuter les tests, tout simplement, et c'est tout. On a d'autres étapes, on peut avoir des étapes de validation, etc. Mais là, en l'occurrence, ça me suffit. Donc vous voyez, tout ce que j'ai à fournir, c'est ce fichier de configuration, et puis de lui dire les artefacts, donc les résultats, le résultat de ce build, c'est les deux librairies, ce qui doit être packagé et livré dans S3 pour CodeDeploy ensuite. Il y a mes deux librairies, le fichier de configuration de CodeDeploy qui va servir à faire le déploiement et puis j'ai un petit script qui est appelé par le deployeur. On part des sources, on build et on livre les librairies et le fichier de déploiement et le script qui va servir à faire le déploiement. Donc le code build, je pourrais l'appeler, je l'ai configuré là, je pourrais l'appeler à la main. Vous voyez, il y a une série de builds qui ont déjà réussi. Qu'est-ce qu'on voit ? On voit que je build sur un Ubuntu, j'ai pris un petit environnement pas puissant mais j'ai pas besoin de plus. On peut aussi faire du code build à la main, on n'est pas obligé de passer directement dans le pipeline. Alors ce pipeline à quoi il ressemble ? Donc j'ai donc ça c'est le code pipeline ce que vous voyez là. J'ai donc mon étape source qui va donc dans mon repository CodeCommit et qui va extraire la branche master du repo DataStructures et qui va stocker dans un bucket S3 un artefact qui contient les sources qui s'appelle MyApp. Alors vous pouvez le voir le bucket il va s'appeler code pipeline quelque chose il est là voilà ok donc si je regarde là dedans en fait alors ça saute pas aux yeux en fait chacun de ces fichiers là c'est un zip qui contient mes sources ok donc là c'est tout simplement le résultat du git pull qui a été fait par CodePipeline et qui est donc stocké dans S3. Ça finalement c'est toutes les versions sources successives qui correspondent à tous mes builds successifs. Donc l'étape de build, voilà ce qu'elle fait. Elle récupère les sources dans CodeCommit, elle les zippe et elle les copie dans S3. Et ça c'est un artefact qui s'appelle MyApp. Ensuite, j'ai une étape de build qui est faite par code build. On voit qu'il va prendre comme artefact d'entrée MyApp et il va produire un artefact de sortie qui s'appelle MyAppBuild et qui va être donc le binaire qu'il a produit. Un zip qui contient les binaires. Tout à l'heure, on a vu à l'instant MyApp qui contient les sources zippées et de manière symétrique, myAppBuild, ici donc ça c'est un fichier zip qui va contenir les artefacts que j'ai demandé à CodeBuild de produire, donc les deux librairies et puis les fichiers de configuration pour le déploiement. Ok ? Très bien, et puis une fois que le build est terminé, j'ai une étape de deploy qui prend comme artefact d'entrée MyAppBuild, ce que je viens de vous montrer, et qui va le déployer sur un groupe de déploiement que j'ai appelé DataStructure EC2, qui est configuré dans CodeDeploy. Et donc c'est ça qui va faire la livraison de ma librairie. Donc si je vais dans CodeDeploy, j'ai créé une application qui s'appelle DataStructure, et un groupe de déploiement qui s'appelle Data Structure EC2. Alors c'est une notion qui a l'air compliquée le groupe de déploiement, mais en fait, si vous regardez cette ligne ici, c'est à peu près tout ce qu'il faut savoir. Qu'est-ce que c'est qu'un groupe de déploiement ? C'est un ensemble d'instances EC2 qui ont un tag déclaré. Voilà, donc tout simplement pour qu'une instance EC2 soit dans ce groupe de déploiement, il faut qu'il y ait un tag qui s'appelle « Deployment Group », qui est la valeur « Data Structure ». C'est tout. Ce n'est vraiment pas une configuration compliquée et ça permet facilement d'ajouter ou d'enlever des instances dans un groupe de déploiement. Une fois de plus, pour qu'une instance soit dans un groupe de déploiement, il suffit qu'elle ait été taguée conformément à ce que vous avez déclaré à la création du groupe de déploiement. Et puis là je vais voir un peu d'historique, je vois les différentes révisions qui ont été déployées, on a accès à des logs, on a accès à pas mal de choses. Donc vous voyez ce n'est pas des concepts très compliqués et le truc qui est sympa c'est qu'en fait ce pipeline on peut l'éditer complètement comme ça graphiquement. C'est à dire que si j'avais envie de rajouter un stade de déploiement ici, je le ferai, je ferai un deploy, si j'avais envie de faire un deploy prod, je ferai comme ça, je choisirai ici une action de déploiement, je dirai tiens je vais faire un déploiement avec, pourquoi pas, tiens, CloudFormation, etc. Donc vous pouvez, bien sûr vous pouvez créer les pipelines en API et ou en SDK, comme d'habitude. Mais pour commencer, pour expérimenter, le plus simple, c'est sûrement de le faire comme ça. C'est sûrement de les créer à la main, de les enchaîner comme ça. Donc voilà les notions sur le pipeline. CodeCommit pour les sources, CodeBuild pour le build, CodeDeploy pour le déploiement sur une instance EC2 que j'ai déjà créée, et CodePipeline pour orchestrer le tout. On va vérifier, oui, mon instance EC2 est là. Voilà donc ça, là j'ai une instance avec mes sources, on va faire une petite modification. Et la voici, voilà, là je suis sur l'instance de destination donc qui doit recevoir le mail. On va éditer un fichier, on va prendre un fichier WhatsApp, voilà, on va ajouter un commentaire, on ne va pas se lancer dans des codes complexes pendant le webinaire. Ok, donc je fais un changement dans un fichier, je mets le commit. Ok. Voilà. Donc ce repo, je peux le pusher sur GitHub, c'est la version que vous pouvez voir, et je peux aussi le pusher sur CodeCommit. Mon pipeline est configuré sur CodeCommit, donc c'est là que je vais le faire. Voilà, donc là j'ai poussé mon changement. Je dois le voir si je vais dans mon repo. Voilà, je vois que j'ai ajouté un commentaire stupide. Je dois pouvoir voir. Voilà, ok, donc tout va bien. Vous voyez, c'est du git après, vous utilisez vos outils standards. Moi, je trouve que CodeCommit est sympa, ça permet d'avoir des dépôts privés, protégés, hautement disponibles, tout en faisant du git comme d'habitude. Et donc normalement, ceci doit provoquer le réveil de mon pipeline qui va attendre peut-être quelques secondes avant de le faire. Il y a un hook sur le dépôt qui est configuré automatiquement. Et voilà, donc on voit ici, vous le voyez, il progresse. On va peut-être zoomer un petit peu. Ce qui se passe tout simplement, c'est que CodePipeline a été notifié du changement de mon commit dans CodeCommit et donc il exécute automatiquement l'étape source. Il est en train de faire un Git Pull, il est en train d'extraire les sources. Il vient de faire le pull, il a zippé les sources et CodePipeline va dire ok, c'est bon. Et donc automatiquement, il enclenche sur l'étape de build. On va essayer de la suivre. On va faire ce machin-là. Donc là, j'ai un build en cours. Bien sûr, vous pouvez aller chercher les artefacts dans le bucket S3, puis vous avez les logs, on va essayer de les afficher, on va voir ce qui se passe. C'est évidemment indispensable pour pouvoir déboguer son build. Il faut attendre un tout petit peu que les logs arrivent, ils arrivent dans CloudWatch Logs, il faut attendre un tout petit peu. Voilà, et donc là je vois les étapes de mon build. Je vois qu'il est en train de faire le `apt-get update`, etc. Il a installé ses unités et il est en train de compiler. Là, je vois les commandes de mon Makefile. On les voit ici, donc là il a compilé la partie de la base. Là, il fait la librairie dynamique, etc. Donc ça, c'est vraiment génial parce que si le build échoue et ne donne pas plus de détails, c'est agaçant pour ne pas dire plus. Le build ne devrait pas tarder à être fini. Voilà, terminé. Il a duré 1 minute et 16 secondes. Il doit être en train de copier les artefacts dans S3. Il va passer la main à CodeDeploy. On va recharger la page parce que parfois le JavaScript n'est pas hyper réactif. Donc là, il a fini le build, donc maintenant il va passer la main à CodeDeploy qui va faire le déploiement. On va aller regarder ce qui se passe de ce côté-là. On va recharger la page. Voilà, là je vois que j'ai un déploiement en cours. Et donc ce déploiement, c'est tout simplement copier mes deux librairies dans `/usr/local/lib`. Pas de déploiement très compliqué. Voilà, mon déploiement est en cours. Et si je vais voir sur l'instance, qui est celle-là, est-ce qu'on les voit arriver ? Oui, ça doit être ça. Il y a un décalage d'une heure parce que mon instance doit être en UTC. Et voilà, donc là j'ai bien mes deux librairies qui ont été compilées et qui sont livrées au bon endroit. Voilà, tout ça en ayant fait juste un commit. Et le pipeline doit être terminé. Voilà, il traîne encore un petit peu. Voilà, succédé en temps réel. Donc voilà un exemple de pipeline tout simple, complètement basé sur les outils AWS et que vous pouvez reproduire en 5 minutes chrono. Aucun problème. On va regarder un deuxième exemple, un petit peu plus compliqué. On va aller vite. C'est une démo qui est basée sur un post de blog que j'ai enrichi, que j'ai complété. Il y a un template de CloudFormation là-dedans que vous pourrez utiliser pour reproduire cette démo. L'idée, c'est la suivante. Là, j'ai un dépôt qui est dans GitHub qui contient une petite app Tomcat, je vais la builder avec Jenkins, je vais la déployer sur un environnement de dev qui est composé d'une seule instance. Je vais avoir une phase d'approbation manuelle parce que j'ai envie de regarder ce qui se passe, j'ai envie de faire des tests peut-être complémentaires, et puis ensuite je vais déployer en prod sur un groupe de quatre instances. Ça ressemble à ça. Donc j'ai une première instance de dev qui s'appelle `dev.julien.org` qui doit être tournée, vous pouvez essayer de vous connecter dessus. Et puis j'ai un groupe de déploiement qui contient quatre instances qui me servent à faire la prod avec un load balancer devant. Et j'ai une instance EC2 qui fait tourner Jenkins. Donc on prend les sources dans GitHub, on les passe à Jenkins, ils les build, ils les passent à CodeDeploy qui fait un premier déploiement sur cette instance de dev. Ensuite, une approbation manuelle où je vais recevoir un mail. Et puis ensuite, si j'approuve le déploiement, on fera le déploiement de la prod. Ok ? Vous avez le schéma en tête. Donc on va... Donc là, on doit déjà avoir... On doit avoir les environnements qui tournent. C'est une belle application de costumes pour chiens, c'est magnifique. Voilà, ça c'est donc le dev, on voit qu'il n'y a qu'une instance qui est là. Et puis j'ai `prod.julien.org`, vous pouvez vous connecter, c'est ouvert depuis Internet, où j'ai 4 instances. Ok ? Donc ce que je vais faire maintenant, je vais faire un petit changement. Il faut que j'aille sur la bonne instance. Là aussi, on va faire un changement mineur. On va chercher le titre. Voilà, ça c'est le titre de la page, ok, et puis là on va ajouter un petit message. Voilà, et j'ai un clavier bizarre donc on va pas faire comme ça, désolé, on va ajouter un petit message comme ça. Ok. Voilà. Très bien. Je vais committer ça. Ok. Je vais vérifier mes IPs. Je ne pousse que sur GitHub. Voilà, donc là j'ai poussé ce changement dans mon repo. On va aller vérifier. Ça doit être celui-là. Oui, les tests commis doivent être là, 39 secondes de go, c'est celui-là. Donc là, j'ai poussé le changement et là, idem, j'ai un hook qui va... Donc là, je vais changer de région parce que cette démo est dans U-Assist. Voilà. Et donc ce changement... Si le pipeline doit bien se réveiller, doit être détecté comme tout à l'heure et puis on va suivre les différentes étapes. Voilà, c'est parti. Donc exactement le même principe que tout à l'heure, la seule différence est que cette fois, je prends mes sources dans GitHub dans le dépôt dont le nom est là, j'ai autorisé la connexion à ce dépôt, etc. Et puis ensuite, je vais construire avec Jenkins et livrer en bêta, etc. Donc on va laisser ça se dérouler et puis ensuite on conclura et on répondra à vos questions. N'hésitez pas à envoyer vos questions comme d'habitude à Hugo qui est en train de les trier. Voilà, donc la phase de source est conclue. On va avoir le build de Jenkins. Et donc tout ça, ça tourne dans EC2, on doit pouvoir le voir là, si on va dans la bonne région. Donc, je vois mon serveur Jenkins qui est une instance EC2 installée à la main pour le coup. Ce n'est pas un environnement géré CodeBuild. Je fais du Jenkins. J'ai mon instance de dev qui me sert à faire `dev.julien.org` et puis j'ai mes instances de prod qui sont là. Très bien, il faut que Jenkins finisse sa petite histoire. On va regarder, on va surveiller l'environnement dev mais là, ça me part encore un peu tôt. Ouais, c'est encore un peu tôt. Allez Jenkins. Loin de moi l'idée de dire que CodeBuild aurait été plus rapide. Mais c'est quand même important d'avoir l'intégration sur tous les outils, plein de gens qui ont des serveurs qui ont des environnements de développement déjà installés et configurés, il n'y a pas de raison qu'on les oblige à jeter tout ça à la poubelle, ça serait stupide. Alors voilà, il a fini, on va faire le déploiement. Donc là, on fait le déploiement sur l'instance de dev d'abord. Ok, donc j'ai un déploiement en cours ici. Alors, le déploiement, c'est déployer Tomcat. Si on recharge la page, voilà, on voit que ça y est, le déploiement a été fait, on a bien notre message. Et donc normalement, là-dessus, on doit s'arrêter. On va laisser le temps à CodePipeline de se rendre compte qu'il a fini. Et on doit passer sur une étape d'approbation. Je ne vais pas ouvrir mes mails, ça n'a pas d'intérêt, mais voilà ce qu'on reçoit. C'est une notification par SNS, donc on pourrait avoir soit un SMS, soit un mail, soit invoquer une lambda, etc. Là, j'ai fait un envoi par mail. Là, je reçois un mail qui me dit ça, qui me dit qu'il y a eu une modif sur le pipeline, est-ce que tu veux approuver ou pas. Je ne vais pas ouvrir mes mails, je vais faire l'approbation, s'il me rend la main, je vais faire l'approbation là et puis ensuite il va finir le déploiement sur le groupe de déploiement. Pendant qu'il finit ça, on peut peut-être prendre une ou deux questions. Est-ce que les étapes de pipeline peuvent être parallélisées ? On peut les paralléliser. Si on édite le pipeline, on peut ajouter des actions. Je pourrais avoir deux builds en parallèle par exemple. Je pourrais avoir un build Jenkins version de debug et puis un build de Jenkins version profiling. Donc à l'intérieur d'un stage, donc à l'intérieur d'une grande étape comme ça, on peut avoir plusieurs actions en parallèle. Ok ? Alors il faut surtout que je fasse cancel, sinon on va fracasser tout ça. Ok ? On va regarder, je pense qu'il doit avoir fini. Je vais juste vous montrer la fin de ça. Oui, cancel. C'est cancel continue. C'est pas tout à fait intuitif. Voilà donc là on est bloqué sur l'approbation, donc là je vais le faire à la main. Je vais dire ok, c'est bon pour la prod, approuve. Et donc là, du coup, on va débloquer le pipeline et puis d'ici quelques secondes, il va faire le déploiement sur le groupe de prod tout simplement. Donc on va laisser faire ça tranquillement puis on va continuer à répondre. Alors, il y a plusieurs questions sur est-ce qu'on peut utiliser CodeDeploy pour déployer sur Lambda ? Pour l'instant, non. Pour l'instant, non. Je pense que c'est un roadmap. Mais pour l'instant, les seules cibles de déploiement, comme j'ai dit tout à l'heure, sont les instances EC2, les groupes d'autoscaling ou les instances on-premise. Malheureusement, pas encore de Lambda pour l'instant. Alors, pouvons-nous créer nos propres étapes, appel d'API, script, etc. ? Alors, question de Christophe. Tout à fait, c'est le stage que je ne vous ai pas montré. Alors, on y retourne, edit, pendant qu'il fait son déploiement. Puis on va rajouter, par exemple, là, un stage. On va rajouter un stage de notification. Donc, on va l'appeler, ben, appelons comme ça, tiens. Notif. Et on mettra une action invoke. Je ne sais pas. On va mettre n'importe quoi. Ce n'est pas le sujet. Send notif. Et là, je peux appeler une lambda. Une fois qu'on a dit ça, on peut tout imaginer. On peut appeler une lambda qui va faire ce que vous voulez. Pas forcément à la fin du pipeline, ça peut être pendant, les étapes peuvent être à peu près dans n'importe quel ordre. Donc, vous pouvez tout à fait customiser des actions comme ça, en appelant des fonctions lambda à n'importe quel endroit dans le pipeline. Vous pouvez avoir plusieurs étapes invoke, enfin voilà, vous faites à peu près ce que vous voulez. Donc oui, d'ailleurs c'est une idée intéressante pour faire des scripts et des choses comme ça. Non, c'est « cancel, continue ». Je vais y arriver. Après, il y a des questions. Je vois des questions sur… Je vais répondre à cela parce qu'il m'amuse. « PHP est utilisé par 80% des sites internet. Pourquoi vous ne faites pas de démo sur ce langage ? » 80% des sites internet codés en 2000. J'aurais pu faire une démo PHP, mais j'avais envie de montrer des builds. Pourquoi pas du C, pourquoi pas du Java. Mais une fois de plus, vous pourriez builder ce que vous voulez. On vous fournit différents environnements et vous pouvez aussi fournir dans votre container Docker. Donc voilà, il n'y a pas de limite à ce que vous pouvez builder. Mais je n'ai rien de particulier contre PHP, j'ai quelques souvenirs douloureux, c'est tout. Voilà, c'est plus rigolo de compiler du C. Alors, qu'est-ce qu'on a d'autre ? Il y en a quelques-unes sur lesquelles j'ai déjà répondu. Alors, il y a des questions sur le support de Bitbucket, je vois qu'il y a plusieurs personnes qui se tracassent. Alors, on va regarder, donc on va retourner encore dans le pipeline, on va l'éditer et donc dans les actions par exemple de source, là on voit les providers, voilà et on a S3, CodeCommit, Editor, il n'y a pas Bitbucket. Ne me demandez pas pourquoi, je n'en sais rien. Mais voilà, si vous voulez Bitbucket, il faut réclamer Bitbucket. Et sans doute, Bitbucket arrivera. Au début, je crois qu'au début, je crois que quand on l'a lancé, me semble-t-il, je crois qu'il y avait GitHub et je crois qu'il n'y avait même pas CodeCommit, en fait, si je me souviens bien. Donc voilà, il n'y a pas de raison philosophique pour qu'on ne l'ajoute pas. Donc je vous conseille de passer par votre camp manager pour réclamer Bitbucket, soit si vous n'avez pas de camp manager, vous passez par le support AWS, ou vous passez par les forums AWS, ou vous passez par le contactus AWS, quelle que soit la méthode, et vous réclamez d'avoir Bitbucket. Et comme toujours chez nous, si suffisamment de gens le réclament, vous l'aurez. Alors, il y a des questions aussi sur ECS, est-ce qu'on peut faire ça avec ECS ? Tout à fait. J'ai une autre démo mais qui est plus compliquée et que je n'avais vraiment pas le temps de vous montrer aujourd'hui. Je voulais plutôt vous montrer des choses, je n'ose pas dire de débutant, mais des choses plutôt une introduction où on peut, alors là il faudra que je change là, voilà, hop ! Et donc quand je vais dans le déploiement, si je regarde mes fournisseurs de déploiement, je peux déployer sur CodeDeploy comme je vous l'ai montré, je peux déployer sur Elastic Beanstalk, je peux déployer via OpsWorks, Stax, qui est notre chef manager, mais en l'occurrence, je peux aussi déployer sur CloudFormation. Et en fait, c'est comme ça qu'on va faire, c'est-à-dire qu'on va avoir un template CloudFormation qui va déployer les containers sur ECS et on va mettre à jour dans le template CloudFormation la référence de l'image Docker qui est associée au container et on va donc réappliquer le template avec cette mise à jour. Donc on peut tout à fait, je vais essayer de vous retrouver l'article de blog à la. Je ne vous le garantis pas. Code pipeline, j'ai mis tous les mots clés là. Si les moteurs de recherche sont avec moi aujourd'hui, je vais me trouver. Mais ils ne sont peut-être pas dans Yahoo. Ah, quoique, non, non, je suis une mauvaise langue. Regardez, c'est celui-là. Merci Yahoo. C'est celui-là. Continuous deployment to ECS using code pipeline, etc. C'est ça l'idée. Je ne sais pas s'il y a un petit schéma. L'idée, c'est qu'on met toutes les informations sur les containers dans des templates CloudFormation, on les met à jour dans le build et on les réapplique pour refaire le déploiement. Je l'ai déjà fait, ça marche très bien. Alors, qu'est-ce qu'on a d'autre ? Alors, est-ce qu'on peut déployer sur BinStall ? Je viens de répondre. Est-ce qu'on peut déployer en autoscaling ? Oui, on peut déployer en autoscaling. Question, le pipeline se réveille seulement si on touche sur un acheteur ? Non, non, non. Vous l'avez vu, je vais revenir dessus. La branche, on va l'éditer là, voilà. La branche sur laquelle on est... Si je touche à ça, il va me déconnecter. Je le vois là. La branche sur laquelle l'étape source se réveille est configurable. Là, j'ai pris Master, je n'ai pas de raison de faire autrement. Mais vous pouvez prendre n'importe quelle branche. Alors, question de Mickaël. CodeDeploy et CodePipeline sont-ils des outils 100% Amazon ou sont-ils basés sur des outils open source ? Mickaël, soit vous n'avez pas écouté le début, soit vous êtes arrivé. Donc CodeDeploy et CodePipeline, ce sont les versions, on va dire, AWS d'outils développés par Amazon. Donc CodeDeploy, c'est la version productisée d'Apollo et CodePipeline, c'est la version productisée de Pipeline. Donc là, vous utilisez les mêmes outils que ceux que les développeurs d'Amazon utilisent. Est-ce qu'on peut remplacer l'étape Approuval par une étape automatisée ? Oui, tout à fait. Là, j'ai mis une étape d'approbation parce que ça m'amusait de faire une étape d'approbation. D'ailleurs, il a fini son déploiement. On pourrait imaginer que l'étape d'approbation, au lieu de m'envoyer un mail, qu'elle invoque une fonction lambda qui vérifie à son tour que telle et telle métrique de monitoring sont correctes avant de dire oui ou non. L'idée, on est bien d'accord, c'est de faire des pipelines le plus automatisés possible. Donc voilà. Là, c'était juste pour vous montrer cette étape d'approbation avec un truc un peu concret. Et si vous avez besoin de choses plus compliquées, invoquez le lambda. Et puis si vous avez besoin d'obtenir l'approbation de 10 personnes, vous codez un truc avec le lambda. Une dernière question. Une dernière question. À quoi je n'ai pas répondu dans tout ça ? Oui, une question de Ludovic qui est intéressante et dont je n'ai pas du tout parlé. La question, c'est comparé à un GitLab, CodeCommit permet quel genre de stratégie, côté ACL pour les utilisateurs, etc. Donc évidemment, tout ça, c'est soumis à IAM. C'est-à-dire que la moindre action sur CodeDeploy, CodeCommit, CodePipeline, etc., comme d'habitude chez nous, c'est des appels d'API. Et donc vous pouvez autoriser ou interdire ces appels d'API sur tel ou tel pipeline via IAM. Donc vous pouvez interdire à tel utilisateur de commettre sur tel repo, vous pouvez interdire à tel utilisateur d'utiliser tel pipeline, etc. Donc on n'est pas rentré dans IAM parce que c'était déjà assez dense, mais évidemment, vous pouvez utiliser IAM pour customiser tout ça. Je crois qu'on est presque à court de temps. Hugo va vous afficher le sondage. Hugo va vous afficher le sondage tout de suite. De 1 à 5, vous commencez à avoir l'habitude pour ceux qui sont là chaque fois. Donc 5, c'est la meilleure note. 1, c'est la plus mauvaise. Ne vous trompez pas parce qu'on reçoit toujours des messages de gens qui disent « Ah, j'ai cliqué au lieu d'envoyer ». Donc 5 bien, 1 pas bien. Et puis Hugo insiste pour que je désigne un gagnant et donc je vais me fâcher avec à peu près tout le monde. C'est sadique. Pourquoi c'est pas toi qui choisis le gagnant ? Pourquoi c'est pas toi qui choisis le gagnant ? Et bien je vais choisir qui ? Je vais prendre la question de Ludovic sur IAM. Parce que je n'en ai pas parlé. Et je ne ferai pas de commentaire sur le GitLab qui a eu un petit souci récemment. On compatit. Mais n'oubliez pas IAM évidemment pour tout ça. Bien, on a fini ? Écoutez, il ne me reste plus qu'à conclure très très rapidement. Et puis on va faire une petite pause. Ce qu'on a vu aujourd'hui, c'est la capacité finalement à construire de manière automatique des pipelines de livraison continue. Et vraiment, je vous incite à l'essayer. Faites-le dans la console, n'essayez pas de le faire en API, commencez par le faire dans la console. Essayez de refaire un petit exemple, un peu comme le premier exemple. Que j'ai fait vraiment, vous allez voir, il n'y a aucune complexité, je n'ai pas fait de cachotterie et vous pouvez faire ce source bill de diplôme, vous pouvez le faire vraiment cinq minutes de manière super simple en n'ayant aucune infrastructure à gérer et avec des coûts qui sont extrêmement faibles. Voilà, je vous ai mis quelques petits liens pour aller plus loin, je vous laisse regarder ça tranquillement. Je vous rappelle qu'on est des user groups. On a créé il y a peu de temps un user group Côte d'Azur. Si vous êtes dans cette région-là, n'hésitez pas à le rejoindre. J'en profite pour saluer tous les francophones qui sont là, parce que je sais qu'on a de fidèles participants au Canada, en Belgique, etc. Donc salut à vous et merci d'être là. N'oubliez pas que nous avons aussi des webinars au mois de mars et en avril, avec un zoom sur ECS en mars et un zoom sur les bases de données relationnelles en avril. Vous trouverez tous les détails et sans doute les avez-vous déjà puisque vous êtes inscrit à ce webinaire-là. Si vous voulez, allez les reconsulter, ils sont sur le site. Merci beaucoup. On va faire une petite pause de 5 minutes pour reconfigurer nos environnements et puis on vous retrouve tout de suite pour la suite de l'histoire avec l'infra as code platform, Terraform, Troposphère. Merci beaucoup et à tout de suite.