Projets sur AWS

Création d'une application Web moderne

Déployer une application Web, se connecter à une base de données et analyser le comportement des utilisateurs

Module 2 : Hébergement de votre application sur un serveur Web

Dans ce module, vous allez créer un nouveau microservice hébergé à l'aide d'AWS Fargate.  

Présentation

Dans ce module, vous allez créer un nouveau microservice hébergé à l'aide d'AWS Fargate afin que votre site Web Mythical Mysfits puisse s'intégrer à un backend d'application.

AWS Fargate est une option d'Amazon Elastic Container Service (ECS) vous permettant de déployer des conteneurs sans avoir à gérer des serveurs ou des clusters. Pour notre backend Mythical Mysfits, nous allons utiliser Python et créer une application Flask dans un conteneur Docker derrière un Network Load Balancer. Ces éléments formeront le backend du microservice pour le site Web frontend.

Pourquoi avons-nous choisi Fargate ?

Nous avons sélectionné Fargate car il représente un excellent choix pour construire des processus à long terme tels que les backends de microservice pour les plateformes Web, mobiles et PaaS. Avec Fargate, vous avez le contrôle des conteneurs et la possibilité de choisir le moment où ils fonctionnent sans vous soucier de la mise en service et de l'évolutivité des serveurs. Cette solution offre un contrôle complet de la mise en réseau, de la sécurité et de la communication de service à service. En outre, elle est intégrée de façon native à des services AWS pour la sécurité, la mise en réseau, le contrôle d'accès, les outils de développement, la surveillance et la journalisation.

En plus de Fargate, les clients ont la possibilité d'utiliser AWS Lambda pour leurs besoins de calcul. Bien que Lambda offre les mêmes avantages sans serveur que Fargate, Lambda est idéal pour les applications orientées données qui doivent répondre en temps réel aux changements de données, aux changements d'état du système ou aux actions des utilisateurs. Nous détaillerons Lambda dans le Module 5 car nous l'utiliserons pour analyser le comportement des clients sur le site.

Instructions

Suivez les instructions détaillées ci-dessous pour créer votre service AWS Fargate. Ce module étant important, nous l'avons divisé en trois sous-modules. Dans le module 2a, vous configurerez l'infrastructure de base en vue du déploiement de votre service. Dans le module 2b, vous déploierez votre service à l'aide d'AWS Fargate. Enfin, dans le module 2c, vous mettrez en place un déploiement automatique à l'aide des services AWS Code.

Module 2A : Configuration de l'infrastructure de base

Avant de pouvoir créer notre service, nous devons créer l'environnement de l'infrastructure de base que le service emploiera, dont l'infrastructure de mise en réseau dans Amazon VPC, ainsi que les rôles AWS Identity and Access Management qui définiront les autorisations dont ECS et nos conteneurs disposeront en plus d'AWS.

