DevOps with Amazon Web Services

Transcript

Bonjour à tous, bonjour à toutes. Nous sommes vraiment très heureux d'être à Marseille. On ne dit pas toujours ça tous les jours. Croyez-moi sur parole. Nous avons le stade Vélodrome, du monde, et même le soleil aujourd'hui. Hier, on avait un peu peur, mais aujourd'hui c'est magnifique. Je m'appelle Julien, je suis évangéliste technique chez AWS. Ce qui est une façon compliquée de dire que je passe ma vie dans les trains et les avions pour venir voir des gens comme vous, des gens sympas, j'espère, pour parler de techno, de use case, de ce que nos clients font sur AWS. En préparant cette session, je me suis dit : "Bon, ok, j'ai bien compris, on va parler de DevOps, mais de quoi on va parler exactement ?" Le premier truc qu'on a fait, c'est de mettre tout le matériel dans le coffre de la R16 et on s'est dit : "Ok, direction Marseille." Non, ce n'est pas vrai, on est venus en avion. Mais quand même, on s'est dit : "C'est Marseille, il faut faire quelque chose de bien." Alors, évidemment, je me suis dit : "Bon, je vais parler d'AWS." Ça paraît très logique. J'aurais pu parler de notre plateforme qui est scalable et globale, mais en regardant ce slide d'un autre œil, je me suis dit que ce n'était peut-être pas une excellente idée. Donc, on va oublier les généralités et parler des trucs vraiment importants. Si vous suivez un peu notre actualité, vous savez qu'il y a à peu près une semaine, on a annoncé qu'AWS allait ouvrir une région en France. On va enfin avoir des dates. C'est une super nouvelle, en tout cas, ça nous fait très plaisir, on a plein de clients que ça excite et plein de futurs clients aussi. Mais je me suis dit que je risquais de dire une connerie sur ce slide, donc il vaut mieux ne pas en faire trop. Donc, mauvaise idée. Et en fait, je me suis dit : "Merde, de quoi je vais leur parler aux Marseillais ?" Je me suis dit que je vais revenir un peu dans le temps et parler de ce qu'Amazon.com a fait en termes de DevOps. Ça nous amène à la préhistoire de l'internet en 2001. Amazon était déjà un assez gros site e-commerce et, croyez-le ou non, ils avaient une architecture qui était franchement monolithique. Ça ne veut pas dire qu'ils déployaient un seul point jar, war, whatever en production, c'était découpé, mais vous savez comme moi que même une architecture qui est un peu découpée, à force de mal gérer les dépendances et d'avoir du code spaghetti et des API spaghetti partout, on se retrouve obligé de tout déployer tout le temps. Même Amazon était dans cette situation. Le cycle de développement d'Amazon à l'époque ressemblait à ça. Je n'ose pas vous demander qui est encore dans cette situation, mais bon, allons-y quand même. Est-ce qu'il y a encore des gens qui sont dans cette situation ? Non, mais n'ayez pas honte, vous êtes des millions. L'essentiel, c'est que ce ne soit pas votre faute. Si ce n'est pas vous qui avez pris la décision il y a dix ans, tout va bien. Vous connaissez bien ce problème, et il se produit vite. Il n'y a pas besoin d'avoir des milliers de développeurs, même à cinq ou dix développeurs, on a déjà ce problème. On travaille en parallèle, on committe sur des branches, à la fin on les merge, on essaie de déployer et on rollback en 30 secondes parce que ça ne marche pas. Je parle d'expérience, j'ai eu ce problème, et c'est difficile de s'en sortir. Quand on est dans cette situation, le process de release ressemble à ça. On fait des incantations, ça a marché sur l'environnement d'intégration ou l'environnement de pré-prod. On espère qu'automagiquement, ça marchera en prod et qu'on ne rollbackera pas deux minutes plus tard, faisant un trou dans la courbe des clics, des ventes, etc. Mais comment sortir de cette situation ? On pourra en discuter ensuite, n'hésitez pas à venir me voir pour partager comment vous vous en êtes sortis. En ce qui concerne Amazon, ils ont décidé de faire un saut quantique. On imagine que devant la croissance du business et l'explosion de l'e-commerce, souvenez-vous, c'était 2002, c'était vraiment de la folie. Ce problème était totalement critique pour le développement de l'entreprise. Ils ont fait un grand saut technique en allant vers une architecture SOA basée sur des petits services. Ce diagramme que vous voyez, bien qu'il date maintenant, représente les microservices qui composent le site d'e-commerce d'Amazon. Des petits services à objectif unique, avec des API, un découplage fort, etc. Vous en entendez parler depuis ce matin, et vous entendrez parler encore pendant un mois ou dix ans. Les microservices, tout le monde en parle, mais c'est une démarche technique qu'Amazon a entamée très tôt, au début des années 2000. Mais vous savez comme moi que le DevOps, ce n'est pas juste un sujet technique, c'est aussi un sujet d'organisation. Si vous avez une organisation qui ne se prête pas au développement parallèle, au release, au release often, etc., ça ne marche pas. Il y a ce concept dont vous avez peut-être entendu parler, qui s'appelle les "two pizza teams", qui est qu'aucune équipe de développement ne doit être supérieure à ce que deux pizzas peuvent nourrir. Attention, ce sont des pizzas américaines, car je pense que dans la salle, on a des gens qui seraient capables de manger deux pizzas marseillaises tout seul. Il y a des gourmands, je les ai croisés. Donc, on parle de pizzas américaines, donc c'est la taille XXL. Le concept est de faire des petites équipes, et la taille idéale est peut-être 6-8 personnes maximum, comme dans les équipes Scrum. Des petites équipes qui sont totalement responsables de leur code, du design jusqu'au suivi de prod, donc il n'y a pas de "voilà le code, mets-le en prod et maintenant c'est ton problème". Des équipes qui vont jusqu'au maintien en condition opérationnelle de la plateforme, sans responsable. Aujourd'hui, ce concept paraît naturel, en tout cas sur le papier, on a tous entendu parler mille fois de DevOps, mais c'est quelque chose qu'Amazon a entamé très tôt. Une fois cette organisation mise en place, il restait encore un problème à résoudre : comment faire en sorte que tous ces livrables arrivent en production de manière cohérente, efficace, et qu'ils livrent un truc qui marche à la fin. Les quelques requirements étaient de disposer d'outils en self-service, sans avoir à créer des tickets pour que quelqu'un déploie, ce qui est un cauchemar. Il fallait que toutes les technologies fonctionnent avec ces outils, car vous savez peut-être que les équipes de dev Amazon peuvent choisir leur techno. Ce n'est pas une plateforme homogène, donc ce n'est pas tout en Java, tout en Python, ou tout en C++. Si elles considèrent que C++ est plus adapté à leur appli, elles le font. Elles définissent des contrats d'API avec les autres équipes, et le reste est une boîte noire. Il fallait que les outils encouragent les bonnes pratiques. Vous savez comme moi qu'on peut répéter les bonnes pratiques mille fois, mais si les outils finalement vous éduquent, voire vous imposent les bonnes pratiques, elles s'appliqueront toutes seules. Et surtout, des services simples, compréhensibles, pas des usines à gaz qui essaient de faire le CI, le CD, le QA, les tests unitaires, le déploiement, le monitoring, les tests de charge, etc. Le couteau suisse est joli sur l'étagère, mais quand on en a vraiment besoin, ça ne marche pas. Il vaut mieux avoir des outils qui font un seul truc, mais qui le font vraiment bien. Ils ont développé deux outils. Un s'appelle Apollo. Il y a une certaine obsession pour les sujets spatiaux chez Amazon. Vous savez que notre fondateur, Jeff Bezos, a aussi une boîte qui lance des fusées réutilisables. Quand on veut que les projets soient approuvés par Jeff, si on leur donne un nom qui a un rapport avec l'espace, ça marche sans doute un peu mieux. Apollo est le service de déploiement. On fait des lancements, pas des fusées, mais du code. Les requirements étaient de ne pas avoir de downtime, quel que soit le déroulement du déploiement, bon ou mauvais. Il fallait un suivi permanent de l'état des instances sur lesquelles on déploie, du versionnage, qui paraît indispensable, et la capacité à faire des rollbacks, car même avec des bonnes politiques de test et toutes les bonnes pratiques, de temps en temps, il y a un problème, et il faut être capable de faire un rollback le moins pénalisant possible pour la plateforme. Le deuxième outil qui a été développé s'appelle Pipelines. Comme son nom l'indique, c'est un outil qui va vous permettre de faire du continuous delivery, de définir des pipelines de manière complètement automatisée. On parle toujours d'automatisation, mais pourquoi est-ce que c'est bien ? C'est bien parce que ça va plus vite, on n'a pas d'humain au milieu pour créer des tickets, valider des tickets, refuser des tickets, etc. On enlève la lenteur de l'être humain, et surtout, on fait en sorte que les étapes soient toujours suivies dans le même ordre, et que si des étapes de validation doivent être passées et que la validation n'est pas là, elles ne sont pas passées. L'automatisation, c'est vraiment dire qu'on va plus vite, mais surtout qu'on a un process répétable auquel on peut faire confiance pour arriver à un résultat le plus déterministe possible. Cet outil Pipelines est utilisé par quasiment la totalité des équipes de développement Amazon. Il y a certaines équipes qui ont des besoins très particuliers et ont leur propre outil de développement, mais Amazon a réussi à unifier cet outil et à le faire utiliser par toutes les équipes. Grâce à ces outils, et quelques autres, on a pu compléter le process de DevOps en disant qu'on a des équipes de petite taille, autonomes, agiles, capables de pousser du code tout le temps sans être bloquées par telle ou telle dépendance ou tel ou tel souci. Elles le font parce qu'elles ont des outils qui supportent ce mode d'organisation. Aujourd'hui, Amazon, c'est des milliers d'équipes de développement avec une architecture microservices qui font à peu près tout, de la livraison en continu sur un tas d'environnements de tests, de sécurité, de tests de charge, etc. Ces chiffres datent de 2014, mais vous pouvez les multiplier par un facteur. On arrive à des dizaines de millions de déploiements par an. Si on ramène ça en seconde, ça veut dire plus d'un déploiement par seconde. C'est-à-dire que quand vous utilisez Amazon.com, Amazon.fr, ou Amazon.étoile, ce site-là, toutes les secondes, il y a quelque chose qui change en termes de code. Après, il y a les produits aussi qui changent, mais en termes de code, de fonctionnalités, de bug fix, etc., ça change à chaque seconde. Ce problème d'architecture monolithique et d'organisation monolithique a été résolu. La science-fiction qui était de dire qu'on veut pouvoir réaliser tout le temps, 24h sur 24, qu'on veut pouvoir changer une ligne de code et la déployer en production en 10 minutes ou 5 minutes, est devenue une réalité. Et je sais qu'il y a beaucoup de gens partout qui courent après ça aussi. On essaye tous de faire ça, on essaye tous d'arriver à un schéma comme ça. Amazon y est arrivé parce que c'était critique pour son business, parce qu'il y avait déjà des outils et beaucoup de développeurs. Mais la vraie question, au-delà de ce que fait Amazon, c'est de se dire : "S'il fallait être à la taille d'Amazon pour avoir ces process, ça serait triste." La question, c'est de savoir comment on peut amener ça à tout le monde. Comment une équipe de deux personnes, ou même un seul développeur, peut utiliser les mêmes outils, avoir la même agilité, les mêmes process, la même facilité de développement sans se soucier d'avoir une infrastructure de développement qui va être compliquée, fragile, ou coûteuse, etc. Ce qu'a fait AWS, c'est de prendre les outils qui étaient utilisés en interne et de les packager pour les rendre disponibles au plus grand nombre. Ils sont au nombre de trois, c'est ce dont je vais parler aujourd'hui. Il y a CodePipeline, qui est la version AWS de Pipeline, qui va vous permettre de définir des pipelines de déploiement. On verra un exemple et une démo tout à l'heure. CodeCommit, qui n'est ni plus ni moins qu'un Git manager. On verra aussi. Et CodeDeploy, qui est la version AWS d'Apollo, qui va vous permettre de déployer du code de manière fiable et répétable sur vos instances, quelle que soit la technologie que vous utilisez, l'environnement de développement, ou le langage. Bien sûr, le monde n'a pas attendu Amazon et AWS pour faire du CI/CD et de l'automatisation. Il y a tout un tas de partenaires et d'outils qui ont émergé sur le marché et que vous utilisez au quotidien. Je pense que vous reconnaissez vos outils favoris sur ce site. L'objectif est aussi de dire qu'on veut pouvoir intégrer tous ces outils avec CodeCommit, CodeDeploy, et CodePipeline. C'est le cas. En fonction des cas, je vous le montrerai tout à l'heure. Dans ma démo, j'ai Jenkins et GitHub. Ne croyez pas que ce soit une solution monolithique où il faut adopter toute la suite Code et jeter tout ce que vous faisiez à la poubelle. Ce n'est pas du tout ce qu'on souhaite. Au contraire, on souhaite que vous gardiez vos outils actuels et que vous puissiez les enrober ou les compléter avec nos propres outils. Rapidement, quelques détails sur ces trois produits, puis on passera à la démo. CodeCommit, c'est le plus simple des trois. Qu'est-ce que CodeCommit ? C'est un Git manager dans AWS. Vous utilisez vos outils Git normaux. Vous allez me dire : "Quel avantage à faire ça ? On a GitHub, on est content de GitHub, on ne voit pas pourquoi on aurait besoin d'un autre Git." Dans ma démo, j'utilise GitHub. Quelle est la justification de CodeCommit ? Je pense que GitHub est une super plateforme collaborative, c'est beaucoup plus qu'un repo, mais il y a plein de use case où on a envie d'avoir son code au plus près de son infrastructure. Avoir CodeCommit, ça vous permet d'avoir vos repositories au même endroit que votre infrastructure cloud, avec la durabilité, la scalabilité, et la sécurité que peut apporter AWS, en l'occurrence S3, puisque les données de CodeCommit sont stockées dans S3 et peuvent être chiffrées automatiquement avec des clés, etc. L'idée n'est pas du tout de chercher à remplacer GitHub. L'idée est de dire que GitHub est vraiment un outil, une plateforme de collaboration, de développement, etc., mais dans le workflow, à un moment, ça peut être intéressant de ne pas déployer à partir de GitHub mais de déployer à partir d'un repo qui a d'autres propriétés. CodeDeploy, on va le voir en action tout à l'heure. CodeDeploy est un déployeur, donc vous allez définir ce qu'on appelle des groupes de déploiement, des ensembles d'instances qui vont recevoir une version de l'application. L'avantage de CodeDeploy, c'est que c'est difficile de le faire de manière fiable. Quand le déploiement se passe bien, tout va bien, mais quand il se passe mal, quelle que soit la raison, c'est vraiment difficile de savoir dans quel état est la plateforme, ce qu'il faut rollback, et comment le faire sans tout faire tomber, etc. Le point clé de CodeDeploy est la fiabilité, la capacité à faire des rolling upgrades, des rollbacks en cas de pépins, et à scaler votre plateforme de manière transparente. On peut déployer sur des autoscaling groups, vous n'avez pas à vous soucier de combien d'instances vous avez à l'instant T. À partir du moment où elles sont dans le bon groupe de déploiement, qu'il y en ait 4 ou 38, CodeDeploy va les trouver et toutes les déployer. CodeDeploy est agnostique, donc on peut déployer sur Linux, sur Windows, sur EC2 chez nous, et même sur des instances on-premise chez vous via l'installation d'un petit agent. Vous pouvez même utiliser CodeDeploy pour déployer dans votre datacenter, histoire d'avoir un déploiement unifié et de ne pas avoir différentes façons de déployer le même code à des endroits différents. Quand on déploie, il y a trois questions : qu'est-ce qu'on déploie, comment on déploie, et où est-ce qu'on déploie. Qu'est-ce qu'on déploie ? Du code versionné, donc ça sera dans un repo. Comment on le déploie ? C'est ce qu'on appelle la configuration de déploiement. Est-ce que vous shootez toutes les instances d'un coup, les faites une par une, ou 30% par 30% ? C'est vous qui le décidez. Vous pouvez créer votre configuration de déploiement qui sera aussi la configuration de rollback pour dire : "Je veux faire une rolling upgrade si c'est de la prod, ou je veux faire toutes les instances d'un coup si c'est de la dev, même si j'ai un downtime, mais c'est de la cellule dev, donc ce n'est pas gênant." Où est-ce qu'on déploie ? Vous pouvez déployer sur une seule instance, un ensemble d'instances, un groupe d'autoscaling, ou même sur des serveurs on-premise chez vous dans votre datacenter. Le dernier point, CodePipeline. L'idée est simple : vous allez définir un ensemble d'étapes. Ça peut être des sources, donc je récupère des sources dans GitHub ou CodeCommit, je les build, donc là ça peut être avec Jenkins ou d'autres outils, je les teste, donc je peux passer des tests de charge, des tests de perfs, etc., je les déploye, donc je vais amener l'application sur mon groupe de déploiement, je m'assure que tout fonctionne bien, je peux invoquer des fonctions Lambda, qui permettent d'appeler une fonction qui va exécuter un traitement au sein de la plateforme. Vous pourriez dire : "J'ai des instances déployées, donc je vais activer tel monitoring, faire telle opération dans mon DNS, ou lancer tel check de sécurité." On peut tout imaginer. Bref, vous pouvez déclencher des traitements post-déploiement. Et puis une étape que j'utilise, qui s'appelle "approuv", est une approbation manuelle. Parce que l'automatisation est bien, mais il y a des moments où il faut peut-être qu'il y ait une opération manuelle, ou en termes de process, une approbation formelle avant de déployer en prod. On peut définir une étape d'approbation qui va envoyer une notification. Si vous approuvez, on continue le déploiement. Si vous n'approuvez pas, on arrête le déploiement. L'avantage de CodePipeline, c'est que vous pouvez définir votre pipeline graphiquement. C'est super simple. Vous créez des boîtes, par exemple, pour la source, vous dites : "Voilà, j'utilise GitHub, voilà les credentials, voilà mon repo, voilà la branche, ok, clique, et c'est bon." Puis vous construisez le pipeline de déploiement graphiquement. Bien sûr, on peut aussi faire ça en ligne de commande. C'est vraiment facile à mettre en place. Donc, voilà pour la partie théorique. Maintenant, je pense que vous avez envie de le voir marcher. Voilà ce qu'on va construire. J'espère que vous arrivez à lire sur les écrans, sur les côtés. C'est bon, ça va, c'est pas trop petit. J'ai un pipeline qui est composé des étapes indiquées là. J'ai une étape source où je vais récupérer mon code dans GitHub, une étape build où un serveur Jenkins va compiler mon code, une étape de déploiement sur un environnement de dev avec CodeDeploy, une approbation manuelle via une notification par email, et ensuite un déploiement en prod toujours avec CodeDeploy. Sur la droite, vous voyez l'ensemble des services qui vont servir à faire ça. J'ai un repo GitHub, dans lequel il y a mon code, et un fichier important qui est le fichier de configuration de CodeDeploy, appelé AppSpec, qui est en YAML. Vous allez définir les étapes indispensables au déploiement : ce qu'il faut faire avant l'installation, pour installer, post-install, et comment valider que l'application fonctionne. Il faut aussi que ces scripts soient disponibles. Pour pimenter et aller au bout de la logique d'automatisation, tout ça va être construit automatiquement par CloudFormation, notre techno d'infrastructure as code. Vous décrivez l'ensemble des ressources dont vous avez besoin, les instances, le load balancer, etc., via un template JSON ou YAML. Tout ça va être construit automatiquement. Je vais vous montrer les différentes étapes, puis une fois que l'infra est construite, on va utiliser CodePipeline, CodeDeploy, et SNS pour gérer la première étape, qui est de créer un VPC réseau privé au sein de ma région. Ici, je fais la démo dans la région américaine. Donc j'ai une gateway internet également, puisque je vais déployer des sites web et j'ai envie d'y accéder. Je déploie une première instance qui est une instance de dev, qui s'appelle devwebapp1, sur laquelle j'ai mis un nom de domaine dev.julien.org. J'ai un deuxième ensemble d'instances identifiées, équilibré sur deux zones de disponibilité, donc prodwebapp1, 2, 3, 4. Devant, j'ai mis un load balancer, notre application load balancer, qui fait du load balancing niveau 7, de choisir des routes, etc. Et histoire de rigoler, j'ai mis un certificat dessus pour avoir HTTPS en cinq minutes sur mon environnement de production. Donc, voilà, c'est mon infra, et j'ai un serveur Jenkins qui est là aussi pour faire le build. Voilà, c'est ce que crée automatiquement mon template CloudFormation. Je l'ai fait à l'avance parce que ça prend une dizaine de minutes, et regarder la création se faire est aussi intéressant que de regarder l'herbe pousser. Donc, on a économisé ce temps-là. En termes de déploiement, j'ai deux groupes de déploiement gérés par CodeDeploy. Un qui va faire le déploiement sur le dev, instance unique, et un qui va faire le déploiement sur la prod, donc avec mes quatre instances, en faisant une rolling upgrade. C'est à peu près clair ? Ça marche. Je vais basculer sur la console. Voilà la console AWS. CloudFormation en 5 secondes. Le principe, c'est ce que je disais tout à l'heure. On a un template. Là, il est en JSON. Je décris en JSON l'ensemble des ressources dont j'ai besoin. Donc, je crée mes subnets, mon VPC, ma gateway, mes tables de routage, etc. Il est assez long, il y a pas mal de choses. Je crée mes instances, mon Jenkins, tout ça est créé là-dedans. Je le lance, ça dure, on va regarder combien de temps ça a duré. Voilà, 16h23, 16h28, ça a été assez rapide, 5 minutes. Donc, j'ai construit toute l'infrastructure que je vous ai montrée sur le slide précédent, y compris le pipeline de déploiement. Je ne vous cache pas que pour écrire le template, il faut un peu plus de 5 minutes, mais une fois que vous avez sué pour l'écrire, même si en YAML ça sera un peu plus simple maintenant, vous pouvez rejouer ça à l'infini dans toutes les régions et créer votre infrastructure assez rapidement. Ça m'a créé des instances. Voilà, on voit mon serveur de dev, mes 4 instances de prod, mon Jenkins. Voilà, mes instances sont là. J'ai mon load balancer qui est là, qui balance sur 80 et 443. Si je regarde là, normalement, je dois avoir mes 4 instances. Voilà, les targets. Elles sont là, les 4. 2 dans la zone de dispo 1A, 2 dans la zone 2C. Elles vont toutes bien. Parfait. Mon petit certificat que j'ai installé, le modèle que vous connaissez sûrement, c'est quand vous devez déployer des certificats, c'est : je vais chez mon fournisseur de certificats préféré, je trouve quelqu'un qui a la carte bleue corporate, j'achète les certificats, j'espère que je les ai bien configurés, je les télécharge, et après je vais les déployer soit sur toutes mes instances, soit sur mon load balancer. C'est tout un cirque, j'essaie de ne pas péter ma prod en le faisant. Là, ça m'a pris 5 minutes. Vous rentrez votre nom de domaine, vous cliquez OK, ça renvoie un mail au propriétaire du domaine, en l'occurrence moi. Vous acceptez la création du certificat, il est créé, et puis ensuite vous allez sur le load balancer, vous attachez le certificat, c'est terminé. C'est vraiment un service, et les certificats sont gratuits. Dans ce monde, il y a peu de choses gratuites, mais voilà, les certificats le sont. Donc, voilà, j'ai mon infra. Le pipeline, vous voyez, j'ai les étapes que j'ai indiquées tout à l'heure : source, build, beta qui est mon déploiement en dev, approv qui est mon étape d'approbation manuelle, puis prod qui est mon étape de déploiement en prod. Je pourrais l'éditer, par exemple, voilà ce qui a été configuré là. Je vois que je déploie à partir de GitHub, j'aurais pu déployer à partir de CodeCommit, et j'ai donné mes credentials GitHub. Tout se passe bien. J'aurais pu rajouter plein d'étapes, mais tout est configurable assez simplement. Bien sûr, comme j'ai dit tout à l'heure, vous pouvez aussi le faire en scriptant et créer des pipelines à la volée. CodeCommit, même si je ne l'utilise pas aujourd'hui, je vous montre en cinq secondes. L'objectif n'est pas du tout de remplacer GitHub, c'est vraiment d'avoir des repos hostés dans AWS au plus près de l'infra. Voilà, donc j'ai mon projet, je peux voir mes commits. Si le wifi veut bien suivre. Allez, non, c'est pas grave. Voilà, ça c'est sympa, je peux voir mes branches, etc. Mais vous voyez, il n'y a pas les pull requests, il n'y a pas tout le truc collaboratif. En fait, plus, nous, ce qu'on veut, c'est fournir un point à partir duquel vous pouvez déployer facilement vers votre infra. Mon repo est là, il est dans GitHub. Il est forké sur un repo AWS, j'ai mis l'URL dans les slides que vous aurez évidemment. Il y a toute une démo basée autour de tout ça qui m'a servi de point de départ et que vous pourrez rejouer à partir de ce repo. J'ai un Jenkins, ok, magnifique. Voilà, c'est mon Jenkins au sein d'AWS. On va pas s'attarder sur Jenkins. Ce qui est plus intéressant, ce sont mes groupes de déploiement. J'ai un groupe de déploiement pour le dev, un groupe de déploiement pour la prod. C'est là que je vais dire que je déploie sur des instances EC2, et je vais déployer sur toutes les instances EC2 qui sont taguées avec ce tag. Ce qui fait qu'une instance est dans un groupe, c'est tout simplement qu'elle a ce tag. Je pourrais créer des triggers, des alarmes actives, des rollbacks, etc. Il y a tout un tas de fonctionnalités, donc je n'ai pas le temps d'en parler aujourd'hui, mais c'est relativement complet. Idem pour les déploiements en prod. Voilà, je vois la liste de tous les déploiements que j'ai pu faire, ils se sont bien passés. S'il se passe mal, j'en ai pas un fail quelque part, ça serait rigolo. Si c'est fait, vous pouvez récupérer les logs, il y a pas mal d'infos sur comment s'est passé le déploiement. Tout ça sert à déployer ma magnifique appli, qui est mon site e-commerce de vêtements pour chiens. Voilà, c'est la version de dev. Je vois ici un petit bout de JS qui me dit que c'est bien le groupe de dev, et il n'y a qu'une instance. Et puis j'ai la même version en prod, sur laquelle vous pouvez vous connecter, c'est ouvert. Je vois là aussi que j'ai mes quatre instances et mon groupe de prod. Tout ça, hop, ça s'est fait automatiquement. Ce qu'on va faire maintenant, c'est qu'on va faire un petit changement parce que sinon c'est pas rigolo. Voilà, donc... Ok, j'ai mes remotes qui sont configurés, donc je peux pusher un code commit, j'ai l'origine et puis l'upstream. Ok, donc là, on va changer quelque chose dans la page. On va changer un truc simple. On va changer peut-être le titre. Voilà. Je vais voir. Si ça ne fail pas, il est en train de faire le pull. Donc, il y a un hook dans le repository GitHub. Il est en train de faire le pull dans S3, et il va livrer à Jenkins à partir de là. On va voir Jenkins qui se met à builder. Vous voyez, l'automatisation est là, et là, sur ça, moi, je n'ai rien configuré à part définir graphiquement le pipeline. En l'occurrence, il a été fait avec CloudFormation, mais on aurait pu le faire à la main. Les étapes s'enchaînent automatiquement. Jenkins va faire son job, il va builder, il va livrer l'artefact, et il va passer la main à CodeDeploy, donc il va déployer sur l'instance de dev. On va attendre que Jenkins fasse son travail, même pour des petites applications, ce n'est jamais hyper rapide. Dépêche-toi, allez, on a perdu assez de temps comme ça. Et puis ensuite, je vais recevoir un mail avec la demande d'approbation. Allez, Jenkins, fais ton travail. Ça y est, build succeeded. Si je vais voir là, j'ai le déploiement qui est en cours. Si je vais sur mon site, c'est la version de dev. Oui, c'est le titre, il est là. Je l'ai changé. Donc, là, il est changé. Si je vais vite sur la prod, non, puisque j'ai l'approbation. Voilà, waiting for approval. Là, j'ai reçu un mail, je ne vais pas ouvrir ma mailbox parce que Dieu sait ce qu'il pourrait y avoir dedans. Mais ça ressemble à ça. Ah, ouais, on a tous les mêmes problèmes. Quelqu'un a un bon filtre en spam. Ça passe par SNS, ça pourrait être un SMS, un email, un message dans une file de messages, etc. Vous recevez un mail comme ça, qui vous dit : "Coucou, il y a eu un déploiement." Donc, va jeter un œil sur dev.julien.org, et puis si ça te plaît, tu approuves ou tu rejettes le changement. On peut aussi le faire dans la console. On va dire que tout va bien. Approuve. Voilà, l'approbation est passée, et puis je vais voir mon déploiement en prod qui va se produire dans 5 secondes. Voilà, le temps qu'il se réveille. Voilà, donc là, il va faire le déploiement en prod, et si on a de la chance, voilà, là, il y a un load balancer, donc on va voir si on tape une qui est déployée ou pas. Voilà, ça y est, ah non, pardon, non, c'est pas encore bon, c'est toujours la même. Allez, voilà, ça y est. Donc, celle-là, elle est déployée, celle-là, elle l'est pas. Voyez, load balancer, celle-là, elle l'est pas, celle-là, elle l'est pas. Ah ! Voilà ! Et oui ! Bon, ça c'est ma config de l'autre balancer qui est pas bonne. C'est normal, je l'avais déjà vu ça. Si, si, c'est bon. Et donc, il va faire... Voilà, si on va voir dans la fenêtre, on voit le rolling upgrade qui est en train de se faire. Bon, vous avez compris tout. Si vous voulez en savoir plus, vous pouvez aller voir AWS Code sur notre site, qui est le point de départ pour toutes les activités de développement. On a un blog dédié sur tout ce qui est DevOps, qui s'appelle Application Management. La troisième URL est celle de la démo qui m'a servi de point de départ. Et puis, après, à vous de vous créer un compte, sachant que vous savez qu'on a un niveau d'usage gratuit les 12 premiers mois. Et donc, sur cette URL slash free, vous trouverez comment utiliser la plupart des services AWS gratuitement pendant 12 mois. Juste pour finir, on a des user groups un peu partout en France. Mon grand désespoir, il n'y en a pas à Marseille. Donc, s'il y a des gens qui sont intéressés pour monter un groupe AWS à Marseille, venez nous voir sur le stand, on peut en discuter, ça sera avec plaisir. Et puis, dernière chose, on a l'Enterprise Summit à Paris le 27 octobre. C'est un événement d'une journée avec des sessions business, des sessions techniques sur AWS, comment il est utilisé par les grandes entreprises. Mais ça peut déborder très largement le cadre des grandes entreprises. Si vous voulez vous inscrire, vous trouverez les infos sur notre site ou à cette URL. Voilà, j'ai terminé. Je vous remercie beaucoup. Je voulais remercier Triptyque pour ce bel événement et vous remercier d'être venu nombreux m'écouter. C'est vraiment super. Voilà, passez une bonne fin d'après-midi, et puis venez sur notre stand si vous avez des questions, on essaiera d'y répondre. Merci beaucoup. Gracias.