Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.
# Tutorial de CLI: pila de dos niveles de alta disponibilidad (Linux/RHEL)
En esta sección se describe cómo implementar una pila de dos niveles de alta disponibilidad (HA) en un entorno AMS mediante la CLI de AMS.
**nota**
Este tutorial de implementación se ha probado en entornos AMZN Linux y RHEL.
Resumen de las tareas y requisitos: RFCs
1. Cree una infraestructura (pila de dos niveles de alta disponibilidad)
1. Cree un bucket de S3 para aplicaciones CodeDeploy
1. Cree el paquete de WordPress aplicaciones y cárguelo en el bucket de S3
1. Implemente la aplicación con CodeDeploy
1. Acceda al WordPress sitio e inicie sesión para validar la implementación
# Antes de empezar
Deployment \$1 Advanced Stack Components \$1 High Availability Two Tier Stack Advanced \$1 Create CT crea un grupo de Auto Scaling, un balanceador de cargas, una base de datos y un nombre de CodeDeploy aplicación y un grupo de implementación (con el mismo nombre que le dé a la aplicación). Para obtener más información, CodeDeploy consulte [¿Qué es? CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
Este tutorial utiliza una RFC de dos niveles (avanzada) de alta disponibilidad que incluye UserData y también describe cómo crear un WordPress paquete que CodeDeploy se pueda implementar.
Lo que `UserData` se muestra en el ejemplo obtiene los metadatos de la instancia, como el ID de la instancia, la región, etc., de una instancia en ejecución consultando el servicio de metadatos de la EC2 instancia disponible en http://169.254.169.254/latest/meta-data/. Esta línea del script de datos de usuario:`REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')`, recupera el nombre de la zona de disponibilidad del servicio de metadatos y lo coloca en la variable \$1REGION de las regiones admitidas y lo usa para completar la URL del depósito de S3 donde se descarga el agente. CodeDeploy La IP 169.254.169.254 solo se puede enrutar dentro de la VPC (todos pueden consultar el servicio). VPCs [Para obtener información sobre el servicio, consulte Metadatos de instancia y datos de usuario.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) Tenga en cuenta también que los scripts introducidos como UserData se ejecutan como usuario «root» y no necesitan usar el comando «sudo».
Este tutorial deja los siguientes parámetros en el valor predeterminado (que se muestra):
+ Grupo 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 datos:`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`.
+ Solicitud:`DeploymentConfigName=CodeDeployDefault.OneAtATime`.
+ Cubeta S3:`AccessControl=Private`.
AJUSTES ADICIONALES:
`RequestedStartTime`y `RequestedEndTime` si quieres programar tu RFC: puedes usar [Time.is](https://time.is/UTC) para determinar la hora UTC correcta. Los ejemplos proporcionados deben ajustarse adecuadamente. Una RFC no puede continuar si ha pasado la hora de inicio. Como alternativa, puede omitir esos valores para crear un RFC ASAP que se ejecute en cuanto se aprueben las aprobaciones.
**nota**
Hay muchos parámetros que puede elegir configurar de forma diferente a la que se muestra. Los valores de los parámetros que se muestran en el ejemplo se han probado, pero es posible que no sean adecuados para usted.
# Cree la infraestructura
Si recopila los siguientes datos antes de empezar, la implementación será más rápida.
LOS DATOS NECESARIOS TIENEN UNA PILA:
+ AutoScalingGroup:
+ `UserData`: Este valor se proporciona en este tutorial. Incluye comandos para configurar el recurso CodeDeploy e iniciar el CodeDeploy agente.
+ `AMI-ID`: Este valor determina qué tipo de EC2 instancias activará su grupo de Auto Scaling (ASG). Asegúrese de seleccionar una AMI en su cuenta que comience por «customer-» y que sea del sistema operativo que desee. Busque la AMI IDs con la referencia de la API SKMS de AMS, consulte la pestaña **Informes** de la consola AWS Artifact Console. Operation (CLI: list-amis) o en la consola AMS -> página de detalles. VPCs VPCs Este tutorial es para ASGs configurar el uso de una AMI de Linux.
+ Base de datos:
+ Estos parámetros, `DBEngine``EngineVersion`, y `LicenseModel` deben configurarse de acuerdo con su situación, aunque se han probado los valores que se muestran en el ejemplo.
+ Estos parámetros, `RDSSubnetIds` `DBName``MasterUsername`, y `MasterUserPassword` son necesarios para implementar el paquete de aplicaciones. Para RDSSubnet los identificadores, utilice dos subredes privadas.
+ LoadBalancer:
+ Estos parámetros, `DBEngine``EngineVersion`, y `LicenseModel` deben configurarse de acuerdo con su situación, aunque se han probado los valores que se muestran en el ejemplo.
+ `ELBSubnetIds`: Utilice dos subredes públicas.
+ Aplicación: el `ApplicationName` valor establece el nombre de la CodeDeploy aplicación y el nombre del grupo de CodeDeploy implementación. Se usa para implementar la aplicación. Debe ser único en la cuenta. Para comprobar los CodeDeploy nombres de su cuenta, consulte la CodeDeploy consola. En el ejemplo se usa WordPress "" pero, si va a utilizar ese valor, asegúrese de que no esté ya en uso.
Este procedimiento utiliza el CT de pila de dos niveles (avanzado) de alta disponibilidad (ct-06mjngx5flwto) y el CT de almacenamiento Create S3 (ct-1a68ck03fn98r). Desde su cuenta autenticada, siga estos pasos en la línea de comandos.
1. Lanza la pila de infraestructuras.
1. Envía los parámetros de ejecución del esquema JSON de la pila de dos niveles de alta disponibilidad (CT) a un archivo de tu carpeta actual denominado CreateStackParams .json.
```
aws amscm get-change-type-version --change-type-id "ct-06mjngx5flwto" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateStackParams.json
```
1. Modifique el esquema. *variables*Sustitúyala según proceda. Por ejemplo, utilice el sistema operativo que desee para las EC2 instancias que cree el ASG. Guárdelo`ApplicationName`, ya que lo usará más adelante para implementar la aplicación. Tenga en cuenta que puede añadir hasta 50 etiquetas.
```
{
"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. Envía la plantilla CreateRfc JSON a un archivo de tu carpeta actual denominado CreateStackRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > CreateStackRfc.json
```
1. Modifique la plantilla RFC de la siguiente manera y guárdela; puede eliminar y reemplazar el contenido. Tenga en cuenta que `RequestedStartTime` ahora `RequestedEndTime` son opcionales; al excluirlos, se crea un RFC lo antes posible que se ejecuta tan pronto como se aprueba (lo que normalmente ocurre automáticamente). Para enviar una RFC programada, añada esos valores.
```
{
"ChangeTypeVersion": "3.0",
"ChangeTypeId": "ct-06mjngx5flwto",
"Title": "HA-Stack-For-WP-RFC"
}
```
1. Cree el RFC especificando el CreateStackRfc archivo.json y el archivo de parámetros de ejecución CreateStackParams .json:
```
aws amscm create-rfc --cli-input-json file://CreateStackRfc.json --execution-parameters file://CreateStackParams.json
```
Recibirás el ID de RFC en la respuesta. Guarde el ID para los pasos siguientes.
1. Envíe el RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Si la RFC es correcta, no recibirá ningún resultado.
1. Para comprobar el estado del RFC, ejecute
```
aws amscm get-rfc --rfc-id RFC_ID
```
Anote el ID de RFC.
1. Lance un bucket de S3
Si recopila los siguientes datos antes de empezar, la implementación será más rápida.
DEPÓSITO S3 DE DATOS NECESARIO:
+ `VPC-ID`: Este valor determina dónde estará su bucket de S3. Use el mismo ID de VPC que utilizó anteriormente.
+ `BucketName`: Este valor establece el nombre del bucket de S3, que se utiliza para cargar el paquete de aplicaciones. Debe ser único en toda la región de la cuenta y no puede incluir letras mayúsculas. No BucketName es obligatorio incluir tu ID de cuenta como parte de él, pero te permitirá identificar el segmento más adelante con más facilidad. Para ver qué nombres de bucket de S3 existen en la cuenta, vaya a la consola de Amazon S3 de su cuenta.
1. Genere los parámetros de ejecución del esquema JSON para el CT de creación del almacenamiento de S3 en un archivo JSON denominado CreateS3 StoreParams .json.
```
aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3StoreParams.json
```
1. Modifique el esquema de la siguiente manera, puede eliminar y reemplazar el contenido. Reemplace *VPC\$1ID* adecuadamente. Los valores del ejemplo se han probado, pero es posible que no sean adecuados para usted.
**sugerencia**
`BucketName`Deben ser únicos en la región de la cuenta y no pueden incluir letras mayúsculas. No BucketName es obligatorio incluir tu ID de cuenta como parte de él, pero te permitirá identificar el segmento más adelante con más facilidad. Para ver qué nombres de bucket de S3 existen en la cuenta, vaya a la consola de Amazon S3 de su cuenta.
```
{
"Description": "S3BucketForWordPressBundle",
"VpcId": "VPC_ID",
"StackTemplateId": "stm-s2b72beb000000000",
"Name": "S3BucketForWP",
"TimeoutInMinutes": 60,
"Parameters": {
"AccessControl": "Private",
"BucketName": "ACCOUNT_ID-BUCKET_NAME"
}
}
```
1. Envía la plantilla JSON CreateRfc a un archivo, en tu carpeta actual, denominado CreateS3 StoreRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > CreateS3StoreRfc.json
```
1. Modifique y guarde el archivo CreateS3 StoreRfc .json. Puede eliminar y reemplazar el contenido. Tenga en cuenta que `RequestedStartTime` ahora `RequestedEndTime` son opcionales; al excluirlos, se crea un RFC ASAP que se ejecuta tan pronto como se aprueba (lo que normalmente ocurre automáticamente). Para enviar una RFC programada, añada esos valores.
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-1a68ck03fn98r",
"Title": "S3-Stack-For-WP-RFC"
}
```
1. Cree el RFC especificando el archivo CreateS3 StoreRfc .json y el archivo de parámetros de ejecución StoreParams CreateS3 .json:
```
aws amscm create-rfc --cli-input-json file://CreateS3StoreRfc.json --execution-parameters file://CreateS3StoreParams.json
```
Recibirá el nuevo RFC en RfcId la respuesta. Guarde el ID para los pasos siguientes.
1. Envíe el RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Si la RFC es correcta, no recibirá ningún resultado.
1. Para comprobar el estado del RFC, ejecute
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Crear, cargar e implementar la aplicación
En primer lugar, cree un paquete de WordPress aplicaciones y, a continuación, utilice el CodeDeploy CTs para crear e implementar la aplicación.
1. Descargue WordPress, extraiga los archivos y cree un. directorio /scripts.
Comando de Linux:
```
wget https://github.com/WordPress/WordPress/archive/master.zip
```
Windows: pégalo `https://github.com/WordPress/WordPress/archive/master.zip` en una ventana del navegador y descarga el archivo zip.
Cree un directorio temporal en el que ensamblar el paquete.
Linux:
```
mkdir /tmp/WordPress
```
Windows: cree un directorio WordPress «», utilizará la ruta del directorio más adelante.
1. Extraiga la WordPress fuente al directorio WordPress «» y cree un. directorio /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: vaya al directorio «WordPress» que creó y cree allí un directorio de «scripts».
Si se encuentra en un entorno Windows, asegúrese de establecer el tipo de interrupción de los archivos de script en Unix (LF). En Notepad \$1\$1, esta opción se encuentra en la parte inferior derecha de la ventana.
1. Cree el archivo CodeDeploy **appspec.yml** en el WordPress directorio (si va a copiar el ejemplo, compruebe la hendidura, cada espacio cuenta). IMPORTANTE: Asegúrese de que la ruta «fuente» sea correcta para copiar los WordPress archivos (en este caso, en su WordPress directorio) al destino esperado (/). var/www/html/WordPress En el ejemplo, el archivo appspec.yml está en el directorio con los WordPress archivos, por lo que solo se necesita «/». Además, aunque haya utilizado una AMI de RHEL para su grupo de Auto Scaling, deje la línea «os: linux» tal como está. Ejemplo de archivo 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. Cree scripts de archivos bash en. WordPress directorio /scripts.
En primer lugar, cree `config_wordpress.sh` con el siguiente contenido (si lo prefiere, puede editar el archivo wp-config.php directamente).
**nota**
*DBName*Sustitúyalo por el valor indicado en el RFC de HA Stack (por ejemplo,`wordpress`).
*DB\$1MasterUsername*Sustitúyalo por el `MasterUsername` valor indicado en el RFC de HA Stack (por ejemplo,`admin`).
*DB\$1MasterUserPassword*Sustitúyalo por el `MasterUserPassword` valor indicado en el RFC de HA Stack (por ejemplo,`p4ssw0rd`).
*DB\$1ENDPOINT*Sustitúyalo por el nombre DNS del punto final en los resultados de ejecución del RFC de la pila HA (por ejemplo,`srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com`). Puede encontrarlo en la [GetRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetRfc.html)operación (CLI: get-rfc --rfc-id RFC\$1ID) o en la página de detalles del RFC de la consola AMS para el RFC de la pila de alta disponibilidad que envió anteriormente.
```
#!/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. En `install_dependencies.sh` el mismo directorio, cree con el siguiente contenido:
```
#!/bin/bash
yum install -y php
yum install -y php-mysql
yum install -y mysql
service httpd restart
```
**nota**
HTTPS se instala como parte de los datos del usuario en el momento del lanzamiento para permitir que las comprobaciones de estado funcionen desde el principio.
1. En el mismo directorio, cree `start_server.sh` con el siguiente contenido:
+ Para las instancias de Amazon Linux, usa lo siguiente:
```
#!/bin/bash
service httpd start
```
+ Para las instancias de RHEL, usa esto (los comandos adicionales son políticas que permiten que SELINUX las acepte): 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. En el mismo directorio, cree `stop_server.sh` con el siguiente contenido:
```
#!/bin/bash
service httpd stop
```
1. Cree el paquete zip.
Linux:
```
$ cd /tmp/WordPress
$ zip -r wordpress.zip .
```
Windows: Ve a tu directorio WordPress «», selecciona todos los archivos y crea un archivo zip, asegúrate de llamarlo wordpress.zip.
1. Cargue el paquete de aplicaciones en el bucket de S3.
El paquete debe estar en su lugar para poder seguir desplegando la pila.
Tendrá acceso automáticamente a cualquier instancia de bucket de S3 que cree. Puedes acceder a él a través de tus bastiones o a través de la consola S3 y cargar el WordPress paquete con el archivo zip drag-and-drop o buscarlo y seleccionarlo.
También puedes usar el siguiente comando en una ventana de shell; asegúrate de tener la ruta correcta al archivo zip:
```
aws s3 cp wordpress.zip s3://BUCKET_NAME/
```
1. Implemente el paquete de WordPress aplicaciones.
Si recopila los siguientes datos antes de empezar, la implementación será más rápida.
DATOS NECESARIOS:
+ `VPC-ID`: Este valor determina dónde estará su bucket de S3. Use el mismo ID de VPC que utilizó anteriormente.
+ `CodeDeployApplicationName`y`CodeDeployApplicationName`: El `ApplicationName` valor que utilizó en el RFC de pila de 2 niveles de HA estableció el y el CodeDeployApplicationName . CodeDeployDeploymentGroupName En el ejemplo se utiliza «WordPress», pero es posible que haya utilizado un valor diferente.
+ `S3Location`: Para`S3Bucket`, usa el `BucketName` que creaste anteriormente. Los `S3BundleType` y `S3Key` son del paquete que pusiste en tu tienda S3.
1. Genera el esquema JSON de los parámetros de ejecución para la CodeDeploy aplicación Deploy Params.json en un archivo JSON denominado Deploy CDApp Params.json.
```
aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json
```
1. Modifique el esquema de la siguiente manera y guárdelo como, puede eliminar y reemplazar el contenido.
```
{
"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. Envía la plantilla JSON CreateRfc a un archivo, en tu carpeta actual, denominado Deploy CDApp RFC.json:
```
aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json
```
1. Modifica y guarda el archivo Deploy CDApp RFC.json. Puedes eliminar y reemplazar el contenido. Tenga en cuenta que `RequestedStartTime` ahora `RequestedEndTime` son opcionales; al excluirlos, se crea un RFC ASAP que se ejecuta tan pronto como se aprueba (lo que normalmente ocurre automáticamente). Para enviar una RFC programada, añada esos valores.
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-2edc3sd1sqmrb",
"Title": "CD-Deploy-For-WP-RFC"
}
```
1. Cree la RFC especificando el archivo CDApp Rfc de despliegue y el archivo de parámetros de ejecución de Deploy CDApp Params:
```
aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json
```
Recibirá el RfcId nuevo RFC en la respuesta. Guarde el ID para los pasos siguientes.
1. Envíe el RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Si la RFC es correcta, no recibirá ningún resultado.
1. Para comprobar el estado del RFC, ejecute
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Validar el despliegue de la aplicación
Navegue hasta el punto final (ELB CName) del balanceador de cargas creado anteriormente, con la ruta implementada:/. WordPress WordPress Por ejemplo:
```
http://stack-ID-FOR-ELB.us-east-1.elb.amazonaws.com/WordPress
```
# Destruya la implementación de aplicaciones
Cuando termines con el tutorial, querrás desmantelar el despliegue para que no te cobren por los recursos.
La siguiente es una operación genérica de eliminación de pilas. Deberá enviarla dos veces, una para la pila de 2 niveles de alta disponibilidad y otra para la pila de cubos de S3. Como seguimiento final, envíe una solicitud de servicio para que se eliminen todas las instantáneas del bucket de S3 (incluya el ID de la pila de S3 en la solicitud de servicio). Se eliminan automáticamente al cabo de 10 días, pero eliminarlas anticipadamente supone un pequeño ahorro de costes.
Este tutorial proporciona un ejemplo del uso de la consola AMS para eliminar una pila S3; este procedimiento se aplica a la eliminación de cualquier pila mediante la consola AMS.
**nota**
Si borras un depósito de S3, primero debes vaciarlo de objetos.
DATOS NECESARIOS:
+ `StackId`: La pila que se va a utilizar. Puedes encontrarlo consultando la página de **pilas** de consolas de AMS, disponible a través de un enlace en la barra de navegación izquierda. Con la API/CLI de AMS SKMS, ejecute la operación Para la referencia de la API de AMS SKMS, consulte la pestaña **Informes** de la AWS Artifact Console. (en la CLI). `list-stack-summaries`
+ El identificador de tipo de cambio para este tutorial es que la versión es `ct-0q0bic0ywqk6c` «1.0". Para averiguar cuál es la versión más reciente, ejecute este comando:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-0q0bic0ywqk6c
```
*CREACIÓN* EN LÍNEA:
+ Ejecute el comando create RFC con los parámetros de ejecución proporcionados en línea (comillas de escape cuando se proporcionan los parámetros de ejecución en línea). E
```
aws amscm create-rfc --change-type-id "ct-0q0bic0ywqk6c" --change-type-version "1.0" --title "Delete My Stack" --execution-parameters "{\"StackId\":\"STACK_ID\"}"
```
+ Envíe la RFC mediante el ID de RFC devuelto en la operación de creación de la RFC. Hasta que se envíe, la RFC permanece en ese `Editing` estado y no se toman medidas al respecto.
```
aws amscm submit-rfc --rfc-id RFC_ID
```
+ Supervise el estado de la RFC y vea el resultado de la ejecución:
```
aws amscm get-rfc --rfc-id RFC_ID
```
*CREACIÓN DE PLANTILLA*:
1. Envía la plantilla RFC a un archivo de tu carpeta actual; el ejemplo la nombra DeleteStackRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > DeleteStackRfc.json
```
1. Modifique y guarde el DeleteStackRfc archivo.json. Como la eliminación de una pila solo tiene un parámetro de ejecución, los parámetros de ejecución pueden estar en el propio DeleteStackRfc archivo.json (no es necesario crear un archivo JSON independiente con los parámetros de ejecución).
Las comillas internas de la extensión ExecutionParameters JSON deben ir precedidas de una barra invertida (\$1). Ejemplo sin hora de inicio y finalización:
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-0q0bic0ywqk6c",
"Title": "Delete-My-Stack-RFC"
"ExecutionParameters": "{
\"StackId\":\"STACK_ID\"}"
}
```
1. Cree el RFC:
```
aws amscm create-rfc --cli-input-json file://DeleteStackRfc.json
```
Recibirá el RfcId nuevo RFC en la respuesta. Por ejemplo:
```
{
"RfcId": "daaa1867-ffc5-1473-192a-842f6b326102"
}
```
Guarde el ID para los pasos siguientes.
1. Envíe el RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Si la RFC se realiza correctamente, no recibirá ninguna confirmación en la línea de comandos.
1. Para supervisar el estado de la solicitud y ver el resultado de la ejecución:
```
aws amscm get-rfc --rfc-id RFC_ID --query "Rfc.{Status:Status.Name,Exec:ExecutionOutput}" --output table
```