As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá. # Tutorial de CLI: pilha de duas camadas de alta disponibilidade (Linux/RHEL) Esta seção descreve como implantar uma pilha de duas camadas de alta disponibilidade (HA) em um ambiente AMS usando a CLI do AMS. **nota** Esse passo a passo de implantação foi testado em ambientes AMZN Linux e RHEL. Resumo das tarefas e tarefas necessárias RFCs: 1. Crie infraestrutura (pilha HA de dois níveis) 1. Crie um bucket S3 para aplicativos CodeDeploy 1. Crie o pacote de WordPress aplicativos e faça o upload para o bucket do S3 1. Implante o aplicativo com CodeDeploy 1. Acesse o WordPress site e faça login para validar a implantação # Antes de começar O Deployment \$1 Advanced Stack Components \$1 High Availability Two Tier Stack Advanced \$1 Create CT cria um grupo de Auto Scaling, um balanceador de carga, um banco de dados e CodeDeploy um nome de aplicativo e grupo de implantação (com o mesmo nome que você dá ao aplicativo). Para obter informações sobre, CodeDeploy consulte [O que é CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html) Este passo a passo usa uma RFC de pilha de duas camadas de alta disponibilidade (avançada) que inclui UserData e também descreve como criar um WordPress pacote que pode ser implantado. CodeDeploy O exemplo `UserData` mostrado no exemplo obtém metadados da instância, como ID da instância, região etc., de dentro de uma instância em execução, consultando o serviço de metadados da EC2 instância disponível em http://169.254.169.254/latest/meta-data/. Essa linha no script de dados do usuário:`REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')`, recupera o nome da zona de disponibilidade do serviço de metadados na variável \$1REGION de nossas regiões suportadas e a usa para preencher a URL do bucket do S3 em que o agente é baixado. CodeDeploy O IP 169.254.169.254 é roteável somente dentro da VPC (todos podem consultar o serviço). VPCs Para obter informações sobre o serviço, consulte [Metadados da instância e dados do usuário](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html). Observe também que os scripts inseridos como UserData são executados como usuário “root” e não precisam usar o comando “sudo”. Essa explicação passo a passo deixa os seguintes parâmetros no valor padrão (mostrado): + Grupo de 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` + Balanceador de carga:. `HealthCheckInterval=30, HealthCheckTimeout=5` + Banco de dados:`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`. + Aplicação:`DeploymentConfigName=CodeDeployDefault.OneAtATime`. + Balde S3:`AccessControl=Private`. CONFIGURAÇÕES ADICIONAIS: `RequestedStartTime`e `RequestedEndTime` se você quiser agendar sua RFC: você pode usar [Time.is](https://time.is/UTC) para determinar a hora UTC correta. Os exemplos fornecidos devem ser ajustados adequadamente. Uma RFC não pode continuar se a hora de início tiver passado. Como alternativa, você pode deixar esses valores desativados para criar um ASAP RFC que seja executado assim que as aprovações forem aprovadas. **nota** Há muitos parâmetros que você pode escolher definir de forma diferente dos mostrados. Os valores desses parâmetros mostrados no exemplo foram testados, mas podem não ser adequados para você. # Crie a infraestrutura Coletar os dados a seguir antes de começar fará com que a implantação seja mais rápida. OS DADOS NECESSÁRIOS TÊM UMA PILHA: + AutoScalingGroup: + `UserData`: esse valor é fornecido neste tutorial. Ele inclui comandos para configurar o recurso CodeDeploy e iniciar o CodeDeploy agente. + `AMI-ID`: esse valor determina que tipo de EC2 instâncias seu grupo de Auto Scaling (ASG) criará. Certifique-se de selecionar uma AMI em sua conta que comece com “cliente-” e seja do sistema operacional que você deseja. Encontre a AMI IDs com a referência da API For the AMS SKMS, consulte a guia **Relatórios** no AWS Artifact Console. operação (CLI: list-amis) ou no console do AMS -> página de detalhes. VPCs VPCs Este passo a passo é para ASGs configurar o uso de uma AMI Linux. + Banco de dados: + Esses parâmetros,`DBEngine`,`EngineVersion`, e `LicenseModel` devem ser definidos de acordo com sua situação, embora os valores mostrados no exemplo tenham sido testados. + Esses parâmetros,`RDSSubnetIds`,, `DBName``MasterUsername`, e `MasterUserPassword` são necessários ao implantar o pacote de aplicativos. Para RDSSubnet IDs, use duas sub-redes privadas. + LoadBalancer: + Esses parâmetros,`DBEngine`,`EngineVersion`, e `LicenseModel` devem ser definidos de acordo com sua situação, embora os valores mostrados no exemplo tenham sido testados. + `ELBSubnetIds`: Use duas sub-redes públicas. + Aplicativo: o `ApplicationName` valor define o nome do CodeDeploy aplicativo e o nome do grupo de CodeDeploy implantação. Você o usa para implantar seu aplicativo. Ele deve ser exclusivo na conta. Para verificar os CodeDeploy nomes da sua conta, consulte o CodeDeploy console. O exemplo usa "WordPress", mas, se você usar esse valor, certifique-se de que ele ainda não esteja em uso. Esse procedimento utiliza a CT de duas camadas (avançada) de alta disponibilidade (ct-06mjngx5flwto) e a CT de armazenamento Create S3 (ct-1a68ck03fn98r). Na sua conta autenticada, siga estas etapas na linha de comando. 1. Inicie a pilha de infraestrutura. 1. Envie os parâmetros de execução do esquema JSON para a pilha HA de duas camadas CT em um arquivo em sua pasta atual chamado .json. CreateStackParams ``` aws amscm get-change-type-version --change-type-id "ct-06mjngx5flwto" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateStackParams.json ``` 1. Modifique o esquema. Substitua o *variables* conforme apropriado. Por exemplo, use o sistema operacional que você deseja para as EC2 instâncias que o ASG criará. Grave o `ApplicationName` como você o usará posteriormente para implantar o aplicativo. Observe que você pode adicionar até 50 tags. ``` { "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. Envie o modelo CreateRfc JSON para um arquivo na sua pasta atual chamado CreateStackRfc .json: ``` aws amscm create-rfc --generate-cli-skeleton > CreateStackRfc.json ``` 1. Modifique o modelo RFC da seguinte forma e salve-o, você pode excluir e substituir o conteúdo. Observe que `RequestedStartTime` agora `RequestedEndTime` são opcionais; excluí-los cria um ASAP RFC que é executado assim que aprovado (o que geralmente acontece automaticamente). Para enviar um RFC agendado, adicione esses valores. ``` { "ChangeTypeVersion": "3.0", "ChangeTypeId": "ct-06mjngx5flwto", "Title": "HA-Stack-For-WP-RFC" } ``` 1. Crie o RFC, especificando o CreateStackRfc arquivo.json e o arquivo de parâmetros de execução CreateStackParams .json: ``` aws amscm create-rfc --cli-input-json file://CreateStackRfc.json --execution-parameters file://CreateStackParams.json ``` Você recebe o ID do RFC na resposta. Salve o ID para as etapas subsequentes. 1. Envie o RFC: ``` aws amscm submit-rfc --rfc-id RFC_ID ``` Se o RFC for bem-sucedido, você não receberá nenhuma saída. 1. Para verificar o status do RFC, execute ``` aws amscm get-rfc --rfc-id RFC_ID ``` Anote o ID do RFC. 1. Inicie um bucket S3 Coletar os dados a seguir antes de começar fará com que a implantação seja mais rápida. BUCKET S3 DE DADOS NECESSÁRIO: + `VPC-ID`: esse valor determina onde seu S3 Bucket estará. Use a mesma VPC ID que você usou anteriormente. + `BucketName`: esse valor define o nome do S3 Bucket, você o usa para carregar seu pacote de aplicativos. Ele deve ser exclusivo em toda a região da conta e não pode incluir letras maiúsculas. Incluir o ID da sua conta como parte do não BucketName é obrigatório, mas facilita a identificação posterior do bucket. Para ver quais nomes de bucket do S3 existem na conta, acesse o console do Amazon S3 da sua conta. 1. Envie os parâmetros de execução do esquema JSON para o armazenamento S3 create CT em um arquivo JSON chamado createS3 .json. StoreParams ``` aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3StoreParams.json ``` 1. Modifique o esquema da seguinte forma, você pode excluir e substituir o conteúdo. Substitua *VPC\$1ID* adequadamente. Os valores no exemplo foram testados, mas podem não ser adequados para você. **dica** O `BucketName` deve ser exclusivo em toda a região da conta e não pode incluir letras maiúsculas. Incluir o ID da sua conta como parte do não BucketName é obrigatório, mas facilita a identificação posterior do bucket. Para ver quais nomes de bucket do S3 existem na conta, acesse o console do Amazon S3 da sua conta. ``` { "Description": "S3BucketForWordPressBundle", "VpcId": "VPC_ID", "StackTemplateId": "stm-s2b72beb000000000", "Name": "S3BucketForWP", "TimeoutInMinutes": 60, "Parameters": { "AccessControl": "Private", "BucketName": "ACCOUNT_ID-BUCKET_NAME" } } ``` 1. Envie o modelo JSON CreateRfc para um arquivo, na sua pasta atual, chamado StoreRfc createS3 .json: ``` aws amscm create-rfc --generate-cli-skeleton > CreateS3StoreRfc.json ``` 1. Modifique e salve o arquivo CreateS3 StoreRfc .json, você pode excluir e substituir o conteúdo. Observe que `RequestedStartTime` agora `RequestedEndTime` são opcionais; excluí-los cria um ASAP RFC que é executado assim que aprovado (o que geralmente acontece automaticamente). Para enviar um RFC agendado, adicione esses valores. ``` { "ChangeTypeVersion": "1.0", "ChangeTypeId": "ct-1a68ck03fn98r", "Title": "S3-Stack-For-WP-RFC" } ``` 1. Crie o RFC, especificando o arquivo CreateS3 .json e o arquivo de parâmetros de execução CreateS3 StoreRfc .json: StoreParams ``` aws amscm create-rfc --cli-input-json file://CreateS3StoreRfc.json --execution-parameters file://CreateS3StoreParams.json ``` Você recebe o RfcId do novo RFC na resposta. Salve o ID para as etapas subsequentes. 1. Envie o RFC: ``` aws amscm submit-rfc --rfc-id RFC_ID ``` Se o RFC for bem-sucedido, você não receberá nenhuma saída. 1. Para verificar o status do RFC, execute ``` aws amscm get-rfc --rfc-id RFC_ID ``` # Crie, carregue e implante o aplicativo Primeiro, crie um pacote de WordPress aplicativos e, em seguida, use o CodeDeploy CTs para criar e implantar o aplicativo. 1. Baixe WordPress, extraia os arquivos e crie um. diretório /scripts. Comando Linux: ``` wget https://github.com/WordPress/WordPress/archive/master.zip ``` Windows: cole `https://github.com/WordPress/WordPress/archive/master.zip` em uma janela do navegador e baixe o arquivo zip. Crie um diretório temporário no qual montar o pacote. Linux ``` mkdir /tmp/WordPress ``` Windows: Crie um diretório WordPress "", você usará o caminho do diretório posteriormente. 1. Extraia a WordPress fonte para o diretório WordPress "" e crie um. diretório /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: vá para o diretório WordPress "" que você criou e crie um diretório de “scripts” lá. Se você estiver em um ambiente Windows, certifique-se de definir o tipo de interrupção dos arquivos de script como Unix (LF). No Notepad \$1\$1, essa é uma opção na parte inferior direita da janela. 1. Crie o arquivo CodeDeploy **appspec.yml**, no WordPress diretório (se estiver copiando o exemplo, verifique o recuo, cada espaço conta). IMPORTANTE: Certifique-se de que o caminho de “origem” esteja correto para copiar os WordPress arquivos (nesse caso, em seu WordPress diretório) para o destino esperado (/var/www/html/WordPress). No exemplo, o arquivo appspec.yml está no diretório com os WordPress arquivos, portanto, somente “/” é necessário. Além disso, mesmo que você tenha usado uma AMI RHEL para seu grupo de Auto Scaling, deixe a linha “os: linux” como está. Exemplo de arquivo 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. Crie scripts de arquivo bash no WordPress . diretório /scripts. Primeiro, crie `config_wordpress.sh` com o conteúdo a seguir (se preferir, você pode editar o arquivo wp-config.php diretamente). **nota** *DBName*Substitua pelo valor fornecido no HA Stack RFC (por exemplo,`wordpress`). *DB\$1MasterUsername*Substitua pelo `MasterUsername` valor fornecido no HA Stack RFC (por exemplo,`admin`). *DB\$1MasterUserPassword*Substitua pelo `MasterUserPassword` valor fornecido no HA Stack RFC (por exemplo,`p4ssw0rd`). *DB\$1ENDPOINT*Substitua pelo nome DNS do endpoint nas saídas de execução do HA Stack RFC (por exemplo,). `srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com` Você pode encontrar isso na [GetRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetRfc.html)operação (CLI: get-rfc --rfc-id RFC\$1ID) ou na página de detalhes do RFC do console AMS para o HA Stack RFC que você enviou 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. No mesmo diretório, crie `install_dependencies.sh` com o seguinte conteúdo: ``` #!/bin/bash yum install -y php yum install -y php-mysql yum install -y mysql service httpd restart ``` **nota** O HTTPS é instalado como parte dos dados do usuário no lançamento para permitir que as verificações de saúde funcionem desde o início. 1. No mesmo diretório, crie `start_server.sh` com o seguinte conteúdo: + Para instâncias do Amazon Linux, use isso: ``` #!/bin/bash service httpd start ``` + Para instâncias do RHEL, use isso (os comandos extras são políticas que permitem que o SELINUX aceite): 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. No mesmo diretório, crie `stop_server.sh` com o seguinte conteúdo: ``` #!/bin/bash service httpd stop ``` 1. Crie o pacote zip. Linux ``` $ cd /tmp/WordPress $ zip -r wordpress.zip . ``` Windows: Vá para o diretório WordPress "", selecione todos os arquivos e crie um arquivo zip, não se esqueça de chamá-lo de wordpress.zip. 1. Faça o upload do pacote de aplicativos no bucket do S3. O pacote precisa estar pronto para continuar implantando a pilha. Você tem acesso automático a qualquer instância de bucket do S3 que você criar. Você pode acessá-lo por meio de seus bastiões ou do console S3 e fazer o upload do WordPress pacote drag-and-drop ou navegar até o arquivo zip e selecioná-lo. Você também pode usar o seguinte comando em uma janela de shell; verifique se você tem o caminho correto para o arquivo zip: ``` aws s3 cp wordpress.zip s3://BUCKET_NAME/ ``` 1. Implante o pacote de WordPress aplicativos. Coletar os dados a seguir antes de começar fará com que a implantação seja mais rápida. DADOS NECESSÁRIOS: + `VPC-ID`: esse valor determina onde seu S3 Bucket estará. Use a mesma VPC ID que você usou anteriormente. + `CodeDeployApplicationName`e`CodeDeployApplicationName`: O `ApplicationName` valor que você usou no HA 2-Tier Stack RFC definiu o CodeDeployApplicationName e o. CodeDeployDeploymentGroupName O exemplo usa "WordPress", mas você pode ter usado um valor diferente. + `S3Location`: Para`S3Bucket`, use o `BucketName` que você criou anteriormente. Os `S3BundleType` e `S3Key` são do pacote que você colocou na sua loja S3. 1. Exiba os parâmetros de execução do esquema JSON para o CodeDeploy aplicativo deploy CT em um arquivo JSON chamado Deploy Params.json. CDApp ``` aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json ``` 1. Modifique o esquema da seguinte forma e salve-o como, você pode excluir e substituir o conteúdo. ``` { "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. Envie o modelo JSON CreateRfc para um arquivo, na sua pasta atual, chamado Deploy CDApp RFC.json: ``` aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json ``` 1. Modifique e salve o arquivo Deploy CDApp RFC.json, você pode excluir e substituir o conteúdo. Observe que `RequestedStartTime` agora `RequestedEndTime` são opcionais; excluí-los cria um ASAP RFC que é executado assim que aprovado (o que geralmente acontece automaticamente). Para enviar um RFC agendado, adicione esses valores. ``` { "ChangeTypeVersion": "1.0", "ChangeTypeId": "ct-2edc3sd1sqmrb", "Title": "CD-Deploy-For-WP-RFC" } ``` 1. Crie o RFC, especificando o arquivo Deploy CDApp Rfc e o arquivo de parâmetros de execução do Deploy CDApp Params: ``` aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json ``` Você recebe o RfcId do novo RFC na resposta. Salve o ID para as etapas subsequentes. 1. Envie o RFC: ``` aws amscm submit-rfc --rfc-id RFC_ID ``` Se o RFC for bem-sucedido, você não receberá nenhuma saída. 1. Para verificar o status do RFC, execute ``` aws amscm get-rfc --rfc-id RFC_ID ``` # Validar a implantação do aplicativo Navegue até o endpoint (ELB CName) do balanceador de carga criado anteriormente, com o caminho implantado:/. WordPress WordPress Por exemplo: ``` http://stack-ID-FOR-ELB.us-east-1.elb.amazonaws.com/WordPress ``` # Elimine a implantação de aplicativos Depois de concluir o tutorial, você deverá desmontar a implantação para não ser cobrado pelos recursos. A seguir está uma operação genérica de exclusão de pilha. Você vai querer enviá-lo duas vezes, uma para a pilha HA de 2 níveis e outra para a pilha de buckets S3. Como acompanhamento final, envie uma solicitação de serviço para que todos os snapshots do bucket do S3 (incluindo o ID da pilha do bucket do S3 na solicitação de serviço) sejam excluídos. Eles são excluídos automaticamente após 10 dias, mas excluí-los antecipadamente economiza um pouco de custo. Este passo a passo fornece um exemplo do uso do console AMS para excluir uma pilha do S3; esse procedimento se aplica à exclusão de qualquer pilha usando o console do AMS. **nota** Se você excluir um bucket do S3, primeiro ele deverá ser esvaziado de objetos. DADOS NECESSÁRIOS: + `StackId`: A pilha a ser usada. Você pode encontrar isso acessando a página AMS Console **Stacks**, disponível por meio de um link no painel de navegação esquerdo. Usando a API/CLI do AMS SKMS, execute a referência da API Para o AMS SKMS, consulte a **guia** Relatórios no AWS Artifact Console. operação (na CLI). `list-stack-summaries` + O ID do tipo de alteração para este passo a passo é`ct-0q0bic0ywqk6c`: a versão é “1.0". Para descobrir a versão mais recente, execute este comando: ``` aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-0q0bic0ywqk6c ``` *CRIAÇÃO EM LINHA*: + Execute o comando create RFC com os parâmetros de execução fornecidos em linha (aspas de escape ao fornecer parâmetros de execução em linha). E ``` aws amscm create-rfc --change-type-id "ct-0q0bic0ywqk6c" --change-type-version "1.0" --title "Delete My Stack" --execution-parameters "{\"StackId\":\"STACK_ID\"}" ``` + Envie a RFC usando a ID da RFC retornada na operação de criação da RFC. Até ser enviada, a RFC permanece no `Editing` estado e não é aplicada. ``` aws amscm submit-rfc --rfc-id RFC_ID ``` + Monitore o status da RFC e visualize a saída da execução: ``` aws amscm get-rfc --rfc-id RFC_ID ``` *CRIAÇÃO DE MODELO*: 1. Envie o modelo RFC para um arquivo em sua pasta atual; o exemplo o chama de DeleteStackRfc .json: ``` aws amscm create-rfc --generate-cli-skeleton > DeleteStackRfc.json ``` 1. Modifique e salve o DeleteStackRfc arquivo.json. Como a exclusão de uma pilha tem apenas um parâmetro de execução, os parâmetros de execução podem estar no próprio DeleteStackRfc arquivo.json (não há necessidade de criar um arquivo JSON separado com parâmetros de execução). As aspas internas na extensão ExecutionParameters JSON devem ser excluídas com uma barra invertida (\$1). Exemplo sem horário de início e término: ``` { "ChangeTypeVersion": "1.0", "ChangeTypeId": "ct-0q0bic0ywqk6c", "Title": "Delete-My-Stack-RFC" "ExecutionParameters": "{ \"StackId\":\"STACK_ID\"}" } ``` 1. Crie o RFC: ``` aws amscm create-rfc --cli-input-json file://DeleteStackRfc.json ``` Você recebe o RfcId do novo RFC na resposta. Por exemplo: ``` { "RfcId": "daaa1867-ffc5-1473-192a-842f6b326102" } ``` Salve o ID para as etapas subsequentes. 1. Envie o RFC: ``` aws amscm submit-rfc --rfc-id RFC_ID ``` Se o RFC for bem-sucedido, você não receberá nenhuma confirmação na linha de comando. 1. Para monitorar o status da solicitação e visualizar a Saída de Execução: ``` aws amscm get-rfc --rfc-id RFC_ID --query "Rfc.{Status:Status.Name,Exec:ExecutionOutput}" --output table ```