À cette fin, nous utiliserons AWS CloudFormation. Le service AWS CloudFormation fournit, par programmation, des ressources AWS que vous déclarez dans des fichiers JSON ou YAML appelés modèles CloudFormation. Ces derniers assurent les bonnes pratiques de l'infrastructure sous forme de code.  

  • Nous avons mis à disposition un modèle CloudFormation pour créer toutes les ressources nécessaires en matière de réseau et de sécurité dans /module-2/cfn/core.yml. Ce modèle va créer les ressources suivantes :

    • Un VPC Amazon - Un environnement de réseau qui contient quatre sous-réseaux (deux publics et deux privés) dans l'espace IP privé 10.0.0.0/16 ainsi que toutes les configurations de table de routage nécessaires. Les sous-réseaux sont créés dans des zones de disponibilité AWS distinctes pour permettre une haute disponibilité entre les multiples installations physiques d'une région AWS. En savoir plus sur la façon dont les zones de disponibilité peuvent vous permettre d'atteindre une haute disponibilité.
    • Deux passerelles NAT (une pour chaque sous-réseau public) - Celles-ci permettent aux conteneurs que nous allons déployer dans nos sous-réseaux privés de communiquer avec Internet, notamment pour télécharger les packages nécessaires.
    • Un point de terminaison VPC Dynamo DB - Notre backend de microservice s'intègrera à Amazon DynamoDB pour la persistence (dans le cadre du module 3).
    • Un groupe de sécurité - Permet à vos conteneurs Docker de recevoir le trafic sur le port 8080 depuis Internet grâce au Network Load Balancer.
    • Rôles IAM - Des rôles Identity and Access Management sont créés. Ils seront utilisés tout au long de la formation pour donner aux services ou ressources AWS que vous créez un accès à d'autres services AWS comme DynamoDB ou S3.

    Pour créer ces ressources, exécutez la commande suivante dans le terminal Cloud9 (la pile sera créée en environ 10 minutes) :

    aws cloudformation create-stack --stack-name MythicalMysfitsCoreStack --capabilities CAPABILITY_NAMED_IAM --template-body file://~/environment/aws-modern-application-workshop/module-2/cfn/core.yml

    Vous pouvez vérifier le statut de la création de votre pile soit via la console AWS, soit en exécutant la commande :

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack

    Exécutez la commande describe-stacks jusqu'à ce que vous voyiez le statut « StackStatus » : « CREATE_COMPLETE ».

    describe stacks

    (cliquer pour agrandir)

    Cette réponse signifie que CloudFormation a terminé de mettre en service toutes les ressources de mise en réseau de base et les ressources de sécurité décrites ci-dessus. Avant de poursuivre, attendez que la pile ci-dessus affiche le message CREATE_COMPLETE.

    Vous utiliserez les valeurs provenant des résultats de cette commande pendant le reste de la formation. Vous pouvez exécuter la commande suivante pour envoyer directement la commande describe-stacks ci-dessus dans un nouveau fichier de votre EDI qui sera stocké sous le nom de cloudformation-core-output.json:

    aws cloudformation describe-stacks --stack-name MythicalMysfitsCoreStack > ~/environment/cloudformation-core-output.json

Module 2B : Déploiement d'un service à l'aide d'AWS Fargate

Ensuite, vous allez créer une image de conteneur Docker qui contient tout le code et la configuration nécessaires pour faire fonctionner le backend Mythical Mysfits comme une API de microservice créée avec Flask. Nous allons créer l'image du conteneur Docker dans Cloud9, puis nous la transfèrerons dans Amazon Elastic Container Registry, où elle sera disponible une fois notre service créé à l'aide de Fargate.

Diagramme d'architecture

