

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

# Tutoriel CLI : Stack à deux niveaux de haute disponibilité (Linux/RHEL)
<a name="tut-create-ha-stack"></a>

Cette section décrit comment déployer une pile à deux niveaux de haute disponibilité (HA) dans un environnement AMS à l'aide de la CLI AMS. 

**Note**  
Cette procédure de déploiement a été testée dans les environnements AMZN Linux et RHEL.

Résumé des tâches et des exigences RFCs :

1. Création d'une infrastructure (pile HA à deux niveaux)

1. Création d'un compartiment S3 pour les CodeDeploy applications

1. Créez le bundle WordPress d'applications et chargez-le dans le compartiment S3

1. Déployez l'application avec CodeDeploy

1. Accédez au WordPress site et connectez-vous pour valider le déploiement

# Avant de commencer
<a name="ha-stack-ex-before-begin"></a>

Deployment \$1 Advanced Stack Components \$1 High Availability Two Tier Stack Advanced \$1 Create CT crée un groupe Auto Scaling, un équilibreur de charge, une base de données, ainsi qu'un nom d' CodeDeploy application et un groupe de déploiement (avec le même nom que celui que vous donnez à l'application). Pour plus d'informations, CodeDeploy voir [Qu'est-ce que c'est CodeDeploy ?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)

Cette procédure pas à pas utilise une RFC de haute disponibilité à deux niveaux (avancée) qui inclut UserData et décrit également comment créer un WordPress bundle pouvant CodeDeploy être déployé.

L'exemple `UserData` illustré permet d'obtenir les métadonnées d'instance telles que l'ID d'instance, la région, etc., à partir d'une instance en cours d'exécution en interrogeant le service de métadonnées d' EC2 instance disponible sur http://169.254.169.254/latest/meta-data/. Cette ligne du script de données utilisateur :`REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')`, extrait le nom de la zone de disponibilité du service de métadonnées dans la variable \$1REGION pour nos régions prises en charge, et l'utilise pour compléter l'URL du compartiment S3 dans lequel l' CodeDeploy agent est téléchargé. L'IP 169.254.169.254 est routable uniquement au sein du VPC (tout le monde peut interroger le service). VPCs Pour plus d'informations sur le service, consultez la section [Métadonnées d'instance et données utilisateur](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html). Notez également que les scripts saisis UserData sont exécutés en tant qu'utilisateur « root » et n'ont pas besoin d'utiliser la commande « sudo ».

Cette procédure pas à pas laisse les paramètres suivants à la valeur par défaut (illustrée) :
+ Groupe Auto Scaling :`Cooldown=300, DesiredCapacity=2, EBSOptimized=false, HealthCheckGracePeriod=600, IAMInstanceProfile=customer-mc-ec2-instance-profile, InstanceDetailedMonitoring=true, InstanceRootVolumeIops=0, InstanceRootVolumeType=standard, InstanceType=m3.medium, MaxInstances=2, MinInstances=2, ScaleDownPolicyCooldown=300, ScaleDownPolicyEvaluationPeriods=4, ScaleDownPolicyPeriod=60, ScaleDownPolicyScalingAdjustment=-1, ScaleDownPolicyStatistic=Average, ScaleDownPolicyThreshold=35, ScaleMetricName=CPUUtilization, ScaleUpPolicyCooldown=60, ScaleUpPolicyEvaluationPeriods=2, ScaleUpPolicyPeriod=60, ScaleUpPolicyScalingAdjustment=2, ScaleUpPolicyStatistic=Average, ScaleUpPolicyThreshold=75`.
+ Load Balancer :. `HealthCheckInterval=30, HealthCheckTimeout=5`
+ Base de données :`BackupRetentionPeriod=7, Backups=true, InstanceType=db.m3.medium, IOPS=0, MultiAZ=true, PreferredBackupWindow=22:00-23:00, PreferredMaintenanceWindow=wed:03:32-wed:04:02, StorageEncrypted=false, StorageEncryptionKey="", StorageType=gp2`.
+ Application :`DeploymentConfigName=CodeDeployDefault.OneAtATime`.
+ Seau S3 :`AccessControl=Private`.

PARAMÈTRES SUPPLÉMENTAIRES :

`RequestedStartTime`et `RequestedEndTime` si vous souhaitez planifier votre RFC : vous pouvez utiliser [Time.is](https://time.is/UTC) pour déterminer l'heure UTC correcte. Les exemples fournis doivent être adaptés de manière appropriée. Une RFC ne peut pas continuer si l'heure de début est dépassée. Vous pouvez également omettre ces valeurs pour créer une RFC ASAP qui s'exécute dès que les approbations sont passées.

**Note**  
Il existe de nombreux paramètres que vous pouvez choisir de définir différemment de ceux illustrés. Les valeurs des paramètres présentés dans l'exemple ont été testées mais ne vous conviennent peut-être pas.

# Création de l'infrastructure
<a name="ex-create-ha-infra-deploy"></a>

La collecte des données suivantes avant de commencer accélérera le déploiement.

LES DONNÉES REQUISES ONT UNE PILE :
+ AutoScalingGroup:
  + `UserData`: Cette valeur est fournie dans ce didacticiel. Il inclut des commandes permettant de configurer la ressource pour l' CodeDeploy agent CodeDeploy et de le démarrer.
  + `AMI-ID`: Cette valeur détermine le type d' EC2 instances que votre groupe Auto Scaling (ASG) va créer. Assurez-vous de sélectionner une AMI dans votre compte qui commence par « customer- » et qui utilise le système d'exploitation que vous souhaitez. Trouvez l'AMI à l' IDs aide de la référence For the AMS SKMS API, consultez l'onglet **Rapports** de l'opération AWS Artifact Console (CLI : list-amis) ou sur la page de détails de la console AMS ->. VPCs VPCs Cette procédure pas à pas est destinée aux ASGs personnes configurées pour utiliser une AMI Linux.
+ Base de données : 
  + Ces paramètres, `DBEngine``EngineVersion`, et `LicenseModel` doivent être définis en fonction de votre situation, bien que les valeurs indiquées dans l'exemple aient été testées.
  + Ces paramètres,`RDSSubnetIds`, `DBName``MasterUsername`, et `MasterUserPassword` sont obligatoires lors du déploiement du bundle d'applications. Pour RDSSubnet les identifiants, utilisez deux sous-réseaux privés.
+ LoadBalancer:
  + Ces paramètres, `DBEngine``EngineVersion`, et `LicenseModel` doivent être définis en fonction de votre situation, bien que les valeurs indiquées dans l'exemple aient été testées.
  + `ELBSubnetIds`: utilisez deux sous-réseaux publics.
+ Application : la `ApplicationName` valeur définit le nom de l' CodeDeploy application et le nom du groupe de CodeDeploy déploiement. Vous l'utilisez pour déployer votre application. Il doit être unique dans le compte. Pour vérifier les CodeDeploy noms de votre compte, consultez la CodeDeploy console. L'exemple utilise « WordPress » mais, si vous voulez utiliser cette valeur, assurez-vous qu'elle n'est pas déjà utilisée.

Cette procédure utilise le CT à deux niveaux (avancé) à haute disponibilité (ct-06mjngx5flwto) et le CT Create S3 storage (ct-1a68ck03fn98r). À partir de votre compte authentifié, suivez ces étapes sur la ligne de commande.

1. Lancez la pile d'infrastructure.

   1. Exportez le schéma JSON des paramètres d'exécution pour la pile HA à deux niveaux CT dans un fichier de votre dossier actuel nommé CreateStackParams .json.

      ```
      aws amscm get-change-type-version --change-type-id "ct-06mjngx5flwto" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateStackParams.json
      ```

   1. Modifiez le schéma. Remplacez-le *variables* comme il convient. Par exemple, utilisez le système d'exploitation que vous souhaitez pour les EC2 instances que l'ASG créera. Enregistrez-le `ApplicationName` tel que vous l'utiliserez ultérieurement pour déployer l'application. Notez que vous pouvez ajouter jusqu'à 50 balises.

      ```
      {
      "Description":      "HA two tier stack for WordPress",
      "Name":             "WordPressStack",
      "TimeoutInMinutes":  360,
      "Tags": [
              {
                  "Key": "ApplicationName",
                  "Value": "WordPress"
              }
          ],
      "AutoScalingGroup": {
                  "AmiId":    "AMI-ID",
                  "UserData": "#!/bin/bash \n
                  REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//') \n
                  yum -y install ruby httpd \n
                  chkconfig httpd on \n
                  service httpd start \n
                  touch /var/www/html/status \n
                  cd /tmp \n
                  curl -O https://aws-codedeploy-$REGION.s3.amazonaws.com/latest/install \n
                  chmod +x ./install \n
                  ./install auto \n
                  chkconfig codedeploy-agent on \n
                  service codedeploy-agent start"
          },
          "LoadBalancer": {
              "Public":               true,
              "HealthCheckTarget":    "HTTP:80/status"
          },
          "Database":     {
              "DBEngine":             "MySQL",
              "DBName":               "wordpress",
              "EngineVersion":        "8.0.16 ",
              "LicenseModel":         "general-public-license",
              "MasterUsername":       "admin",
              "MasterUserPassword":   "p4ssw0rd"
          },
          "Application":  {
          "ApplicationName":  "WordPress"
              }
      }
      ```

   1. Exportez le modèle CreateRfc JSON dans un fichier de votre dossier actuel nommé CreateStackRfc .json :

      ```
      aws amscm create-rfc --generate-cli-skeleton > CreateStackRfc.json
      ```

   1. Modifiez le modèle RFC comme suit et enregistrez-le, vous pouvez supprimer et remplacer le contenu. Notez que `RequestedStartTime` et `RequestedEndTime` sont désormais facultatifs ; leur exclusion crée une RFC ASAP qui s'exécute dès qu'elle est approuvée (ce qui se produit généralement automatiquement). Pour soumettre une RFC planifiée, ajoutez ces valeurs.

      ```
      {
      "ChangeTypeVersion":    "3.0",
      "ChangeTypeId":         "ct-06mjngx5flwto",
      "Title":                "HA-Stack-For-WP-RFC"
      }
      ```

   1. Créez la RFC en spécifiant le fichier CreateStackRfc .json et le fichier de paramètres d'exécution CreateStackParams .json :

      ```
      aws amscm create-rfc --cli-input-json file://CreateStackRfc.json --execution-parameters file://CreateStackParams.json
      ```

      Vous recevez l'identifiant RFC dans la réponse. Enregistrez l'identifiant pour les étapes suivantes.

   1. Soumettez le RFC :

      ```
      aws amscm submit-rfc --rfc-id  RFC_ID
      ```

      Si la RFC réussit, vous ne recevrez aucune sortie.

   1. Pour vérifier l'état de la RFC, exécutez 

      ```
      aws amscm get-rfc --rfc-id RFC_ID
      ```

   Notez l'identifiant RFC.

1. Lancer un compartiment S3

   La collecte des données suivantes avant de commencer accélérera le déploiement.

   BUCKET S3 DE DONNÉES REQUIS :
   + `VPC-ID`: Cette valeur détermine l'emplacement de votre compartiment S3. Utilisez le même ID VPC que celui que vous avez utilisé précédemment.
   + `BucketName`: Cette valeur définit le nom du compartiment S3, vous l'utilisez pour télécharger votre bundle d'applications. Il doit être unique dans la région du compte et ne peut pas contenir de majuscules. Il n' BucketName est pas obligatoire d'inclure votre identifiant de compte, mais cela permet d'identifier plus facilement le compartiment ultérieurement. Pour voir quels noms de compartiment S3 existent dans le compte, accédez à la console Amazon S3 de votre compte.

   1. Exportez le schéma JSON des paramètres d'exécution pour le stockage S3 create CT dans un fichier JSON nommé CreateS3 StoreParams .json.

      ```
      aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3StoreParams.json
      ```

   1. Modifiez le schéma comme suit, vous pouvez supprimer et remplacer le contenu. Remplacez *VPC\$1ID* de manière appropriée. Les valeurs de l'exemple ont été testées, mais elles ne vous conviennent peut-être pas.
**Astuce**  
Ils `BucketName` doivent être uniques dans la région du compte et ne peuvent pas inclure de majuscules. Il n' BucketName est pas obligatoire d'inclure votre identifiant de compte, mais cela permet d'identifier plus facilement le compartiment ultérieurement. Pour voir quels noms de compartiment S3 existent dans le compte, accédez à la console Amazon S3 de votre compte.

      ```
      {
      "Description":      "S3BucketForWordPressBundle",
      "VpcId":            "VPC_ID",
      "StackTemplateId":  "stm-s2b72beb000000000",
      "Name":             "S3BucketForWP",
      "TimeoutInMinutes":  60,
      "Parameters":   {
          "AccessControl":    "Private",
          "BucketName":       "ACCOUNT_ID-BUCKET_NAME"
          }
      }
      ```

   1. Exportez le modèle JSON CreateRfc pour dans un fichier, dans votre dossier actuel, nommé CreateS3 StoreRfc .json :

      ```
      aws amscm create-rfc --generate-cli-skeleton > CreateS3StoreRfc.json
      ```

   1. Modifiez et enregistrez le fichier CreateS3 StoreRfc .json, vous pouvez supprimer et remplacer le contenu. Notez que `RequestedStartTime` et `RequestedEndTime` sont désormais facultatifs ; leur exclusion crée une RFC ASAP qui s'exécute dès qu'elle est approuvée (ce qui se produit généralement automatiquement). Pour soumettre une RFC planifiée, ajoutez ces valeurs.

      ```
      {
      "ChangeTypeVersion":    "1.0",
      "ChangeTypeId":         "ct-1a68ck03fn98r",
      "Title":                "S3-Stack-For-WP-RFC"
      }
      ```

   1. Créez la RFC en spécifiant le fichier CreateS3 StoreRfc .json et le fichier de paramètres d'exécution StoreParams CreateS3 .json :

      ```
      aws amscm create-rfc --cli-input-json file://CreateS3StoreRfc.json  --execution-parameters file://CreateS3StoreParams.json
      ```

      Vous recevez RfcId le nouveau RFC dans la réponse. Enregistrez l'identifiant pour les étapes suivantes.

   1. Soumettez le RFC :

      ```
      aws amscm submit-rfc --rfc-id RFC_ID
      ```

      Si la RFC réussit, vous ne recevrez aucune sortie.

   1. Pour vérifier l'état de la RFC, exécutez 

      ```
      aws amscm get-rfc --rfc-id RFC_ID
      ```

# Création, téléchargement et déploiement de l'application
<a name="ex-create-app"></a>

Créez d'abord un bundle d' WordPress applications, puis utilisez-le CodeDeploy CTs pour créer et déployer l'application.

1. Téléchargez WordPress, extrayez les fichiers et créez un. répertoire /scripts.

   Commande Linux :

   ```
   wget https://github.com/WordPress/WordPress/archive/master.zip
   ```

   Windows : collez `https://github.com/WordPress/WordPress/archive/master.zip` le fichier dans une fenêtre de navigateur et téléchargez le fichier zip.

   Créez un répertoire temporaire dans lequel assembler le package.

   Linux :

   ```
   mkdir /tmp/WordPress
   ```

   Windows : Créez un répertoire WordPress « », vous utiliserez le chemin du répertoire ultérieurement.

1. Extrayez la WordPress source dans le répertoire WordPress « » et créez un fichier. répertoire /scripts.

   Linux :

   ```
   unzip master.zip -d /tmp/WordPress_Temp
   cp -paf /tmp/WordPress_Temp/WordPress-master/* /tmp/WordPress
   rm -rf /tmp/WordPress_Temp
   rm -f master
   cd /tmp/WordPress
   mkdir scripts
   ```

   Windows : Accédez au répertoire « WordPress » que vous avez créé et créez-y un répertoire « scripts ».

   Si vous êtes dans un environnement Windows, veillez à définir le type de rupture des fichiers de script sur Unix (LF). Dans Notepad \$1\$1, il s'agit d'une option en bas à droite de la fenêtre.

1. Créez le fichier CodeDeploy **appspec.yml** dans le WordPress répertoire (si vous copiez l'exemple, vérifiez l'indentation, chaque espace compte). IMPORTANT : Assurez-vous que le chemin « source » est correct pour copier les WordPress fichiers (dans ce cas, dans votre WordPress répertoire) vers la destination prévue (/var/www/html/WordPress). Dans l'exemple, le fichier appspec.yml se trouve dans le répertoire contenant les WordPress fichiers, donc seul «/» est nécessaire. De plus, même si vous avez utilisé une AMI RHEL pour votre groupe Auto Scaling, laissez la ligne « os : linux » telle quelle. Exemple de fichier appspec.yml :

   ```
   version: 0.0
   os: linux
   files:
     - source: /
       destination: /var/www/html/WordPress
   hooks:
     BeforeInstall:
       - location: scripts/install_dependencies.sh
         timeout: 300
         runas: root
     AfterInstall:
       - location: scripts/config_wordpress.sh
         timeout: 300
         runas: root
     ApplicationStart:
       - location: scripts/start_server.sh
         timeout: 300
         runas: root
     ApplicationStop:
       - location: scripts/stop_server.sh
         timeout: 300
         runas: root
   ```

1. Créez des scripts de fichiers bash dans le WordPress . répertoire /scripts.

   Commencez `config_wordpress.sh` par créer avec le contenu suivant (si vous préférez, vous pouvez modifier directement le fichier wp-config.php).
**Note**  
Remplacez *DBName* par la valeur indiquée dans la RFC HA Stack (par exemple,`wordpress`).  
Remplacez *DB\$1MasterUsername* par la `MasterUsername` valeur indiquée dans la RFC HA Stack (par exemple,`admin`).  
Remplacez *DB\$1MasterUserPassword* par la `MasterUserPassword` valeur indiquée dans la RFC HA Stack (par exemple,`p4ssw0rd`).  
*DB\$1ENDPOINT*Remplacez-le par le nom DNS du point de terminaison dans les sorties d'exécution de la HA Stack RFC (par exemple,`srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com`). Vous pouvez le trouver dans l'[GetRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetRfc.html)opération (CLI : get-rfc --rfc-id RFC\$1ID) ou dans la page de détails de la RFC de la console AMS pour la RFC HA Stack que vous avez précédemment soumise.

   ```
   #!/bin/bash
   chmod -R 755 /var/www/html/WordPress
   cp /var/www/html/WordPress/wp-config-sample.php /var/www/html/WordPress/wp-config.php
   cd /var/www/html/WordPress
   sed -i "s/database_name_here/DBName/g" wp-config.php
   sed -i "s/username_here/DB_MasterUsername/g" wp-config.php
   sed -i "s/password_here/DB_MasterUserPassword/g" wp-config.php
   sed -i "s/localhost/DB_ENDPOINT/g" wp-config.php
   ```

1. Dans le même répertoire, créez `install_dependencies.sh` avec le contenu suivant :

   ```
   #!/bin/bash
   yum install -y php
   yum install -y php-mysql
   yum install -y mysql
   service httpd restart
   ```
**Note**  
Le protocole HTTPS est installé dans les données utilisateur au lancement afin de permettre aux contrôles de santé de fonctionner dès le départ.

1. Dans le même répertoire, créez `start_server.sh` avec le contenu suivant :
   + Pour les instances Amazon Linux, utilisez ceci :

     ```
     #!/bin/bash
     service httpd start
     ```
   + Pour les instances RHEL, utilisez ceci (les commandes supplémentaires sont des politiques qui autorisent SELINUX à accepter) : WordPress

     ```
     #!/bin/bash
     setsebool -P  httpd_can_network_connect_db 1
     setsebool -P  httpd_can_network_connect 1
     chcon -t httpd_sys_rw_content_t /var/www/html/WordPress/wp-content -R
     restorecon -Rv /var/www/html
     service httpd start
     ```

1. Dans le même répertoire, créez `stop_server.sh` avec le contenu suivant :

   ```
   #!/bin/bash
   service httpd stop
   ```

1. Créez le bundle zip.

   Linux :

   ```
   $ cd /tmp/WordPress
   $ zip -r wordpress.zip .
   ```

   Windows : Accédez à votre répertoire WordPress « », sélectionnez tous les fichiers et créez un fichier zip. N'oubliez pas de le nommer wordpress.zip.

1. Téléchargez le bundle d'applications dans le compartiment S3.

   Le bundle doit être en place pour continuer à déployer la pile. 

   Vous avez automatiquement accès à toutes les instances de compartiment S3 que vous créez. Vous pouvez y accéder via vos bastions ou via la console S3, et télécharger le WordPress bundle avec le fichier zip drag-and-drop ou en le recherchant et en le sélectionnant.

   Vous pouvez également utiliser la commande suivante dans une fenêtre shell ; assurez-vous que le chemin d'accès au fichier zip est correct :

   ```
   aws s3 cp wordpress.zip s3://BUCKET_NAME/
   ```

1. Déployez le bundle WordPress d'applications.

   La collecte des données suivantes avant de commencer accélérera le déploiement.

   DONNÉES REQUISES :
   + `VPC-ID`: Cette valeur détermine l'emplacement de votre compartiment S3. Utilisez le même ID VPC que celui que vous avez utilisé précédemment.
   + `CodeDeployApplicationName`et `CodeDeployApplicationName` : La `ApplicationName` valeur que vous avez utilisée dans la RFC HA 2-Tier Stack définit le CodeDeployApplicationName et le. CodeDeployDeploymentGroupName L'exemple utilise « WordPress », mais vous avez peut-être utilisé une valeur différente.
   + `S3Location`: Pour`S3Bucket`, utilisez celui `BucketName` que vous avez créé précédemment. Les `S3BundleType` et `S3Key` proviennent du bundle que vous avez ajouté à votre boutique S3.

   1. Exportez le schéma JSON des paramètres d'exécution pour le déploiement de CodeDeploy l'application CT dans un fichier JSON nommé Deploy CDApp Params.json.

      ```
      aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json
      ```

   1. Modifiez le schéma comme suit et enregistrez-le sous le nom, vous pouvez supprimer et remplacer le contenu.

      ```
      {
      "Description":                       "DeployWPCDApp",
      "VpcId":                             "VPC_ID",
      "Name":                              "WordPressCDAppDeploy",
      "TimeoutInMinutes":                  60,
      "Parameters":   {
          "CodeDeployApplicationName":                "WordPress",
          "CodeDeployDeploymentGroupName":            "WordPress",
          "CodeDeployIgnoreApplicationStopFailures":   false,
          "CodeDeployRevision": {
            "RevisionType": "S3",
            "S3Location": {
              "S3Bucket":     "BUCKET_NAME",
              "S3BundleType": "zip",
              "S3Key":        "wordpress.zip" }
              }
          }
      }
      ```

   1. Exportez le modèle JSON CreateRfc pour dans un fichier, dans votre dossier actuel, nommé Deploy CDApp RFC.json :

      ```
      aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json
      ```

   1. Modifiez et enregistrez le fichier Deploy CDApp RFC.json, vous pouvez supprimer et remplacer le contenu. Notez que `RequestedStartTime` et `RequestedEndTime` sont désormais facultatifs ; leur exclusion crée une RFC ASAP qui s'exécute dès qu'elle est approuvée (ce qui se produit généralement automatiquement). Pour soumettre une RFC planifiée, ajoutez ces valeurs.

      ```
      {
      "ChangeTypeVersion":    "1.0",
      "ChangeTypeId":         "ct-2edc3sd1sqmrb",
      "Title":                "CD-Deploy-For-WP-RFC"
      }
      ```

   1. Créez le RFC en spécifiant le fichier Deploy CDApp Rfc et le fichier de paramètres d'exécution de Deploy CDApp Params :

      ```
      aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json  --execution-parameters file://DeployCDAppParams.json
      ```

      Vous recevez RfcId le nouveau RFC dans la réponse. Enregistrez l'identifiant pour les étapes suivantes.

   1. Soumettez le RFC :

      ```
      aws amscm submit-rfc --rfc-id RFC_ID
      ```

      Si la RFC réussit, vous ne recevrez aucune sortie.

   1. Pour vérifier l'état de la RFC, exécutez

      ```
      aws amscm get-rfc --rfc-id RFC_ID
      ```

# Valider le déploiement de l'application
<a name="ex-validate-app-deploy"></a>

Accédez au point de terminaison (ELB CName) de l'équilibreur de charge créé précédemment, avec le WordPress chemin déployé :/. WordPress Exemples :

```
http://stack-ID-FOR-ELB.us-east-1.elb.amazonaws.com/WordPress
```

# Démanteler le déploiement de l'application
<a name="ex-tear-down-app-deploy"></a>

Une fois que vous aurez terminé le didacticiel, vous souhaiterez réduire le déploiement afin de ne pas avoir à vous facturer les ressources.

Voici une opération générique de suppression de pile. Vous devez le soumettre deux fois, une fois pour la pile HA à 2 niveaux et une fois pour la pile de compartiments S3. Enfin, soumettez une demande de service demandant que tous les instantanés du compartiment S3 (incluez l'ID de pile du compartiment S3 dans la demande de service) soient supprimés. Ils sont automatiquement supprimés au bout de 10 jours, mais leur suppression anticipée permet d'économiser un peu d'argent.

Cette procédure pas à pas fournit un exemple d'utilisation de la console AMS pour supprimer une pile S3 ; cette procédure s'applique à la suppression de toute pile à l'aide de la console AMS.
**Note**  
Si vous supprimez un compartiment S3, il doit d'abord être vidé de ses objets.

DONNÉES REQUISES :
+ `StackId`: La pile à utiliser. Vous pouvez le trouver en consultant la page AMS Console **Stacks**, disponible via un lien dans le menu de navigation de gauche. À l'aide de l'API/CLI AMS SKMS, exécutez la référence For the AMS SKMS API, voir l'onglet **Rapports** dans l'opération AWS Artifact Console (dans l'interface de ligne de commande). `list-stack-summaries`
+ L'identifiant du type de modification pour cette procédure pas à pas est « 1.0 ». Pour connaître la dernière version, exécutez cette commande : `ct-0q0bic0ywqk6c`

  ```
  aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-0q0bic0ywqk6c
  ```

*CRÉATION EN LIGNE* :
+ Émettez la commande create RFC avec les paramètres d'exécution fournis en ligne (évitez les guillemets lorsque vous fournissez des paramètres d'exécution en ligne). E

  ```
  aws amscm create-rfc --change-type-id "ct-0q0bic0ywqk6c" --change-type-version "1.0" --title "Delete My Stack" --execution-parameters "{\"StackId\":\"STACK_ID\"}"
  ```
+ Soumettez le RFC à l'aide de l'ID RFC renvoyé lors de l'opération de création du RFC. Jusqu'à ce qu'elle soit soumise, la RFC reste en l'`Editing`état et ne fait l'objet d'aucune action.

  ```
  aws amscm submit-rfc --rfc-id RFC_ID
  ```
+ Surveillez l'état de la RFC et visualisez le résultat de l'exécution :

  ```
  aws amscm get-rfc --rfc-id RFC_ID
  ```

*CRÉATION D'UN MODÈLE* :

1. Exportez le modèle RFC dans un fichier de votre dossier actuel ; l'exemple le nomme DeleteStackRfc .json :

   ```
   aws amscm create-rfc --generate-cli-skeleton > DeleteStackRfc.json
   ```

1. Modifiez et enregistrez le fichier DeleteStackRfc .json. Comme la suppression d'une pile ne comporte qu'un seul paramètre d'exécution, les paramètres d'exécution peuvent se trouver dans le fichier DeleteStackRfc .json lui-même (il n'est pas nécessaire de créer un fichier JSON distinct avec les paramètres d'exécution).

   Les guillemets internes de l'extension ExecutionParameters JSON doivent être masqués par une barre oblique inverse (\$1). Exemple sans heure de début et de fin :

   ```
   {
   "ChangeTypeVersion":    "1.0",
   "ChangeTypeId":         "ct-0q0bic0ywqk6c",
   "Title":                "Delete-My-Stack-RFC"
   "ExecutionParameters":  "{
           \"StackId\":\"STACK_ID\"}"
   }
   ```

1. Créez le RFC :

   ```
   aws amscm create-rfc --cli-input-json file://DeleteStackRfc.json 
   ```

   Vous recevez le code RfcId de la nouvelle RFC dans la réponse. Exemples :

   ```
   {
   "RfcId": "daaa1867-ffc5-1473-192a-842f6b326102"
   }
   ```

   Enregistrez l'identifiant pour les étapes suivantes.

1. Soumettez le RFC :

   ```
   aws amscm submit-rfc --rfc-id RFC_ID
   ```

   Si le RFC réussit, vous ne recevez aucune confirmation sur la ligne de commande.

1. Pour surveiller l'état de la demande et consulter le résultat de l'exécution, procédez comme suit :

   ```
   aws amscm get-rfc --rfc-id RFC_ID --query "Rfc.{Status:Status.Name,Exec:ExecutionOutput}" --output table
   ```