Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Tutorial CLI: Stack a due livelli ad alta disponibilità (Linux/RHEL)
Questa sezione descrive come implementare uno stack a due livelli ad alta disponibilità (HA) in un ambiente AMS utilizzando l'AMS CLI.
**Nota**
Questa procedura dettagliata di implementazione è stata testata in ambienti AMZN Linux e RHEL.
Riepilogo delle attività e dei requisiti richiesti: RFCs
1. Crea un'infrastruttura (stack HA a due livelli)
1. Crea un bucket S3 per le applicazioni CodeDeploy
1. Crea il pacchetto di WordPress applicazioni e caricalo nel bucket S3
1. Distribuisci l'applicazione con CodeDeploy
1. Accedi al WordPress sito e accedi per convalidare la distribuzione
# Prima di iniziare
The Deployment \$1 Advanced Stack Components \$1 High Availability Two Tier Stack Advanced \$1 Create CT crea un gruppo Auto Scaling, un load balancer, un database e CodeDeploy un nome di applicazione e un gruppo di implementazione (con lo stesso nome assegnato all'applicazione). [Per informazioni su CodeDeploy , consulta What is? CodeDeploy](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
Questa procedura dettagliata utilizza un RFC High Availability Two-Tier Stack (Advanced) che include UserData e descrive anche come creare un WordPress pacchetto da distribuire. CodeDeploy
L'esempio `UserData` illustrato nell'esempio ottiene i metadati dell'istanza, come l'ID dell'istanza, la regione e così via, dall'interno di un'istanza in esecuzione interrogando il servizio di metadati dell'istanza disponibile all'indirizzo http://169.254.169.254/latest/meta-data/. EC2 Questa riga dello script dei dati utente:`REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')`, recupera il nome della zona di disponibilità dal servizio di metadati nella variabile \$1REGION per le nostre regioni supportate e lo utilizza per completare l'URL per il bucket S3 in cui viene scaricato l'agente. CodeDeploy L'IP 169.254.169.254 è instradabile solo all'interno del VPC (tutti possono interrogare il servizio). VPCs [Per informazioni sul servizio, consulta Metadati dell'istanza e dati utente.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) Nota anche che gli script immessi come UserData vengono eseguiti come utente «root» e non è necessario utilizzare il comando «sudo».
Questa procedura dettagliata lascia i seguenti parametri al valore predefinito (mostrato):
+ Gruppo 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`
+ Banca dati:`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`.
+ Applicazione:`DeploymentConfigName=CodeDeployDefault.OneAtATime`.
+ Secchio S3:. `AccessControl=Private`
IMPOSTAZIONI AGGIUNTIVE:
`RequestedStartTime`e `RequestedEndTime` se desideri pianificare la tua RFC: puoi usare [Time.is](https://time.is/UTC) per determinare l'ora UTC corretta. Gli esempi forniti devono essere modificati in modo appropriato. Una RFC non può procedere se è trascorsa l'ora di inizio. In alternativa, puoi lasciare questi valori disattivati per creare un RFC ASAP che venga eseguito non appena vengono approvate.
**Nota**
Ci sono molti parametri che potreste scegliere di impostare in modo diverso da quelli mostrati. I valori dei parametri mostrati nell'esempio sono stati testati ma potrebbero non essere adatti a te.
# Crea l'infrastruttura
La raccolta dei seguenti dati prima di iniziare velocizzerà la distribuzione.
I DATI RICHIESTI HANNO UNO STACK:
+ AutoScalingGroup:
+ `UserData`: Questo valore è fornito in questo tutorial. Include comandi per configurare la risorsa CodeDeploy e avviare l' CodeDeploy agente.
+ `AMI-ID`: Questo valore determina il tipo di EC2 istanze che verrà avviato dal gruppo Auto Scaling (ASG). Assicurati di selezionare nel tuo account un'AMI che inizi con «cliente-» e sia del sistema operativo che desideri. Trova AMI IDs con il riferimento all'API Per l'AMS SKMS, consulta la scheda **Report** nella Console AWS Artifact. operation (CLI: list-amis) o nella pagina dei dettagli della console AMS ->. VPCs VPCs Questa procedura dettagliata è destinata alla ASGs configurazione per l'utilizzo di un'AMI Linux.
+ Database:
+ Questi parametri, `DBEngine``EngineVersion`, `LicenseModel` devono essere impostati in base alla situazione, sebbene i valori mostrati nell'esempio siano stati testati.
+ Questi parametri,`RDSSubnetIds`, `DBName``MasterUsername`, e `MasterUserPassword` sono necessari per la distribuzione del pacchetto di applicazioni. Per gli RDSSubnet ID, utilizzate due sottoreti private.
+ LoadBalancer:
+ Questi parametri, `DBEngine``EngineVersion`, `LicenseModel` devono essere impostati in base alla situazione, sebbene i valori mostrati nell'esempio siano stati testati.
+ `ELBSubnetIds`: utilizza due sottoreti pubbliche.
+ Applicazione: il `ApplicationName` valore imposta il nome dell' CodeDeploy applicazione e il nome del gruppo CodeDeploy di distribuzione. Lo usi per distribuire la tua applicazione. Deve essere unico nell'account. Per verificare la presenza di CodeDeploy nomi nel tuo account, consulta la CodeDeploy Console. L'esempio utilizza "WordPress" ma, se intendi utilizzare quel valore, assicurati che non sia già in uso.
Questa procedura utilizza lo stack a due livelli ad alta disponibilità (avanzato) CT (ct-06mjngx5flwto) e lo storage CT Create S3 (ct-1a68ck03fn98r). Dal tuo account autenticato, segui questi passaggi nella riga di comando.
1. Avvia lo stack di infrastruttura.
1. Invia lo schema JSON dei parametri di esecuzione per lo stack CT a due livelli HA in un file nella cartella corrente denominata .json. CreateStackParams
```
aws amscm get-change-type-version --change-type-id "ct-06mjngx5flwto" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateStackParams.json
```
1. Modifica lo schema. Sostituire *variables* il file appropriato. Ad esempio, utilizzate il sistema operativo desiderato per EC2 le istanze che l'ASG creerà. Registratele `ApplicationName` mentre le utilizzerete in seguito per distribuire l'applicazione. Tieni presente che puoi aggiungere fino a 50 tag.
```
{
"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. Esporta il modello CreateRfc JSON in un file nella cartella corrente denominata CreateStackRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > CreateStackRfc.json
```
1. Modifica il modello RFC come segue e salvalo, puoi eliminare e sostituire i contenuti. Tieni presente che `RequestedStartTime` ora `RequestedEndTime` sono facoltativi; la loro esclusione crea un RFC ASAP che viene eseguito non appena viene approvato (cosa che di solito avviene automaticamente). Per inviare una RFC pianificata, aggiungi questi valori.
```
{
"ChangeTypeVersion": "3.0",
"ChangeTypeId": "ct-06mjngx5flwto",
"Title": "HA-Stack-For-WP-RFC"
}
```
1. Crea la RFC, specificando il CreateStackRfc file.json e il file dei parametri di esecuzione .json: CreateStackParams
```
aws amscm create-rfc --cli-input-json file://CreateStackRfc.json --execution-parameters file://CreateStackParams.json
```
Riceverai l'ID RFC nella risposta. Salva l'ID per i passaggi successivi.
1. Invia la RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Se la RFC ha esito positivo, non riceverai alcun output.
1. Per verificare lo stato della RFC, esegui
```
aws amscm get-rfc --rfc-id RFC_ID
```
Prendi nota dell'ID RFC.
1. Avvia un bucket S3
La raccolta dei seguenti dati prima di iniziare velocizzerà la distribuzione.
BUCKET S3 DI DATI RICHIESTO:
+ `VPC-ID`: questo valore determina dove sarà il tuo S3 Bucket. Usa lo stesso ID VPC che hai usato in precedenza.
+ `BucketName`: Questo valore imposta il nome del bucket S3, lo usi per caricare il pacchetto dell'applicazione. Deve essere univoco in tutta l'area dell'account e non può includere lettere maiuscole. L'inclusione dell'ID dell'account come parte di non BucketName è un requisito, ma semplifica l'identificazione del bucket in un secondo momento. Per vedere quali nomi di bucket S3 esistono nell'account, accedi alla console Amazon S3 del tuo account.
1. Invia lo schema JSON dei parametri di esecuzione per lo storage S3, crea CT in un file JSON denominato CreateS3 .json. StoreParams
```
aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3StoreParams.json
```
1. Modifica lo schema come segue, puoi eliminare e sostituire i contenuti. Sostituisci *VPC\$1ID* in modo appropriato. I valori dell'esempio sono stati testati, ma potrebbero non essere adatti a te.
**Suggerimento**
`BucketName`Devono essere univoci in tutta l'area dell'account e non possono includere lettere maiuscole. L'inclusione dell'ID dell'account come parte di non BucketName è un requisito, ma semplifica l'identificazione del bucket in un secondo momento. Per vedere quali nomi di bucket S3 esistono nell'account, accedi alla console Amazon S3 del tuo account.
```
{
"Description": "S3BucketForWordPressBundle",
"VpcId": "VPC_ID",
"StackTemplateId": "stm-s2b72beb000000000",
"Name": "S3BucketForWP",
"TimeoutInMinutes": 60,
"Parameters": {
"AccessControl": "Private",
"BucketName": "ACCOUNT_ID-BUCKET_NAME"
}
}
```
1. Esporta il modello JSON in un file, nella cartella corrente, denominato CreateS3 .json: CreateRfc StoreRfc
```
aws amscm create-rfc --generate-cli-skeleton > CreateS3StoreRfc.json
```
1. Modifica e salva il file CreateS3 StoreRfc .json, puoi eliminare e sostituire il contenuto. Tieni presente che `RequestedStartTime` ora `RequestedEndTime` sono facoltativi; la loro esclusione crea un RFC ASAP che viene eseguito non appena viene approvato (cosa che di solito avviene automaticamente). Per inviare una RFC pianificata, aggiungi questi valori.
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-1a68ck03fn98r",
"Title": "S3-Stack-For-WP-RFC"
}
```
1. Crea la RFC, specificando il file CreateS3 .json e il file dei parametri di esecuzione CreateS3 StoreRfc .json: StoreParams
```
aws amscm create-rfc --cli-input-json file://CreateS3StoreRfc.json --execution-parameters file://CreateS3StoreParams.json
```
Riceverai il nuovo RFC nella risposta. RfcId Salva l'ID per i passaggi successivi.
1. Invia la RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Se la RFC ha esito positivo, non riceverai alcun output.
1. Per verificare lo stato della RFC, esegui
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Crea, carica e distribuisci l'applicazione
Innanzitutto, create un pacchetto di WordPress applicazioni, quindi utilizzate il CodeDeploy CTs per creare e distribuire l'applicazione.
1. Scarica WordPress, estrai i file e crea un file. cartella /scripts.
Comando Linux:
```
wget https://github.com/WordPress/WordPress/archive/master.zip
```
Windows: incolla `https://github.com/WordPress/WordPress/archive/master.zip` in una finestra del browser e scarica il file zip.
Crea una directory temporanea in cui assemblare il pacchetto.
Linux:
```
mkdir /tmp/WordPress
```
Windows: crea una cartella "WordPress", utilizzerai il percorso della directory in seguito.
1. Estrai il WordPress codice sorgente nella cartella WordPress "" e crea un file. cartella /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: vai alla cartella "WordPress" che hai creato e lì crea una cartella «scripts».
Se utilizzate un ambiente Windows, assicuratevi di impostare il tipo di interruzione per i file di script su Unix (LF). In Notepad \$1\$1, questa è un'opzione in basso a destra della finestra.
1. Crea il file CodeDeploy **appspec.yml**, nella WordPress directory (se copi l'esempio, controlla l'indentazione, ogni spazio conta). IMPORTANTE: assicurati che il percorso «sorgente» sia corretto per copiare WordPress i file (in questo caso, nella tua WordPress directory) nella destinazione prevista (/). var/www/html/WordPress Nell'esempio, il file appspec.yml si trova nella directory con WordPress i file, quindi è necessario solo «/». Inoltre, anche se hai usato un'AMI RHEL per il tuo gruppo Auto Scaling, lascia la riga «os: linux» così com'è. Esempio di file 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. Crea script di file bash in. WordPress cartella /scripts.
Innanzitutto, crea `config_wordpress.sh` con il seguente contenuto (se preferisci, puoi modificare direttamente il file wp-config.php).
**Nota**
Sostituisci *DBName* con il valore fornito nell'HA Stack RFC (ad esempio,`wordpress`).
Sostituisci *DB\$1MasterUsername* con il `MasterUsername` valore fornito nell'HA Stack RFC (ad esempio,). `admin`
Sostituisci *DB\$1MasterUserPassword* con il `MasterUserPassword` valore fornito nell'HA Stack RFC (ad esempio,). `p4ssw0rd`
Sostituire *DB\$1ENDPOINT* con il nome DNS dell'endpoint negli output di esecuzione di HA Stack RFC (ad esempio,). `srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com` Puoi trovarlo con l'[GetRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetRfc.html)operazione (CLI: get-rfc --rfc-id RFC\$1ID) o nella pagina dei dettagli RFC della console AMS per l'HA Stack RFC che hai inviato in precedenza.
```
#!/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. `install_dependencies.sh`Nella stessa directory, crea con il seguente contenuto:
```
#!/bin/bash
yum install -y php
yum install -y php-mysql
yum install -y mysql
service httpd restart
```
**Nota**
HTTPS viene installato come parte dei dati utente al momento del lancio per consentire il funzionamento dei controlli sanitari sin dall'inizio.
1. Nella stessa directory, crea `start_server.sh` con il seguente contenuto:
+ Per le istanze Amazon Linux, usa questo:
```
#!/bin/bash
service httpd start
```
+ Per le istanze RHEL, usa questo (i comandi aggiuntivi sono politiche che consentono a SELINUX di accettare): 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. Nella stessa directory create `stop_server.sh` con il seguente contenuto:
```
#!/bin/bash
service httpd stop
```
1. Crea il pacchetto zip.
Linux:
```
$ cd /tmp/WordPress
$ zip -r wordpress.zip .
```
Windows: vai alla cartella WordPress "" e seleziona tutti i file e crea un file zip, assicurati di chiamarlo wordpress.zip.
1. Carica il pacchetto dell'applicazione nel bucket S3.
Il pacchetto deve essere disponibile per continuare a distribuire lo stack.
Hai automaticamente accesso a qualsiasi istanza di bucket S3 che crei. Puoi accedervi tramite i tuoi bastioni o tramite la console S3 e caricare il WordPress pacchetto drag-and-drop o sfogliare e selezionare il file zip.
Puoi anche usare il seguente comando in una finestra di shell; assicurati di avere il percorso corretto del file zip:
```
aws s3 cp wordpress.zip s3://BUCKET_NAME/
```
1. Distribuite il pacchetto di WordPress applicazioni.
La raccolta dei seguenti dati prima di iniziare velocizzerà la distribuzione.
DATI RICHIESTI:
+ `VPC-ID`: Questo valore determina dove si troverà il tuo S3 Bucket. Usa lo stesso ID VPC che hai usato in precedenza.
+ `CodeDeployApplicationName`e`CodeDeployApplicationName`: il `ApplicationName` valore utilizzato nell'RFC HA 2-Tier Stack imposta e il. CodeDeployApplicationName CodeDeployDeploymentGroupName L'esempio utilizza "WordPress" ma potresti aver usato un valore diverso.
+ `S3Location`: Per`S3Bucket`, usa quello `BucketName` che hai creato in precedenza. I `S3BundleType` e `S3Key` provengono dal pacchetto che hai inserito nel tuo negozio S3.
1. Emetti lo schema JSON dei parametri di esecuzione per l' CodeDeploy applicazione, distribuisci CT in un file JSON denominato Deploy Params.json. CDApp
```
aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json
```
1. Modifica lo schema come segue e salvalo come, puoi eliminare e sostituire i contenuti.
```
{
"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. Esporta il modello JSON CreateRfc per in un file, nella cartella corrente, denominato Deploy CDApp RFC.json:
```
aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json
```
1. Modifica e salva il file Deploy CDApp RFC.json, puoi eliminare e sostituire il contenuto. Tieni presente che `RequestedStartTime` ora `RequestedEndTime` sono facoltativi; la loro esclusione crea un RFC ASAP che viene eseguito non appena viene approvato (cosa che di solito avviene automaticamente). Per inviare una RFC pianificata, aggiungi questi valori.
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-2edc3sd1sqmrb",
"Title": "CD-Deploy-For-WP-RFC"
}
```
1. Crea la RFC, specificando il file Deploy CDApp Rfc e il file dei parametri di esecuzione CDApp Deploy Params:
```
aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json
```
Riceverai il nuovo RFC nella RfcId risposta. Salva l'ID per i passaggi successivi.
1. Invia la RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Se la RFC ha esito positivo, non riceverai alcun output.
1. Per verificare lo stato della RFC, esegui
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Convalida della distribuzione dell'applicazione
Passa all'endpoint (ELB CName) del sistema di bilanciamento del carico creato in precedenza, con il percorso distribuito:/. WordPress WordPress Ad esempio:
```
http://stack-ID-FOR-ELB.us-east-1.elb.amazonaws.com/WordPress
```
# Riduci la distribuzione delle applicazioni
Una volta terminato il tutorial, ti consigliamo di interrompere l'implementazione in modo da non farti pagare per le risorse.
Di seguito è riportata un'operazione generica di eliminazione dello stack. Ti consigliamo di inviarla due volte, una per lo stack HA 2-Tier e una volta per lo stack di bucket S3. Come ultima operazione, invia una richiesta di servizio per eliminare tutte le istantanee per il bucket S3 (include l'ID dello stack del bucket S3 nella richiesta di servizio). Vengono eliminati automaticamente dopo 10 giorni, ma eliminarli anticipatamente consente di risparmiare un po' di costi.
Questa procedura dettagliata fornisce un esempio di utilizzo della console AMS per eliminare uno stack S3; questa procedura si applica all'eliminazione di qualsiasi stack utilizzando la console AMS.
**Nota**
Se si elimina un bucket S3, è necessario prima svuotarlo degli oggetti.
DATI RICHIESTI:
+ `StackId`: Lo stack da usare. Puoi trovarlo consultando la pagina AMS Console **Stacks**, disponibile tramite un link nel menu di navigazione a sinistra. Utilizzando l'API/CLI AMS SKMS, esegui il riferimento per l'API AMS SKMS, consulta la **scheda** Report nella Console AWS Artifact. Operazione (nella CLI). `list-stack-summaries`
+ L'ID del tipo di modifica per questa procedura dettagliata è «1.0"`ct-0q0bic0ywqk6c`, per scoprire la versione più recente, esegui questo comando:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-0q0bic0ywqk6c
```
*CREAZIONE IN LINEA:*
+ Esegui il comando create RFC con i parametri di esecuzione forniti in linea (evita le virgolette quando fornisci i parametri di esecuzione in linea). E
```
aws amscm create-rfc --change-type-id "ct-0q0bic0ywqk6c" --change-type-version "1.0" --title "Delete My Stack" --execution-parameters "{\"StackId\":\"STACK_ID\"}"
```
+ Invia la RFC utilizzando l'ID RFC restituito nell'operazione di creazione RFC. Fino all'invio, la RFC rimane nello `Editing` stato e non viene applicata alcuna modifica.
```
aws amscm submit-rfc --rfc-id RFC_ID
```
+ Monitora lo stato RFC e visualizza l'output di esecuzione:
```
aws amscm get-rfc --rfc-id RFC_ID
```
*CREAZIONE DEL MODELLO*:
1. Esporta il modello RFC in un file nella cartella corrente; l'esempio lo chiama DeleteStackRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > DeleteStackRfc.json
```
1. Modifica e salva il file.json. DeleteStackRfc Poiché l'eliminazione di uno stack ha un solo parametro di esecuzione, i parametri di esecuzione possono essere contenuti nel DeleteStackRfc file.json stesso (non è necessario creare un file JSON separato con parametri di esecuzione).
Le virgolette interne dell'estensione ExecutionParameters JSON devono essere eliminate con una barra rovesciata (\$1). Esempio senza ora di inizio e fine:
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-0q0bic0ywqk6c",
"Title": "Delete-My-Stack-RFC"
"ExecutionParameters": "{
\"StackId\":\"STACK_ID\"}"
}
```
1. Crea la RFC:
```
aws amscm create-rfc --cli-input-json file://DeleteStackRfc.json
```
Riceverai RfcId il nuovo RFC nella risposta. Ad esempio:
```
{
"RfcId": "daaa1867-ffc5-1473-192a-842f6b326102"
}
```
Salva l'ID per i passaggi successivi.
1. Invia la RFC:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Se la RFC ha esito positivo, non riceverai alcuna conferma dalla riga di comando.
1. Per monitorare lo stato della richiesta e visualizzare l'output di esecuzione:
```
aws amscm get-rfc --rfc-id RFC_ID --query "Rfc.{Status:Status.Name,Exec:ExecutionOutput}" --output table
```