Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
# CLI-Tutorial: Zweistufiger Stack mit hoher Verfügbarkeit (Linux/RHEL)
In diesem Abschnitt wird beschrieben, wie Sie mithilfe der AMS-CLI einen zweistufigen Hochverfügbarkeits-Stack (HA) in einer AMS-Umgebung bereitstellen.
**Anmerkung**
Diese exemplarische Vorgehensweise für die Bereitstellung wurde in AMZN Linux- und RHEL-Umgebungen getestet.
Zusammenfassung der Aufgaben und der erforderlichen Aufgaben: RFCs
1. Infrastruktur erstellen (zweistufiger HA-Stack)
1. Erstellen Sie einen S3-Bucket für Anwendungen CodeDeploy
1. Erstellen Sie das WordPress Anwendungspaket und laden Sie es in den S3-Bucket hoch
1. Stellen Sie die Anwendung bereit mit CodeDeploy
1. Greifen Sie auf die WordPress Site zu und melden Sie sich an, um die Bereitstellung zu validieren
# Bevor Sie beginnen
Deployment \$1 Advanced Stack Components \$1 High Availability Two Tier Stack Advanced \$1 Create CT erstellt eine Auto Scaling Scaling-Gruppe, einen Load Balancer, eine Datenbank sowie einen CodeDeploy Anwendungsnamen und eine Bereitstellungsgruppe (mit demselben Namen, den Sie der Anwendung geben). Weitere Informationen finden CodeDeploy Sie unter [Was ist CodeDeploy?](https://docs.aws.amazon.com/codedeploy/latest/userguide/welcome.html)
In dieser exemplarischen Vorgehensweise wird ein High Availability Two-Tier Stack (Advanced) -RFC verwendet, der beinhaltet UserData und auch beschreibt, wie ein WordPress Paket erstellt wird, das CodeDeploy bereitgestellt werden kann.
Im Beispiel werden Instanzmetadaten wie Instanz-ID, Region usw. aus einer laufenden Instanz abgerufen, indem der unter http://169.254.169.254/latest/meta-data/ verfügbare Instanz-Metadatendienst abgefragt wird. `UserData` EC2 Diese Zeile im Benutzerdatenskript:`REGION=$(curl 169.254.169.254/latest/meta-data/placement/availability-zone/ | sed 's/[a-z]$//')`, ruft den Namen der Verfügbarkeitszone aus dem Metadatendienst in die \$1REGION-Variable für unsere unterstützten Regionen ab und vervollständigt damit die URL für den S3-Bucket, in den der Agent heruntergeladen wird. CodeDeploy Die 169.254.169.254 IP ist nur innerhalb der VPC routingfähig (alle können den Service abfragen). VPCs [Informationen zum Service finden Sie unter Instanz-Metadaten und Benutzerdaten.](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-instance-metadata.html) Beachten Sie auch, dass Skripte, UserData die als eingegeben wurden, als „root“ -Benutzer ausgeführt werden und den Befehl „sudo“ nicht verwenden müssen.
In dieser exemplarischen Vorgehensweise werden die folgenden Parameter auf dem Standardwert belassen (siehe Abbildung):
+ Auto Scaling Scaling-Gruppe:`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`.
+ Datenbank:`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`.
+ Anwendung:`DeploymentConfigName=CodeDeployDefault.OneAtATime`.
+ S3-Eimer:`AccessControl=Private`.
ZUSÄTZLICHE EINSTELLUNGEN:
`RequestedStartTime`und `RequestedEndTime` wenn Sie Ihren RFC planen möchten: Sie können [Time.is](https://time.is/UTC) verwenden, um die richtige UTC-Zeit zu ermitteln. Die bereitgestellten Beispiele müssen entsprechend angepasst werden. Ein RFC kann nicht fortgesetzt werden, wenn die Startzeit abgelaufen ist. Alternativ können Sie diese Werte auch weglassen, um einen ASAP-RFC zu erstellen, der ausgeführt wird, sobald die Genehmigungen bestanden wurden.
**Anmerkung**
Es gibt viele Parameter, die Sie möglicherweise anders als in der Abbildung festlegen möchten. Die im Beispiel gezeigten Werte für diese Parameter wurden getestet, sind aber möglicherweise nicht für Sie geeignet.
# Erstellen Sie die Infrastruktur
Wenn Sie die folgenden Daten sammeln, bevor Sie beginnen, kann die Bereitstellung schneller vonstattengehen.
DIE ERFORDERLICHEN DATEN SIND GESTAPELT:
+ AutoScalingGroup:
+ `UserData`: Dieser Wert wird in diesem Tutorial bereitgestellt. Er enthält Befehle zum Einrichten der Ressource für den Agenten CodeDeploy und zum Starten des CodeDeploy Agenten.
+ `AMI-ID`: Dieser Wert bestimmt, welche Art von EC2 Instances Ihre Auto Scaling Scaling-Gruppe (ASG) hochfahren wird. Stellen Sie sicher, dass Sie in Ihrem Konto ein AMI auswählen, das mit „Kunde-“ beginnt und das von Ihnen gewünschte Betriebssystem hat. Finden Sie AMI IDs mit der Referenz zur AMS SKMS API auf der Registerkarte **Berichte** in der AWS Artifact Console. Operation (CLI: list-amis) oder auf der Seite AMS-Konsole -> Details. VPCs VPCs Diese exemplarische Vorgehensweise ist für die ASGs Konfiguration zur Verwendung eines Linux-AMI AMI.
+ Datenbank:
+ Diese Parameter, `DBEngine``EngineVersion`, und `LicenseModel` sollten entsprechend Ihrer Situation eingestellt werden, obwohl die im Beispiel gezeigten Werte getestet wurden.
+ Diese Parameter, `RDSSubnetIds` `DBName``MasterUsername`, und `MasterUserPassword` sind bei der Bereitstellung des Anwendungspakets erforderlich. Verwenden Sie für RDSSubnet IDs zwei private Subnetze.
+ LoadBalancer:
+ Diese Parameter, `DBEngine``EngineVersion`, und `LicenseModel` sollten entsprechend Ihrer Situation eingestellt werden, obwohl die im Beispiel gezeigten Werte getestet wurden.
+ `ELBSubnetIds`: Verwenden Sie zwei öffentliche Subnetze.
+ Anwendung: Der `ApplicationName` Wert legt den CodeDeploy Anwendungsnamen und den Namen der CodeDeploy Bereitstellungsgruppe fest. Sie verwenden ihn, um Ihre Anwendung bereitzustellen. Es muss für das Konto eindeutig sein. Um in Ihrem Konto nach CodeDeploy Namen zu suchen, schauen Sie in der CodeDeploy Konsole nach. Im Beispiel wird "WordPress" verwendet, aber wenn Sie diesen Wert verwenden, stellen Sie sicher, dass er nicht bereits verwendet wird.
Bei diesem Verfahren werden der zweistufige Hochverfügbarkeits-Stack (Advanced) CT (ct-06mjngx5flwto) und der Create S3-Speicher-CT (ct-1a68ck03fn98r) verwendet. Gehen Sie von Ihrem authentifizierten Konto aus in der Befehlszeile wie folgt vor.
1. Starten Sie den Infrastruktur-Stack.
1. Geben Sie das JSON-Schema der Ausführungsparameter für den HA Two-Tier-Stack-CT in eine Datei in Ihrem aktuellen Ordner namens CreateStackParams .json aus.
```
aws amscm get-change-type-version --change-type-id "ct-06mjngx5flwto" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateStackParams.json
```
1. Ändern Sie das Schema. Ersetzen Sie das nach *variables* Bedarf. Verwenden Sie beispielsweise das gewünschte Betriebssystem für die EC2 Instanzen, die die ASG erstellen wird. Notieren Sie das, `ApplicationName` wie Sie es später für die Bereitstellung der Anwendung verwenden werden. Beachten Sie, dass Sie bis zu 50 Tags hinzufügen können.
```
{
"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. Geben Sie die CreateRfc JSON-Vorlage in eine Datei in Ihrem aktuellen Ordner namens CreateStackRfc .json aus:
```
aws amscm create-rfc --generate-cli-skeleton > CreateStackRfc.json
```
1. Ändern Sie die RFC-Vorlage wie folgt und speichern Sie sie. Sie können den Inhalt löschen und ersetzen. Beachten Sie, dass `RequestedStartTime` sie jetzt optional `RequestedEndTime` sind. Wenn Sie sie ausschließen, wird ein ASAP-RFC erstellt, der ausgeführt wird, sobald er genehmigt wurde (was normalerweise automatisch geschieht). Um einen geplanten RFC einzureichen, fügen Sie diese Werte hinzu.
```
{
"ChangeTypeVersion": "3.0",
"ChangeTypeId": "ct-06mjngx5flwto",
"Title": "HA-Stack-For-WP-RFC"
}
```
1. Erstellen Sie den RFC, indem Sie die CreateStackRfc JSON-Datei und die Ausführungsparameterdatei mit den CreateStackParams JSON-Dateien angeben:
```
aws amscm create-rfc --cli-input-json file://CreateStackRfc.json --execution-parameters file://CreateStackParams.json
```
Sie erhalten die RFC-ID in der Antwort. Speichern Sie die ID für nachfolgende Schritte.
1. Reichen Sie den RFC ein:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Wenn der RFC erfolgreich ist, erhalten Sie keine Ausgabe.
1. Führen Sie folgenden Befehl aus, um den RFC-Status zu überprüfen
```
aws amscm get-rfc --rfc-id RFC_ID
```
Notieren Sie sich die RFC-ID.
1. Starten Sie einen S3-Bucket
Wenn Sie die folgenden Daten sammeln, bevor Sie beginnen, kann die Bereitstellung schneller vonstattengehen.
ERFORDERLICHER DATEN-S3-BUCKET:
+ `VPC-ID`: Dieser Wert bestimmt, wo sich Ihr S3-Bucket befinden wird. Verwenden Sie dieselbe VPC-ID, die Sie zuvor verwendet haben.
+ `BucketName`: Dieser Wert legt den Namen des S3-Buckets fest. Sie verwenden ihn, um Ihr Anwendungspaket hochzuladen. Er muss in der gesamten Region des Kontos eindeutig sein und darf keine Großbuchstaben enthalten. Die Angabe Ihrer Konto-ID als Teil von BucketName ist keine Voraussetzung, erleichtert jedoch die spätere Identifizierung des Buckets. Um zu sehen, welche S3-Bucket-Namen in dem Konto vorhanden sind, rufen Sie die Amazon S3 S3-Konsole für Ihr Konto auf.
1. Geben Sie das JSON-Schema der Ausführungsparameter für den S3-Speicher Create CT in eine JSON-Datei mit dem Namen CreateS3 StoreParams .json aus.
```
aws amscm get-change-type-version --change-type-id "ct-1a68ck03fn98r" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > CreateS3StoreParams.json
```
1. Ändern Sie das Schema wie folgt. Sie können den Inhalt löschen und ersetzen. Ersetze es *VPC\$1ID* entsprechend. Die Werte im Beispiel wurden getestet, sind aber möglicherweise nicht für Sie geeignet.
**Tipp**
Die `BucketName` müssen in der gesamten Region des Kontos eindeutig sein und dürfen keine Großbuchstaben enthalten. Die Angabe Ihrer Konto-ID als Teil von BucketName ist keine Voraussetzung, erleichtert jedoch die spätere Identifizierung des Buckets. Um zu sehen, welche S3-Bucket-Namen in dem Konto vorhanden sind, rufen Sie die Amazon S3 S3-Konsole für Ihr Konto auf.
```
{
"Description": "S3BucketForWordPressBundle",
"VpcId": "VPC_ID",
"StackTemplateId": "stm-s2b72beb000000000",
"Name": "S3BucketForWP",
"TimeoutInMinutes": 60,
"Parameters": {
"AccessControl": "Private",
"BucketName": "ACCOUNT_ID-BUCKET_NAME"
}
}
```
1. Geben Sie die JSON-Vorlage für CreateRfc in eine Datei in Ihrem aktuellen Ordner mit dem Namen CreateS3 StoreRfc .json aus:
```
aws amscm create-rfc --generate-cli-skeleton > CreateS3StoreRfc.json
```
1. Ändern und speichern Sie die Datei CreateS3 StoreRfc .json. Sie können den Inhalt löschen und ersetzen. Beachten Sie, dass `RequestedStartTime` sie jetzt optional `RequestedEndTime` sind. Wenn Sie sie ausschließen, wird ein ASAP-RFC erstellt, der ausgeführt wird, sobald er genehmigt wurde (was normalerweise automatisch geschieht). Um einen geplanten RFC einzureichen, fügen Sie diese Werte hinzu.
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-1a68ck03fn98r",
"Title": "S3-Stack-For-WP-RFC"
}
```
1. Erstellen Sie den RFC, indem Sie die Datei CreateS3 StoreRfc .json und die Ausführungsparameterdatei StoreParams CreateS3 .json angeben:
```
aws amscm create-rfc --cli-input-json file://CreateS3StoreRfc.json --execution-parameters file://CreateS3StoreParams.json
```
Sie erhalten den Wert des neuen RFC in RfcId der Antwort. Speichern Sie die ID für nachfolgende Schritte.
1. Reichen Sie den RFC ein:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Wenn der RFC erfolgreich ist, erhalten Sie keine Ausgabe.
1. Führen Sie folgenden Befehl aus, um den RFC-Status zu überprüfen
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Anwendung erstellen, hochladen und bereitstellen
Erstellen Sie zunächst ein WordPress Anwendungspaket und verwenden Sie dann das, CodeDeploy CTs um die Anwendung zu erstellen und bereitzustellen.
1. Laden Sie die Dateien herunter WordPress, extrahieren Sie sie und erstellen Sie eine. Verzeichnis /scripts.
Linux-Befehl:
```
wget https://github.com/WordPress/WordPress/archive/master.zip
```
Windows: `https://github.com/WordPress/WordPress/archive/master.zip` In ein Browserfenster einfügen und die Zip-Datei herunterladen.
Erstellen Sie ein temporäres Verzeichnis, in dem das Paket zusammengestellt werden soll.
Linux:
```
mkdir /tmp/WordPress
```
Windows: Erstellen Sie ein "WordPress" Verzeichnis. Sie werden den Verzeichnispfad später verwenden.
1. Extrahieren Sie die WordPress Quelle in das Verzeichnis WordPress "" und erstellen Sie ein. Verzeichnis /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: Gehen Sie in das Verzeichnis "WordPress", das Sie erstellt haben, und erstellen Sie dort ein Verzeichnis „scripts“.
Wenn Sie sich in einer Windows-Umgebung befinden, stellen Sie sicher, dass Sie den Unterbrechungstyp für die Skriptdateien auf Unix (LF) setzen. In Notepad \$1\$1 ist dies eine Option unten rechts im Fenster.
1. Erstellen Sie die Datei CodeDeploy **appspec.yml** im WordPress Verzeichnis (wenn Sie das Beispiel kopieren, überprüfen Sie den Einzug, jedes Leerzeichen zählt). WICHTIG: Stellen Sie sicher, dass der Quellpfad für das Kopieren der WordPress Dateien (in diesem Fall in Ihrem WordPress Verzeichnis) an das erwartete Ziel (/) korrekt ist. var/www/html/WordPress Im Beispiel befindet sich die Datei appspec.yml im Verzeichnis mit den WordPress Dateien, sodass nur „/“ benötigt wird. Auch wenn Sie ein RHEL-AMI für Ihre Auto Scaling Scaling-Gruppe verwendet haben, sollten Sie die Zeile „os: linux“ unverändert lassen. Beispiel für eine appspec.yml-Datei:
```
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. Erstellen Sie Bash-Dateiskripts in der. WordPress Verzeichnis /scripts.
Erstellen Sie zunächst `config_wordpress.sh` mit dem folgenden Inhalt (wenn Sie möchten, können Sie die Datei wp-config.php direkt bearbeiten).
**Anmerkung**
*DBName*Ersetzen Sie durch den Wert, der im HA Stack-RFC angegeben ist (z. B.`wordpress`).
*DB\$1MasterUsername*Ersetzen Sie durch den `MasterUsername` Wert, der im HA Stack-RFC angegeben ist (z. B.`admin`).
*DB\$1MasterUserPassword*Ersetzen Sie durch den `MasterUserPassword` Wert, der im HA Stack-RFC angegeben ist (z. B.`p4ssw0rd`).
*DB\$1ENDPOINT*Ersetzen Sie es in den Ausführungsausgaben des HA Stack-RFC durch den DNS-Namen des Endpunkts (z. B.`srt1cz23n45sfg.clgvd67uvydk.us-east-1.rds.amazonaws.com`). Sie finden dies mit der [GetRfc](https://docs.aws.amazon.com/managedservices/latest/ApiReference-cm/API_GetRfc.html)Operation (CLI: get-rfc --rfc-id RFC\$1ID) oder auf der RFC-Detailseite der AMS-Konsole für den HA Stack-RFC, den Sie zuvor eingereicht haben.
```
#!/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. Erstellen Sie im selben Verzeichnis mit dem folgenden Inhalt: `install_dependencies.sh`
```
#!/bin/bash
yum install -y php
yum install -y php-mysql
yum install -y mysql
service httpd restart
```
**Anmerkung**
HTTPS wird beim Start als Teil der Benutzerdaten installiert, damit Integritätsprüfungen von Anfang an funktionieren.
1. Erstellen Sie im selben Verzeichnis `start_server.sh` mit dem folgenden Inhalt:
+ Verwenden Sie für Amazon Linux-Instances Folgendes:
```
#!/bin/bash
service httpd start
```
+ Verwenden Sie für RHEL-Instances Folgendes (die zusätzlichen Befehle sind Richtlinien, die es SELINUX ermöglichen, sie zu akzeptieren): 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. Erstellen Sie im selben Verzeichnis `stop_server.sh` mit dem folgenden Inhalt:
```
#!/bin/bash
service httpd stop
```
1. Erstellen Sie das Zip-Bundle.
Linux:
```
$ cd /tmp/WordPress
$ zip -r wordpress.zip .
```
Windows: Gehen Sie in Ihr "WordPress" -Verzeichnis, wählen Sie alle Dateien aus und erstellen Sie eine ZIP-Datei. Achten Sie darauf, sie wordpress.zip zu nennen.
1. Laden Sie das Anwendungspaket in den S3-Bucket hoch.
Das Bundle muss vorhanden sein, um den Stack weiter bereitstellen zu können.
Sie haben automatisch Zugriff auf jede S3-Bucket-Instanz, die Sie erstellen. Sie können über Ihre Bastions oder über die S3-Konsole darauf zugreifen und das WordPress Paket mit hochladen drag-and-drop oder die ZIP-Datei durchsuchen und auswählen.
Sie können auch den folgenden Befehl in einem Shell-Fenster verwenden. Vergewissern Sie sich, dass Sie den richtigen Pfad zur ZIP-Datei haben:
```
aws s3 cp wordpress.zip s3://BUCKET_NAME/
```
1. Stellen Sie das WordPress Anwendungspaket bereit.
Wenn Sie die folgenden Daten sammeln, bevor Sie beginnen, kann die Bereitstellung schneller vonstattengehen.
ERFORDERLICHE DATEN:
+ `VPC-ID`: Dieser Wert bestimmt, wo sich Ihr S3-Bucket befinden wird. Verwenden Sie dieselbe VPC-ID, die Sie zuvor verwendet haben.
+ `CodeDeployApplicationName`und`CodeDeployApplicationName`: Der `ApplicationName` Wert, den Sie im HA 2-Tier Stack-RFC verwendet haben, legt den und den CodeDeployApplicationName fest. CodeDeployDeploymentGroupName Das Beispiel verwendet "WordPress", aber Sie haben möglicherweise einen anderen Wert verwendet.
+ `S3Location`: Verwenden Sie für den `S3Bucket``BucketName`, den Sie zuvor erstellt haben. Die `S3BundleType` und `S3Key` stammen aus dem Paket, das Sie in Ihren S3-Shop gestellt haben.
1. Geben Sie das JSON-Schema der Ausführungsparameter für die CodeDeploy Anwendung Deploy CT in eine JSON-Datei mit dem Namen Deploy CDApp Params.json aus.
```
aws amscm get-change-type-version --change-type-id "ct-2edc3sd1sqmrb" --query "ChangeTypeVersion.ExecutionInputSchema" --output text > DeployCDAppParams.json
```
1. Ändern Sie das Schema wie folgt und speichern Sie es unter. Sie können den Inhalt löschen und ersetzen.
```
{
"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. Geben Sie die JSON-Vorlage für CreateRfc in eine Datei in Ihrem aktuellen Ordner mit dem Namen Deploy CDApp rfc.json aus:
```
aws amscm create-rfc --generate-cli-skeleton > DeployCDAppRfc.json
```
1. Ändern und speichern Sie die Datei Deploy CDApp RFC.json. Sie können den Inhalt löschen und ersetzen. Beachten Sie, dass `RequestedStartTime` sie jetzt optional `RequestedEndTime` sind. Wenn Sie sie ausschließen, wird ein ASAP-RFC erstellt, der ausgeführt wird, sobald er genehmigt wurde (was normalerweise automatisch geschieht). Um einen geplanten RFC einzureichen, fügen Sie diese Werte hinzu.
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-2edc3sd1sqmrb",
"Title": "CD-Deploy-For-WP-RFC"
}
```
1. Erstellen Sie den RFC, indem Sie die Datei Deploy CDApp Rfc und die Ausführungsparameterdatei Deploy CDApp Params angeben:
```
aws amscm create-rfc --cli-input-json file://DeployCDAppRfc.json --execution-parameters file://DeployCDAppParams.json
```
Sie erhalten den Wert RfcId des neuen RFC in der Antwort. Speichern Sie die ID für nachfolgende Schritte.
1. Reichen Sie den RFC ein:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Wenn der RFC erfolgreich ist, erhalten Sie keine Ausgabe.
1. Führen Sie folgenden Befehl aus, um den RFC-Status zu überprüfen
```
aws amscm get-rfc --rfc-id RFC_ID
```
# Validieren Sie die Anwendungsbereitstellung
Navigieren Sie zum Endpunkt (ELB CName) des zuvor erstellten Load Balancers mit dem bereitgestellten Pfad:/. WordPress WordPress Beispiel:
```
http://stack-ID-FOR-ELB.us-east-1.elb.amazonaws.com/WordPress
```
# Machen Sie die Anwendungsbereitstellung rückgängig
Sobald Sie mit dem Tutorial fertig sind, sollten Sie die Bereitstellung beenden, damit Ihnen die Ressourcen nicht in Rechnung gestellt werden.
Im Folgenden wird ein generischer Vorgang zum Löschen von Stacks beschrieben. Sie sollten ihn zweimal einreichen, einmal für den HA 2-Tier-Stack und einmal für den S3-Bucket-Stack. Als letzten Schritt reichen Sie eine Serviceanfrage ein, dass alle Snapshots für den S3-Bucket (einschließlich der S3-Bucket-Stack-ID in der Serviceanfrage) gelöscht werden. Sie werden nach 10 Tagen automatisch gelöscht, aber wenn Sie sie vorzeitig löschen, sparen Sie ein wenig Kosten.
Diese exemplarische Vorgehensweise bietet ein Beispiel für die Verwendung der AMS-Konsole zum Löschen eines S3-Stacks. Dieses Verfahren gilt für das Löschen eines beliebigen Stacks mithilfe der AMS-Konsole.
**Anmerkung**
Wenn Sie einen S3-Bucket löschen, müssen Sie ihn zuerst von Objekten leeren.
ERFORDERLICHE DATEN:
+ `StackId`: Der zu verwendende Stapel. Sie finden ihn auf der Seite AMS Console **Stacks**, die Sie über einen Link im linken Navigationsbereich aufrufen können. Führen Sie mithilfe der AMS SKMS API/CLI den Vorgang For the AMS SKMS API reference, see the **Reports** in der AWS Artifact Console. (in der CLI) aus. `list-stack-summaries`
+ Die Änderungstyp-ID für diese exemplarische Vorgehensweise lautet `ct-0q0bic0ywqk6c` „1.0“. Führen Sie den folgenden Befehl aus, um die neueste Version herauszufinden:
```
aws amscm list-change-type-version-summaries --filter Attribute=ChangeTypeId,Value=ct-0q0bic0ywqk6c
```
*INLINE-ERSTELLUNG*:
+ Geben Sie den Befehl create RFC mit den direkt angegebenen Ausführungsparametern aus (vermeiden Sie Anführungszeichen, wenn Sie die Ausführungsparameter inline angeben). E
```
aws amscm create-rfc --change-type-id "ct-0q0bic0ywqk6c" --change-type-version "1.0" --title "Delete My Stack" --execution-parameters "{\"StackId\":\"STACK_ID\"}"
```
+ Senden Sie den RFC mit der RFC-ID, die bei der RFC-Erstellung zurückgegeben wurde. Bis zur Übermittlung verbleibt der RFC im `Editing` Status und es wird nicht darauf reagiert.
```
aws amscm submit-rfc --rfc-id RFC_ID
```
+ Überwachen Sie den RFC-Status und sehen Sie sich die Ausführungsausgabe an:
```
aws amscm get-rfc --rfc-id RFC_ID
```
*VORLAGE ERSTELLEN*:
1. Gibt die RFC-Vorlage in eine Datei in Ihrem aktuellen Ordner aus. Beispiel nennt sie DeleteStackRfc .json:
```
aws amscm create-rfc --generate-cli-skeleton > DeleteStackRfc.json
```
1. Ändern und speichern Sie die DeleteStackRfc JSON-Datei. Da das Löschen eines Stacks nur einen Ausführungsparameter hat, können sich die Ausführungsparameter in der DeleteStackRfc JSON-Datei selbst befinden (es ist nicht erforderlich, eine separate JSON-Datei mit Ausführungsparametern zu erstellen).
Die internen Anführungszeichen in der ExecutionParameters JSON-Erweiterung müssen mit einem Backslash (\$1) maskiert werden. Beispiel ohne Start- und Endzeit:
```
{
"ChangeTypeVersion": "1.0",
"ChangeTypeId": "ct-0q0bic0ywqk6c",
"Title": "Delete-My-Stack-RFC"
"ExecutionParameters": "{
\"StackId\":\"STACK_ID\"}"
}
```
1. Erstellen Sie den RFC:
```
aws amscm create-rfc --cli-input-json file://DeleteStackRfc.json
```
In der Antwort erhalten Sie den RfcId des neuen RFC. Beispiel:
```
{
"RfcId": "daaa1867-ffc5-1473-192a-842f6b326102"
}
```
Speichern Sie die ID für nachfolgende Schritte.
1. Reichen Sie den RFC ein:
```
aws amscm submit-rfc --rfc-id RFC_ID
```
Wenn der RFC erfolgreich ist, erhalten Sie keine Bestätigung in der Befehlszeile.
1. Um den Status der Anfrage zu überwachen und die Ausführungsausgabe anzuzeigen:
```
aws amscm get-rfc --rfc-id RFC_ID --query "Rfc.{Status:Status.Name,Exec:ExecutionOutput}" --output table
```