Bien demarrer avec AWS CodeStar

Transcript

Bonjour à tous, très content de vous retrouver pour ce nouveau webinar de septembre. J'espère que la rentrée s'est bien passée. Aujourd'hui, nous allons parler d'un service récent qui s'appelle AWS CodeStar et qui va, comme vous allez le voir, vous permettre de démarrer des projets de développement extrêmement rapidement et simplement sur AWS en créant l'infrastructure nécessaire au déploiement de votre projet et en créant aussi automatiquement tout l'environnement d'intégration et de déploiement continu. Ce qui va vous permettre vraiment en quelques minutes d'avoir un environnement de travail complet et sérieux pour développer votre projet. Avant d'attaquer CodeStar, je voulais reparler un tout petit peu de sujets dont on a déjà parlé mais qui sont importants dans le contexte d'aujourd'hui. A savoir, parler un peu de l'approche DevOps et des services d'AWS qui vous permettent d'implémenter des process DevOps. Les avantages du DevOps ont déjà été expliqués de nombreuses fois. L'objectif du DevOps, c'est d'accélérer, de fluidifier la mise en production des applications et de passer d'un modèle où traditionnellement on mettait en production des applications une fois par mois, une fois tous les trimestres, ou parfois, hélas, une fois par an, à un modèle où on est capable, à chaque modification de code, donc à chaque commit, de pousser en production une version correctement testée. C'est vraiment ça l'objectif ultime. Bien sûr, en fonction de la maturité des entreprises, en fonction de l'outillage, etc., il y a tout un continuum de possibilités entre une fois par an et à chaque commit. Mais néanmoins, tout ce qui va vous permettre d'accélérer et d'amener en production plus rapidement vos nouveaux développements ou vos évolutions est avantageux. Ça vous permet d'accélérer le business, ça vous permet de tester plus vite, ça vous permet d'avoir plus vite le retour de vos utilisateurs et d'avoir dans la vraie vie le test de votre application, ça n'a que des avantages. Et bien sûr, le point essentiel là-dedans, c'est que tout le monde est d'accord pour aller plus vite, tout le monde est d'accord pour accélérer le processus de livraison, mais pas au prix de la qualité du code et pas au prix de la stabilité de la plateforme, pas au prix de sa sécurité, etc. Donc l'enjeu, c'est de mettre en place des processus qui certes permettent de mettre en production, de pousser en production des modifications dans les minutes ou les heures qui suivent leur commit, mais en garantissant un niveau de qualité, un niveau de sécurité via un processus de build maîtrisé, un processus de test unitaire maîtrisé et un processus de déploiement maîtrisé. Si c'est pour aller vite et sortir de la route à chaque fois, ça n'a pas un grand intérêt. Donc ce qu'il faut, c'est aller vite et rester sur la route. Et c'est l'objectif des services dont on va parler aujourd'hui. Alors je crois que c'était au mois de février, peut-être une erreur de ma part. On a animé deux webinars sur les services qu'on appelait à l'époque Code étoile, donc CodePipeline, CodeDeploy, CodeCommit, CodeBuild. Je vous renvoie aux vidéos de ces deux webinars. Ces services ont pour but de vous aider à bâtir des usines logicielles qui vont vous permettre, comme je le disais à l'instant, d'amener le plus vite possible en production les modifications de code, les évolutions, les évolutions fonctionnelles, les corrections de bugs, etc., tout en garantissant qu'un processus automatique est absolument respecté et appliqué à chaque modification. Et que toute modification qui ne passerait pas les tests ou cassera le build, évidemment, n'atterrit pas en production et n'a aucun impact sur la production. On va reparler rapidement de ces services-là. Je tenais avant ça à rappeler que bien sûr ces services peuvent s'intégrer avec la liste des services partenaires et des produits partenaires que vous voyez à l'écran. J'imagine que vous retrouvez la plupart des outils de votre propre usine logicielle. L'idée est bien sûr de vous aider à compléter et à améliorer votre usine et non pas de la remplacer. L'objectif des services Code étoile n'est pas de remplacer GitHub ou Travis, etc., mais pour les gens qui n'utilisent pas déjà ces services, de leur proposer sans doute une solution plus simple et plus scalable d'emblée. Pour les gens qui ont déjà des outils en place, de compléter leur jeu d'outils avec tel ou tel service AWS, en particulier CodePipeline, qui est le service de haut niveau qui va orchestrer votre usine logicielle et à l'intérieur duquel vous pouvez venir connecter tel ou tel service externe. Donc ne voyez pas cette panoplie de services AWS comme une série d'outils qui vont forcément remplacer ce que vous avez, peut-être, peut-être pas, à vous d'en décider, mais vraiment plutôt comme des services qui viennent compléter et améliorer, orchestrer l'ensemble de votre usine logicielle. Dans un processus traditionnel de déploiement, on va trouver au moins ces quatre grandes étapes, parfois plus, mais évidemment au moins quatre. Une première étape où on va aller récupérer des sources. Une deuxième étape où on va build ces sources, soit les compiler réellement si on a un langage compilé, soit les packager si on a un langage interprété. Mais en tout cas, une étape où on va transformer les sources en un artefact qu'on va pouvoir ensuite tester et déployer sur des serveurs. Ensuite, on va avoir une étape de test. Alors, de tests unitaires, de tests sécuritaires, de tests de charge, etc. Il peut y avoir, généralement même, il va y avoir plusieurs étapes de test, et le plus souvent en parallèle pour gagner du temps. Et puis enfin, il va y avoir une phase de déploiement. Ici, pour simplifier les choses, en production, mais bien sûr, on va le plus souvent déployer sur des environnements de production, pré-prod où on va compléter avec des tests de recettes utilisateurs, des tests manuels, des tests d'expérience utilisateur, etc. Et puis ensuite une phase de déploiement ultérieure avec une phase de production. Je vous avais montré ça dans les webinars de février et je vous renvoie à tout ça pour la démo de l'ensemble. La première phase, c'est de récupérer les sources. Ça se fait avec, en ce qui nous concerne, un service qui s'appelle CodeCommit. Donc CodeCommit, c'est ni plus ni moins qu'un service Git managé. L'objectif de CodeCommit, c'est de vous permettre de créer des repositories auxquelles vous allez accéder via votre client Git standard. L'avantage étant ici qu'on va stocker les objets Git dans S3, donc avec une durabilité élevée. On va les chiffrer automatiquement avec notre service KMS, dont j'avais également l'occasion de parler. Et surtout, votre repository va être au plus près de votre interface AWS. Si vous mettez vos sources sur GitHub, et on aime tous GitHub, et c'est un outil magnifique, il peut arriver que GitHub ait un incident de production et que vous ne puissiez plus ni commiter ni déployer, ce qui peut être assez gênant dans certains cas si vous avez un bug fix urgent à faire passer et que vous ne pouvez pas le faire parce que GitHub est inaccessible, c'est vraiment impactant. Donc l'idée n'est pas de remplacer GitHub, l'idée c'est de dire que vous avez la possibilité d'avoir un repository sécurisé, scalable, au plus près de votre infra, qui peut venir compléter ce que vous faites au quotidien sur GitHub et qui peut servir de point de déploiement vers vos instances ou vers votre infrastructure. Le service est vraiment super simple à utiliser. On l'utilisera avec Git tout à l'heure. Vous verrez qu'il n'y a pas de complexité particulière. L'étape suivante, c'est donc de build, donc de transformer les sources en un artefact qu'on va pouvoir tester et déployer, et c'est le rôle de CodeBuild. CodeBuild a été lancé à re:Invent, il va vous fournir des environnements de build managés, uniquement sur Linux pour l'instant, et donc vous allez pouvoir choisir l'environnement préinstallé, soit un environnement de base donc avec un Linux simple pour des applications natives par exemple, soit un environnement Java, soit un environnement Python, etc. Donc on va vous fournir, un peu comme dans Elastic Beanstalk, une plateforme avec un environnement et des outils préinstallés. Et ensuite, vous allez à partir de ça, récupérer vos sources et les build dans cet environnement, sans avoir à gérer l'infrastructure. Le script de build, vous pouvez le passer à l'invocation, en ligne, ou vous pouvez l'intégrer dans vos sources, dans un repository, via un fichier de configuration YAML dans lequel vous allez détailler les opérations de build. L'avantage de CodeBuild, c'est qu'on le paye uniquement à l'usage et en fonction des tailles d'environnement qui sont disponibles, les prix commencent à 1,5 cent par minute. C'est vraiment avantageux par rapport à une ferme d'instances EC2 qui vous servirait à faire du build et où finalement vous les payez à l'heure, même si vous avez sans doute vu que bientôt, à partir du 2 octobre, vous allez les payer à la seconde. Mais néanmoins, vous les payez quand même, même si vous ne les utilisez pas. Ici, dans un environnement CodeBuild, vous ne payez qu'à la minute de build. Donc inutile de maintenir des instances, inutile de payer pour de l'infra qui ne sert pas, et encore plus inutile d'avoir des serveurs dans le placard, ce qui est souvent le lot des environnements de développement avec une mauvaise clim, une seule prise électrique et une canalisation d'eau usée qui coule au-dessus et qui ne demande qu'à détruire tout votre travail. Donc vraiment CodeBuild est fait pour vous simplifier la vie, vous créez l'environnement, vous déployez vos sources, ça build et vous ne payez que la minute de build. L'étape suivante, c'est de passer les tests. Aujourd'hui, on n'a pas de service qui vous permet de faire ça. Il y a plein de services d'intégration continue qui sont disponibles. On en a vu quelques-uns tout à l'heure sur les services partenaires et avec CodePipeline, vous pourrez aisément intégrer Jenkins par exemple ou d'autres dans cette étape. Et bien sûr, continuez à utiliser votre précieuse base de tests unitaires telle qu'elle et sans avoir à changer la façon dont vous travaillez. Vous pourrez simplement l'intégrer dans le pipeline et vous assurer que le pipeline s'arrête si les tests ne passent pas. Et puis la dernière étape, c'est le déploiement, pas forcément en production. Je sais bien qu'on aime bien déployer en production directement, mais il est plutôt sage d'avoir des étapes préliminaires. On va pouvoir le faire avec CodeDeploy. CodeDeploy va vous permettre de déployer sur des instances EC2 et sur des serveurs physiques, ce que les gens ignorent le plus souvent. Et donc à condition qu'évidemment CodeDeploy puisse accéder à ces instances, vous serez en mesure de déployer de la même façon sur votre infra physique et sur votre infra cloud. Ce qui est intéressant, avoir un déployeur fiable, c'est souvent quelque chose de compliqué. Si vous avez des problèmes de déploiement sur vos serveurs physiques, CodeDeploy peut vous aider à régler ça, même si aujourd'hui vous n'êtes pas encore dans AWS. CodeDeploy, comme son nom l'indique, va prendre des artefacts versionnés qui auront été déposés dans S3 par votre outil de test unitaire. Il va les déployer sur des groupes de déploiement. Et des groupes de déploiement, ce sont des ensembles d'instances EC2 qui ont été tagguées avec un tag particulier. Pour qu'une instance appartienne à un groupe, il suffit qu'elle ait un tag. On peut déployer sur Linux ou sur Windows, on peut déployer dans EC2 ou sur site. On peut déployer sur des groupes d'autoscaling, pas forcément sur une liste explicite d'instances. Donc si vous avez un groupe d'autoscaling qui varie de 1 à 10 instances, quel que soit le nombre d'instances dans le groupe à l'instant T, CodeDeploy s'en sortira et déploiera sur les bonnes instances. On peut faire du GreenBlueDeployment, pour les gens qui aiment tester en parallèle différentes versions de leur application, faire un AB test en vrai, mettre peut-être 5% de trafic sur la nouvelle version et puis 95% sur l'ancienne, vérifier les métriques et ensuite progressivement basculer le trafic sur la nouvelle version, détruire l'ancien environnement, etc. On peut faire ça de manière complètement automatique avec CodeDeploy. Et point sympathique, CodeDeploy ne coûte rien à utiliser si vous déployez sur EC2. Si vous déployez sur des serveurs physiques, il y a un petit coût, mais qui est vraiment minime. Au-dessus de tout ça, on va avoir un pipeline. Donc on va avoir un chef d'orchestre qui va s'assurer qu'on passe toujours les étapes, toujours dans le même sens, etc. Vous allez pouvoir soit utiliser les services dont je viens de parler, soit venir brancher tel ou tel outil, tel ou tel service tiers que vous utilisez déjà. Le but, vous l'avez compris, c'est de constituer des pipelines. S3 va servir de point de passage pour les sources et pour les artefacts. Donc c'est dans S3 que finalement les différents éléments du pipeline vont communiquer. On peut créer ces pipelines bien sûr par API, mais on peut aussi les créer visuellement dans la console. C'est vraiment un process assez simple où, là aussi je vous l'avais montré, on construit son pipeline étape par étape. On met des flèches, on définit dans quel repository GitHub on va chercher les sources, etc. Donc on peut utiliser plein d'outils externes. Et puis vraiment le point clé de ce service, c'est de garantir un processus de déploiement unique, uniforme, et donc à chaque modification de source, à chaque commit, le pipeline garantit qu'on suivra toutes les étapes dans cet ordre, et que si une erreur se produit à telle ou telle étape, on n'ira pas plus loin. Donc il n'y a pas d'intervention humaine, il n'y a pas d'exception, même si on peut avoir une phase d'approbation manuelle, on peut demander à recevoir une notification pour approuver ou désapprouver un déploiement par exemple, mais de manière générale, les pipelines vont être automatiques et donc ils vont aller vite et ils feront pas d'exception. Le coût est extrêmement modique, on parle de 1$ par pipeline actif par mois, c'est tout. Vous voyez, ce sont des services qui sont économiques, CodeCommit coûte un peu en fonction du stockage, CodeBuild coûte à la minute de build, CodeDeploy ne coûte rien si vous déployez sur EC2 et CodePipeline coûte 1$ par mois par pipeline. Vous voyez, par rapport au coût d'une infra dans EC2 que vous auriez pu configurer à la main, gérer à la main avec des déploiements d'outils, etc., c'est infiniment moins cher. Ne parlons pas d'une infra de dev qui est dans le placard ou dans le Kajibi qui vous coûte beaucoup plus que ça, que ce soit en licence, en électricité, en maintenance, en temps perdu et en énervement quand ça marche pas. Le but de ces outils est de vous simplifier la vie, c'est de vous aider à automatiser. Il en manquait un sans doute, qui est finalement l'outil pour le développeur. Ce que je vous avais montré dans les webinars antérieurs, c'était comment utiliser ces différents services à la main, comment créer un pipeline, comment créer un groupe de déploiement, etc. Et certes, on pouvait l'automatiser avec CloudFormation, mais encore fallait-il développer les modèles CloudFormation pour créer son infra. Pour simplifier encore l'expérience de développement pour nos clients, on a développé ce nouveau service qui s'appelle CodeStar et qui va finalement faire automatiquement tout ce que je viens de dire, tout ce que je viens de décrire. Vous créez votre projet, créez les ressources AWS nécessaires, créez le pipeline d'intégration et de déploiement continu, tout ça complètement et on va le faire en quelques minutes. Vous allez voir qu'effectivement c'est tout simple. Donc c'est en quelques minutes lancer tout l'environnement nécessaire pour développer une appli en tel ou tel techno avec un pipeline, finalement une usine logicielle prête à servir. Et tout ça ne coûte rien. Donc c'est vraiment un outil de productivité. On va faire la démo dans deux minutes. Vous allez voir, l'intérêt est double. L'intérêt, c'est évidemment de mettre en œuvre un projet très vite, y compris un projet d'équipe, pas forcément un projet individuel. On peut s'en servir, on va dire au long cours pour gérer un projet, mais aussi on peut s'en servir juste comme accélérateur. C'est-à-dire, on dit voilà, moi je veux toutes les ressources pour mon projet web Python, clic, clic, clic, j'attends cinq minutes, j'ai tout. Et puis après, mon projet va vivre, je vais le scaler, il va grossir, etc. Et peut-être que je n'ai pas envie de le gérer avec CodeStar. Eh bien, on pourra supprimer le projet CodeStar, mais garder toutes les ressources créées par ce projet. Donc, vous cesserez finalement d'utiliser CodeStar, mais tout ce qui a été créé via CodeStar, y compris l'usine logicielle, continue à exister. Donc, c'est vraiment un accélérateur, un outil de productivité terrible, sans avoir à développer de template CloudFormation, ce dont j'imagine personne ne va se plaindre. Voilà à quoi ressemble CodeStar. Je vais vous parler un peu du process dans les grandes lignes et puis ensuite on va faire une démo. Un peu comme dans Lambda, un peu comme dans Beanstalk, on vous propose déjà des modèles d'applications, des styles applicatifs toutes prêtes. Donc là il y en a quelques unes à l'écran, mais il y en a bien d'autres. Vous allez choisir par exemple, je ne sais pas, une appli, vous voulez faire une appli Ruby qui tourne dans Beanstalk, qui est la première case à l'écran. Vous allez sélectionner ça et puis vous allez juste donner un nom au projet. Et donc ce modèle, comme vous le voyez ici, va vous créer un repository dans CodeCommit, il va vous créer un environnement CodeBuild, il va faire le déploiement avec CloudFormation et il va mettre en place le monitoring via CloudWatch. Donc on va lancer ça, on va attendre quelques minutes. Pendant ce temps-là, on va configurer nos outils de développement pour pouvoir accéder aisément aux repositories. On peut le faire avec Visual Studio, on peut le faire avec Eclipse, on peut le faire en ligne de commande. Moi, j'aime bien la ligne de commande, donc on fera avec la ligne de commande. En gros, il y a un peu de configuration pour que votre client Git puisse accéder via HTTPS ou via SSH au repository CodeCommit. Ce n'est pas très compliqué. On vous donne toutes les instructions pour le faire. Moi, je l'ai déjà fait. On ne perdra pas de temps avec ça. Et puis ensuite, vous pourrez cloner le repository CodeCommit qui est créé, donc le cloner sur votre machine, et commencer à travailler. Une fois que CodeStar a créé toutes vos ressources, vous avez un dashboard qui vous donne, vous le voyez dans la petite barre d'icône à gauche, qui vous permet d'accéder aisément à votre repository de code, à l'environnement de build, à l'environnement de déploiement, au pipeline, etc. Vous pourrez donner accès au projet à d'autres personnes de votre équipe. Et vous pourrez ajouter, j'en parlerai à la fin, une connexion à Jira pour intégrer CodeStar, intégrer le projet avec la gestion de vos tickets. Et donc une fois que tout ça est prêt, on va travailler comme on travaille d'habitude. On va cloner le repo, on va faire des modifs de code, on va les pousser. Et on va faire la démo dans deux minutes. On verra, évidemment, le code qui s'exécute, le build qui s'exécute, etc. Donc, vraiment, vous voyez, finalement, c'est la couche, c'est l'outil développeur qui nous manquait. On avait CodePipeline pour orchestrer l'intégration et le développement continu, et là maintenant on a rajouté cet outil qui va vous permettre de créer vos projets et de provisionner l'infra du projet et l'outillage du projet en quelques minutes. Alors allons-y, je pense qu'il faut le mieux faire une petite démo maintenant. Alors oui, peut-être avant de faire la démo et avant que j'oublie, le service est disponible. Là, on est sur la fameuse page qui vous indique la disponibilité des services dans nos différentes régions. Ici, j'ai mis les régions européennes. Et si je descends un peu, vous voyez ici que toute la famille Code étoile est disponible dans les trois régions européennes. Une fois n'est pas coutume, vous pourrez intégralement travailler dans la région allemande ou la région irlandaise ou la région londonienne. Et vous aurez tous ces outils. Donc ça c'est quand même plutôt une bonne nouvelle aussi. Bien, on va créer un premier projet. Allons-y. Donc voilà la console de CodeStar. Alors vous pouvez le faire, si vous avez envie de le faire en même temps que moi, pourquoi pas. Vous avez votre console AWS sous les yeux, allez-y. Vous allez voir, je ne vais pas aller trop vite. Donc si vous le voyez, si vous allez dans l'écran CodeStar pour la première fois, vous voyez sûrement un petit truc qui vous dit bonjour, bienvenue, etc. Bon, évidemment, comme j'ai déjà joué avec, je ne le vois pas. Et on va y aller, on va créer un projet tout de suite. Donc voilà l'ensemble... Je vais peut-être me mettre en plein écran, ça sera mieux. Voilà l'ensemble des modèles qui existent. Donc vous voyez qu'on a du C#, du Java, du Node, du PHP. Ça fera plaisir aux développeurs PHP. Jérôme, je parie que tu es là. Donc voilà Jérôme, tu peux faire du PHP avec CodeStar, on ne t'a pas oublié. Salut Amical, bien sûr. On peut faire du Python et on peut faire du Ruby. Et on peut aussi faire du HTML5, puisqu'on a la capacité de déployer un site statique. C'est un peu dommage, on le déploie sur EC2. Je trouve que ça aurait été plus pertinent de déployer un site statique sur S3, parce que vous savez qu'on peut faire ça, utiliser un bucket S3 pour héberger un site statique. Peut-être dans une future version. N'hésitez pas à réclamer le feature si vous en avez besoin. Ensuite, en termes d'environnement, on peut déployer sur Elastic Beanstalk, on peut déployer sur EC2 et on peut déployer sur Lambda. Et en termes d'application, je dirais qu'aujourd'hui, on a fait les choix les plus raisonnables qui sont des applis web, des web services, donc un site web statique, comme je l'ai dit à l'instant, et un skill Alexa, on fera ça pendant le deuxième webinar. On prétextera l'utilisation de CodeStar pour faire un petit tuto Alexa parce qu'on n'en a jamais parlé pour l'instant et j'avais envie d'en parler aujourd'hui. J'ai amené mon écho et on fera un peu de CodeStar et puis beaucoup d'Alexa. Donc si Alexa vous amuse, restez pour le deuxième webinar. Dans l'immédiat, on va faire du PHP. Pour une fois, on n'est pas coutume. Mais voilà, vous êtes libres de faire autre chose. Qu'est-ce qu'on va faire ? Qu'est-ce qu'on a comme choix PHP ? On va regarder là. On va prendre PHP Slim sur EC2. Voilà. On va donner un nom à ce projet, pourquoi pas PHP Project. Et donc ici, je vois qu'on va créer un repository, on va créer un environnement de déploiement et on va gérer, on va monitorer avec CloudWatch l'instance, puisqu'ici on va déployer sur l'instance EC2. Donc manifestement, ici, on a le droit de changer les choses. On peut choisir la taille de l'instance. Ce qui est sympathique. Voilà, on peut choisir le subnet, le VPC, enfin les choix habituels. OK. Bon, on va rester sur une T2 micro parce que je suspecte que cette application-là ne soit pas bien lourde. Donc, next. Une petite paire de clés pour évidemment se connecter sur l'instance SSH. OK. OK. Voilà, et c'est parti. Donc on voit en haut à droite l'avancement. Donc on va vite aller voir rapidement sous le capot. Je suspecte qu'il se passe des choses en CloudFormation. Voilà, ok. Donc pour les gens qui n'ont jamais entendu parler de CloudFormation, il doit bien en rester quelques-uns. CloudFormation, c'est une technologie AWS qu'on appelle Infrastructure as Code et qui vous permet de décrire votre infrastructure dans un document qu'on appelle en bon français un template que vous pouvez écrire soit en JSON soit en YAML. Ici je sélectionne la stack. Je peux voir le template qui est en train d'être exécuté. Et manifestement ici, c'est du YAML, ce qui est une bonne nouvelle, c'est quand même un peu plus lisible que JSON. Donc vous voyez, ça c'est CodeStar qui fait ce travail à votre place, qui va donc créer, qui a construit ce template, et qui l'applique via CloudFormation. On voit qu'on va installer des outils, on installe l'agent CodeDeploy, etc. À la limite, tout ça, on s'en fiche, on n'a pas besoin de le voir. J'aime bien regarder sous le capot. Et bien sûr, ça se passe avec CloudFormation. Et sans surprise, on doit être en train de créer tout ce qu'il faut. Donc, un projet CodeStar, on a créé un security group pour l'instance et puis plus tard on va créer l'instance, on va être en train de faire ça à un moment ou un autre. On a créé un bucket S3 parce que comme je dis tout à l'heure, la communication entre CodeDeploy et les autres CodePipeline va se faire via un bucket S3. Mais une fois de plus, on n'a pas besoin de voir ça, c'est juste par curiosité. Nous, on pourrait tout à fait se contenter de rester là et de dire on va attendre que ce truc arrive à 100%. Alors comme je disais tout à l'heure, on va configurer notre environnement, notre outil pour avoir accès au repository. Alors en fonction, je ne vais pas vous faire le déroulé de toutes ces étapes, c'est bien expliqué dans la doc. Il est même possible si vous utilisez déjà CodeCommit, en fait, que vous l'ayez déjà, voilà, que vous l'ayez déjà fait, pour ce qui concerne l'utilisation d'un client Git en ligne de commande, ça revient exactement à ça. Donc en fait, ce qu'il faut, c'est créer un utilisateur IAM qui va avoir la permission d'accéder à CodeCommit. Et si je l'ai ici quelque part, voilà, de... Vous allez modifier votre config SSH pour utiliser un user AWS. Là, je vais très vite. C'est une fois de plus pour vous montrer que sans doute vous avez déjà cette configuration en place si vous utilisez CodeCommit. Personnellement, je n'ai pas eu besoin de rajouter quoi que ce soit. Si vous ne l'avez jamais fait, pas de souci. Vous suivez les instructions et c'est bon. Donc moi, je vais récupérer l'URL de mon repository. Ok. Donc je vais faire juste skip de ça. On va attendre que ça se termine. Voilà, ça ne devrait pas tarder. On va regarder dans CodeCommit un peu où on en est. Alors ça, c'est un vieux repository. Voilà, phppro. Donc manifestement mon repository a déjà été créé. Donc ça c'est l'interface de CodeCommit. Donc j'ai déjà un squelette d'application de web service PHP qui est déjà installé. Et on va le cloner. Voilà. Voilà, ça c'est fait. OK, on va voir un peu où on est notre ami ici. Ça se termine. OK, donc là, maintenant, ça, j'en ai pas besoin pour l'instant, mais... Voilà, 97%, on y est presque. Oui, bien sûr, tout ça, c'est aussi automatisable. C'est-à-dire que là, je le fais via la console. Mais si vous aviez besoin de créer 50 projets, 50 projets pour 50 développeurs différents et construire comme ça leur infrastructure de dev, bien sûr, vous pouvez le faire en API. Donc voilà mon projet. Je pense que là, il doit se passer des choses dans les CRC. Je ne sais pas, on va regarder un peu ce qu'il y a dans ce truc-là. Ah ben non, il y avait index.php. Alors voilà, index.php, oui, c'est Hello World. C'est Hello World. OK, donc c'est un web service qui fait Hello World, pourquoi pas. Et donc, il doit être déployé à ce stade. On va fermer ce truc de welcome. Voilà. Mes outils, je les ai désconnectés. Merci. Et donc là, je vois ma console, mon dashboard CodeStar. OK ? Donc, par défaut, on a un petit wiki qu'on peut éditer. OK ? Donc, c'est du markdown. On peut le modifier. OK ? On peut changer ce qu'on a envie de changer là-dedans. Une petite présentation du projet. On a une petite fenêtre qui nous donne l'historique des commits sur ce projet-là. On peut avoir évidemment plusieurs branches. On peut aller voir plus en détail ce qui se passe dans le code commit. L'activité de l'application, ici, elle est en cours de déploiement. Pour l'instant, il ne se passe pas grand-chose. Si j'avais une interconnection avec Jira, je vois que là j'ai un petit peu d'activité sur mon instance, donc le déploiement doit être en cours. Si j'avais une interconnection avec Jira, je pourrais voir mes tickets Jira ici. L'intégration se fait via l'extension qui est là. Et je le dirai tout à l'heure, mais vous pouvez avoir accès à une licence Jira gratuite dans le cadre d'un partenariat avec Atlassian. Ce qui est le plus intéressant, c'est de voir ça. On voit ce pipeline qui est en cours d'exécution. Complètement automatiquement, l'infrastructure qui a été créée par CodeStar va récupérer dans CodeCommit les sources existantes et est en train de les déployer. Ici, j'ai mon NBP. Je vais laisser le déploiement se faire. Et ça, évidemment, c'est une instance AWS. On va voir si c'est déjà prêt ou pas. On est peut-être un peu trop impatient. On est un peu trop impatient, donc on va attendre que ça se termine. On va essayer de se connecter sur l'instance pour voir. Donc, oui, EC2 user. Ah oui, alors ça, ça ne va pas fonctionner. Voilà. Donc, bien sûr, toutes les ressources qui sont créées, ce sont des ressources normales. Donc là, on est sur une instance EC2. Voilà, on se connecte dessus. Voilà. Et on fait ce qu'on a à y faire d'habitude. Ce n'est pas parce que c'est créé par CodeStar que les choses se passent de manière différente. Donc ça doit être quelque part dans varw, je navigue un peu au pif, html, index.php, voilà. Donc là, je vais retrouver mes sources qui ont été déployées, et puis il doit y avoir un petit serveur web qui va se mettre à tourner un moment. Si CodeDeploy a fini son travail. On va attendre encore un petit peu. C'est une toute petite instance, une T2 micro, donc il faut être un petit peu patient. On va essayer de recharger cette page pour voir. Il faudrait que ça dise Hello World à un moment. Voilà. Donc manifestement, c'est un peu petit, mais vous voyez. Donc ce n'est pas l'application web la plus intelligente. Mais je ne vois pas le serveur, je ne sais pas où il est. Il doit être en bas. Voilà. Donc, de manière complètement automatique, j'ai configuré mon infrastructure. Et automatiquement, j'ai créé mon instance EC2, que sans doute je vois là, dans la console EC2. Si je la rechargeais, où est-ce qu'elle est ? J'ai mon instance EC2, j'ai déployé mon code, etc. Vous voyez, c'est vraiment complètement automatique. Si j'avais voulu faire ça à l'ancienne, j'aurais créé mon pile, j'aurais créé mes outils, j'aurais créé tout ça, j'aurais démarré mon instance, j'aurais créé un groupe de déploiement dans CodeDeploy. Oui alors je l'aurais fait, c'est exactement ce que j'avais fait la dernière fois. Ou alors j'aurais écrit un template CloudFormation pour faire tout ça et j'y serais très bien arrivé. Mais c'est aussi sympa finalement de rien faire. Où est-ce qu'elle est cette T2 micro ? Voilà, celle-là, elle est déterminée. Donc ça, c'est bien mon instance. C'est une instance EC2, vous voyez, je me suis connecté dessus et je la gère comme ça. Et si j'avais du travail à y faire, indépendamment de mon projet CodeStar, je pourrais faire comme ce que je fais aujourd'hui, me connecter dessus et travailler. OK ? Bon, donc ça c'est bien, mais ça c'est que le déploiement initial. Donc bien sûr, ce qu'on a envie de faire, c'est de faire des modifications. On va faire des modifications. On va faire des modifications majeures. Voilà, tout à fait fondamental. Ok, donc je vais changer ça. Ok. Je vais donc committer mon changement. Et donc je vais regarder un peu mon remote. Ok, donc je vais bien committer sur CodeCommit. Voilà, magnifique. C'est pour ça que vous avez besoin d'avoir une configuration SSH aussi, il n'y a pas d'authentification là, parce que, évidemment, je commit via SSH et je commit via la configuration SSH que je vous ai montrée tout à l'heure. Mais une fois de plus, c'est bien expliqué dans la doc, donc pas de soucis. Si je vais voir un peu dans CodeCommit, j'imagine que je vois ma modif. J'espère. Voilà. Donc je vois le commit qui a été fait. Je peux voir les différences. Si vous n'avez jamais vu CodeCommit, voilà l'outil. Rien de très surprenant, mais juste de quoi faire le boulot, finalement. Il y a un petit... Alors, évidemment, là, il n'y a pas grand-chose à voir, mais s'il y avait des branches, on verrait les branches. Enfin, on peut visualiser les commits, etc. Donc ça, j'imagine que ça doit redéclencher quelque chose dans CodeStar, automatiquement. Automatiquement, j'ai une intégration entre CodeCommit et CodePipeline. CodePipeline détecte qu'un nouveau commit a été fait. On repart pour un tour, on récupère les sources. Ici, on fait directement le déploiement, il n'y a pas d'étape de build. Vous voyez que dans mon dashboard, je vois l'historique de mon commit, etc. On va laisser faire ça. Pendant qu'il fait ça, je vais vous montrer la gestion des utilisateurs. Ici, je n'ai rien que moi, mais je pourrais tout à fait créer d'autres utilisateurs. Je pourrais créer un nouvel utilisateur IAM. Ici, j'ai mes utilisateurs existants. Ou je pourrais dire que tiens, Spark User, tiens. Il a le droit de contribuer à mon projet. Et c'est bon. Il faudrait évidemment qu'il gère sa configuration SSH, etc. Mais voilà, via IAM, finalement, vous allez pouvoir... On pourrait lui autoriser l'accès SSH. Et vous allez pouvoir rajouter comme ça des utilisateurs. Alors évidemment il faut qu'ils soient à l'intérieur du même compte, ça reste toujours la même histoire. Mais si vous avez un compte pour vos développeurs, eh bien voilà, aisément vous pouvez rajouter les nouveaux utilisateurs et leur donner accès. Alors après ces raccourcis là, ils vont tout simplement ouvrir, alors ici on va revenir je crois sur ma page CodeCommit, donc, je vais voir le code commit du projet. Là, je vais voir le code deploy du projet. Et là, je vais voir le code pipeline du projet, tout simplement. Voilà. Donc là, je vois à nouveau mon repo, j'imagine. Allez. Voilà. Voilà. Donc, c'est ce que je voulais vous montrer tout à l'heure. C'est vraiment juste des raccourcis sur les environnements du projet. Donc là, je dois avoir le code deploy. Donc je vois que le déploiement est terminé. Je pourrais avoir l'historique des révisions qui ont été déployées. Enfin là, c'est code deploy tel que vous le connaissez sûrement déjà. On pourrait voir qu'un déploiement a échoué, on pourrait accéder aux logs des instances, etc. Et puis, code pipeline, on va sans trop de surprises, on voit finalement le pipeline extrêmement simple qu'on a ici, où on ajuste finalement deux étapes. Là, je pense, on va voir qu'on récupère les sources dans CodeCommit. Ok, donc on voit qu'elles sont dans CodeCommit, que c'est la branche master. On les récupère, on crée un artefact dans S3 qui s'appelle comme ça, etc. On les passe à code deploy, etc. Il faut être plus. On a regardé tout ça en détail dans des webinaires précédents, donc je ne passe pas trop de temps dessus. Donc j'imagine que ma modif est terminée, que mon... On va regarder mon dashboard, qu'elle est déployée. Voilà, elle est déployée. Et donc si je recharge ma page, j'espère bien que mon message a changé. Voilà. Je ne suis pas un grand développeur PHP, mais ça, j'ai réussi à le faire. Voilà ce que je peux dire comme introduction à CodeStar. Et peut-être juste pour terminer, vous pouvez détruire le projet. Voilà. Ici, je vois toutes les ressources du projet. Je peux l'effacer. Il y a quand même une vérification pour éviter de faire des âneries. Et j'ai la possibilité, comme je le disais en introduction, de garder toutes les ressources qui sont associées au projet. Si c'était vraiment juste un test rapide, bien sûr, vous avez sûrement envie de tout effacer. Ici, c'est ce qu'on va faire. Dire non tu gardes rien tu détruis tout mais si vous avez envie de vous servir de CodeStar comme d'un outil pour démarrer rapidement vos projets pour bootstraper les environnements etc et bien à ce moment-là moi je vous conseille évidemment de cliquer dans cette case vous allez supprimer le projet CodeStar tel quel tel qu'on l'a vu là mais vous allez garder toutes les ressources donc là dans mon exemple ici l'instance EC2 resterait là tout l'environnement code code pipeline, code build resterait là, etc. Ce que je trouve sympa. C'est vraiment une façon simple de dire, allez, avec CloudFormation, construis-moi tout, mais je ne veux même pas avoir CloudFormation. Et puis ensuite, on travaille un peu. Et si on veut garder le projet CodeStar, s'il est utile, très bien. Si on ne veut pas s'en servir comme ça, on ne le garde pas. C'est un petit conseil que je peux vous donner. Donc ici, on va lui dire, allez, tu détruis tout, delete. Donc, le projet, lui, disparaît très vite. Et ça, ça va disparaître. Et bien sûr, dans CloudFormation, on voit « Delete and Progress ». Et il va faire le chemin inverse. Et il va aller supprimer l'instance EC2. Il va aller supprimer le pipeline. Enfin, tout ce qu'on a vu. Tout ça va être supprimé au fil de l'eau. Voilà. En quelques minutes. Je ne sais pas s'il est déjà en train de tuer là. Peut-être pas tout de suite, non pas tout de suite mais ça va pas tarder. Donc il va nettoyer et détruire proprement tout ça. CloudFormation je dis toujours c'est bien pour construire mais c'est bien pour nettoyer. Imaginez que vous ayez 100 développeurs qui chacun travaillent sur leur environnement, leurs branches ou leurs propres petits bouts d'appli. Vous n'avez pas envie d'aller nettoyer derrière eux en permanence. Comme ça vous êtes sûr que tout est détruit et qu'il reste rien de ces environnements temporaires. Voilà donc ça va se nettoyer tranquillement. Je pense qu'on est à peu près dans les temps. Ça va ? On est en retard ? Une fois de plus. Donc on va en rester là pour ce premier webinar. Que voulais-je vous dire d'autre ? Oui, je voulais vous annoncer que la semaine du 11 au 15 décembre, je vous prends bien à l'avance comme ça vous pouvez bloquer les dates dans vos agendas, donc dans la semaine du 11 au 15 nous allons animer une série de webinars spéciaux et dédiés au machine learning et deep learning, un peu à l'instar de ce qu'on avait fait comme sur la Security Week l'année dernière. On avait animé je crois 10 webinars en 5 jours sur la sécurité. Là on va refaire la même chose mais cette fois 10 webinars avec machine learning, deep learning et les inévitables nouveautés de reInvent sur ces sujets. Donc pensez à... Oui on aura quelques invités, on devrait avoir une intervention de NVIDIA, on devrait avoir des clients aussi probablement. Tout ça est encore un peu à confirmer. Mais on essaie de vous faire un truc sympa, un vrai parcours d'introduction et de progression sur machine learning, deep learning, avec les services AWS et des outils open source comme MXNet et peut-être d'autres si j'ai le temps d'en parler. Voilà, donc notez bien les dates du 11 au 15 décembre. C'est notre cadeau de Noël. Vous aurez tout ça. Que dire d'autre ? Je crois qu'Hugo va afficher le sondage. Voilà, comme d'habitude, ne vous trompez pas, 5 est la meilleure note, 1 est la moins bonne note. On va vous laisser quelques minutes pour voter. N'hésitez pas à envoyer toutes vos questions. Vous avez l'habitude maintenant. Je pense qu'on va y répondre pendant le deuxième webinaire. On va garder du temps pour le faire, parce qu'on est déjà en retard. Donc, voilà. Posez toutes vos questions. Hugo les centralise, il me les prépare pendant le deuxième webinaire. Et puis, j'y répondrai ensuite. OK ? Et on choisira des gagnants et on fera gagner encore des goodies. Vous pourrez vous battre pour les chaussettes lambda et des t-shirts. Voilà. Quoi ? Si, si, moi il m'en reste. J'ai un stock secret de chaussettes lambda. Ok, voilà. Donc, on vous laisse voter encore quelques secondes. Et puis, on vous donne rendez-vous dans quelques minutes pour le deuxième webinar où on va, avec CodeStar, créer un Skill Alexa. Donc, la partie CodeStar est assez simple, vous l'avez vu. Mais on va repasser dessus avec un autre petit d'appli. Comme ça, ça nous permet de voir un deuxième cas d'application. Et puis ensuite, on prendra ce prétexte pour faire un tuto sur Alexa et un skill tout simple. Et puis bien sûr, après, on répondra à vos questions. Je promets de garder du temps pour ça. Merci beaucoup de votre fidélité. Et donc rendez-vous dans quelques minutes pour le deuxième webinaire. Merci.