Navigateur pour charger l'équilibreur dans Fargate
  • A : Création d'une image Docker

    Tout le code nécessaire pour faire fonctionner le backend de notre service est stocké dans le répertoire /module-2/app/ du référentiel que vous avez cloné dans votre IDE Cloud9. Si vous souhaitez vérifier le code Python qui utilise Flask pour créer l'API du service, consultez le fichier /module-2/app/service/mythicalMysfitsService.py.

    Docker est déjà installé sur l'IDE Cloud9 que vous avez créé. Pour créer l'image Docker en local, il suffit donc d'exécuter les deux commandes suivantes dans le terminal Cloud9 :  

    D'abord, changez de répertoire pour accéder à ~/environment/module-2/app.

    cd ~/environment/aws-modern-application-workshop/module-2/app

    Vous pouvez obtenir votre ID de compte et la région par défaut depuis le résultat du **describe-stacks CloudFormation précédent.

    Remplacez REPLACE_ME_ACCOUNT_ID par votre ID de compte et REPLACE_ME_REGION par votre région par défaut dans la commande suivante pour créer l'image Docker à l'aide du fichier Dockerfile qui contient les instructions de Docker. La commande identifie l'image Docker, en utilisant l'option -t, avec un format de balise spécifique afin que l'image puisse ensuite être transférée vers le service Amazon Elastic Container Registry.

    Une fois que vous avez votre ID de compte, vous êtes prêt à créer l'image Docker :

    docker build . -t REPLACE_ME_AWS_ACCOUNT_ID.dkr.ecr.REPLACE_ME_REGION.amazonaws.com/mythicalmysfits/service:latest

    Vous verrez Docker télécharger et installer tous les packages de dépendance nécessaires dont notre application a besoin et extraire la balise de l'image construite. Copiez la balise de l'image à titre informatif. Ci-dessous, la balise en exemple est : 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Successfully built 8bxxxxxxxxab
    Successfully tagged 111111111111.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest
    B : Test du service en local

    Testons notre image en local dans Cloud9 pour nous assurer que tout fonctionne comme prévu. Copiez la balise de l'image issue de la commande précédente et exécutez la commande suivante pour déployer le conteneur « en local » (qui se trouve en fait dans votre IDE Cloud9 dans AWS !) :

    docker run -p 8080:8080 REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Docker signalera alors que votre conteneur fonctionne correctement en local :

     * Running on http://0.0.0.0:8080/ (Press CTRL+C to quit)

    Pour tester notre service avec une requête locale, nous allons ouvrir le navigateur Web intégré dans l'IDE Cloud9 afin de prévisualiser les applications s'exécutant sur l'instance de l'IDE.

    Pour ouvrir le navigateur Web d'aperçu, sélectionnez Preview > Preview Running Application (Aperçu > Afficher l'application active) dans la barre de menu de Cloud9 :

    preview-menu

     

    Cette action ouvrira un autre panneau dans l'IDE dans lequel le navigateur Web sera disponible. Ajoutez /mysfits à la fin de l'URL dans la barre d'adresse du navigateur d'aperçu et appuyez sur ENTRÉE :

    address-bar

    En cas de succès, vous verrez une réponse du service qui renvoie le document JSON stocké sur `/aws-modern-application-workshop/module-2/app/service/mysfits-response.json`

    Lorsque vous avez terminé de tester le service, vous pouvez arrêter en appuyant sur Ctrl-c sur PC ou Mac.

    C : Transfert de l'image Docker vers Amazon ECR

    Maintenant que le test de notre service a réussi au niveau local, nous sommes prêts à créer un référentiel d'images de conteneur dans Amazon Elastic Container Registry (Amazon ECR) et à y transférer notre image. Pour créer le registre, exécutez la commande suivante afin d'ajouter un nouveau référentiel au registre AWS ECR par défaut créé pour votre compte.

    aws ecr create-repository --repository-name mythicalmysfits/service

    La réponse à cette commande contiendra des métadonnées supplémentaires concernant le référentiel créé. Pour transférer les images des conteneurs dans notre nouveau référentiel, nous devrons obtenir des identifiants d'authentification pour notre client Docker sur le référentiel.

    Exécutez la commande suivante, qui vous renverra une commande de connexion pour récupérer les informations d'identification de notre client Docker et l'exécuter automatiquement (saisissez la commande complète, y compris le $ ci-dessous). « Login Succeeded » (Connexion réussie) apparaîtra si la commande est réussie.

    $(aws ecr get-login --no-include-email)

    Ensuite, transférez l'image créée dans le référentiel ECR à l'aide de la balise copiée plus haut. À l'aide de cette commande, Docker va transférer votre image et toutes les images qui en dépendent vers Amazon ECR :

    docker push REPLACE_ME_WITH_DOCKER_IMAGE_TAG

    Exécutez la commande suivante pour voir votre image Docker récemment transférée dans le référentiel ECR :

    aws ecr describe-images --repository-name mythicalmysfits/service
  • A : Création d'un cluster AWS Fargate

    Nous avons désormais une image disponible dans ECR que nous pouvons déployer vers un service hébergé sur Amazon ECS à l'aide d'AWS Fargate. Le même service que vous avez testé localement via le terminal dans Cloud9 dans le cadre du dernier module sera désormais déployé dans le cloud et disponible publiquement derrière un Network Load Balancer.

    D'abord, nous allons créer un cluster dans Amazon Elastic Container Service (ECS). Celui-ci représente le cluster de « serveurs » dans lequel vos conteneurs de services seront déployés. Les serveurs sont « entre guillemets » car vous utiliserez AWS Fargate. Fargate vous permet de spécifier que vos conteneurs seront déployés dans un cluster sans devoir mettre en service ou gérer vous-même des serveurs.

    Pour créer un nouveau cluster dans ECS, exécutez la commande suivante :

    aws ecs create-cluster --cluster-name MythicalMysfits-Cluster
    B : Création d'un groupe AWS CloudWatch Logs

    Ensuite, nous allons créer un nouveau groupe de journaux dans AWS CloudWatch Logs. AWS CloudWatch Logs est un service de collecte et d'analyse de journaux. Les journaux que votre conteneur génère seront automatiquement transférés vers AWS CloudWatch Logs dans le cadre de ce groupe spécifique. Cette action revêt une importance particulière lorsque vous utilisez AWS Fargate, car vous n'aurez pas accès à l'infrastructure du serveur où sont exécutés vos conteneurs.

    Pour créer le nouveau groupe de journaux dans CloudWatch Logs, exécutez la commande suivante :

    aws logs create-log-group --log-group-name mythicalmysfits-logs
    C : Enregistrement d'une définition de tâche ECS

    Maintenant que nous avons créé un cluster et défini un groupe de journaux vers lequel seront transférés nos journaux de conteneur, nous sommes prêts à enregistrer une définition de tâche ECS. Une tâche dans ECS est un ensemble d'images de conteneurs qui doivent être programmées ensemble. Une définition de tâche déclare cet ensemble de conteneurs ainsi que les ressources et la configuration que ces conteneurs demandent. Vous utiliserez l'interface de ligne de commande AWS pour créer une nouvelle définition de tâche qui permettra de savoir comment votre nouvelle image de conteneur devra être programmée pour le cluster ECS que nous venons de créer.

    Un fichier JSON a été fourni, il servira d'entrée pour la commande d'interface de ligne de commande.

    Ouvrez ~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json dans l'IDE.

    Remplacez les valeurs indiquées par les valeurs appropriées de vos ressources créées.

    Ces valeurs seront extraites de la réponse de CloudFormation que vous avez copiée précédemment ainsi que de la balise d'image Docker que vous avez transférée plus tôt vers ECR, par exemple : REPLACE_ME_ACCOUNT_ID.dkr.ecr.us-east-1.amazonaws.com/mythicalmysfits/service:latest

    Une fois que vous avez remplacé et enregistré les valeurs dans task-definition.json, exécutez la commande suivante pour enregistrer une nouvelle définition de tâche dans ECS :

    aws ecs register-task-definition --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/task-definition.json
  • A : Création d'un Network Load Balancer

    Maintenant que la nouvelle définition de tâche est enregistrée, nous sommes prêts à mettre en service l'infrastructure nécessaire dans notre pile de services. Plutôt que d'exposer directement notre service à Internet, nous allons mettre en place un Network Load Balancer (NLB) qui sera un point d'entrée à notre offre de service. Cela permettra au code de notre site Web frontend de communiquer avec un seul nom DNS, tandis que notre service backend sera en mesure de se redimensionner de manière élastique en fonction de la demande ou en cas de défaillance et de la nécessité de mettre en service de nouveaux conteneurs.

    Pour mettre en service un nouveau NLB, exécutez la commande d'interface de ligne de commande suivante dans le terminal Cloud9 (récupérez les ID de sous-réseau du résultat CloudFormation que vous avez enregistré) :

    aws elbv2 create-load-balancer --name mysfits-nlb --scheme internet-facing --type network --subnets REPLACE_ME_PUBLIC_SUBNET_ONE REPLACE_ME_PUBLIC_SUBNET_TWO > ~/environment/nlb-output.json

    Lorsque cette commande aura réussi, un nouveau fichier sera créé dans votre IDE, appelé nlb-output.json. Dans les prochaines étapes, vous utiliserez DNSName, VpcId et LoadBalancerArn.

    B : Création d'un groupe cible d'équilibreur de charge

    Ensuite, utilisez l'interface de ligne de commande pour créer un groupe cible NLB. Un groupe cible permet aux ressources AWS de s'enregistrer comme cibles pour les demandes à transmettre que l'équilibreur de charge reçoit. Nos conteneurs de service s'enregistreront automatiquement auprès de cette cible afin de pouvoir recevoir le trafic du NLB lorsqu'ils seront mis en service. Cette commande inclut une valeur qui devra être remplacée, votre vpc-id, qui peut être trouvé comme valeur dans le résultat que MythicalMysfitsCoreStack a enregistré précédemment et qui est renvoyé par CloudFormation.

    aws elbv2 create-target-group --name MythicalMysfits-TargetGroup --port 8080 --protocol TCP --target-type ip --vpc-id REPLACE_ME_VPC_ID --health-check-interval-seconds 10 --health-check-path / --health-check-protocol HTTP --healthy-threshold-count 3 --unhealthy-threshold-count 3 > ~/environment/target-group-output.json

    Lorsque cette commande sera terminée, son résultat sera enregistré dans le fichier target-group-output.json de votre IDE. Vous référencerez la valeur TargetGroupArn dans une étape ultérieure.

    C : Création d'un écouteur d'équilibreur de charge

    Ensuite, utilisez l'interface de ligne de commande pour créer un écouteur d'équilibreur de charge pour le NLB. Cela informe cet équilibreur de charge que pour les demandes reçues sur un port spécifique, elles doivent être transmises aux cibles qui se sont inscrites auprès du groupe cible ci-dessus. Veillez à remplacer les deux valeurs indiquées par l'ARN approprié du TargetGroup et du NLB que vous avez enregistré lors des étapes précédentes :

    aws elbv2 create-listener --default-actions TargetGroupArn=REPLACE_ME_NLB_TARGET_GROUP_ARN,Type=forward --load-balancer-arn REPLACE_ME_NLB_ARN --port 80 --protocol TCP
  • A : Création d'un rôle lié aux services pour ECS

    Si vous avez déjà utilisé ECS, vous pouvez sauter cette étape et passer à l'étape suivante. Si vous n'avez jamais utilisé ECS auparavant, nous devons créer un **rôle lié au service** dans IAM qui autorise le service ECS lui-même de faire des demandes d'API ECS dans votre compte. Ceci est nécessaire car lorsque vous créez un service dans ECS, le service appellera des API dans votre compte pour effectuer des actions comme l'extraction d'images Docker, la création de nouvelles tâches, etc.

    Sans la création de ce rôle, le service ECS ne serait pas autorisé à effectuer les actions requises. Pour créer le rôle, exécutez la commande suivante dans le terminal :  

    aws iam create-service-linked-role --aws-service-name ecs.amazonaws.com

    Si la commande ci-dessus renvoie une erreur signalant que le rôle existe déjà, vous pouvez l'ignorer car elle indiquerait que le rôle a déjà été créé automatiquement dans votre compte dans le passé.

    B : Création du service

    Maintenant que le NLB a été créé et configuré et que le service ECS a reçu les autorisations appropriées, nous sommes prêts à créer le véritable **service** ECS sur lequel nos conteneurs s'exécuteront et s'enregistreront eux-mêmes auprès de l'équilibreur de charge pour recevoir le trafic. Nous avons inclus un fichier JSON pour l'entrée de l'interface de ligne de commande dont l'emplacement se trouve ici : `~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json`. Ce fichier comprend toutes les informations de configuration du service à créer ; il indique notamment que ce service doit être lancé avec **AWS Fargate** - ce qui signifie que vous n'avez pas besoin de mettre en service un serveur dans le cluster ciblé. Les conteneurs programmés dans le cadre de la tâche utilisée dans ce service fonctionneront en plus d'un cluster entièrement géré par AWS.

    Ouvrez ~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json dans l'IDE et remplacez les valeurs indiquées de REPLACE_ME. Enregistrez-le, puis exécutez la commande suivante pour créer le service :

    aws ecs create-service --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/service-definition.json
    C : Test du service

    Copiez le nom DNS que vous avez enregistré lors de la création du NBL et envoyez-lui une demande en utilisant le navigateur d'aperçu dans Cloud9 (ou n'importe quel autre navigateur Web, car cette fois notre service est disponible sur Internet). Essayez d'envoyer une demande à la ressource mysfits :

    http://mysfits-nlb-123456789-abc123456.elb.us-east-1.amazonaws.com/mysfits

    Une réponse affichant la même réponse JSON que celle que nous avions reçue plus tôt lors du test du conteneur Docker en local dans Cloud9 signifie que votre API Flask fonctionne sur AWS Fargate.

    Remarque : ce Network Load Balancer ne prend en charge que les demandes HTTP (http://) car aucun certificat SSL/TLS n'est installé dessus. Pour ce tutoriel, assurez-vous d'envoyer uniquement des demandes http://, les demandes https:// ne fonctionneront pas correctement.

  • A : Remplacement du point de terminaison d'une API

    Ensuite, nous devons intégrer notre site Web au backend de votre nouvelle API au lieu d'utiliser les données codées en dur que nous avons précédemment chargées dans S3. Vous devrez mettre à jour le fichier suivant pour utiliser la même URL du NLB pour les appels API (n'incluez pas le chemin /mysfits) : /module-2/web/index.html

    Ouvrez le fichier dans Cloud9 et remplacez la zone ci-dessous qui est en surbrillance et entre guillemets par l'URL du NLB :

    before-replace

    Après l'avoir collée, la ligne doit ressembler à ceci :

    after-replace
    B : Chargement dans S3

    Pour charger ce fichier sur votre site Web hébergé par S3, utilisez à nouveau le nom du compartiment créé dans le Module 1, puis exécutez la commande suivante :

    aws s3 cp ~/environment/aws-modern-application-workshop/module-2/web/index.html s3://INSERT-YOUR-BUCKET-NAME/index.html

    Ouvrez votre site Web avec la même URL que celle utilisée à la fin du Module 1 afin de voir votre nouveau site Web Mythical Mysfits, qui récupère les données JSON de votre API Flask s'exécutant dans un conteneur Docker déployé sur AWS Fargate !

