Automatisez votre infrastructure avec Amazon Web Services

Transcript

Nous revoilà, j'espère que vous avez eu le temps de prendre un café. Nous non, mais c'est pas grave, on est à fond. Deuxième webinaire de l'après-midi, infrastructure as code. Pour repositionner un petit peu la discussion, et puis peut-être qu'il y a des gens qui nous rejoignent maintenant et qui n'ont pas assisté au webinaire précédent, le précédent on a parlé d'intégration continue et de déploiement continu. On a vu comment construire des pipelines de déploiement pour des applications déployées sur EC2 et comment dérouler des tests et comment faire du déploiement de manière automatique, répétable, etc. Maintenant, il y a un deuxième sujet qui est : quid de l'infra, quid de ces instances EC2, quid des VPC, quid de ce qui me sert à déployer mes applications ? Est-ce que ça aussi je peux l'automatiser et le déployer de la même façon ? La réponse est oui, c'est ce fameux sujet infrastructure as code. On va rapidement, ou pas d'ailleurs, ça mérite peut-être d'être expliqué en détail. On va parler un peu de ce concept, concrètement de ce qu'il représente. Et puis on va voir trois technos qui permettent de faire de l'automatisation de déploiement d'infrastructures. La première, dont vous avez certainement déjà entendu parler, s'appelle CloudFormation, qui est un service AWS extrêmement présent. Une deuxième façon de le faire avec un produit open source qui a une version commerciale, on ne parlera aujourd'hui que de la version open source, qui s'appelle Terraform, développé par une société qui s'appelle HashiCorp, que vous connaissez sans doute également. Et puis enfin, on verra une troisième façon de le faire avec un autre projet open source qui s'appelle Troposphere et qui permet d'écrire du code qui littéralement va générer les fichiers qui vont vous permettre de créer l'infrastructure. Donc trois façons intéressantes et complémentaires avec des avantages et des inconvénients, on en parlera tout à l'heure. Alors, qu'est-ce que c'est que l'infrastructure as code ? C'est de l'infrastructure. C'était une photo de ma collection personnelle. Des baies, des câbles, des serveurs, etc. Magnifique. Et l'objectif, c'est d'arriver à décrire ça dans un document. Voilà, tout simplement. De décrire la structure de cette infrastructure, de décrire les liens entre le serveur, le réseau, bref, de décrire toutes les propriétés de cette infrastructure dans un document. En l'occurrence, ici à droite, on voit un document CloudFormation, ce qu'on appelle un template, on va en reparler. Et c'est vraiment ça, quand on parle d'infrastructure as code, on parle de rédiger dans un document, de décrire dans un document toutes les propriétés d'une infrastructure et ensuite d'utiliser ce document pour exécuter la construction de cette infrastructure. Pourquoi est-ce que c'est superbe ? Pourquoi est-ce que c'est un concept hyper excitant ? Vous pourriez me dire, oui, mais bon, ok, dans le cloud on peut déjà faire des trucs, on peut scripter, on a des SDK, il y a la ligne de commande AWS, il y a Boto, le SDK Python, il y a le SDK PHP, il y a le SDK dans tous les langages, et avec tout ça, je peux automatiser, je peux créer mes instances, je peux créer mes RDS, je peux créer mes buckets, donc pourquoi j'ai besoin d'un truc en plus ? Qu'est-ce que ça m'apporte en plus ? La première chose, c'est l'automatisation. Vous avez compris que dans le DevOps, l'automatisation est une obsession. Et ici, ce qu'on veut faire, c'est décrire cette infrastructure dans un document pour pouvoir rejouer ce document autant de fois que nécessaire, de manière complètement automatisée, ce qui, comme d'habitude, réduira le temps de construction de l'infrastructure et surtout réduira l'erreur humaine. Parce que si vous faites comme moi, vous passez votre temps à cliquer dans la console, au bout d'un certain temps, vous savez plus très bien ce que vous avez cliqué, vous oubliez que vous avez lancé une instance dans un coin et puis après vous recevez la facture et c'est un problème. Ou alors vous avez créé des ressources que vous n'avez pas taguées et puis vous savez plus à quoi elles correspondent, vous n'osez pas les effacer, vous n'osez pas les détruire, vous n'êtes pas sûr que ce soit vous qui les ayez créées, s'il y a plusieurs personnes qui utilisent le compte, etc. Donc le premier gros bénéfice de l'infrastructure as code, c'est l'automatisation. Une fois que la description est faite, vous utilisez le document pour construire l'infra, vous mettez les bons tags, ça sera toujours fait de la même façon, etc. Il n'y aura pas de doute sur « Où est-ce que j'ai cliqué ? » Il n'y a personne qui a cliqué, on a juste utilisé le document pour construire l'infra. Une autre conséquence de cette description, c'est que vous allez avoir des builds qui sont prévisibles. L'infrastructure qui va être construite, elle va correspondre exactement à ce qui est décrit dans le document. Il n'y aura pas de variation, il n'y aura pas d'étape en plus, en moins, ce qui est toujours le risque quand on fait les choses à la main. Une fois de plus, je passe ma vie à cliquer dans la console, je fais rarement les choses deux fois de la même façon, c'est pas bien, et en particulier quand je prépare des démos, parfois j'ai des surprises, j'ai oublié une étape, j'ai oublié un security group, j'ai oublié un truc comme ça, et je me fais avoir. Si j'étais plus rigoureux, je ferais les déploiements de CloudFormation pour toutes mes démos, et je pourrais les construire de la même façon exactement chaque fois. Comme le document est un document de texte, vous allez pouvoir le versionner, vous allez pouvoir le mettre dans Git, vous allez pouvoir tracer toutes les modifs qui sont faites, qui a changé quoi. C'est l'équivalent de quand quelqu'un va dans le data center et débranche un câble réseau sur un switch et le branche sur un autre switch parce qu'à l'instant T c'était soit une bonne idée soit une mauvaise idée, mais en tout cas on l'a fait. C'est hyper difficile si ça crée un incident, si ça pose un problème, c'est hyper difficile de savoir qui a fait quoi parce que même si vous allez discuter avec la personne qui l'a fait en disant, mais qu'est-ce que tu as fait dans le data center, tu as touché à quoi, elle a peut-être oublié. La moindre modif sera une modif dans un document, vous allez versionner, vous allez mettre dans votre gestion de conf et donc il n'y a plus d'ambiguïté, il n'y a plus de doute sur qui a touché à quoi. Et puis bien sûr, c'est un document, donc vous pouvez faire des tests, vous pouvez écrire des scripts ou vous pouvez implémenter des outils qui vont aller vérifier que les bonnes pratiques sont appliquées dans ces documents. Vous pouvez vérifier que les security group ne sont pas ouverts aux 80, vous pouvez vérifier que les volumes EBS sont chiffrés, etc. Puisque toute la config de l'infra est décrite dans les documents, vous allez pouvoir la tester, vous allez pouvoir aller parser ce document et vérifier que les bonnes pratiques ont été respectées. Et j'adore le scripting, mais c'est très difficile d'atteindre tous ces objectifs, d'atteindre le même niveau de rigueur avec des scripts. Parce qu'à la fin, les scripts c'est quand même un être humain qui va les lancer, c'est un être humain qui va potentiellement les bidouiller, alors qu'avec CloudFormation et les autres technos comme on va le voir, c'est un outil qui va lancer la construction d'infrastructures. Et donc on va pouvoir appliquer sur cet outil les contrôles d'accès habituels, IAM, etc. C'est vraiment une étape. Si vous avez déjà l'infrastructure automatisée avec des scripts, c'est très bien. Si vous voulez passer au stade d'après, il faut que vous commenciez à travailler sur l'infrastructure as code. Les cas d'usage classiques, il y en a un qui est évident, c'est juste de construire autant d'environnements que nécessaire. Si vous avez défini ce qu'est un environnement pour un développeur, si vous voulez en construire 10, vous en construisez 10. Vous les créez le matin à 9h, vous les détruisez le soir et puis c'est tout. Donc vous pouvez, si un environnement c'est une instance EC2, un MySQL, un Bucket S3 et que sais-je, vous décrivez ça une bonne fois pour toutes dans un document et puis vous les rejouez autant de fois que nécessaire. Si ça, ça sert de modèle pour la pré-prod, très bien. Et puis si la prod, c'est la pré-prod x4, très bien. Vous changez les paramètres qui sont dans le document de la pré-prod, vous faites x4 et puis vous avez la même architecture sur votre prod. Donc il y a vraiment cette capacité à bâtir plein d'environnements qui est super intéressante. Un autre exemple, c'est évidemment déployer dans d'autres régions. Cet exemple-là, mais c'est un exemple que j'ai connu où on vous tombe dessus un lundi matin et on vous dit à quelle vitesse tu peux déployer l'infrastructure au Japon ou au Brésil. Même si vous avez des scripts, même si vous avez déjà un peu d'automatisation, c'est un vrai sujet, ça reste un vrai projet si vous n'avez rien et toute votre infrastructure a été construite à la main, bon courage. Si vous avez un document qui décrit l'infra, vous n'avez qu'à rejouer ce document dans une autre région et vous obtiendrez exactement le même résultat. Donc si vous avez des problématiques multi-régions et que vous voulez vous simplifier la vie, une fois de plus, cette approche-là est la bonne approche. On peut faire du Green-Blue Deployment. J'en ai parlé tout à l'heure, je ne vais pas l'expliquer, mais vous pouvez, un peu comme le fait de redéployer dans une région, construire plusieurs versions de votre infrastructure ou plusieurs versions d'une partie de votre infrastructure, faire des tests dessus et puis basculer quand vous êtes satisfait du fonctionnement. Et puis la dernière étape qui est quand même importante, c'est le disaster recovery. Si vous avez décrit votre infrastructure ou en tout cas les parties critiques de votre infrastructure et que vous avez un problème majeur soit à cause d'une erreur humaine soit à cause d'une panne peu importe, vous décidez de reconstruire soit dans cette région soit dans une autre région, vous avez gagné. Vous allez gagner des jours et peut-être même des semaines à remonter votre infrastructure. Donc toutes ces bonnes raisons méritent que l'infrastructure as code soit relativement indispensable à partir d'un certain niveau. Alors, première technologie dont j'ai envie de parler aujourd'hui, c'est CloudFormation. CloudFormation c'est vraiment un service fondamental. Je dis souvent que si vous faites du AWS et que vous n'utilisez pas du tout CloudFormation, vous passez à côté de 50% de l'élasticité et de l'automatisation du cloud. C'est vraiment un outil qui est d'autant plus fondamental qu'il est utilisé en interne par d'autres services. C'est-à-dire que quand vous faites du Elastic Beanstalk, vous utilisez CloudFormation pour construire l'infra. Quand vous faites du ECS avec Docker, vous utilisez un template CloudFormation pour construire le cluster, etc. Nous-mêmes, on s'appuie massivement sur CloudFormation pour créer l'infra de certains services. Donc on va décrire l'infra dans un document qu'on appelle un template. Pendant longtemps on a supporté que JSON et depuis quelques mois maintenant on peut également rédiger les templates en YAML. Et j'insiste, ce n'est pas un script ce qu'il y a à l'intérieur du template, on en verra des exemples tout à l'heure. Ce qu'il y a à l'intérieur du template c'est une description, ce n'est pas des commandes exécutables. Donc ce n'est pas un script qui exécute des API AWS, etc. C'est vraiment juste une description. Ce template a une structure un peu particulière, on va la voir tout à l'heure, où on définit les ressources AWS, les paramètres d'entrée, les valeurs de sortie, etc. Une fois que vous avez rédigé ce document, vous allez l'uploader dans le service CloudFormation, soit par la console, soit en ligne de commande, soit par SDK. Et CloudFormation va analyser ce template et construire la liste des ressources AWS que vous avez décrites. Combien ça coûte ? Rien. C'est un service que vous pouvez utiliser sans rien ajouter à votre facture AWS. Donc raison de plus pour le tester. Un petit dessin pour qu'on soit bien clair sur ce que fait CloudFormation. Vous écrivez un template ou vous aviez déjà écrit des templates et vous les réutilisez, ce qui est évidemment l'objectif. Vous les copiez dans un bucket S3 ou vous les upload directement à partir de la console. Vous les passez à CloudFormation qui va analyser le template, créer et configurer toutes les ressources qui sont spécifiées à l'intérieur. Donc c'est l'équivalent de cliquer pendant des heures dans la console et c'est vraiment répétable à l'infini. Vous passez le template, vous dites dans quelle région vous voulez l'exécuter, éventuellement les quelques paramètres qui ont été définis dans le template et puis vous laissez CloudFormation construire tout à votre place. Donc un template va avoir cette forme-là, c'est un document, ici j'ai travaillé plutôt avec des documents JSON avec quelques grandes catégories : metadata qui est juste un truc standard, un espèce de header qu'on trouve dans tous les templates. Parameters, qui vont être les paramètres du template, par exemple on verra tout à l'heure, on peut passer le nom de l'AMI à utiliser ou la taille des instances à créer ou le nom du security group à utiliser. On peut faire plein de choses comme ça. De manière symétrique, on a les outputs, donc ils vont être des résultats. Si vous voulez par exemple retourner l'adresse IP, le nom de domaine d'une instance qui a été créée pour votre utilisateur, vous allez faire de l'output. Ensuite, on a les ressources. C'est exactement ce que ça dit. C'est là qu'on va créer les instances EC2, les buckets, etc. Les clusters RDS, l'immense majorité des ressources et des services AWS sont disponibles dans CloudFormation. D'ailleurs, si vous suivez un peu l'actualité AWS, très régulièrement, il y a des nouvelles features qui sortent sur CloudFormation pour supporter encore plus finement tel ou tel service. Donc vraiment, on ne peut pas dire que 100% des ressources sont supportées dans CloudFormation. Je ne sais pas quel est le pourcentage exact, mais il est vraiment très très élevé. Et puis ensuite, il y a deux autres rubriques dont on parlera un peu moins aujourd'hui, qui sont les mappings, qui vont vous permettre de définir des tableaux de correspondance. On verra notamment que ça peut servir pour les AMI, ça permet de rendre les templates beaucoup plus génériques en évitant d'avoir des valeurs codées en dur. Par exemple, de dire que dans telle région, le numéro d'AMI c'est ça, dans telle autre région c'est ça, puis on pourra se référer au mapping pour aller extraire la bonne valeur quand on en aura besoin. Et puis les conditions qui sont là aussi, on pourrait dire si on est dans l'environnement de dev on fait ça, si on est dans l'environnement de prod on fait ça, etc. Donc on est en JSON, ce n'est pas un langage, il n'y a pas d'action programmatique, mais on peut avec quelques conditions rendre le template un petit peu plus dynamique. La ligne de commande, on va la regarder évidemment après, on va faire des démos. La ligne de commande est plutôt simple. Donc on a une commande qui s'appelle validate template, que je vous incite très très fortement à utiliser, qui va détecter tout un tas d'erreurs à l'intérieur de votre template. Bien sûr, si le JSON est incorrect, on va vous le dire. Si vous voulez faire une ressource qui n'existe pas, on va vous le dire, etc. Ce n'est vraiment pas une étape optionnelle de valider son template. Sinon, vous allez le balancer à CloudFormation et puis il va vous le recracher tout de suite en disant « Désolé, il y a des erreurs ». Et puis, les deux commandes les plus importantes, c'est sur un « create stack ». Vous voyez qu'on passe le fichier JSON, on passe le template qui décrit la stack que vous voulez créer et puis le nom de la stack. Un « delete stack » comme son nom l'indique qui va détruire une stack et toutes les ressources associées. Et puis on verra comment faire des updates aussi qui est quand même un truc important. Comment mettre à jour une stack puisque l'idée c'est de construire son infra de manière itérative, de la maintenir, de la mettre à jour, etc. Une fois que vous faites du CloudFormation, il n'est plus question de cliquer dans la console. Donc lorsque vous voulez faire des modifications sur un bout de l'infrastructure, sur une stack, vous le ferez en passant par des updates CloudFormation. Les change sets justement, on va les regarder, on va essayer de faire un petit exemple après. C'était un des, j'ose pas dire des points noirs de CloudFormation, mais c'était quand même un des trucs qui faisait réfléchir avant de l'utiliser. C'était que lorsqu'on faisait UpdateStack en particulier, on n'avait aucune idée de ce qui allait être modifié. C'est-à-dire que si on avait supprimé une ressource du template, CloudFormation allait la supprimer directement. Donc on n'avait finalement pas la capacité de faire un delta entre ce qui est présent dans la stack en prod là tout de suite et ce qu'il va y avoir après. Donc c'est ce que j'appelle le fire and forget. Donc on lançait l'update, on faisait des diff sur les templates, on regardait vraiment au niveau du document lui-même quelle différence il y avait. Mais bon, on pouvait se faire piéger, on pouvait se faire piéger et je pense qu'on a un certain nombre à se faire piéger. Donc le fire and forget de temps en temps c'était fire, new member, all your life, je pense qu'on a tous des exemples personnels cuisants de mise à jour de stack CloudFormation qui ne se sont pas bien passées. Donc pour régler ce problème, on a introduit les change sets. Donc les change sets c'est un ensemble d'API supplémentaires qui vont justement vous permettre de prévisualiser les changements que vous allez faire lorsque vous faites un update sur une stack. Donc là l'API est aussi assez simple, vous créez un change set, et vous le décrivez donc là il va vous lister les ressources impactées, etc, puis ensuite soit vous voulez l'appliquer, vous faites execute change set, soit vous voulez ne pas l'appliquer et le détruire, et vous faites delete change set. Donc par pitié, utilisez-les. Je croise encore des gens qui ne sont pas au courant de ce feature ou qui ne les utilisent pas de manière systématique, etc. Attention, l'update d'une stack ça peut être... Si c'est un environnement de dev, un environnement sur lequel il n'y a pas d'enjeu, au pire vous perdez un peu de temps, c'est pas grave. Si vous utilisez CloudFormation pour de la pré-prod ou pour de la prod, ça me paraît absolument indispensable d'utiliser les change sets. Si vous ne le faites pas, c'est à vos risques et périls. Voilà un petit exemple. On le verra après plutôt en démo, c'est plus intéressant. Donc on va prendre un ensemble d'exemples qui sont des différents templates, on va les mettre à jour, on va voir ce qui se passe. Vous pouvez trouver ça sur GitHub, c'est dans mon repo AWS dans lequel il y a tous mes trucs de démo. On va en avant. Ok, alors, là c'est les templates, vous devriez pouvoir trouver ça dans mon repo, vous trouverez les templates et puis il y a ça, il y a toute la démo en fait, je ne sais pas si on va faire tout ça aujourd'hui, ça paraît un peu long, mais voilà, là vous avez un ensemble de manipulations que vous pouvez faire pour vous entraîner et pour vérifier que ça fonctionne. Donc on va regarder un premier temps peut-être tout simple. Voilà donc c'est difficile de faire plus simple. Donc la section ressources, c'est là, où on voit quoi ? On voit une ressource qui s'appelle EC2 instance 0, ça c'est le nom que je lui ai donné. Elle est du type EC2 instance et puis elle a des propriétés. Donc elle a un numéro d'AMI, c'est du Amazon Linux, c'est une T2 micro, elle a une clé SSH qui est ma clé que j'appelle admin, puis elle a un security group qui s'appelle ping SG qui permet de pinger et d'ouvrir SSH. Et puis je lui ai ajouté un tag qui s'appelle name et qui porte la valeur CF instance 0. Et puis j'ai une section où je vais afficher l'adresse IP de l'instance que j'ai créée. Et donc vous voyez comment je fais ça. J'utilise une fonction de CloudFormation, quand vous voyez Fn là, ça veut dire qu'on appelle des fonctions. On a quelques fonctions qui permettent de manipuler le JSON. Donc getAttributes qui va récupérer l'attribute public IP de la ressource EC2 instance 0. Et puis pareil avec le nom de DNS. Donc comment est-ce qu'on exécute ça ? Déjà on va vérifier dans quelle région on est. On va se mettre en eu-central-1. Ah non parce qu'il me faut. C'est mon terminal, je fais des bêtises. Il me faut mon security group. Donc on va rester sur eu-west-1. Donc comment est-ce que j'exécute ça ? Alors il faudrait valider le template. Je vous remonte la commande. C'est la première commande que vous devez apprendre. Donc AWS CloudFormation. Valider le template avec la référence du template. Faisons-le. Voilà. Bon, OK. S'il ne vous dit rien, c'est que tout va bien. C'est que ce template, il est prêt à être lancé. OK ? Bon, et puis pour lancer le template, on y va. Donc, CloudFormation, CreateStack. Le nom du template, NewStackName. On va l'appeler template 0, on ne va pas être très original. Voilà, c'est tout. Donc là, j'ai un acquittement de JSON. Et donc là, j'ai envoyé mon template à CloudFormation. Et si je vais voir... ce qui se passe. Je retourne en Irlande et je vais aller voir ce qui se passe dans CloudFormation qui est là. Je vois donc ma stack qui est en train de s'éclater. Ok, si je peux voir à l'intérieur de ça les différents événements qui sont en train de se produire. Voilà donc je vois que j'ai lancé la création à 17h12, je vois que je suis en train de créer une ressource, etc. Ok donc là automatiquement CloudFormation va me créer toutes les ressources dont j'ai besoin. Et donc assez vite dans EC2, je devrais voir arriver mon instance qui s'appelle cf instance 0, il faut même peut-être la... Voilà, ok. Là vous voyez, il est en train de me créer mon instance. C'est une T2 micro, elle a la bonne AMI, elle a le bon security group. Et si je vais dans les outputs, je vois ce que je vais demander. Donc l'adresse IP, le nom de domaine. Donc voilà l'exemple tout simple. Et donc ça je peux le faire à volonté, dix fois, cent fois, autant fois que j'ai envie. Si j'ai envie de la détruire, le CloudFormation sert aussi à nettoyer, parfois même surtout à nettoyer. Je vais juste faire ça. Voilà, et c'est tout. Vous voyez qu'il n'y a pas de confirmation. Donc attention aux permissions IAM sur qui a le droit de faire « DeleteStack ». Sinon là aussi, vous allez avoir des soucis. Tout ça, c'est soumis à IAM. Et donc là, je vois l'opération inverse. Il fait « Delete in progress » et donc il va me détruire mon instance. Il va faire shutdown sur cette instance dès que possible. Et il va complètement détruire toutes les ressources qui sont allouées. On va laisser finir ça. On va faire autre chose en attendant. OK. Alors il y a d'autres petits appels, je ne vous les montre pas parce qu'ils ne sont pas passionnants. Vous pouvez décrire la stack, vous pouvez avoir le statut d'une stack, vous pouvez lister les événements d'une stack, vous pouvez récupérer le template associé à une stack, etc. Voilà c'est tout simple. Alors on va regarder un template un peu plus compliqué. A peine plus compliqué. Donc là, dans ce template-là, j'ai un mapping. C'est ce que je disais tout à l'heure. Donc je définis un tableau de correspondance entre le nom d'une région et l'AMI Amazon Linux présente dans cette région. Donc j'ai quelques régions AWS, elles ne sont pas toutes. Dans les ressources, j'ai une instance qui s'appelle instance 1 cette fois. Elle a des propriétés qui sont quoi ? Donc un identifiant d'image, et cette fois au lieu de mettre en dur un identifiant d'image comme tout à l'heure, ce qui n'est jamais une très bonne idée parce que du coup comme les AMI sont régionales, votre template il est plus générique d'une région à l'autre, eh bien au lieu de faire ça maintenant, je vais utiliser cette variable prédéfinie dans CloudFormation qui donne le nom de la région et je vais faire find in map pour aller chercher la bonne ID. Donc ça, ce petit bout de cette fonction-là de CloudFormation et puis finalement elle va me permettre, si je suis dans EU West 1, elle va me retourner ça. Donc les mappings et cette petite ruse-là, ça vous permet de rendre vos templates beaucoup plus indépendant et de les réutiliser dans différentes régions. Pour le reste c'est pareil, j'ai T2Micro, le même security group, etc. Et puis les paramètres. Donc vous avez compris, on va refaire Create Stack, ça on va l'appeler Template 1. Voilà. C'est parti. Donc on est reparti pour un tour, on va recréer une stack. L'autre était en train de s'effacer, voilà, elle a disparu. Là, j'en ai relancé une. Et donc comme je suis dans EU West 1, automatiquement, j'ai pris la bonne AMI. On va laisser faire ça tranquillement. Vous voyez, l'idée, c'est de regarder les stacks que CloudFormation exécute. C'est à peu près aussi intéressant de regarder les nouilles tuyaux. On les lance et on regarde plus ce qui se passe. Puis on va regarder, on va essayer de versionner, on va essayer de faire un update stack. Donc on a un template v2, on va regarder ce qu'il y a là-dedans. Alors qu'est-ce qu'on a ? Manifestement on a rajouté un paramètre donc on rentre on donne en paramètres le nom du security group qui va être attaché à l'instance c'est ça le mapping ça a l'air d'être le même voilà le security group au lieu d'être passé en dur il est passé dans un paramètre ok donc cette stack là on peut l'exécuter directement et puis que ça recréerait une deuxième stack CloudFormation. Ce qui est plus rigolo évidemment c'est de faire l'update. Donc on va faire ça, celle là est prête donc maintenant je vais mettre à jour ma stack, je vais exécuter cette commande là. Update stack avec le nom de la stack que j'ai construite et puis le nouveau template. Et là vous voyez c'est sans confirmation, c'est pour ça que je vous dis faire ça c'est dangereux, il vaut mieux utiliser les change sets parce que là j'ai lancé une mise à jour, si je me suis raté, je me suis raté. J'ai fermé Firefox, c'est pas mal. Donc là, je dois avoir ma stack qui doit être dans l'état « update in progress ». Puisque c'était une stack existante et je la mets à jour. Le point délicat, c'est qu'est-ce que j'ai fait comme mise à jour ? Parce que dans certains cas, imaginons que j'ai créé une deuxième instance. Il y avait une première instance qui tournait. Je rajoute une deuxième instance. Ce n'est pas disruptif pour la première instance qui était déjà là. Donc c'est un changement qui va être un changement additif. C'est très bien. Maintenant, si je... fais ce que j'ai fait là, ça va vous donner un bon exemple de ce qu'il ne faut pas faire. Qu'est-ce que j'ai fait dans ce changement si on regarde bien, je lui ai dit, je lui ai dit tu m'exécutes ça, il y a un paramètre, il a une valeur par défaut qui est default, qui est un security group par défaut et tu m'as ce changement sur la stack qui existe et je n'ai pas fourni le paramètre. Donc qu'est-ce que fait CloudFormation ? Il va prendre la valeur par défaut de ce paramètre. Donc il dit, ah ok, on me demande d'avoir une instance qui a un security group qui vaut default. Ok, très bien. Et bien là, j'ai déjà une ressource qui s'appelle EC2 instance 1 qui a un autre security group, celui que je lui ai assigné tout à l'heure, et il faut mettre à jour le security group. Il n'y a qu'une façon de faire ça, c'est de tuer l'instance et de la recréer avec le nouveau security group. Et vous voyez, à aucun moment, je n'ai eu une confirmation de ce truc-là. Donc, c'est vraiment pour illustrer ce que je vous disais tout à l'heure, faire la mise à jour, qu'est-ce qu'il a fait concrètement ? Il a recréé, il vous le dit là « Requested update requires the creation of a new physical resource. » Donc oui, j'ai toujours une instance EC2 qui s'appelle EC2 instance 1, mais ce n'est pas la même. Parce que j'ai fait un changement qui était un changement destructeur, et donc il a fallu recréer la ressource. Donc tout ça, c'est bien expliqué dans la doc de CloudFormation. On vous dit bien quels modifs sont additifs, quels modifs sont destructeurs. C'est un truc auquel il faut faire attention. Et donc du coup la bonne façon de faire cette manip, je vais juste vous la montrer, ça aurait été de faire ça, ça aurait été de faire ce qu'il y a là, de faire un change set. Donc j'aurais créé la stack template 1, comme tout à l'heure, je lui aurais dit crée-moi un change set sur la base de template 1v2.json. Donc là il analyse les différences qu'il va y avoir entre la stack existante et la future stack. Je vais les voir lorsque je vais faire describe change set. Donc là je vais avoir un document JSON qui va me lister les modifs et puis après je décide ou pas de faire l'execute. Et là effectivement on peut visualiser ce qui se passe et on voit s'il y a des créations, des suppressions. Donc j'insiste lourdement, c'est vraiment comme ça qu'il faut le faire maintenant, en utilisant les change sets, et pas comme ça. Si vous faites « create update sans change set », vous risquez de vous exposer à de graves désillusions. Et j'en ai eu. Je préférerais vous les éviter. Je vous montre un dernier exemple de template. Vous aurez de toute façon ces fichiers-là et vous pourrez rejouer les démos. Là, j'ai toujours mon mapping. J'ai toujours ma ressource. Je récupère son AMI via mon mapping. Et qu'est-ce que j'ai fait en plus ? J'ai créé un security group. C'est pour vous montrer un autre exemple de ressource. Une ressource qui s'appelle Web Security Group qui est du type AWS EC2 Security Group et qui va contenir deux règles qui autorisent le port 80 depuis partout HTTP et le port 22 depuis partout SSH. Toutes ces ressources sont bien décrites dans la doc, vous avez toutes ces informations, il faut bien lire. On s'y habitue assez vite et donc on peut décrire comme ça toute son infrastructure AWS et la créer automatiquement. On va juste lancer celle-là rapido. On va faire tout ça d'un coup, à voir si ça marche. Il faudrait que je détruise stack 1 d'abord. On va shooter celle-là. On va la laisser disparaître. Et puis on va faire la création complète. Je suis obligé d'attendre la fin parce que comme elle s'appelle template 1, si j'exécute des commandes alors qu'elle est encore là, ça va être un peu bon. Allez, dépêche-toi ! Allez ! Bon bah avance et on le fera après, c'est pas grave, on continue. Je vous ferai la manip après. Donc voilà pour CloudFormation. CloudFormation, c'est vraiment le service AWS. C'est le service AWS qui décrit finalement tous les autres services AWS. Je vous conseille très fortement de le regarder. Ça va même vous permettre de comprendre plein de choses sur la façon dont les ressources sont créées, sont dépendantes. C'est vraiment un très bon exercice de décrire des templates de CloudFormation. Ça vous permet vraiment de comprendre quel est le lien entre une instance ou Security Group, quel est le lien entre un VPC et son subnet, etc. Deuxième façon de faire les choses, Terraform. Une différence principale étant le langage dans lequel les documents sont rédigés. HashiCorp appelle ces documents des configurations et donc on les rédige dans un langage qui est propriétaire à HashiCorp, qui s'appelle le HCL. Vous irez voir sur leur GitHub pourquoi ils ont jugé nécessaire de recoder encore un langage. Ce n'est pas du YAML, ce n'est pas du Ruby, ce n'est pas du JSON, c'est quelque chose d'encore d'autre, mais qui est plutôt lisible et assez simple à utiliser. Un des avantages de Terraform, c'est qu'il ne supporte pas seulement AWS, il va supporter plein d'autres providers, cloud et SaaS. Par exemple, si vous voulez créer des repos GitHub, vous pouvez le faire avec Terraform. Si vous avez beaucoup de SaaS, l'utilisation de Terraform peut être intéressante pour unifier le provisioning de votre infra. Mais ne rêvez pas, ce n'est pas une couche d'abstraction pour le multicloud, et je mets des grosses guillemets autour de ça. Ça vous permet éventuellement de créer des ressources dans différents clouds et dans différents SaaS, mais ce n'est pas une API magique ou une surcouche magique sur je ne sais quoi. Alors moi ce que j'aime bien dans Terraform, il y a des grands débats philosophico-religieux sur Terraform versus CloudFormation versus encore d'autres trucs. Moi ce que j'aime bien et je vais vous montrer, c'est justement que c'est plus facile dans Terraform de voir les modifications et c'est facile de prendre en compte la dérive, c'est-à-dire que si votre infrastructure est modifiée en dehors de Terraform, vous pouvez rafraîchir Terraform avec les modifs qui ont été faites. Alors ça peut être pratique dans certains cas, ça peut être risqué également. C'est-à-dire que si quelqu'un est allé cliquer dans la console à modifier votre infra de manière incontrôlée et que vous la rafraîchissez, vous prenez en compte implicitement ces modifs. Là où CloudFormation vous dirait non, désolé, l'infra qui est là, elle n'est plus en ligne avec le template, je ne veux pas. Donc voilà, c'est 50-50, à vous de voir. La ligne de commande de Terraform est très simple, donc on va faire plan pour prévisualiser les changements, apply pour les appliquer, show pour voir ce qui tourne, plan-destroy pour prévisualiser la destruction et destroy pour l'effectuer. Ok ? Super simple. Alors, démo. Donc on va changer de repo. On va changer de répertoire par exemple. Donc on va commencer, un petit exemple tout simple. Voilà, ça c'est sans doute le minimum qu'on peut faire. Donc vous voyez, j'utilise le provider AWS. Il y a plusieurs produits qui sont supportés par Terraform, je crée une ressource qui est du type AWS instance que j'appelle MyFirstTerraformInstance avec une AMI, une TAI, etc. Un peu comme tout à l'heure. Donc ça, ce langage, c'est du HCL. Alors ça ressemble un peu à du Ruby mais pas complètement. À vous de vous faire une idée sur à quoi ça ressemble. Donc si j'ai envie d'appliquer ça, je vais faire Terraform plan. Il va réfléchir un peu et il va me dire, voilà en vert, vous voyez un plus, il va me dire voilà tu vas ajouter une ressource qui est une instance qui s'appelle MyFirstTerraformInstance, etc. Quand vous avez fourni un paramètre, il vous le donne explicitement. Pour le reste, computed, ça veut dire il va générer des valeurs. Si ça, ça vous va, vous faites Terraform Apply. Voilà, et là, il va créer les ressources. Et là, il ne passe pas par du CloudFormation. Derrière, c'est des appels d'API, etc. Donc, si vous allez dans la console CloudFormation, on est toujours en Irlande, on ne voit rien, on est d'accord, il n'y a pas d'activité de CloudFormation. Terraform, c'est une autre façon de faire les choses. Pour autant, si je vais voir un peu dans EC2, je dois voir mon instance qui s'appelle Terraform0, quelque chose comme ça. Terraform 1, elle est en train de s'initialiser. Elle a le security group, elle doit avoir la clé SSH, elle a tout ce qui va bien, je pourrais me loguer dessus etc. Et voilà c'est fait. Donc là il m'a créé ma ressource. Et vous voyez qu'il y a un fichier Terraform State qui est apparu. Il y a encore un fichier qui ressemble plutôt à du JSON, qui décrit l'effet des commandes qu'on a exécutées. Ne perdez pas ce fichier parce que c'est lui qui vous dit dans quel état est l'infrastructure que vous venez de créer. Si vous effacez ce fichier, il perd la mémoire et il perd le fait que cette instance-là, c'est bien celle qui a été créée. Donc on peut faire Terraform show, pour voir de manière un peu plus lisible ce qui a été créé, mais ça n'est qu'afficher le state. Et puis on peut faire Terraform show, et là il dit attention tu vas détruire cette ressource là. Oui ok c'est ce que j'ai envie de faire. Lui il a la gentillesse de vous demander de taper yes, ce que je trouve plutôt une bonne idée. Et puis, c'est pareil, il va shooter l'instance. Donc, on va le laisser faire ça. Il va détruire ma ressource. On va regarder un autre exemple. Un petit peu plus déroulé. J'ai une autre ressource, je crée une Elastic IP que j'attache à ma ressource. Certains vont vous dire non, on préfère JSON, c'est plus clair. D'autres vont vous dire non, on préfère ça, c'est plus clair. Après c'est vraiment une guerre de religion. Je préfère que chacun se fasse son opinion. Un dernier exemple, qu'est-ce qu'il y a dans celui-là ? Là il y a un peu plus, donc il faudrait qu'il arrête de m'enlever avec ce message. Donc là je crée une instance AWS que j'appelle MyFirstWebserver. J'ai une AMI, j'ai une clé, etc. J'ai un security group qui est créé en dessous. Voilà, qui est là. Ça y est, il a fini par détruire son truc, magnifique. On va réafficher ça parce qu'on ne voit rien. J'ai un security group qui est créé en bas. J'autorise 20, 80. Et puis, j'utilise ce que Terraform appelle des provisionneurs. C'est la capacité à exécuter des commandes. Là, je vais exécuter une commande locale sur ma machine pour récupérer l'adresse IP de l'instance que je viens de créer. Et je vais utiliser le remote exec provisionner pour exécuter des commandes sur l'instance. Donc ça c'est l'équivalent de ce qu'on ferait en user data par exemple sur l'instance. Et là vous voyez on peut aussi dans la configuration passer des commandes à exécuter directement sur l'instance avec une syntaxe qui est plutôt sympa. Donc en avant, Terraform plan. Donc là il me dit quoi ? Il me dit je vais créer une instance et je vais créer un security group. Oui c'est bien. Il va créer ça. C'est parti. On devrait voir ça dans la console rapidement. Voilà, on voit une instance qui est en train de démarrer. Ça doit être celle-là. Vous voyez, le principe est toujours le même. Après, c'est la ligne de commande qui change et puis c'est le langage de description qui change. Mais globalement, on fait à peu près la même chose. Voilà, donc mon Terraform Web Server, il est lancé. Je vais récupérer son IP. Je ne crois qu'il n'y en a pas encore. Allez, dépêche-toi. J'ai une autre instance sélectionnée quelque part. Voilà. Voilà, donc là il est en train d'exécuter le remote exec, donc on voit les mises à jour de package qui sont en train de se faire. Ça c'est le yum update que vous voyez là. Et donc mon terraform web server, il est à ce moment là. On va juste attendre qu'il ait terminé. Voilà, magnifique. Donc voilà comment je provisionne en une minute ou deux une machine, comment je lui fais exécuter des commandes, etc. Voilà Terraform. Il y a un million d'autres choses à montrer dans Terraform, mais on n'a pas le temps. Aujourd'hui, il faut que vous exploriez. Je vais juste vous montrer Troposphère en deux minutes. Alors Troposphère, on va quand même dire cinq secondes ce que c'est. Donc Troposphère, c'est un projet Open source sur GitHub et là on l'a l'idée un peu différente. Vous allez écrire du code Python super simple à mon avis qui va générer un template CloudFormation en JSON. Ok donc pour les gens qui veulent pas écrire de JSON qui sont allergiques à JSON, trop pour se faire une bonne alternative voilà. On va faire une démo tout de suite, vous allez voir c'est assez simple et ce que j'aime c'est que c'est vraiment naturel d'écrire et de débuter. Alors une toute petite démo. J'ai fait simple. J'ai installé Troposphère, c'est du Python. J'ai un paramètre qui est une paire de clés. C'est ça. Vous voyez là, on écrit du Python. C'est la bonne nouvelle. On ajoute tout ça au template, on crée un mapping, comme tout à l'heure, c'est presque le même exemple que tout à l'heure. On crée un template, on crée une ressource EC2 avec tous les paramètres, on l'ajoute au template, on définit des outputs, on les ajoute au template, etc. Et l'avantage c'est que c'est du Python. Donc si vous avez envie d'utiliser vos fonctions Python pour générer 10 instances différentes avec des noms différents, etc. Voilà, là c'est du code, c'est du vrai code. Et à la fin, tout simplement, faites ça. Et donc, si je le fais, tout simplement, si je prends, si j'exécute ce script, je redirige le résultat dans un fichier et j'ai un template CloudFormation, tout ce qu'il y a de plus normal. Vous voyez ça ressemble exactement à ce qu'on avait tout à l'heure. Et je prends ça, je le balance à CloudFormation et il me crée mes ressources. Après c'est du CloudFormation normal, la différence c'est qu'au lieu d'écrire ce JSON à la main, vous l'écrivez avec du code Python. Personnellement je préfère, mais après tous les goûts sont dans la nature. Si on résume, CloudFormation c'est un service AWS, Troposphère et Terraform sont des projets open source. Terraform est plus populaire, c'est pas facile. En termes de couverture des services AWS, CloudFormation est supérieur puisque c'est notre service maison. Il couvre quasiment tout, il est très à jour. Il est même utilisé en interne pour un certain nombre de services. Terraform est très à jour, il y a quelques trous noirs. Et Troposphère, il est très à jour sur la plupart des services. Les services les plus récents peuvent manquer. Les langages, donc JSON ou YAML pour CloudFormation, Python vers JSON pour Troposphère, et le fameux HCL pour Terraform. Les interfaces sur Terraform, c'est uniquement la ligne de commande, il n'y a pas de GUI. Les permissions d'accès, alors vous avez IAM pour CloudFormation et Troposphère, vous l'avez pas dans Terraform. Je crois savoir que dans leurs produits commerciaux, ils offrent des choses, mais je ne le connais pas, je ne peux pas en parler. Le refresh par rapport à de l'infrastructure existante est possible dans Terraform, il n'est pas permis par CloudFormation. La capacité à décrire des ressources existantes, elle est supportée plus ou moins par ces différentes solutions. Avec CloudFormation, on a une solution qui s'appelle CloudFormer. Je répondrai peut-être dans les questions, je suis sûr que j'aurai la question sur CloudFormer. Dans Terraform, il y a un autre projet open source qui s'appelle Terraforming et qui permet de générer une configuration Terraform à partir de ressources existantes. Le déploiement continu, vous pouvez intégrer CloudFormation avec CodePipeline, on en a rapidement parlé tout à l'heure. Avec Terraform, c'est à vous de construire quelque chose. Le preview, vous avez l'Exchange Set dans CloudFormation et le plan dans Terraform. Les rollbacks, vous pouvez les faire dans CloudFormation, vous ne pouvez pas les faire dans la version open source de Terraform. Là aussi, il me semble que dans la version commerciale, on peut le faire. La gestion, je veux déployer multi-comptes, multi-régions, etc. C'est bien supporté dans Terraform, on peut le faire dans CloudFormation avec Lambda. Puis voilà, quelques autres points, on a plein de ce qu'on appelle des quick start CloudFormation, qui sont des archives déjà définies, vous trouverez tout ça sur notre site. Et Terraform a une console interactive, que je ne vous ai pas montrée, qui permet de tester ces configurations de manière un peu interactive et de débugger. Après, je m'interdis d'avoir un avis définitif, je trouve que les trois ont des avantages et des inconvénients, mais c'est à vous de tester et c'est à vous de jouer. Donc on a vu comment créer l'infra. Maintenant on pourrait faire un troisième webinaire DevOps pour parler du reste, c'est-à-dire de comment on automatise la création des AMI, comment on automatise le provisionnement des services, etc. Donc là il y a plein d'autres outils que vous utilisez peut-être déjà pour le faire, ce n'est pas le sujet du jour, je vous ai juste mis les noms des outils, si vous ne les connaissez pas ça mérite d'être investigué, mais voilà le DevOps c'est vraiment entre une infra complètement manuelle et une infra complètement automatisée, il y a vraiment pas mal de travail, c'est un long voyage, mais tout est fait pour que vous puissiez y aller progressivement. Il faut que cette démarche-là soit itérative et que vous automatisiez progressivement et que progressivement vous fassiez monter le niveau de qualité, le niveau d'automatisation de votre infra. Donc avec tous ces outils, vous pouvez tout couvrir. On a vu tout à l'heure comment le faire sur les applis. Vous pouvez le faire avec Puppet, chef, etc. pour les services. Vous pouvez le faire avec les AMI, avec Aminator et Packer, et vous pouvez le faire avec l'infra sur CloudFormation, Terraform, Troposphère. Vraiment une grande quantité d'outils, je vous incite vraiment à jouer, c'est super intéressant. Et puis vous vous construirez votre propre opé. Voilà, plein d'autres ressources, je vous laisserai regarder tout ça. No User Group, j'en ai parlé tout à l'heure, mais je suis venu de remontrer ce slide quand même. N'hésitez pas à les rejoindre. Et puis nos prochains webinaires en mars et en avril sur EC2, les bases de données et puis sans doute plein d'autres sujets encore après avril. On est en train d'y réfléchir. Voilà, merci beaucoup. On va faire le petit sondage de satisfaction, Hugo. Comme d'habitude, tu l'as affiché. 5 c'est la meilleure note 1 c'est la moins bonne si vous êtes très content c'est 5 si vous êtes très fâché c'est 1 et je pense que Hugo va partager les slides aussi si ce n'est pas déjà fait vous avez les slides des deux webinaires dans lesquels vous aurez les liens sur GitHub etc tout ce que je vous ai montré et un peu plus est disponible là dedans. Vous pourrez jouer, vous pourrez découvrir tout ça. Et on va passer aux questions. On laisse le sondage encore un peu ? Non, ça y est. On fait les questions. Alors, on va essayer de le prendre un peu dans l'ordre. Alors, question d'Arnaud. Est-ce que CloudFormation permet de gérer absolument tous les services ou y en a-t-il certains qui ne sont pas gérés ? Alors, c'est ce que je disais tout à l'heure. Tous les services dont vous avez besoin, à mon avis, ils sont. Il y a des cas très particuliers de choses que nous, on appelle services, mais qui ne sont pas forcément visibles dans la console et qui ne sont pas non plus forcément décrits dans CloudFormation. Donc oui, maintenant, il n'y a aucun service qui sort sans qu'il soit pris en compte par CloudFormation. Ce qui peut arriver, c'est qu'un nouveau feature sorte sur un service et qu'il ne soit pas encore 100% supporté sur CloudFormation. Mais sincèrement, je trouve que cette situation-là a tendance à se produire de moins en moins. L'équipe de CloudFormation court très vite et je pense que même les équipes produits ont compris l'intérêt d'avoir CloudFormation dès le premier jour. Donc il peut toujours y avoir un trou, mais franchement la situation, c'est beaucoup, beaucoup mieux. Si vous en trouvez, si vous trouvez un truc qui manque et qui est vraiment bloquant, n'hésitez pas à me l'envoyer, je relierai l'info. Alors question de Benjamin, je voulais y répondre tout à l'heure et puis je me suis dit j'aurais la question. Alors comment ça se passe pour mettre à jour une base RDS avec CloudFormation ? Ça risque de détruire la base. C'est tout à fait ce que je disais tout à l'heure sur les updates qui sont additives ou destructrices. Ce que vous devez chercher quand vous regardez dans la cloud, c'est un truc qui s'appelle la « Deletion Policy ». C'est-à-dire qu'est-ce qui se passe quand on doit typiquement, en particulier sur RDS, certaines modifs sur une base RDS sont on va dire destructrices, alors destructrices dans le sens où on n'a pas d'autre choix que de recréer l'instance RDS. Donc déjà il faut bien lire la doc, il faut bien regarder si l'opération qu'on est en train de faire c'est juste une modif d'une instance existante ou si ça va provoquer la destruction et la recréation de l'instance. Donc ça c'est le premier point, bien lire la doc. Et le deuxième point c'est sur les ressources, regardez la Deletion Policy qui vous dit si jamais je dois détruire la ressource, qu'est-ce que je fais ? Donc par exemple dans le cas de RDS, on pouvait lui dire fais un snapshot, ce qui permet de recréer l'instance plus rapidement, je ne sais pas. Et puis ce qui surtout en cas de fausse manip limite la casse en disant merde j'ai détruit la ressource mais j'ai le snapshot, j'ai pas perdu les données. Ok ? Donc regardez beaucoup ça, ça s'appelle la Deletion Policy dans RDS et sur d'autres services. Alors comment sécuriser les droits d'utilisation de CloudFormation et Terraform ? Alors CloudFormation c'est IAM, c'est-à-dire que le droit d'exécuter une stack etc. etc. c'est soumis à IAM. Je vous laisserai regarder ça. C'est comme d'habitude, les actions, les ressources, etc. Pour Terraform, dans la version que je vous ai montrée là, il n'y a pas de notion de multi-dozer. C'est ce que je disais tout à l'heure, je crois que dans leurs produits commerciaux, ils supportent ce genre de choses, mais je ne l'ai pas essayé, je ne préfère pas en parler. Bon, après, on peut tout imaginer, mais si vous voulez le faire avec la version open source, ça passera par des droits d'accès sur Terraform lui-même ou des droits d'accès sur les stacks dans GitHub, enfin je ne sais pas, c'est un problème, c'est un des points qui me gêne un peu sur le Terraform open source, effectivement c'est l'absence de contrôle d'accès. Alors est-ce que les stacks CloudFormation et Terraform peuvent être exécutés par une fonction lambda. Alors CloudFormation, oui, vous pouvez dans une lambda, il y a une API CloudFormation que vous pouvez appeler et vous pouvez lancer la création d'une stack à partir de l'API CreateStack, dans lambda ou ailleurs d'ailleurs. Pour Terraform, c'est plus compliqué parce qu'il faut lancer le binaire Terraform, c'est un unique binaire, c'est en Go, c'est un gros binaire. On pourrait imaginer qu'il soit sur une instance et que vous déclenchiez le traitement, mais là aussi c'est moins intégré. L'un des avantages de CloudFormation par rapport à Terraform, c'est qu'il est très intégré avec les autres services, il est bien intégré avec Lambda, etc. C'est un point à garder en tête aussi. Alors est-ce que les erreurs d'exécution de CloudFormation sont visibles dans la console ? Vous pouvez décrire ces événements par la ligne de commande. Vous avez tous les événements. Tous les événements qui se sont produits dans la stack et s'il y a une erreur et que la stack a été rollbackée, je vois ce qui s'est passé, etc. Donc là, une fois de plus, on le voit dans la console et vous pouvez faire AWS CloudFormation, je crois que c'est describe stack events, un truc comme ça. Avec le nom de la stack. Et là, il va vous... Question d'Olivier, est-ce qu'on peut tester CloudFormation pour reconstruire un environnement qui aurait été corrompu ? Je pense que tu parles d'un environnement qui a été bricolé à la main ou qui a subi en tout cas une modification en dehors de CloudFormation. Le choix de design de CloudFormation, c'est de ne pas l'autoriser. C'est-à-dire que si l'environnement, si l'ensemble des ressources qui tournent ne colle pas au template et que vous essayez de faire une modif, CloudFormation va râler. Donc c'est vraiment indispensable avec CloudFormation que toutes les modifs soient faites par CloudFormation. C'est un choix, c'est vraiment un choix de dire on ne veut pas risquer d'intégrer des modifs a priori pas contrôlées sur une infra. Terraform a un choix différent, ce que je disais tout à l'heure, vous pouvez faire Terraform Refresh où il va aller relire ce qui tourne réellement, puis il va vous montrer les changements, et potentiellement les intégrer si vous souhaitez. Bon, voilà. Moi je suis partagé là-dessus. En tout cas avec CloudFormation, on ne peut pas le faire. Alors, est-ce qu'on peut intégrer CloudFormation dans un flux code pipeline ? Oui, tout à fait. Je l'ai montré rapidement tout à l'heure, mais une des actions possibles de code deploy c'est d'exécuter un template de CloudFormation. C'est comme ça qu'on peut faire du déploiement sur Docker par exemple. Je vous renvoie à l'article de blog que j'ai mentionné tout à l'heure. Alors qu'est-ce qu'on a d'autre ? Est-ce qu'il y a une interface graphique pour modéliser ? Alors oui, ça s'appelle de mémoire Cloud Designer, je ne l'utilise jamais pour être honnête. Est-ce qu'elle est dans la console CloudFormation ? Je ne l'utilise jamais parce que je préfère faire du JSON, je dois être un tordu. Vous la trouverez dans la doc, donc il y a un espèce de petit environnement graphique où effectivement on peut dessiner, on peut drag and dropper des ressources, les lier entre elles, etc. Mon avis là-dessus, c'est que c'est pas mal pour débuter, c'est pas mal pour se former, mais ça me paraît assez limité. Je n'ai jamais réussi à l'utiliser pour de la prod et pour des choses très sérieuses. Mais pour commencer, pourquoi pas. Donc cherchez « CloudFormation Designer ». Ça peut vous aider à démarrer et à comprendre un peu ce qui se passe. Alors question de Jean-Philippe, est-ce que Terraform permet de débuter une instance et d'y installer des packages ? Alors oui c'est ce que j'ai montré, c'est les fameux provisionneurs, donc on peut exécuter des commandes via C'est dans mon web-server là. Voilà mon remote-exec. Donc avec les provisionneurs de Terraform, on peut ici, vous voyez, exécuter des commandes et faire provisionner des packages au démarrage. Donc voilà. Il y a plein de sortes de provisionneurs différents. Je vais juste montrer remote-exec et local-exec. Alors local-exec, il m'a retourné l'IP de mon web-serveur. Il y en a plein d'autres. On a encore le temps pour 2-3 questions. Alors la question de Thomas. Mettre à jour le security group ne nécessite normalement pas de tuer l'instance EC2. Alors c'est vrai, mettre à jour le security group, c'est-à-dire changer les règles à l'intérieur du security group, ça ne nécessite pas de tuer l'instance mais là ce que je fais c'est que je change le security group. Je change le nom, c'est un nouveau security group et ça aujourd'hui ce n'est pas une action qu'on peut faire à chaud sur une instance et j'ai envie de dire tant mieux parce qu'il me semble que ça serait quand même un gros trou de sécurité. Donc c'est pour ça que dans la démo si je lui dis au lieu d'utiliser le security group ping tu utilises le security group default, il n'a pas d'autre choix que de tuer l'instance et de la recréer. Alors, qu'est-ce qu'on a d'autre ? Comment versionner les évolutions des templates avec les versions des applications ? Ça, c'est une question intéressante. Alors... Moi, j'ai envie de dire que ça devrait être assez orthogonal. Ce que je veux dire par là, c'est que le CloudFormation ou Terraform, ça va vous servir à construire l'infra. Vous voyez, vous allez créer vraiment de l'infra des ressources. Et puis, vous allez faire du code pipeline, du code deploy, etc. pour déployer vos applis. Mais de mon point de vue, c'est vraiment deux sujets qui sont séparés. C'est-à-dire que je répugne et je refuse d'utiliser CloudFormation pour déployer autre chose que de l'infra. Et on pourrait dans le user data des instances, on pourrait aller déclencher une action de déploiement d'applications, etc. Mais je trouve que c'est mélangé les genres. Et donc moi, ce que je vous conseille de faire, c'est d'avoir vraiment un process de déploiement d'infra vraiment l'infra pur et puis d'avoir un process de déploiement des applis et de bien les séparer et de versionner les templates de manière séparée et de surtout pas mélanger les deux sujets, ça me paraît dangereux. Alors, peut-on créer une stack avec Terraform et récupérer son code CloudFormation ? Alors non, parce que vous avez vu tout à l'heure que quand on crée des ressources avec Terraform, on n'appelle pas CloudFormation. Terraform n'est pas une surcouche de CloudFormation. Troposphère, oui, si on va par là, mais Terraform c'est vraiment une autre approche. Donc il y a peut-être un projet open source qui le fait, si c'est le cas, tenez-moi au courant, ça m'intéresse, mais je ne connais pas de solution pour, à partir d'une config Terraform, générer le JSON CloudFormation. Peut-être un gars qui a codé ça dans un coin, mais moi je ne le connais pas. Petite dernière Hugo ? Allez, juste une dernière, après il faut choisir encore un gagnant et se fâcher avec tout le monde. Ah, ça c'est bien. Ouais, c'est Lutte qui a gagné. Mickaël, la suppression d'une stack supprime toutes les ressources qui ont été créées par le template. Oui, l'idée c'est vraiment c'est tout ce que vous avez créé par le template vous allez le défaire et c'est ce que je disais tout à l'heure en rigolant mais CloudFormation c'est au moins aussi utile pour nettoyer que pour construire être sûr qu'on laisse rien derrière et du coup la question de Michael c'est bah oui mais si ce security group je l'ai associé à la main à une autre instance EC2 et bien tu n'arriveras pas à effacer la stack. C'est-à-dire que CloudFormation te dira, il te fera « delete failed » ou un truc comme ça, en te disant qu'il y a une dépendance, que tu as une dépendance entre la ressource Security Group et une autre ressource, il te dira laquelle, et il refusera d'effacer la stack. Donc l'idée, c'est quand même pas de casser l'infrastructure. Donc tout ça, une fois de plus, ça milite pour le fait que quand vous commencez à utiliser CloudFormation en tout cas le périmètre d'infrastructure qui est géré par CloudFormation il ne doit plus être géré que par CloudFormation si vous avez des bouts d'infra que vous continuez à gérer à la main à côté c'est pas un problème mais ne mélangez pas les deux parce que vous allez créer des dépendances dans les deux sens et vous allez dans ce cas là dans l'incapacité d'effacer vos stacks moi ça m'arrive tout le temps je rajoute un load balancer à la main devant mes instances EC2 et puis après quand je vais effacer il n'est pas content etc. Donc voilà le but de l'automatisation c'est d'automatiser et c'est de se débarrasser des opérations manuelles. Bon je crois qu'on est à court de temps donc je vais vous remercier, pour info on a battu le record de participants aujourd'hui, de beaucoup, je ne sais pas si on a droit de donner les chiffres je ne crois pas mais bon. Mais voilà, on a explosé le record aujourd'hui. Donc on est vraiment super super content de votre présence. Je salue aussi les gens que j'ai croisés à Law Sunday à Paris l'autre jour, qui m'ont fait des gentils commentaires sur le fait que c'était sympa de me voir en vrai. J'espère qu'ils n'étaient pas déçus. En tout cas, c'est vraiment un plaisir de faire ces webinars. Je vous rappelle, je vous donne rendez-vous en mars pour donc un deep dive assez violent sur EC2, on va bien s'amuser, et puis on va parler je crois de EC2 Systems Manager, qui est une des nouvelles annonces de re-invent, et en avril on parlera, je ne sais plus, de SQL Server, parce qu'on va obliger, et d'Athena ou de RDS, enfin je ne sais pas, ça ne me paraît pas encore bien clair sur le mois d'avril, mais on va y arriver, on va y arriver. Voilà, et puis... Bien sûr, n'oubliez pas, on a une chaîne YouTube que je peux vous montrer, qui s'appelle « Amazon Web Services France ». Donc, cherchez bien… Mon Dieu, j'ouvre YouTube. Je ne sais pas ce qui va se passer. Non, ça va. Donc, si vous cherchez « Amazon Web Services France », voilà, merci encore, merci de votre fidélité, merci pour toutes vos questions. Désolé à toutes les personnes à qui on n'a pas pu répondre, mais c'est vraiment, il faudrait qu'on y passe des nuits entières. N'hésitez pas à envoyer vos questions au support ou dans les forums AWS officiels où les gens répondent vraiment assez rapidement, vous trouverez vos réponses. Si vraiment vous êtes coincé, coincé, envoyez-moi un petit mail, mais je mets parfois du temps à répondre et je m'en excuse. Merci mille fois, à bientôt, rendez-vous en mars et bonne soirée.