Module 2C : Automatisation des déploiements avec des services AWS Code

Maintenant que votre service est opérationnel, vous pourriez envisager des modifications de code que vous aimeriez apporter à votre service Flask. Votre vitesse de développement serait fortement ralentie si vous deviez repasser par toutes les étapes précédentes à chaque fois que vous souhaitez déployer une nouvelle fonctionnalité dans votre service. C'est là où l'intégration et la livraison continues ou CI/CD interviennent !

Dans ce module, vous allez créer une pile de CI/CD entièrement gérée qui livrera automatiquement toutes les modifications de code que vous apportez à votre base de code au service que vous avez créé au cours du dernier module.

Diagramme d'architecture

Créer une architecture de site Web dynamique - cloud9, outils de code, fargate
  • A : Création d'un compartiment S3 pour les artefacts de pipeline

    Nous aurons besoin de créer un autre compartiment S3 qui sera utilisé pour stocker les artefacts temporaires créés pendant les exécutions de notre pipeline de CI/CD. Choisissez un nouveau nom de compartiment pour ces artefacts et créez-en un à l'aide de la commande d'interface de ligne de commande suivante :

    aws s3 mb s3://REPLACE_ME_CHOOSE_ARTIFACTS_BUCKET_NAME

    Ensuite, ce compartiment a besoin d'une stratégie de compartiment pour définir les autorisations pour les données qui y sont stockées. Mais contrairement au compartiment de notre site Web qui permettait l'accès à n'importe qui, seul notre pipeline de CI/CD doit avoir accès à ce compartiment. Le fichier JSON nécessaire à cette stratégie se trouve ici : ~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json.

    Ouvrez ce fichier dans lequel vous devrez remplacer plusieurs chaînes pour inclure les ARN créés pour MythicalMysfitsCoreStack, ainsi que votre nouveau nom de compartiment choisi pour vos artefacts de CI/CD.

    Une fois que vous avez modifié et enregistré ce fichier, exécutez la commande suivante pour autoriser l'accès à ce compartiment à votre pipeline de CI/CD :

    aws s3api put-bucket-policy --bucket REPLACE_ME_ARTIFACTS_BUCKET_NAME --policy file://~/environment/aws-modern-application-workshop/module-2/aws-cli/artifacts-bucket-policy.json
    B : Création d'un référentiel CodeCommit

    Vous avez besoin d'un emplacement dans lequel transférer et stocker votre code. Créez un **référentiel AWS CodeCommit à l'aide de l'interface de ligne de commande prévue :

    aws codecommit create-repository --repository-name MythicalMysfitsService-Repository
    C : Création d'un projet CodeBuild

    Outre le référentiel de stockage du code et le compartiment S3 utilisé pour nos artefacts de CI/CD, ajoutons à la pile de CI/CD un moyen de produire une génération de service. Pour cela, nous devrons créer un projet AWS CodeBuild. Chaque fois qu'une génération est exécutée, AWS CodeBuild met automatiquement en service un serveur de génération pour notre configuration et exécute les étapes nécessaires pour créer notre image Docker et transférer une nouvelle version de celle-ci vers le référentiel ECR que nous avons créé (et ensuite arrêter le serveur lorsque la génération est terminée).

    Les étapes de notre génération (qui regroupent notre code Python et construisent/transfèrent le conteneur Docker) sont incluses dans le fichier ~/environment/aws-modern-application-workshop/module-2/app/buildspec.yml. Le fichier buildspec.yml donne à CodeBuild les étapes à suivre pour exécuter une génération dans un projet CodeBuild.

    Pour créer le projet CodeBuild, un autre fichier d'entrée d'interface de ligne de commande doit être mis à jour avec des paramètres spécifiques à vos ressources. Il se trouve ici ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json. De même, remplacez les valeurs dans ce fichier comme vous l'aviez fait auparavant pour MythicalMysfitsCoreStackOutput. Une fois enregistré, exécutez l'action suivante avec l'interface de ligne de commande pour créer le projet :

    aws codebuild create-project --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-build-project.json
    D :Création d'un pipeline CodePipeline

    Enfin, nous avons besoin d'un moyen d'intégrer de façon continue notre référentiel CodeCommit à notre projet CodeBuild afin que des générations se déclenchent automatiquement chaque fois qu'un changement de code est transféré vers le référentiel. Ensuite, nous devons trouver un moyen de livrer de façon continue ces artefacts nouvellement créés à notre service dans ECS. AWS CodePipeline est le service qui relie ensemble ces actions dans un pipeline que vous allez créer ensuite.

    C'est précisément le rôle de votre pipeline créé dans CodePipeline. Chaque fois qu'une modification de code est intégrée à votre référentiel CodeCommit, CodePipeline fournira le code le plus récent à votre projet AWS CodeBuild de façon à déclencher une génération. Une fois la génération réussie par CodeBuild, CodePipeline effectuera un déploiement vers ECS en utilisant la dernière image de conteneur que l'exécution de CodeBuild a transféré dans ECR.

    Toutes ces étapes sont définies dans un fichier JSON à condition que vous l'utilisiez comme entrée dans l'interface de ligne de commande AWS pour créer le pipeline. Ce fichier se trouve ici : ~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json. Ouvrez-le et remplacez les attributs requis, puis enregistrez-le.

    Ensuite, créez un pipeline dans CodePipeline avec la commande suivante :

    aws codepipeline create-pipeline --cli-input-json file://~/environment/aws-modern-application-workshop/module-2/aws-cli/code-pipeline.json
    E : Activation d'un accès automatisé au référentiel d'image ECR

    Il nous reste une étape avant que notre pipeline de CI/CD puisse fonctionner correctement de bout en bout. Lorsque le pipeline de CI/CD est en place, vous n'avez plus besoin de transférer manuellement les images du conteneur dans ECR. Désormais, CodeBuild transfère les nouvelles images.

    Nous devons donner à CodeBuild l'autorisation d'effectuer des actions sur votre référentiel d'images avec une stratégie de référentiel ECR*. Le document de stratégie doit être mis à jour avec l'ARN spécifique pour le rôle de CodeBuild créé par MythicalMysfitsCoreStack ; ce document se trouve ici : ~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json.

    Mettez à jour ce fichier et enregistrez-le, puis exécutez la commande suivante pour créer la stratégie :

    aws ecr set-repository-policy --repository-name mythicalmysfits/service --policy-text file://~/environment/aws-modern-application-workshop/module-2/aws-cli/ecr-policy.json

    Vous disposerez alors d'un pipeline de CI/CD de bout en bout pour fournir automatiquement les changements de code à votre service dans ECS.

  • A : Utilisation de Git avec AWS CodeCommit

    Pour tester le nouveau pipeline, nous devons configurer git dans votre IDE Cloud9 et l'intégrer à votre référentiel CodeCommit.

    AWS CodeCommit fournit un outil d'aide Git destiné à la gestion des identifiants que nous utiliserons pour faciliter l'intégration.

    Exécutez les commandes suivantes en séquence sur le terminal pour configurer Git afin qu'il soit utilisé avec AWS CodeCommit (aucun des deux ne donnera de réponse en cas de succès) :

    git config --global user.name "REPLACE_ME_WITH_YOUR_NAME"
    git config --global user.email REPLACE_ME_WITH_YOUR_EMAIL@example.com
    git config --global credential.helper '!aws codecommit credential-helper $@'
    git config --global credential.UseHttpPath true

    Ensuite, changez les répertoires dans votre IDE en faveur du répertoire de l'environnement à l'aide du terminal :

    cd ~/environment/

    Vous êtes maintenant prêt à cloner votre référentiel en utilisant la commande de terminal suivante :

    git clone https://git-codecommit.REPLACE_REGION.amazonaws.com/v1/repos/MythicalMysfitsService-Repository

    Cela nous dira que notre référentiel est vide ! Réglons le problème en copiant les fichiers d'application dans le répertoire de notre référentiel à l'aide de la commande suivante :

    cp -r ~/environment/aws-modern-application-workshop/module-2/app/* ~/environment/MythicalMysfitsService-Repository/
    B : Transfert d'une modification de code

    Maintenant, la totalité du code de service que nous avons utilisé pour créer notre service Fargate dans le Module 2 est stockée dans le référentiel local que nous venons de cloner depuis AWS CodeCommit. Apportons un changement au service Flask avant de valider nos modifications pour prouver que le pipeline de CI/CD que nous avons créé fonctionne. Dans Cloud9, ouvrez le fichier ~/environment/MythicalMysfitsService-Repository/service/mysfits-response.json, changez l'âge de l'un des mysfits, puis enregistrez le fichier.

    Après avoir enregistré le fichier, changez les répertoires par le nouveau répertoire de référentiel :

    cd ~/environment/MythicalMysfitsService-Repository/

    Ensuite, exécutez les commandes Git suivantes pour transférer vos modifications de code.

    git add .
    git commit -m "I changed the age of one of the mysfits."
    git push

    Une fois le changement transféré vers le référentiel, vous pouvez ouvrir le service CodePipeline dans la console AWS pour voir vos changements au fur et à mesure de leur progression dans le pipeline CI/CD. Après la validation de la modification de votre code, il faudra environ 5 à 10 minutes pour que les changements soient déployés dans votre service en ligne s'exécutant sous Fargate.

    Pendant ce temps, AWS CodePipeline organisera le déclenchement d'une exécution de pipeline après la vérification des modifications dans votre référentiel CodeCommit. Le service déclenchera également votre projet CodeBuild pour lancer une nouvelle génération et récupérer l'image Docker transférée vers ECR, afin d'effectuer une action automatisée du service de mise à jour ECS permettant de connecter le drainage des conteneurs existants qui sont en cours d'exécution dans votre service et les remplacer par la nouvelle image. Rafraîchissez votre site Web Mythical Mysfits dans le navigateur pour vérifier que les modifications sont bien implémentées.

    Vous pouvez consulter la progression de vos modifications de code via la console CodePipeline ici (aucune action nécessaire, il suffit de regarder l'automatisation en action !) : AWS CodePipeline.

    Le module 2 se termine ici.

Stocker les données mysfit.