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. # CodeDeploy AppSpec Dateiverweis Dieser Abschnitt dient nur als Referenz. Einen konzeptionellen Überblick über die AppSpec Datei finden Sie unter[CodeDeploy Anwendungsspezifikationsdateien (AppSpec)](application-specification-files.md). Die Anwendungsspezifikationsdatei (AppSpec Datei) ist eine Datei im [YAML](http://www.yaml.org) - oder JSON-Format, die zur Verwaltung einer Bereitstellung verwendet wird. CodeDeploy **Anmerkung** Die AppSpec Datei für eine EC2/On-Premises-Bereitstellung muss benannt `appspec.yml` werden, es sei denn, Sie führen eine lokale Bereitstellung durch. Weitere Informationen finden Sie unter [Erstellen Sie eine lokale Bereitstellung](deployments-local.md#deployments-local-deploy). **Topics** + [AppSpec Dateien auf einer Amazon ECS-Rechenplattform](#appspec-reference-ecs) + [AppSpec Dateien auf einer AWS Lambda Rechenplattform](#appspec-reference-lambda) + [AppSpec Dateien auf einer EC2/lokalen Rechenplattform](#appspec-reference-server) + [AppSpec Struktur der Datei](reference-appspec-file-structure.md) + [AppSpec Beispiel für eine Datei](reference-appspec-file-example.md) + [AppSpec Abstand zwischen den Dateien](#reference-appspec-file-spacing) + [Bestätigen Sie Ihre AppSpec Datei und den Dateispeicherort](reference-appspec-file-validate.md) ## AppSpec Dateien auf einer Amazon ECS-Rechenplattform Für Amazon ECS-Rechenplattformanwendungen wird die AppSpec Datei verwendet, um CodeDeploy Folgendes zu ermitteln: + Ihre Amazon ECS-Aufgabendefinitionsdatei. Dies wird mit seinem ARN in der `TaskDefinition` Anweisung in der AppSpec Datei angegeben. + Der Container und der Port in Ihrem Ersatzaufgabensatz, an den Ihr Application Load Balancer oder Network Load Balancer den Datenverkehr während einer Bereitstellung umleitet. Dies wird mit der `LoadBalancerInfo` Anweisung in der Datei angegeben. AppSpec + Optionale Informationen über Ihren Amazon ECS-Service, z. B. die Plattformversion, auf der er ausgeführt wird, seine Subnetze und seine Sicherheitsgruppen. + Optionale Lambda-Funktionen, die während Hooks ausgeführt werden, die Lebenszyklusereignissen während einer Amazon ECS-Bereitstellung entsprechen. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Hooks“ für eine Amazon ECS-Bereitstellung](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs). ## AppSpec Dateien auf einer AWS Lambda Rechenplattform Für AWS Lambda-Compute-Plattformanwendungen wird die AppSpec Datei verwendet, CodeDeploy um Folgendes zu ermitteln: + Welche Lambda-Funktionsversion soll bereitgestellt werden. + Welche Lambda-Funktionen sollen als Validierungstests verwendet werden? Eine AppSpec Datei kann YAML- oder JSON-formatiert sein. Sie können den Inhalt einer AppSpec Datei auch direkt in die CodeDeploy Konsole eingeben, wenn Sie ein Deployment erstellen. ## AppSpec Dateien auf einer EC2/lokalen Rechenplattform Wenn Ihre Anwendung die EC2/On-Premises-Computing-Plattform verwendet, muss es sich bei der AppSpec Datei um eine YAML-formatierte Datei mit dem Namen handeln `appspec.yml` und sie muss sich im Stammverzeichnis der Verzeichnisstruktur des Quellcodes einer Anwendung befinden. Andernfalls schlagen Bereitstellungen fehl. Sie wird verwendet, um Folgendes zu ermitteln: CodeDeploy + Was es auf Ihren Instances aus Ihrer Anwendungsversion in Amazon S3 oder installieren sollte GitHub. + Welche Lebenszyklusereignis-Hooks als Reaktion auf Bereitstellungslebenszyklusereignisse ausgeführt werden sollen. Nachdem Sie eine vollständige AppSpec Datei erstellt haben, bündeln Sie sie zusammen mit dem Inhalt, der bereitgestellt werden soll, in einer Archivdatei (zip, tar oder komprimiertes Tar). Weitere Informationen finden Sie unter [Arbeiten mit Anwendungsrevisionen für CodeDeploy](application-revisions.md). **Anmerkung** Die Archivdateiformate tar und komprimiertes TAR-Archiv (.tar und .tar.gz) werden für Windows Server-Instanzen nicht unterstützt. Nachdem Sie eine gebündelte Archivdatei (bekannt CodeDeploy als *Revision*) haben, laden Sie sie in einen Amazon S3 S3-Bucket oder ein Git-Repository hoch. Anschließend verwenden Sie CodeDeploy , um die Revision bereitzustellen. Detaillierte Anweisungen finden Sie unter [Erstellen Sie eine Bereitstellung mit CodeDeploy](deployments-create.md). Die Datei appspec.yml für eine EC2/On-Premises-Compute-Plattform-Bereitstellung wird im Stammverzeichnis Ihrer Revision gespeichert. Weitere Informationen erhalten Sie unter [Fügen Sie eine AppSpec Datei für eine EC2/On-Premises-Bereitstellung hinzu](application-revisions-appspec-file.md#add-appspec-file-server) und [Planen Sie eine Revision für CodeDeploy](application-revisions-plan.md). # AppSpec Struktur der Datei Im Folgenden finden Sie die allgemeine Struktur für eine AppSpec Datei, die für Bereitstellungen auf AWS Lambda- und EC2/On-Premises-Computerplattformen verwendet wird. Ein Wert in einer AppSpec Datei im YAML-Format, bei dem es sich um eine Zeichenfolge handelt, darf nicht in Anführungszeichen („“) eingeschlossen werden, sofern nicht anders angegeben. ## AppSpec Dateistruktur für Amazon ECS-Bereitstellungen **Anmerkung** Diese AppSpec Datei ist in YAML geschrieben, aber Sie können dieselbe Struktur verwenden, um eine Datei in JSON zu schreiben. Eine Zeichenfolge in einer AppSpec Datei im JSON-Format ist immer in Anführungszeichen („“) eingeschlossen. ``` version: 0.0 resources: ecs-service-specifications hooks: deployment-lifecycle-event-mappings ``` In dieser Struktur: ** **Version** ** In diesem Abschnitt wird die Version der Datei angegeben. AppSpec Ändern Sie diesen Wert nicht. Sie ist erforderlich. Der einzige zulässige Wert ist derzeit **0.0**. Es ist CodeDeploy für die future Verwendung reserviert. Geben Sie **version** mit einer Zeichenfolge an. ** **Ressourcen** ** Dieser Abschnitt enthält Informationen über die bereitzustellende Amazon ECS-Anwendung. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Ressourcen“ für Amazon ECS-Bereitstellungen](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs). ** **hooks** ** In diesem Abschnitt werden Lambda-Funktionen beschrieben, die bei bestimmten Event-Hooks für den Bereitstellungslebenszyklus ausgeführt werden sollen, um die Bereitstellung zu validieren. Weitere Informationen finden Sie unter [Liste der Lifecycle-Event-Hooks für eine Amazon ECS-Bereitstellung](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs). ## AppSpec Dateistruktur für AWS Lambda-Bereitstellungen **Anmerkung** Diese AppSpec Datei ist in YAML geschrieben, aber Sie können dieselbe Struktur verwenden, um eine AppSpec Datei für eine Lambda-Bereitstellung in JSON zu schreiben. Eine Zeichenfolge in einer AppSpec Datei im JSON-Format ist immer in Anführungszeichen („“) eingeschlossen. ``` version: 0.0 resources: lambda-function-specifications hooks: deployment-lifecycle-event-mappings ``` In dieser Struktur: ** **Version** ** In diesem Abschnitt wird die Version der Datei angegeben. AppSpec Ändern Sie diesen Wert nicht. Sie ist erforderlich. Der einzige zulässige Wert ist derzeit **0.0**. Es ist CodeDeploy für die future Verwendung reserviert. Geben Sie **version** mit einer Zeichenfolge an. ** **Ressourcen** ** Dieser Abschnitt enthält Informationen über die bereitzustellende Lambda-Funktion. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Ressourcen“ (nur Amazon ECS und AWS Lambda Bereitstellungen)](reference-appspec-file-structure-resources.md). ** **hooks** ** In diesem Abschnitt werden Lambda-Funktionen beschrieben, die bei bestimmten Ereignissen im Bereitstellungslebenszyklus ausgeführt werden sollen, um die Bereitstellung zu validieren. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Hooks“](reference-appspec-file-structure-hooks.md). ## AppSpec Dateistruktur für EC2/lokale Bereitstellungen ``` version: 0.0 os: operating-system-name files: source-destination-files-mappings permissions: permissions-specifications hooks: deployment-lifecycle-event-mappings ``` In dieser Struktur: ** **Version** ** In diesem Abschnitt wird die Version der Datei angegeben. AppSpec Ändern Sie diesen Wert nicht. Sie ist erforderlich. Der einzige zulässige Wert ist derzeit **0.0**. Es ist CodeDeploy für die future Verwendung reserviert. Geben Sie **version** mit einer Zeichenfolge an. ** **os** ** In diesem Abschnitt wird der Betriebssystemwert der Instance angegeben, auf der Sie bereitstellen. Es ist erforderlich. Die folgenden Werte können angegeben werden: + **linux** — Die Instance ist eine Amazon Linux-, Ubuntu Server- oder RHEL-Instance. + **windows** — Die Instance ist eine Windows Server-Instance. Geben Sie **os** mit einer Zeichenfolge an. ** **files** ** In diesem Abschnitt werden die Namen der Dateien angegeben, die während dem **Install**-Ereignis der Bereitstellung auf die Instance kopiert werden sollen. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Dateien“ (nur für EC2/lokale Bereitstellungen)](reference-appspec-file-structure-files.md). ** **permissions** ** In diesem Abschnitt wird angegeben, wie spezielle Berechtigungen, sofern vorhanden, auf die Dateien im Abschnitt `files` angewendet werden sollen, wenn diese auf die Instance kopiert werden. Dieser Abschnitt gilt nur für Amazon Linux-, Ubuntu Server- und Red Hat Enterprise Linux (RHEL) -Instances. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Berechtigungen“ (nur für EC2/lokale Bereitstellungen)](reference-appspec-file-structure-permissions.md). ** **hooks** ** In diesem Abschnitt werden Skripts angegeben, die bei bestimmten Bereitstellungslebenszyklusereignissen während der Bereitstellung ausgeführt werden sollen. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Hooks“](reference-appspec-file-structure-hooks.md). **Topics** + [AppSpec Dateistruktur für Amazon ECS-Bereitstellungen](#ecs-appspec-structure) + [AppSpec Dateistruktur für AWS Lambda-Bereitstellungen](#lambda-appspec-structure) + [AppSpec Dateistruktur für EC2/lokale Bereitstellungen](#server-appspec-structure) + [AppSpec Abschnitt „Dateien“ (nur für EC2/lokale Bereitstellungen)](reference-appspec-file-structure-files.md) + [AppSpec Abschnitt „Ressourcen“ (nur Amazon ECS und AWS Lambda Bereitstellungen)](reference-appspec-file-structure-resources.md) + [AppSpec Abschnitt „Berechtigungen“ (nur für EC2/lokale Bereitstellungen)](reference-appspec-file-structure-permissions.md) + [AppSpec Abschnitt „Hooks“](reference-appspec-file-structure-hooks.md) # AppSpec Abschnitt „Dateien“ (nur für EC2/lokale Bereitstellungen) Enthält Informationen CodeDeploy darüber, welche Dateien aus Ihrer Anwendungsversion während des **Installationsereignisses** auf der Instanz installiert werden sollten. Dieser Abschnitt ist nur erforderlich, wenn Sie während der Bereitstellung Dateien aus Ihrer Revision an Standorte auf der Instance kopieren. Dieser Abschnitt hat die folgende Struktur: ``` files: - source: source-file-location-1 destination: destination-file-location-1 file_exists_behavior: DISALLOW|OVERWRITE|RETAIN ``` Mehrere `source`- und `destination`-Paare können festgelegt werden. Die `source`-Anweisung identifiziert eine Datei oder ein Verzeichnis aus Ihrer Revision, die bzw. das auf die Instance kopiert werden soll: + Wenn sich `source` auf eine Datei bezieht, werden nur die angegebenen Dateien auf die Instance kopiert. + Wenn sich `source` auf ein Verzeichnis bezieht, werden alle Dateien im Verzeichnis auf die Instance kopiert. + Wenn `source` es sich um einen einzelnen Schrägstrich handelt („/“ für Amazon Linux-, RHEL- und Ubuntu-Server-Instances oder „\$1“ für Windows Server-Instances), dann werden alle Dateien aus Ihrer Revision in die Instance kopiert. Die in verwendeten Pfade `source` beziehen sich auf die `appspec.yml` Datei, die sich im Stammverzeichnis Ihrer Revision befinden sollte. Einzelheiten zur Dateistruktur einer Revision finden Sie unter[Planen Sie eine Revision für CodeDeploy](application-revisions-plan.md). Die `destination`-Anweisung identifiziert den Standort auf der Instance, an den die Dateien kopiert werden sollen. Dies muss ein vollständig qualifizierter Pfad sein, z. B. `/root/destination/directory` (unter Linux, RHEL und Ubuntu) oder `c:\destination\folder` (unter Windows). `source` und `destination` werden jeweils mit einer Zeichenfolge angegeben. Die `file_exists_behavior` Anweisung ist optional und gibt an, wie CodeDeploy mit Dateien umgegangen wird, die bereits an einem Bereitstellungszielort vorhanden sind, aber nicht Teil der vorherigen erfolgreichen Bereitstellung waren. Diese Einstellung kann einen der folgenden Werte annehmen: + DISALLOW: Die Bereitstellung schlägt fehl. Dies ist auch das Standardverhalten, wenn keine Option angegeben ist. + ÜBERSCHREIBEN: Die Version der Datei aus der Anwendungsrevision, die gerade bereitgestellt wird, ersetzt die Version, die sich bereits auf der Instanz befindet. + RETAIN: Die Version der Datei, die sich bereits auf der Instanz befindet, wird beibehalten und als Teil der neuen Bereitstellung verwendet. Wenn Sie die `file_exists_behavior` Einstellung verwenden, sollten Sie sich darüber im Klaren sein, dass diese Einstellung: + kann nur einmal angegeben werden und gilt für alle Dateien und Verzeichnisse, die unter aufgeführt sind`files:`. + hat Vorrang vor der `--file-exists-behavior` AWS CLI Option und der `fileExistsBehavior` API-Option (beide sind ebenfalls optional). Hier ist ein `files` Beispielabschnitt für eine Amazon Linux-, Ubuntu Server- oder RHEL-Instance. ``` files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp ``` In diesem Beispiel werden die folgenden beiden Operationen während des **Installations**-Ereignisses ausgeführt: 1. Kopieren Sie die Datei `Config/config.txt` in Ihrer Revision zum `/webapps/Config/config.txt`-Pfad auf der Instance. 1. Kopieren Sie alle Dateien im `source`-Verzeichnis Ihrer Revision rekursiv in das Verzeichnis `/webapps/myApp` auf der Instance. ## Beispiele für den Abschnitt „Dateien“ Die folgenden Beispiele zeigen, wie Sie den Abschnitt `files` angeben. Diese Beispiele beschreiben zwar die Datei- und Verzeichnisstrukturen (Ordner) von Windows Server, können aber problemlos für Amazon Linux-, Ubuntu Server- und RHEL-Instances angepasst werden. **Anmerkung** Nur EC2/On-Premises-Bereitstellungen verwenden diesen Abschnitt. `files` Sie gilt nicht für AWS Lambda-Bereitstellungen. Für die folgenden Beispiele nehmen wir an, dass diese Dateien im Bündel im Stammverzeichnis von `source` angezeigt werden: + `appspec.yml` + `my-file.txt` + `my-file-2.txt` + `my-file-3.txt` ``` # 1) Copy only my-file.txt to the destination folder c:\temp. # files: - source: .\my-file.txt destination: c:\temp # # Result: # c:\temp\my-file.txt # # --------------------- # # 2) Copy only my-file-2.txt and my-file-3.txt to the destination folder c:\temp. # files: - source: my-file-2.txt destination: c:\temp - source: my-file-3.txt destination: c:\temp # # Result: # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 3) Copy my-file.txt, my-file-2.txt, and my-file-3.txt (along with the appspec.yml file) to the destination folder c:\temp. # files: - source: \ destination: c:\temp # # Result: # c:\temp\appspec.yml # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt ``` Für die folgenden Beispielen nehmen wir an, dass `appspec.yml` im Bündel im Stammverzeichnis von `source` zusammen mit einem Ordner mit dem Namen `my-folder`, der drei Dateien enthält, angezeigt wird: + `appspec.yml` + `my-folder\my-file.txt` + `my-folder\my-file-2.txt` + `my-folder\my-file-3.txt` ``` # 4) Copy the 3 files in my-folder (but do not copy my-folder itself) to the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp # # Result: # c:\temp\my-file.txt # c:\temp\my-file-2.txt # c:\temp\my-file-3.txt # # --------------------- # # 5) Copy my-folder and its 3 files to my-folder within the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp\my-folder # # Result: # c:\temp\my-folder\my-file.txt # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt # # --------------------- # # 6) Copy the 3 files in my-folder to other-folder within the destination folder c:\temp. # files: - source: .\my-folder destination: c:\temp\other-folder # # Result: # c:\temp\other-folder\my-file.txt # c:\temp\other-folder\my-file-2.txt # c:\temp\other-folder\my-file-3.txt # # --------------------- # # 7) Copy only my-file-2.txt and my-file-3.txt to my-folder within the destination folder c:\temp. # files: - source: .\my-folder\my-file-2.txt destination: c:\temp\my-folder - source: .\my-folder\my-file-3.txt destination: c:\temp\my-folder # # Result: # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt # # --------------------- # # 8) Copy only my-file-2.txt and my-file-3.txt to other-folder within the destination folder c:\temp. # files: - source: .\my-folder\my-file-2.txt destination: c:\temp\other-folder - source: .\my-folder\my-file-3.txt destination: c:\temp\other-folder # # Result: # c:\temp\other-folder\my-file-2.txt # c:\temp\other-folder\my-file-3.txt # # --------------------- # # 9) Copy my-folder and its 3 files (along with the appspec.yml file) to the destination folder c:\temp. If any of the files already exist on the instance, overwrite them. # files: - source: \ destination: c:\temp file_exists_behavior: OVERWRITE # # Result: # c:\temp\appspec.yml # c:\temp\my-folder\my-file.txt # c:\temp\my-folder\my-file-2.txt # c:\temp\my-folder\my-file-3.txt ``` # AppSpec Abschnitt „Ressourcen“ (nur Amazon ECS und AWS Lambda Bereitstellungen) Der Inhalt des `'resources'` Abschnitts der AppSpec Datei hängt von der Rechenplattform Ihrer Bereitstellung ab. Der `'resources'` Abschnitt für eine Amazon ECS-Bereitstellung enthält Ihre Amazon ECS-Aufgabendefinition, den Container und den Port für die Weiterleitung des Datenverkehrs an Ihren aktualisierten Amazon ECS-Aufgabensatz sowie weitere optionale Informationen. Der `'resources'` Abschnitt für eine AWS Lambda Bereitstellung enthält den Namen, den Alias, die aktuelle Version und die Zielversion einer Lambda-Funktion. **Topics** + [AppSpec Abschnitt „Ressourcen“ für AWS Lambda-Bereitstellungen](#reference-appspec-file-structure-resources-lambda) + [AppSpec Abschnitt „Ressourcen“ für Amazon ECS-Bereitstellungen](#reference-appspec-file-structure-resources-ecs) ## AppSpec Abschnitt „Ressourcen“ für AWS Lambda-Bereitstellungen Der `'resources'` Abschnitt spezifiziert die bereitzustellende Lambda-Funktion und hat die folgende Struktur: YAML: ``` resources: - name-of-function-to-deploy: type: "AWS::Lambda::Function" properties: name: name-of-lambda-function-to-deploy alias: alias-of-lambda-function-to-deploy currentversion: version-of-the-lambda-function-traffic-currently-points-to targetversion: version-of-the-lambda-function-to-shift-traffic-to ``` JSON: ``` "resources": [ { "name-of-function-to-deploy" { "type": "AWS::Lambda::Function", "properties": { "name": "name-of-lambda-function-to-deploy", "alias": "alias-of-lambda-function-to-deploy", "currentversion": "version-of-the-lambda-function-traffic-currently-points-to", "targetversion": "version-of-the-lambda-function-to-shift-traffic-to" } } } ] ``` Jede Eigenschaft wird mit einer Zeichenfolge angegeben. + `name` – Erforderlich. Dies ist der Name der Lambda-Funktion, die bereitgestellt werden soll. + `alias` – Erforderlich. Dies ist der Name des Alias für die Lambda-Funktion. + `currentversion` – Erforderlich. Dies ist die Version der Lambda-Funktion, auf die der Traffic derzeit verweist. Dieser Wert muss eine gültige positive Ganzzahl sein. + `targetversion` – Erforderlich. Dies ist die Version der Lambda-Funktion, auf die der Datenverkehr umgestellt wird. Dieser Wert muss eine gültige positive Ganzzahl sein. ## AppSpec Abschnitt „Ressourcen“ für Amazon ECS-Bereitstellungen Der `'resources'` Abschnitt spezifiziert den bereitzustellenden Amazon ECS-Service und hat die folgende Struktur: YAML: ``` Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "task-definition-arn" LoadBalancerInfo: ContainerName: "ecs-container-name" ContainerPort: "ecs-application-port" # Optional properties PlatformVersion: "ecs-service-platform-version" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["ecs-subnet-1","ecs-subnet-n"] SecurityGroups: ["ecs-security-group-1","ecs-security-group-n"] AssignPublicIp: "ENABLED | DISABLED" CapacityProviderStrategy: - Base: integer CapacityProvider: "capacityProviderA" Weight: integer - Base: integer CapacityProvider: "capacityProviderB" Weight: integer ``` JSON: ``` "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "task-definition-arn", "LoadBalancerInfo": { "ContainerName": "ecs-container-name", "ContainerPort": "ecs-application-port" }, "PlatformVersion": "ecs-service-platform-version", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "ecs-subnet-1", "ecs-subnet-n" ], "SecurityGroups": [ "ecs-security-group-1", "ecs-security-group-n" ], "AssignPublicIp": "ENABLED | DISABLED" } }, "CapacityProviderStrategy": [ { "Base": integer, "CapacityProvider": "capacityProviderA", "Weight": integer }, { "Base": integer, "CapacityProvider": "capacityProviderB", "Weight": integer } ] } } } ] ``` Jede Eigenschaft wird mit einer Zeichenfolge angegeben, mit Ausnahme von`ContainerPort`, bei der es sich um eine Zahl handelt. + `TaskDefinition` – Erforderlich. Dies ist die Aufgabendefinition für den bereitzustellenden Amazon ECS-Service. Sie wird mit dem ARN der Aufgabendefinition angegeben. Das ARN-Format ist `arn:aws:ecs:aws-region:account-id:task-definition/task-definition-family:task-definition-revision`. Weitere Informationen finden Sie unter [Amazon Resource Names (ARNs) und AWS Service-Namespaces](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html). **Anmerkung** Der `:task-definition-revision` Teil des ARN ist optional. Wenn es weggelassen wird, verwendet Amazon ECS die neueste ACTIVE-Version der Aufgabendefinition. + `ContainerName` – Erforderlich. Dies ist der Name des Amazon ECS-Containers, der Ihre Amazon ECS-Anwendung enthält. Es muss sich um einen Container handeln, der in Ihrer Amazon ECS-Aufgabendefinition angegeben ist. + `ContainerPort` – Erforderlich. Dies ist der Port auf dem Container, zu dem der Verkehr weitergeleitet wird. + `PlatformVersion`: Optional. Die Plattformversion der Fargate-Aufgaben im bereitgestellten Amazon ECS-Service. Weitere Informationen finden Sie unter [AWS Fargate -Plattformversionen](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html). Wenn nicht angegeben, `LATEST` wird sie standardmäßig verwendet. + `NetworkConfiguration`: Optional. Unter `AwsvpcConfiguration` können Sie Folgendes angeben. Weitere Informationen finden Sie [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)in der *Amazon ECS Container Service API-Referenz*. + `Subnets`: Optional. Eine durch Kommas getrennte Liste von einem oder mehreren Subnetzen in Ihrem Amazon ECS-Service. + `SecurityGroups`: Optional. Eine durch Kommas getrennte Liste mit einer oder mehreren Sicherheitsgruppen in Ihrem Amazon Elastic Container Service. + `AssignPublicIp`: Optional. Eine Zeichenfolge, die angibt, ob die elastic network interface Ihres Amazon ECS-Service eine öffentliche IP-Adresse erhält. Die gültigen Werte sind `ENABLED` und `DISABLED`. **Anmerkung** Alle oder keine der Einstellungen unter `NetworkConfiguration` müssen angegeben werden. Wenn Sie beispielsweise `Subnets` angeben möchten, müssen Sie auch `SecurityGroups` und `AssignPublicIp` angeben. Wenn keine angegeben ist, werden die aktuellen Netzwerkeinstellungen von Amazon ECS CodeDeploy verwendet. + `CapacityProviderStrategy`: Optional. Eine Liste der Amazon ECS-Kapazitätsanbieter, die Sie für Ihre Bereitstellung verwenden möchten. Weitere Informationen finden Sie unter [Amazon ECS Capacity Providers](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html) im *Amazon Elastic Container Service Developer Guide*. Für jeden Kapazitätsanbieter können Sie die folgenden Einstellungen angeben. Einzelheiten zu diesen Einstellungen finden Sie [AWS::ECS::ServiceCapacityProviderStrategyItem](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html)im *AWS CloudFormation Benutzerhandbuch* + `Base`: Optional. Der Basiswert gibt an, wie viele Aufgaben mindestens mit dem angegebenen Kapazitätsanbieter ausgeführt werden sollen. In einer Kapazitätsanbieter-Strategie kann nur für einen Kapazitätsanbieter ein Basiswert festgelegt werden. Wenn kein Wert angegeben wird, wird der Standardwert 0 verwendet. + `CapacityProvider`: Optional. Der Kurzname des Kapazitätsanbieters. Beispiel: *capacityProviderA* + `Weight`: Optional. Der *Gewichtungswert* gibt den relativen Prozentsatz der Gesamtzahl der gestarteten Aufgaben an, die den angegebenen Kapazitätsanbieter verwenden sollten. Der `weight`-Wert wird berücksichtigt, nachdem der `base`-Wert, falls definiert, erfüllt ist. Wenn kein `weight`-Wert angegeben wird, wird der Standardwert `0` verwendet. Wenn mehrere Capacity Provider innerhalb einer Capacity Provider-Strategie angegeben werden, muss mindestens einer der Capacity Provider einen Gewichtungswert von mehr als Null haben, und alle Capacity Provider mit einem Gewicht von `0` werden nicht für Aufgaben verwendet. Wenn Sie mehrere Capacity Provider in einer Strategie angeben, die alle ein Gewichtung von `0` haben, schlagen alle `RunTask`- oder `CreateService`-Aktionen, die die Capacity-Provider-Strategie verwenden, fehl. Ein Beispielszenario für die Verwendung von Gewichtungen ist die Definition einer Strategie, die zwei Kapazitätsanbieter enthält, wobei beide eine Gewichtung von `1` haben. Wenn die `base` erfüllt ist, werden die Aufgaben gleichmäßig auf die beiden Kapazitätsanbieter aufgeteilt. Wenn Sie unter Anwendung derselben Logik eine Gewichtung von `1` für *Kapazitätsanbieter A* und eine Gewichtung von `4` für *Kapazitätsanbieter B*, angeben, würden für jede Aufgabe, die mit *Kapazitätsanbieter A*, ausgeführt wird, vier Aufgaben mit *Kapazitätsanbieter B* ausgeführt. # AppSpec Abschnitt „Berechtigungen“ (nur für EC2/lokale Bereitstellungen) `'permissions'`In diesem Abschnitt wird festgelegt, wie spezielle Berechtigungen, falls vorhanden, auf die Dateien und auf den `'files'` Abschnitt nach dem Kopieren directories/folders in die Instanz angewendet werden sollen. Sie können mehrere `object`-Anweisungen angeben. Dieser Abschnitt ist optional. Sie gilt nur für Amazon Linux-, Ubuntu Server- und RHEL-Instances. **Anmerkung** Der `'permissions'` Abschnitt wird nur für EC2/On-Premises-Bereitstellungen verwendet. Es wird nicht für AWS Lambda- oder Amazon ECS-Bereitstellungen verwendet. Dieser Abschnitt hat die folgende Struktur: ``` permissions: - object: object-specification pattern: pattern-specification except: exception-specification owner: owner-account-name group: group-name mode: mode-specification acls: - acls-specification context: user: user-specification type: type-specification range: range-specification type: - object-type ``` Folgende Anleitungen sind zu beachten: + `object` – Erforderlich. Hierbei handelt es sich um eine Reihe von Dateisystemobjekten (Dateien oder Verzeichnisse/Ordner), auf die die angegebenen Berechtigungen angewendet werden, nachdem die Dateisystemobjekte auf die Instance kopiert wurden. Geben Sie `object` mit einer Zeichenfolge an. + `pattern` – Optional. Gibt ein Muster für das Anwenden von Berechtigungen an. Wenn nichts angegeben ist oder wenn mit den Sonderzeichen **"\$1\$1"** angegeben, werden die Berechtigungen abhängig von `type` auf alle übereinstimmenden Dateien oder Verzeichnisse angewendet. Geben Sie `pattern` mit einer Zeichenfolge in Anführungszeichen ("") an. + `except` – Optional. Gibt alle Dateien oder Verzeichnisse an, die Ausnahmen für `pattern` sind. Geben Sie `except` mit einer durch Komma getrennten Liste von Zeichenfolgen in eckigen Klammern an. + `owner` – Optional. Der Name des Eigentümers von `object`. Falls nicht anders angegeben, bleiben alle vorhandenen Eigentümer, die auf die ursprüngliche Datei- oder Verzeichnis-/Ordnerstruktur angewendet wurden, nach dem Kopiervorgang unverändert. Geben Sie `owner` mit einer Zeichenfolge an. + `group` – Optional. Der Name der Gruppe für `object`. Falls nicht anders angegeben, bleiben alle vorhandenen Gruppen, die auf die ursprüngliche Datei- oder Verzeichnis-/Ordnerstruktur angewendet wurden, nach dem Kopiervorgang unverändert. Geben Sie `group` mit einer Zeichenfolge an. + `mode` – Optional. Ein numerischer Wert, der die Berechtigungen angibt, auf die angewendet werden soll. `object` Die Moduseinstellung folgt der Linux-Befehlssyntax chmod. **Wichtig** Wenn der Wert eine führende Null enthält, müssen Sie ihn mit doppelten Anführungszeichen umgeben oder die führende Null entfernen, sodass nur noch drei Ziffern übrig bleiben. **Anmerkung** Symbolische Schreibweise wie **u\$1x** wird für die `mode` Einstellung nicht unterstützt. Beispiele: + `mode: "0644"`erteilt dem Besitzer des Objekts Lese- und Schreibberechtigungen (6), Schreibberechtigungen für die Gruppe (4) und Schreibberechtigungen für alle anderen Benutzer (4). + `mode: 644`gewährt dieselben Berechtigungen wie. `mode: "0644"` + `mode: 4755`setzt das setuid-Attribut (4), gewährt dem Besitzer Vollzugriff (7), erteilt der Gruppe Lese- und Ausführungsrechte (5) und erteilt allen anderen Benutzern Lese- und Ausführungsberechtigungen (5). Weitere Beispiele finden Sie in der Dokumentation zum Linux-Befehl chmod. Wenn der Modus nicht angegeben ist, bleiben alle vorhandenen Modi, die auf die ursprüngliche Datei- oder Ordnerstruktur angewendet wurden, nach dem Kopiervorgang unverändert. + `acls` – Optional. Eine Liste von Zeichenfolgen, die für einen oder mehrere Zugriffskontrolllisten (Access Control List, ACL)-Einträge stehen, die auf `object` angewendet werden. Beispielsweise steht **u:bob:rw** für Lese- und Schreibberechtigungen für den Benutzer **bob**. (Weitere Beispiele finden Sie unter den Beispielen für ACL-Eintragsformate in der Dokumentation zum Linux-Befehl `setfacl`.) Sie können mehrere ACL-Einträge angeben. Wenn nicht `acls` angegeben, bleiben alle vorhandenen Elemente, die auf die ursprüngliche Datei oder directory/folder Struktur ACLs angewendet wurden, nach dem Kopiervorgang unverändert. Diese ersetzen alle vorhandenen ACLs. Geben Sie einen `acls` mit einem Bindestrich (-), gefolgt von einem Leerzeichen, und dann einer Zeichenfolge (z. B. `- u:jane:rw`) an. Wenn Sie über mehr als eine ACL verfügen, wird jede jeweils in einer separaten Zeile angegeben. **Anmerkung** Wenn Sie unbenannte Benutzer, unbenannte Gruppen oder andere ähnliche ACL-Einträge festlegen, schlägt die AppSpec Datei fehl. Verwenden Sie stattdessen `mode`, um diese Art von Berechtigungen festzulegen. + `context` – Optional. Für Security-Enhanced Linux (SELinux) -fähige Instances eine Liste sicherheitsrelevanter Kontext-Labels, die auf die kopierten Objekte angewendet werden sollen. Bezeichnungen werden als Schlüssel angegeben, die `user`, `type` und `range` enthalten. (Weitere Informationen finden Sie in der Dokumentation.) SELinux Jeder Schlüssel wird mit einer Zeichenfolge eingegeben. Falls nicht angegeben, bleiben alle vorhandenen Beschriftungen, die auf die Originaldatei oder directory/folder Struktur angewendet wurden, nach dem Kopiervorgang unverändert. + `user` – Optional. Der SELinux Benutzer. + `type` – Optional. Der SELinux Typname. + `range` – Optional. Der SELinux Bereichsbezeichner. Dieser hat nur dann eine Auswirkung, wenn Multi-Level Security (MLS) und Multi-Category Security (MCS) auf dem Computer aktiviert ist. Wenn diese Option nicht aktiviert ist, ist der `range`-Standardwert **s0**. Geben Sie `context` mit einer Zeichenfolge an (z. B. `user: unconfined_u`). Jeder `context` wird in einer separaten Zeile angegeben. + `type` – Optional. Die Arten von Objekten, auf die die angegebenen Berechtigungen angewendet werden sollen. `type` ist eine Zeichenfolge, die auf **file** oder **directory** eingestellt sein kann. Wenn **file** angegeben ist, werden die Berechtigungen nur auf Dateien angewendet, die sofort nach dem Kopiervorgang in `object` enthalten sind (und nicht auf `object` selbst). Wenn **directory** angegeben, werden die Berechtigungen rekursiv auf alle Objekte angewendet directories/folders , die sich `object` nach dem Kopiervorgang irgendwo befinden (aber nicht auf sich `object` selbst). Geben Sie `type` mit einem Bindestrich (-), gefolgt von einem Leerzeichen, und dann einer Zeichenfolge (z. B. `- file`) an. ## Beispiel für den Abschnitt „Berechtigungen“ Das folgende Beispiel zeigt, wie Sie den `'permissions'`-Abschnitt mit den Anweisungen `object`, `pattern`, `except`, `owner`, `mode` und `type` angeben. Dieses Beispiel gilt nur für Amazon Linux-, Ubuntu Server- und RHEL-Instances. In diesem Beispiel wird davon ausgegangen, dass die folgenden Dateien und Ordner auf die Instance in dieser Hierarchie kopiert werden: ``` /tmp `-- my-app |-- my-file-1.txt |-- my-file-2.txt |-- my-file-3.txt |-- my-folder-1 | |-- my-file-4.txt | |-- my-file-5.txt | `-- my-file-6.txt `-- my-folder-2 |-- my-file-7.txt |-- my-file-8.txt |-- my-file-9.txt `-- my-folder-3 ``` Die folgende AppSpec Datei zeigt, wie Sie Berechtigungen für diese Dateien und Ordner festlegen, nachdem sie kopiert wurden: ``` version: 0.0 os: linux # Copy over all of the folders and files with the permissions they # were originally assigned. files: - source: ./my-file-1.txt destination: /tmp/my-app - source: ./my-file-2.txt destination: /tmp/my-app - source: ./my-file-3.txt destination: /tmp/my-app - source: ./my-folder-1 destination: /tmp/my-app/my-folder-1 - source: ./my-folder-2 destination: /tmp/my-app/my-folder-2 # 1) For all of the files in the /tmp/my-app folder ending in -3.txt # (for example, just my-file-3.txt), owner = adm, group = wheel, and # mode = 464 (-r--rw-r--). permissions: - object: /tmp/my-app pattern: "*-3.txt" owner: adm group: wheel mode: 464 type: - file # 2) For all of the files ending in .txt in the /tmp/my-app # folder, but not for the file my-file-3.txt (for example, # just my-file-1.txt and my-file-2.txt), # owner = ec2-user and mode = 444 (-r--r--r--). - object: /tmp/my-app pattern: "*.txt" except: [my-file-3.txt] owner: ec2-user mode: 444 type: - file # 3) For all the files in the /tmp/my-app/my-folder-1 folder except # for my-file-4.txt and my-file-5.txt, (for example, # just my-file-6.txt), owner = operator and mode = 646 (-rw-r--rw-). - object: /tmp/my-app/my-folder-1 pattern: "**" except: [my-file-4.txt, my-file-5.txt] owner: operator mode: 646 type: - file # 4) For all of the files that are immediately under # the /tmp/my-app/my-folder-2 folder except for my-file-8.txt, # (for example, just my-file-7.txt and # my-file-9.txt), owner = ec2-user and mode = 777 (-rwxrwxrwx). - object: /tmp/my-app/my-folder-2 pattern: "**" except: [my-file-8.txt] owner: ec2-user mode: 777 type: - file # 5) For all folders at any level under /tmp/my-app that contain # the name my-folder but not # /tmp/my-app/my-folder-2/my-folder-3 (for example, just # /tmp/my-app/my-folder-1 and /tmp/my-app/my-folder-2), # owner = ec2-user and mode = 555 (dr-xr-xr-x). - object: /tmp/my-app pattern: "*my-folder*" except: [tmp/my-app/my-folder-2/my-folder-3] owner: ec2-user mode: 555 type: - directory # 6) For the folder /tmp/my-app/my-folder-2/my-folder-3, # group = wheel and mode = 564 (dr-xrw-r--). - object: /tmp/my-app/my-folder-2/my-folder-3 group: wheel mode: 564 type: - directory ``` Es ergeben sich folgende Berechtigungen: ``` -r--r--r-- ec2-user root my-file-1.txt -r--r--r-- ec2-user root my-file-2.txt -r--rw-r-- adm wheel my-file-3.txt dr-xr-xr-x ec2-user root my-folder-1 -rw-r--r-- root root my-file-4.txt -rw-r--r-- root root my-file-5.txt -rw-r--rw- operator root my-file-6.txt dr-xr-xr-x ec2-user root my-folder-2 -rwxrwxrwx ec2-user root my-file-7.txt -rw-r--r-- root root my-file-8.txt -rwxrwxrwx ec2-user root my-file-9.txt dr-xrw-r-- root wheel my-folder-3 ``` Das folgende Beispiel zeigt, wie Sie den `'permissions'`-Abschnitt unter Hinzunahme der Anweisungen `acls` und `context` angeben. Dieses Beispiel gilt nur für Amazon Linux-, Ubuntu Server- und RHEL-Instances. ``` permissions: - object: /var/www/html/WordPress pattern: "**" except: [/var/www/html/WordPress/ReadMe.txt] owner: bob group: writers mode: 644 acls: - u:mary:rw - u:sam:rw - m::rw context: user: unconfined_u type: httpd_sys_content_t range: s0 type: - file ``` # AppSpec Abschnitt „Hooks“ Der Inhalt des `'hooks'` Abschnitts der AppSpec Datei variiert je nach Rechenplattform für Ihre Bereitstellung. Der `'hooks'` Abschnitt für eine EC2/On-Premises-Bereitstellung enthält Zuordnungen, die Event-Hooks für den Deployment-Lebenszyklus mit einem oder mehreren Skripts verknüpfen. Der `'hooks'` Abschnitt für eine Lambda- oder Amazon ECS-Bereitstellung spezifiziert Lambda-Validierungsfunktionen, die während eines Deployment-Lifecycle-Ereignisses ausgeführt werden sollen. Wenn ein Ereignis-Hook nicht vorhanden ist, wird kein Vorgang für dieses Ereignis ausgeführt. Dieser Abschnitt ist nur erforderlich, wenn Sie im Rahmen der Bereitstellung Skripts oder Lambda-Validierungsfunktionen ausführen. **Topics** + [AppSpec Abschnitt „Hooks“ für eine Amazon ECS-Bereitstellung](#appspec-hooks-ecs) + [AppSpec Abschnitt „Hooks“ für eine AWS Lambda-Bereitstellung](#appspec-hooks-lambda) + [AppSpec Abschnitt „Hooks“ für eine EC2/On-Premises-Bereitstellung](#appspec-hooks-server) ## AppSpec Abschnitt „Hooks“ für eine Amazon ECS-Bereitstellung **Topics** + [Liste der Lifecycle-Event-Hooks für eine Amazon ECS-Bereitstellung](#reference-appspec-file-structure-hooks-list-ecs) + [Führen Sie die Reihenfolge der Hooks in einer Amazon ECS-Bereitstellung aus.](#reference-appspec-file-structure-hooks-run-order-ecs) + [Struktur des Abschnitts „Hooks“](#reference-appspec-file-structure-hooks-section-structure-ecs) + [Beispiel für die Lambda-Funktion „Hooks“](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function) ### Liste der Lifecycle-Event-Hooks für eine Amazon ECS-Bereitstellung Ein AWS Lambda-Hook ist eine Lambda-Funktion, die mit einer Zeichenfolge in einer neuen Zeile nach dem Namen des Lebenszyklusereignisses angegeben wird. Jeder Hook wird einmal pro Bereitstellung ausgeführt. Im Folgenden finden Sie Beschreibungen der Lebenszyklusereignisse, bei denen Sie während einer Amazon ECS-Bereitstellung einen Hook ausführen können. + `BeforeInstall`— Wird verwendet, um Aufgaben auszuführen, bevor der Ersatzaufgabensatz erstellt wird. Eine Zielgruppe wird dem ursprünglichen Aufgabesatz zugeordnet. Wenn ein optionaler Test-Listener angegeben wird, wird er dem ursprünglichen Aufgabensatz zugeordnet. Ein Rollback ist zu diesem Zeitpunkt nicht möglich. + `AfterInstall`— Wird verwendet, um Aufgaben auszuführen, nachdem der Ersatz-Tasksatz erstellt wurde und ihm eine der Zielgruppen zugeordnet wurde. Wenn ein optionaler Test-Listener angegeben wird, wird er dem ursprünglichen Aufgabensatz zugeordnet. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen. + `AfterAllowTestTraffic`— Wird verwendet, um Aufgaben auszuführen, nachdem der Test-Listener Traffic an den Ersatz-Tasksatz weitergeleitet hat. Die Ergebnisse einer hook-Funktion können zu diesem Zeitpunkt einen Rollback auslösen. + `BeforeAllowTraffic`— Wird verwendet, um Aufgaben auszuführen, nachdem die zweite Zielgruppe dem Ersatz-Task-Set zugeordnet wurde, aber bevor der Verkehr auf den Ersatz-Tasksatz umgeleitet wird. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen. + `AfterAllowTraffic`— Wird verwendet, um Aufgaben auszuführen, nachdem die zweite Zielgruppe Traffic an den Ersatz-Tasksatz weitergeleitet hat. Die Ergebnisse einer hook-Funktion bei diesem Lebenszyklus-Ereignis können einen Rollback auslösen. Weitere Informationen erhalten Sie unter [Was passiert während einer Amazon ECS-Bereitstellung](deployment-steps-ecs.md#deployment-steps-what-happens) und [Tutorial: Bereitstellen eines Amazon ECS-Service mit einem Validierungstest](tutorial-ecs-deployment-with-hooks.md). ### Führen Sie die Reihenfolge der Hooks in einer Amazon ECS-Bereitstellung aus. In einer Amazon ECS-Bereitstellung werden Event-Hooks in der folgenden Reihenfolge ausgeführt: ![\[Die Reihenfolge der Event-Hooks in einer Amazon ECS-Bereitstellung.\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/images/lifecycle-event-order-ecs.png) **Anmerkung** Für die Ereignisse **Start **TestTraffic****, **Install **AllowTraffic****, und **End** in der Bereitstellung können keine Skripts erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. ### Struktur des Abschnitts „Hooks“ Die folgenden Beispiele veranschaulichen die Struktur des Abschnitts `'hooks'`. Mit YAML: ``` Hooks: - BeforeInstall: "BeforeInstallHookFunctionName" - AfterInstall: "AfterInstallHookFunctionName" - AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName" - BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName" - AfterAllowTraffic: "AfterAllowTrafficHookFunctionName" ``` Mit JSON: ``` "Hooks": [ { "BeforeInstall": "BeforeInstallHookFunctionName" }, { "AfterInstall": "AfterInstallHookFunctionName" }, { "AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName" }, { "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" } ] } ``` ### Beispiel für die Lambda-Funktion „Hooks“ Verwenden Sie den `'hooks'` Abschnitt, um eine Lambda-Funktion anzugeben, die aufgerufen CodeDeploy werden kann, um eine Amazon ECS-Bereitstellung zu validieren. Sie können dieselbe oder eine andere Funktion für die Ereignisse im Lebenszyklus der `AfterAllowTraffic` Bereitstellung `BeforeInstall` `AfterInstall``AfterAllowTestTraffic`,`BeforeAllowTraffic`,, und verwenden. Nach Abschluss der Validierungstests ruft die `AfterAllowTraffic` Lambda-Funktion zurück CodeDeploy und liefert das Ergebnis `Succeeded` oder`Failed`. **Wichtig** Die Bereitstellung gilt als fehlgeschlagen, wenn sie nicht innerhalb einer Stunde von der Lambda-Validierungsfunktion benachrichtigt CodeDeploy wird. Vor dem Aufrufen einer Lambda-Hook-Funktion muss der Server mithilfe des Befehls über die Bereitstellungs-ID und die Ausführungs-ID des Lifecycle-Event-Hooks informiert werden. `putLifecycleEventHookExecutionStatus` Im Folgenden finden Sie ein Beispiel für eine Lambda-Hook-Funktion, die in Node.js geschrieben wurde. ``` 'use strict'; const aws = require('aws-sdk'); const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'}); exports.handler = (event, context, callback) => { //Read the DeploymentId from the event payload. var deploymentId = event.DeploymentId; //Read the LifecycleEventHookExecutionId from the event payload var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId; /* Enter validation tests here. */ // Prepare the validation test results with the deploymentId and // the lifecycleEventHookExecutionId for CodeDeploy. var params = { deploymentId: deploymentId, lifecycleEventHookExecutionId: lifecycleEventHookExecutionId, status: 'Succeeded' // status can be 'Succeeded' or 'Failed' }; // Pass CodeDeploy the prepared validation test results. codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) { if (err) { // Validation failed. callback('Validation test failed'); } else { // Validation succeeded. callback(null, 'Validation test succeeded'); } }); }; ``` ## AppSpec Abschnitt „Hooks“ für eine AWS Lambda-Bereitstellung **Topics** + [Liste der Lifecycle-Event-Hooks für eine AWS Lambda-Bereitstellung](#reference-appspec-file-structure-hooks-list-lambda) + [Reihenfolge der Hooks in einer Bereitstellung einer Lambda-Funktionsversion ausführen](#reference-appspec-file-structure-hooks-run-order-lambda) + [Struktur des Abschnitts „Hooks“](#reference-appspec-file-structure-hooks-section-structure-lambda) + [Beispiel für die Lambda-Funktion „Hooks“](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function) ### Liste der Lifecycle-Event-Hooks für eine AWS Lambda-Bereitstellung Ein AWS Lambda-Hook ist eine Lambda-Funktion, die mit einer Zeichenfolge in einer neuen Zeile nach dem Namen des Lebenszyklusereignisses angegeben wird. Jeder Hook wird einmal pro Bereitstellung ausgeführt. Im Folgenden finden Sie Beschreibungen der Hooks, die für die Verwendung in Ihrer AppSpec Datei verfügbar sind. + **BeforeAllowTraffic**— Wird verwendet, um Aufgaben auszuführen, bevor der Datenverkehr auf die bereitgestellte Lambda-Funktionsversion umgestellt wird. + **AfterAllowTraffic**— Wird verwendet, um Aufgaben auszuführen, nachdem der gesamte Datenverkehr auf die bereitgestellte Lambda-Funktionsversion umgestellt wurde. ### Reihenfolge der Hooks in einer Bereitstellung einer Lambda-Funktionsversion ausführen In einer serverlosen Bereitstellung einer Lambda-Funktionsversion werden Event-Hooks in der folgenden Reihenfolge ausgeführt: ![\[Die Reihenfolge der Event-Hooks in einer Lambda-Bereitstellung.\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/images/lifecycle-event-order-lambda.png) **Anmerkung** Für die **Start **AllowTraffic****- und **Endereignisse** in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. ### Struktur des Abschnitts „Hooks“ Die folgenden Beispiele veranschaulichen die Struktur des 'hooks'-Abschnitts . Mit YAML: ``` hooks: - BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName - AfterAllowTraffic: AfterAllowTrafficHookFunctionName ``` Mit JSON: ``` "hooks": [{ "BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName" }, { "AfterAllowTraffic": "AfterAllowTrafficHookFunctionName" }] ``` ### Beispiel für die Lambda-Funktion „Hooks“ Verwenden Sie den Abschnitt „Hooks“, um eine Lambda-Funktion anzugeben, die aufgerufen CodeDeploy werden kann, um eine Lambda-Bereitstellung zu validieren. Sie können dieselbe oder eine andere Funktion für die Ereignisse im Lebenszyklus der `BeforeAllowTraffic` `AfterAllowTraffic` Bereitstellung verwenden. Nach Abschluss der Validierungstests ruft die Lambda-Validierungsfunktion zurück CodeDeploy und liefert ein Ergebnis von `Succeeded` oder`Failed`. **Wichtig** Die Bereitstellung gilt als fehlgeschlagen, wenn sie nicht innerhalb einer Stunde von der Lambda-Validierungsfunktion benachrichtigt CodeDeploy wird. Vor dem Aufrufen einer Lambda-Hook-Funktion muss der Server mithilfe des Befehls über die Bereitstellungs-ID und die Ausführungs-ID des Lifecycle-Event-Hooks informiert werden. `putLifecycleEventHookExecutionStatus` Im Folgenden finden Sie ein Beispiel für eine Lambda-Hook-Funktion, die in Node.js geschrieben wurde. ``` 'use strict'; const aws = require('aws-sdk'); const codedeploy = new aws.CodeDeploy({apiVersion: '2014-10-06'}); exports.handler = (event, context, callback) => { //Read the DeploymentId from the event payload. var deploymentId = event.DeploymentId; //Read the LifecycleEventHookExecutionId from the event payload var lifecycleEventHookExecutionId = event.LifecycleEventHookExecutionId; /* Enter validation tests here. */ // Prepare the validation test results with the deploymentId and // the lifecycleEventHookExecutionId for CodeDeploy. var params = { deploymentId: deploymentId, lifecycleEventHookExecutionId: lifecycleEventHookExecutionId, status: 'Succeeded' // status can be 'Succeeded' or 'Failed' }; // Pass CodeDeploy the prepared validation test results. codedeploy.putLifecycleEventHookExecutionStatus(params, function(err, data) { if (err) { // Validation failed. callback('Validation test failed'); } else { // Validation succeeded. callback(null, 'Validation test succeeded'); } }); }; ``` ## AppSpec Abschnitt „Hooks“ für eine EC2/On-Premises-Bereitstellung **Topics** + [Liste der Lifecycle-Event-Hooks](#reference-appspec-file-structure-hooks-list) + [Verfügbarkeit von Hooks für Lebenszyklus-Ereignisse](#reference-appspec-file-structure-hooks-availability) + [Führt die Reihenfolge der Hooks in einem Deployment aus](#reference-appspec-file-structure-hooks-run-order) + [Struktur des Abschnitts „Hooks“](#reference-appspec-file-structure-hooks-section-structure) + [Referenzieren von Dateien in Ihren Hook-Skripten](#codedeploy-agent-working-directory) + [Verfügbarkeit von Umgebungsvariablen für Hooks](#reference-appspec-file-structure-environment-variable-availability) + [Beispiel für Hooks](#reference-appspec-file-structure-hooks-example) ### Liste der Lifecycle-Event-Hooks Ein EC2/On-Premises-Bereitstellungs-Hook wird einmal pro Bereitstellung für eine Instance ausgeführt. Sie können ein oder mehrere Skripts zur Ausführung in einem Hook angeben. Jeder Hook für ein Lebenszyklusereignis wird mit einer Zeichenfolge in einer separaten Zeile angegeben. Im Folgenden finden Sie Beschreibungen der Hooks, die für die Verwendung in Ihrer Datei verfügbar sind. AppSpec Weitere Informationen darüber, welche Lebenszyklusereignis-Hooks für welche Bereitstellungs- und Rollback-Typen gültig sind, finden Sie unter [Verfügbarkeit von Hooks für Lebenszyklus-Ereignisse](#reference-appspec-file-structure-hooks-availability). + `ApplicationStop`— Dieses Ereignis im Bereitstellungszyklus tritt auf, noch bevor die Anwendungsversion heruntergeladen wird. Sie können Skripts für dieses Ereignis angeben, um die Anwendung ordnungsgemäß anzuhalten, oder zur Vorbereitung einer Bereitstellung derzeit installierte Pakete entfernen. Die für dieses Ereignis im Bereitstellungslebenszyklus verwendeten AppSpec Dateien und Skripts stammen aus der vorherigen, erfolgreich bereitgestellten Anwendungsrevision. **Anmerkung** Eine AppSpec Datei ist auf einer Instanz nicht vorhanden, bevor Sie sie auf ihr bereitstellen. Aus diesem Grund wird der `ApplicationStop`-Hook beim ersten Bereitstellen auf der Instance nicht ausgeführt. Sie können den `ApplicationStop`-Hook bei der zweiten Bereitstellung für eine Instance verwenden. Um den Speicherort der letzten erfolgreich bereitgestellten Anwendungsrevision zu ermitteln, sucht der CodeDeploy Agent nach dem in der `deployment-group-id_last_successful_install` Datei aufgeführten Speicherort. Diese Datei befindet sich unter: `/opt/codedeploy-agent/deployment-root/deployment-instructions`Ordner auf Amazon Linux-, Ubuntu Server- und RHEL Amazon EC2 EC2-Instances. `C:\ProgramData\Amazon\CodeDeploy\deployment-instructions`Ordner auf Windows Server Amazon EC2 EC2-Instances. Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses `ApplicationStop` fehlschlägt, finden Sie unter [Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `DownloadBundle`— Während dieses Bereitstellungslebenszyklus kopiert der CodeDeploy Agent die Revisionsdateien der Anwendung an einen temporären Speicherort: `/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive`Ordner auf Amazon Linux-, Ubuntu Server- und RHEL Amazon EC2 EC2-Instances. `C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive`Ordner auf Windows Server Amazon EC2 EC2-Instances. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zum Ausführen von Skripten verwendet werden. Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses `DownloadBundle` fehlschlägt, finden Sie unter [Behebung eines fehlgeschlagenen DownloadBundle Deployment-Lifecycle-Ereignisses mit UnknownError: nicht zum Lesen geöffnet](troubleshooting-deployments.md#troubleshooting-deployments-downloadbundle). + `BeforeInstall`— Sie können dieses Ereignis im Bereitstellungslebenszyklus für Aufgaben vor der Installation verwenden, z. B. für das Entschlüsseln von Dateien und das Erstellen einer Sicherungskopie der aktuellen Version. + `Install`— Während dieses Bereitstellungslebenszyklus kopiert der CodeDeploy Agent die Revisionsdateien vom temporären Speicherort in den endgültigen Zielordner. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zum Ausführen von Skripten verwendet werden. + `AfterInstall`— Sie können dieses Ereignis im Bereitstellungslebenszyklus für Aufgaben wie die Konfiguration Ihrer Anwendung oder das Ändern von Dateiberechtigungen verwenden. + `ApplicationStart`— In der Regel verwenden Sie dieses Ereignis im Bereitstellungslebenszyklus, um Dienste neu zu starten, die währenddessen gestoppt wurden`ApplicationStop`. + `ValidateService`— Dies ist das letzte Ereignis im Bereitstellungslebenszyklus. Es wird verwendet, um zu überprüfen, ob die Bereitstellung erfolgreich abgeschlossen wurde. + `BeforeBlockTraffic`— Sie können dieses Ereignis im Bereitstellungslebenszyklus verwenden, um Aufgaben auf Instances auszuführen, bevor diese bei einem Load Balancer deregistriert werden. Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses `BeforeBlockTraffic` fehlschlägt, finden Sie unter [Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BlockTraffic`— Während dieses Deployment-Lifecycle-Ereignisses wird der Internetverkehr daran gehindert, auf Instances zuzugreifen, die derzeit Traffic bereitstellen. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zur Ausführung von Skripten verwendet werden. + `AfterBlockTraffic`— Sie können dieses Deployment-Lifecycle-Ereignis verwenden, um Aufgaben auf Instances auszuführen, nachdem diese bei ihrem jeweiligen Load Balancer abgemeldet wurden. Informationen zur Problembehebung für eine Bereitstellung, die während des Bereitstellungslebenszyklusereignisses `AfterBlockTraffic` fehlschlägt, finden Sie unter [Behebung eines Fehlers oder eines ApplicationStop BeforeBlockTraffic Ereignisses im Lebenszyklus einer AfterBlockTraffic Bereitstellung](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures). + `BeforeAllowTraffic`— Sie können dieses Deployment-Lifecycle-Ereignis verwenden, um Aufgaben auf Instances auszuführen, bevor diese bei einem Load Balancer registriert wurden. + `AllowTraffic`— Während dieses Bereitstellungslebenszyklus darf Internet-Traffic nach einer Bereitstellung auf Instances zugreifen. Dieses Ereignis ist für den CodeDeploy Agenten reserviert und kann nicht zur Ausführung von Skripten verwendet werden. + `AfterAllowTraffic`— Sie können dieses Deployment-Lifecycle-Ereignis verwenden, um Aufgaben auf Instances auszuführen, nachdem diese bei einem Load Balancer registriert wurden. ### Verfügbarkeit von Hooks für Lebenszyklus-Ereignisse In der folgenden Tabelle finden Sie die Lebenszyklusereignis-Hooks für die einzelnen Bereitstellungs- und Rollback-Szenarien. | Name des Lebenszyklusereignis | Bereitstellung von Auto Scaling Scaling-Start¹ | Bereitstellung von Auto Scaling-Termination¹ | Bereitstellung vor Ort² | Blau/Grün-Bereitstellung: Original-Instances | Blau/Grün-Bereitstellung: Ersatz-Instances | Blau/Grün-Bereitstellungs-Rollback: Original-Instances | Blau/Grün-Bereitstellungs-Rollback: Ersatz-Instances | | --- | --- | --- | --- | --- | --- | --- | --- | | ApplicationStop | ✓ | ✓ | ✓ | | ✓ | | | | DownloadBundle³ | ✓ | | ✓ | | ✓ | | | | BeforeInstall | ✓ | | ✓ | | ✓ | | | | ³ installieren | ✓ | | ✓ | | ✓ | | | | AfterInstall | ✓ | | ✓ | | ✓ | | | | ApplicationStart | ✓ | | ✓ | | ✓ | | | | ValidateService | ✓ | | ✓ | | ✓ | | | | BeforeBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BlockTraffic³ | | ✓ | ✓ | ✓ | | | ✓ | | AfterBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ | | BeforeAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | AllowTraffic³ | ✓ | | ✓ | | ✓ | ✓ | | | AfterAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | | | ¹ Informationen zu Amazon EC2 Auto Scaling Scaling-Bereitstellungen finden Sie unter. [So funktioniert Amazon EC2 Auto Scaling mit CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors) ² Gilt auch für das Rollback einer In-Place-Bereitstellung. ³ Für den Betrieb reserviert CodeDeploy . Kann nicht für die Ausführung von Skripts verwendet werden. | ### Führt die Reihenfolge der Hooks in einem Deployment aus **Auto Scaling Scaling-Startbereitstellungen** CodeDeploy Führt während einer Auto Scaling Scaling-Startbereitstellung Event-Hooks in der folgenden Reihenfolge aus. Weitere Informationen zu Auto Scaling Scaling-Startbereitstellungen finden Sie unter[So funktioniert Amazon EC2 Auto Scaling mit CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors). ![\[Die Reihenfolge der Event-Hooks während einer Auto Scaling Scaling-Startbereitstellung.\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png) **Anmerkung** Für die **Start** - **DownloadBundle**AllowTraffic****, **Installations** - und **Endereignisse** in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. Sie können den `'files'` Abschnitt der AppSpec Datei jedoch bearbeiten, um anzugeben, was während des Installationsereignisses **installiert** wird. **Bereitstellungen zur Kündigung von Auto Scaling** CodeDeploy Führt während einer Auto Scaling-Terminierungsbereitstellung Event-Hooks in der folgenden Reihenfolge aus. Weitere Informationen zu Auto Scaling-Terminierungsbereitstellungen finden Sie unter[Aktivierung von Terminierungsbereitstellungen bei Auto Scaling-Scale-In-Ereignissen](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable). ![\[Die Reihenfolge der Event-Hooks während einer Auto Scaling-Terminierungsbereitstellung.\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png) **Anmerkung** Für die **Start **BlockTraffic****- und **Endereignisse** in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. **In-Situ-Bereitstellungen** In einer In-Situ-Bereitstellung, einschließlich des Rollbacks einer In-Situ-Bereitstellung, werden Ereignis-Hooks in der folgenden Reihenfolge ausgeführt: **Anmerkung** Bei In-Place-Bereitstellungen gelten die sechs Hooks, die sich auf das Blockieren und Zulassen von Traffic beziehen, nur, wenn Sie in der Bereitstellungsgruppe einen Classic Load Balancer, Application Load Balancer oder Network Load Balancer von Elastic Load Balancing angeben. ![\[Die Reihenfolge der Event-Hooks beim Rollback einer In-Place-Bereitstellung.\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png) **Anmerkung** Für die **Start** - **DownloadBundle**, **Installations** - und **Endereignisse** in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. Sie können den `'files'` Abschnitt der AppSpec Datei jedoch bearbeiten, um anzugeben, was während des Installationsereignisses **installiert** wird. **Blau/Grün-Bereitstellungen** In einer blue/green Bereitstellung werden Event-Hooks in der folgenden Reihenfolge ausgeführt: ![\[Die Reihenfolge der Event-Hooks in einer blue/green Bereitstellung.\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png) **Anmerkung** Für die **Start** - **DownloadBundle**, **Installations** - **BlockTraffic**AllowTraffic****, und **Endereignisse** in der Bereitstellung kann kein Skript erstellt werden, weshalb sie in diesem Diagramm grau dargestellt werden. Sie können jedoch den Abschnitt „Dateien“ der AppSpec Datei bearbeiten, um anzugeben, was während des Installationsereignisses **installiert** werden soll. ### Struktur des Abschnitts „Hooks“ Der `'hooks'`-Abschnitt weist die folgende Struktur auf: ``` hooks: deployment-lifecycle-event-name: - location: script-location timeout: timeout-in-seconds runas: user-name ``` Sie können die folgenden Elemente nach dem Namen des Bereitstellungslebenszyklusereignisses in einen **Hook**-Eintrag einschließen: ** location ** Erforderlich Die Position im Paket der Skriptdatei für die Revision. Der Speicherort der Skripts, die Sie in `hooks` diesem Abschnitt angeben, bezieht sich auf das Stammverzeichnis des Revisionspakets der Anwendung. Weitere Informationen finden Sie unter [Planen Sie eine Revision für CodeDeploy](application-revisions-plan.md). ** timeout ** Optional. Die Anzahl der Sekunden, die das Skript ausgeführt wird, bevor es als fehlgeschlagen gilt. Der Standard ist 3 600 Sekunden (1 Stunde). Für jedes Bereitstellungslebenszyklusereignis sind maximal 3 600 Sekunden (1 Stunde) für die Ausführung von Skripts zulässig. Wenn Skripts dieses Limit überschreiten, wird die Bereitstellung angehalten und die Bereitstellung auf der Instance schlägt fehl. Stellen Sie sicher, dass die für **timeout** angegebene Gesamtanzahl der Sekunden für alle Skripts in jedem Bereitstellungslebenszyklusereignis dieses Limit nicht überschreitet. ** runas ** Optional. Der Benutzer, der vorgetäuscht werden soll, wenn das Skript ausgeführt wird. Standardmäßig ist dies der CodeDeploy Agent, der auf der Instanz ausgeführt wird. CodeDeploy speichert keine Passwörter, sodass der Benutzer nicht imitiert werden kann, wenn der **Runas-Benutzer** ein Passwort benötigt. Dieses Element gilt nur für Amazon Linux- und Ubuntu Server-Instances. ### Referenzieren von Dateien in Ihren Hook-Skripten Wenn Sie ein Skript mit einem CodeDeploy Lebenszyklusereignis verknüpfen, wie unter beschrieben[AppSpec Abschnitt „Hooks“](#reference-appspec-file-structure-hooks), und Sie in Ihrem Skript auf eine Datei verweisen möchten (z. B.`helper.sh`), müssen Sie Folgendes angeben`helper.sh`: + (Empfohlen) Ein absoluter Pfad. Siehe [Absolute Pfade verwenden](#codedeploy-agent-working-dir-absolute). + Ein relativer Pfad. Siehe [Verwenden relativer Pfade](#codedeploy-agent-working-dir-relative). #### Absolute Pfade verwenden Um mit ihrem *absoluten* Pfad auf eine Datei zu verweisen, können Sie entweder: + Geben Sie den absoluten Pfad im `files` Abschnitt der AppSpec Datei in der `destination` Eigenschaft an. Geben Sie dann denselben absoluten Pfad in Ihrem Hook-Skript an. Weitere Informationen finden Sie unter [AppSpec Abschnitt „Dateien“ (nur für EC2/lokale Bereitstellungen)](reference-appspec-file-structure-files.md). + Geben Sie einen dynamischen absoluten Pfad in Ihrem Hook-Skript an. Weitere Informationen finden Sie unter [Speicherort des Deployment-Archivs](#codedeploy-agent-working-dir-archive). **Speicherort des Bereitstellungsarchivs** Während des [DownloadBundle](#reference-appspec-file-structure-hooks-list)Lebenszyklusereignisses extrahiert der CodeDeploy Agent die [Version](application-revisions.md) für die Bereitstellung in ein Verzeichnis, das das folgende Format hat: `root-directory/deployment-group-id/deployment-id/deployment-archive` Der *root-directory* Teil des Pfads ist immer entweder auf den in der folgenden Tabelle angegebenen Standard festgelegt oder wird durch die `:root_dir` Konfigurationseinstellung gesteuert. Weitere Informationen zu den Konfigurationseinstellungen finden Sie unter[CodeDeploy Referenz zur Agentenkonfiguration](reference-agent-configuration.md). | Agentenplattform | Standard-Stammverzeichnis | | --- | --- | | Linux — alle RPM-Distributionen | /opt/codedeploy-agent/deployment-root | | Ubuntu Server — alle Deb-Distributionen | /opt/codedeploy-agent/deployment-root | | Windows Server | %ProgramData%\$1Amazon\$1CodeDeploy | Von Ihren Hook-Skripten aus könnten Sie mithilfe des Stammverzeichnispfads und der `DEPLOYMENT_GROUP_ID` Umgebungsvariablen auf das `DEPLOYMENT_ID` aktuelle Deployment-Archiv zugreifen. Weitere Hinweise zu Variablen, die Sie verwenden können, finden Sie unter[Verfügbarkeit von Umgebungsvariablen für Hooks](#reference-appspec-file-structure-environment-variable-availability). So könnten Sie beispielsweise auf eine `data.json` Datei zugreifen, die sich im Stammverzeichnis Ihrer Revision unter Linux befindet: ``` #!/bin/bash rootDirectory="/opt/codedeploy-agent/deployment-root" # note: this will be different if you # customize the :root_dir configuration dataFile="$rootDirectory/$DEPLOYMENT_GROUP_ID/$DEPLOYMENT_ID/deployment-archive/data.json" data=$(cat dataFile) ``` Als weiteres Beispiel können Sie mit Powershell unter Windows auf eine `data.json` Datei zugreifen, die sich im Stammverzeichnis Ihrer Revision befindet: ``` $rootDirectory="$env:ProgramData\Amazon\CodeDeploy" # note: this will be different if you # customize the :root_dir configuration $dataFile="$rootDirectory\$env:DEPLOYMENT_GROUP_ID\$env:DEPLOYMENT_ID\deployment-archive\data.json" $data=(Get-Content $dataFile) ``` #### Verwenden relativer Pfade Um mit ihrem *relativen* Pfad auf eine Datei zu verweisen, müssen Sie das Arbeitsverzeichnis des CodeDeploy Agenten kennen. Dateipfade sind relativ zu diesem Verzeichnis. Die folgende Tabelle zeigt das Arbeitsverzeichnis für jede unterstützte Plattform des CodeDeploy Agenten. [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/de_de/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html) ### Verfügbarkeit von Umgebungsvariablen für Hooks Während jedes Bereitstellungslebenszyklusereignisses können Hook-Skripts auf die folgenden Umgebungsvariablen zugreifen: ** APPLICATION\$1NAME ** Der Name der Anwendung CodeDeploy , die Teil der aktuellen Bereitstellung ist (z. B.`WordPress_App`). ** DEPLOYMENT\$1ID ** Die ID, die der aktuellen Bereitstellung zugewiesen CodeDeploy wurde (z. B.`d-AB1CDEF23`). ** DEPLOYMENT\$1GROUP\$1NAME ** Der Name der Bereitstellungsgruppe CodeDeploy , die Teil der aktuellen Bereitstellung ist (z. B.`WordPress_DepGroup`). ** DEPLOYMENT\$1GROUP\$1ID ** Die ID der Bereitstellungsgruppe CodeDeploy , die Teil der aktuellen Bereitstellung ist (z. B.`b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE`). ** LIFECYCLE\$1EVENT ** Der Name des aktuellen Bereitstellungslebenszyklusereignisses (z. B. `AfterInstall`). Es handelt sich um lokale Umgebungsvariablen für die einzelnen Bereitstellungslebenszyklusereignisse. Abhängig von der Quelle des Bereitstellungspakets stehen zusätzliche Umgebungsvariablen für Hook-Skripte zur Verfügung: **Paket von Amazon S3** + **BUNDLE\$1BUCKET** Der Name des Amazon S3 S3-Buckets, aus dem das Bereitstellungspaket heruntergeladen wurde (z. B.`my-s3-bucket`). + **BUNDLE\$1KEY** Der Objektschlüssel für das heruntergeladene Paket innerhalb des Amazon S3 S3-Buckets (z. B.`WordPress_App.zip`). + **BUNDLE\$1VERSION** Die Objektversion für das Bundle (zum Beispiel). `3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo` Diese Variable wird nur gesetzt, wenn für den Amazon S3 S3-Bucket die [Objektversionierung](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) aktiviert ist. + **BUNDLE\$1ETAG** Das Objekt-Etag für das Bundle (zum Beispiel). `b10a8db164e0754105b7a99be72e3fe5-4` **Paket von GitHub** + **BUNDLE\$1COMMIT** Der SHA256 Commit-Hash des von Git generierten Bundles (zum Beispiel`d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26`). Das folgende Skript ändert den Überwachungsport auf einem Apache HTTP-Server von 80 auf 9090, wenn der Wert von **DEPLOYMENT\$1GROUP\$1NAME** gleich `Staging` ist. Dieses Skript muss während des Bereitstellungslebenszyklusereignisses `BeforeInstall` aufgerufen werden: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf fi ``` Das folgende Skriptbeispiel ändert die Ausführlichkeitsstufe der Nachrichten, die im Fehlerprotokoll aufgezeichnet werden, von Warnung zu Debug-Nachricht, wenn der Wert der Umgebungsvariablen **DEPLOYMENT\$1GROUP\$1NAME** gleich `Staging` ist. Dieses Skript muss während des Bereitstellungslebenszyklusereignisses `BeforeInstall` aufgerufen werden: ``` if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ] then sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf fi ``` Das folgende Skriptbeispiel ersetzt den Text auf der angegebenen Webseite mit Text, der den Wert dieser Umgebungsvariablen anzeigt. Dieses Skript muss während des Bereitstellungslebenszyklusereignisses `AfterInstall` aufgerufen werden: ``` #!/usr/bin/python import os strToSearch="

This application was deployed using CodeDeploy.

" strToReplace="

This page for "+os.environ['APPLICATION_NAME']+" application and "+os.environ['DEPLOYMENT_GROUP_NAME']+" deployment group with "+os.environ['DEPLOYMENT_GROUP_ID']+" deployment group ID was generated by a "+os.environ['LIFECYCLE_EVENT']+" script during "+os.environ['DEPLOYMENT_ID']+" deployment.

" fp=open("/var/www/html/index.html","r") buffer=fp.read() fp.close() fp=open("/var/www/html/index.html","w") fp.write(buffer.replace(strToSearch,strToReplace)) fp.close() ``` ### Beispiel für Hooks Hier finden Sie ein Beispiel für einen **hooks**-Eintrag, der zwei Hooks für das `AfterInstall`-Lebenszyklusereignis angibt: ``` hooks: AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 - location: Scripts/PostDeploy.sh timeout: 180 ``` Das Skript `Scripts/RunResourceTests.sh` wird während der Stufe `AfterInstall` des Bereitstellungsvorgangs ausgeführt. Die Implementierung schlägt fehl, wenn die Ausführung des Skripts mehr als 180 Sekunden (3 Minuten) dauert. Der Speicherort von Skripts, den Sie im Abschnitt „Hooks“ angeben, ist relativ zum Stamm des Anwendungsrevisionspakets. Im obigen Beispiel befindet sich eine Datei mit dem Namen `RunResourceTests.sh` in einem Verzeichnis mit dem Namen `Scripts`. Das Verzeichnis `Scripts` befindet sich auf der Stammebene des Pakets. Weitere Informationen finden Sie unter [Planen Sie eine Revision für CodeDeploy](application-revisions-plan.md). # AppSpec Beispiel für eine Datei Dieses Thema enthält AppSpec Beispieldateien für eine AWS Lambda- und eine EC2/On-Premises-Bereitstellung. **Topics** + [AppSpec Dateibeispiel für eine Amazon ECS-Bereitstellung](#appspec-file-example-ecs) + [AppSpec Dateibeispiel für eine AWS Lambda-Bereitstellung](#appspec-file-example-lambda) + [AppSpec Dateibeispiel für eine EC2/On-Premises-Bereitstellung](#appspec-file-example-server) ## AppSpec Dateibeispiel für eine Amazon ECS-Bereitstellung Hier ist ein Beispiel für eine in YAML geschriebene AppSpec Datei für die Bereitstellung eines Amazon ECS-Service. ``` version: 0.0 Resources: - TargetService: Type: AWS::ECS::Service Properties: TaskDefinition: "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1" LoadBalancerInfo: ContainerName: "SampleApplicationName" ContainerPort: 80 # Optional properties PlatformVersion: "LATEST" NetworkConfiguration: AwsvpcConfiguration: Subnets: ["subnet-1234abcd","subnet-5678abcd"] SecurityGroups: ["sg-12345678"] AssignPublicIp: "ENABLED" CapacityProviderStrategy: - Base: 1 CapacityProvider: "FARGATE_SPOT" Weight: 2 - Base: 0 CapacityProvider: "FARGATE" Weight: 1 Hooks: - BeforeInstall: "LambdaFunctionToValidateBeforeInstall" - AfterInstall: "LambdaFunctionToValidateAfterInstall" - AfterAllowTestTraffic: "LambdaFunctionToValidateAfterTestTrafficStarts" - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeAllowingProductionTraffic" - AfterAllowTraffic: "LambdaFunctionToValidateAfterAllowingProductionTraffic" ``` Hier finden Sie eine Version des obigen Beispiels in JSON. ``` { "version": 0.0, "Resources": [ { "TargetService": { "Type": "AWS::ECS::Service", "Properties": { "TaskDefinition": "arn:aws:ecs:us-east-1:111222333444:task-definition/my-task-definition-family-name:1", "LoadBalancerInfo": { "ContainerName": "SampleApplicationName", "ContainerPort": 80 }, "PlatformVersion": "LATEST", "NetworkConfiguration": { "AwsvpcConfiguration": { "Subnets": [ "subnet-1234abcd", "subnet-5678abcd" ], "SecurityGroups": [ "sg-12345678" ], "AssignPublicIp": "ENABLED" } }, "CapacityProviderStrategy": [ { "Base" : 1, "CapacityProvider" : "FARGATE_SPOT", "Weight" : 2 }, { "Base" : 0, "CapacityProvider" : "FARGATE", "Weight" : 1 } ] } } } ], "Hooks": [ { "BeforeInstall": "LambdaFunctionToValidateBeforeInstall" }, { "AfterInstall": "LambdaFunctionToValidateAfterInstall" }, { "AfterAllowTestTraffic": "LambdaFunctionToValidateAfterTestTrafficStarts" }, { "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeAllowingProductionTraffic" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterAllowingProductionTraffic" } ] } ``` Hier finden Sie die Ereignisabfolge während der Bereitstellung: 1. Bevor die aktualisierte Amazon ECS-Anwendung auf dem Ersatz-Tasksatz installiert wird, wird die Lambda-Funktion mit dem Namen `LambdaFunctionToValidateBeforeInstall` ausgeführt. 1. Nachdem die aktualisierte Amazon ECS-Anwendung auf dem Ersatzaufgabensatz installiert wurde, aber bevor sie Datenverkehr empfängt, wird die Lambda-Funktion namens Lambda-Funktion `LambdaFunctionToValidateAfterInstall` ausgeführt. 1. Nachdem die Amazon ECS-Anwendung auf dem Ersatzaufgabensatz anfängt, Datenverkehr vom Test-Listener zu empfangen, wird die Lambda-Funktion namens `LambdaFunctionToValidateAfterTestTrafficStarts` Lambda-Funktion ausgeführt. Diese Funktion führt wahrscheinlich Validierungstests durch, um zu bestimmen, ob die Bereitstellung fortgesetzt wird. Wenn Sie keinen Test-Listener in Ihrer Bereitstellungsgruppe angeben, wird dieser Hook ignoriert. 1. Nachdem alle Validierungstests im `AfterAllowTestTraffic` Hook abgeschlossen sind und bevor der Produktionsdatenverkehr an die aktualisierte Amazon ECS-Anwendung weitergeleitet wird, wird die Lambda-Funktion mit dem Namen `LambdaFunctionToValidateBeforeAllowingProductionTraffic` ausgeführt. 1. Nachdem der Produktionsdatenverkehr für die aktualisierte Amazon ECS-Anwendung auf dem Ersatz-Tasksatz bereitgestellt wurde, wird die Lambda-Funktion namens Lambda-Funktion `LambdaFunctionToValidateAfterAllowingProductionTraffic` ausgeführt. Die Lambda-Funktionen, die während eines beliebigen Hooks ausgeführt werden, können Validierungstests durchführen oder Verkehrsmetriken sammeln. ## AppSpec Dateibeispiel für eine AWS Lambda-Bereitstellung Hier ist ein Beispiel für eine in YAML geschriebene AppSpec Datei für die Bereitstellung einer Lambda-Funktionsversion. ``` version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "myLambdaFunction" Alias: "myLambdaFunctionAlias" CurrentVersion: "1" TargetVersion: "2" Hooks: - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift" - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift" ``` Hier finden Sie eine Version des obigen Beispiels in JSON. ``` { "version": 0.0, "Resources": [{ "myLambdaFunction": { "Type": "AWS::Lambda::Function", "Properties": { "Name": "myLambdaFunction", "Alias": "myLambdaFunctionAlias", "CurrentVersion": "1", "TargetVersion": "2" } } }], "Hooks": [{ "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift" } ] } ``` Hier finden Sie die Ereignisabfolge während der Bereitstellung: 1. Bevor Sie den Datenverkehr von Version 1 einer aufgerufenen Lambda-Funktion `myLambdaFunction` auf Version 2 verlagern, führen Sie eine Lambda-Funktion namens aus, `LambdaFunctionToValidateBeforeTrafficShift` die bestätigt, dass die Bereitstellung bereit ist, mit der Verkehrsverlagerung zu beginnen. 1. Wenn `LambdaFunctionToValidateBeforeTrafficShift` den Exit-Code 0 (Erfolg) zurückgibt, fangen Sie an, Datenverkehr in Version 2 von `myLambdaFunction` zu verschieben. Die Bereitstellungskonfiguration für diese Bereitstellung bestimmt die Geschwindigkeit, in der der Datenverkehr verschoben wird. 1. Nachdem die Übertragung des Datenverkehrs von Version 1 einer aufgerufenen Lambda-Funktion `myLambdaFunction` auf Version 2 abgeschlossen ist, führen Sie eine aufgerufene Lambda-Funktion aus, `LambdaFunctionToValidateAfterTrafficShift` die bestätigt, dass die Bereitstellung erfolgreich abgeschlossen wurde. ## AppSpec Dateibeispiel für eine EC2/On-Premises-Bereitstellung Hier ist ein Beispiel für eine AppSpec Datei für eine direkte Bereitstellung auf einer Amazon Linux-, Ubuntu Server- oder RHEL-Instance. **Anmerkung** Bereitstellungen auf Windows Server-Instances unterstützen das Element nicht. `runas` Wenn Sie es auf Windows Server-Instanzen bereitstellen, nehmen Sie es nicht in Ihre AppSpec Datei auf. ``` version: 0.0 os: linux files: - source: Config/config.txt destination: /webapps/Config - source: source destination: /webapps/myApp hooks: BeforeInstall: - location: Scripts/UnzipResourceBundle.sh - location: Scripts/UnzipDataBundle.sh AfterInstall: - location: Scripts/RunResourceTests.sh timeout: 180 ApplicationStart: - location: Scripts/RunFunctionalTests.sh timeout: 3600 ValidateService: - location: Scripts/MonitorService.sh timeout: 3600 runas: codedeployuser ``` Wechseln Sie für eine Windows Server-Instanz `os: linux` zu`os: windows`. Außerdem müssen Sie die `destination`-Pfade vollständig qualifizieren (z. B. `c:\temp\webapps\Config` und `c:\temp\webapps\myApp`). Beziehen Sie das Element `runas` nicht mit ein. Hier finden Sie die Ereignisabfolge während der Bereitstellung: 1. Führen Sie das Skript unter `Scripts/UnzipResourceBundle.sh` aus. 1. Wenn das vorherige Skript einen Beendigungscode von 0 (Erfolg) wiedergegeben hat, führen Sie das Skript unter `Scripts/UnzipDataBundle.sh` aus. 1. Kopieren Sie den Dateipfad von `Config/config.txt` zum Pfad `/webapps/Config/config.txt`. 1. Kopieren Sie rekursiv alle Dateien im Verzeichnis `source` in das Verzeichnis `/webapps/myApp`. 1. Führen Sie das Skript unter `Scripts/RunResourceTests.sh` mit einem Timeout von 180 Sekunden (3 Minuten) aus. 1. Führen Sie das Skript unter `Scripts/RunFunctionalTests.sh` mit einem Timeout von 3 600 Sekunden (1 Stunde) aus. 1. Führen Sie das Skript unter `Scripts/MonitorService.sh` als Benutzer `codedeploy` mit einem Timeout von 3 600 Sekunden (1 Stunde) aus. ## AppSpec Abstand zwischen den Dateien Im Folgenden finden Sie das richtige Format für den AppSpec Dateiabstand. Die Zahlen in eckigen Klammern geben die Anzahl der Leerzeichen an, die zwischen Elementen eingefügt werden müssen. `[4]`Bedeutet zum Beispiel, vier Leerzeichen zwischen den Elementen einzufügen. CodeDeploy löst einen Fehler aus, der möglicherweise schwer zu debuggen ist, wenn die Speicherorte und die Anzahl der Leerzeichen in einer AppSpec Datei nicht korrekt sind. ``` version:[1]version-number os:[1]operating-system-name files: [2]-[1]source:[1]source-files-location [4]destination:[1]destination-files-location permissions: [2]-[1]object:[1]object-specification [4]pattern:[1]pattern-specification [4]except:[1]exception-specification [4]owner:[1]owner-account-name [4]group:[1]group-name [4]mode:[1]mode-specification [4]acls: [6]-[1]acls-specification [4]context: [6]user:[1]user-specification [6]type:[1]type-specification [6]range:[1]range-specification [4]type: [6]-[1]object-type hooks: [2]deployment-lifecycle-event-name: [4]-[1]location:[1]script-location [6]timeout:[1]timeout-in-seconds [6]runas:[1]user-name ``` Hier ist ein Beispiel für eine Datei mit korrektem Abstand AppSpec : ``` 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/change_permissions.sh timeout: 300 runas: root ApplicationStart: - location: scripts/start_server.sh - location: scripts/create_test_db.sh timeout: 300 runas: root ApplicationStop: - location: scripts/stop_server.sh timeout: 300 runas: root ``` Weitere Informationen über Leerzeichen finden Sie in der [YAML](http://www.yaml.org)-Spezifikation. # Bestätigen Sie Ihre AppSpec Datei und den Dateispeicherort **Dateisyntax** Sie können das AWS mitgelieferte AppSpec Assistant-Skript verwenden, um den Inhalt einer AppSpec Datei zu überprüfen. Sie finden das Skript zusammen mit den AppSpec Dateivorlagen unter [GitHub](https://github.com/aws-samples/aws-codedeploy-appspec-assistant). Sie können auch ein browserbasiertes Tool wie [YAML Lint oder Online YAML](http://www.yamllint.com/) [Parser verwenden, um Ihre YAML-Syntax](http://yaml-online-parser.appspot.com/) zu überprüfen. **Speicherort der Datei** Führen Sie einen der folgenden Befehle aus, um zu überprüfen, ob Sie Ihre AppSpec Datei im Stammverzeichnis der Verzeichnisstruktur des Quellinhalts der Anwendung abgelegt haben: Auf lokalen Linux-, macOS- oder Unix-Instanzen: ``` ls path/to/root/directory/appspec.yml ``` Wenn sich die AppSpec Datei dort nicht befindet, wird die Fehlermeldung „Keine solche Datei oder kein solches Verzeichnis“ angezeigt. Auf lokalen Windows-Instances: ``` dir path\to\root\directory\appspec.yml ``` Wenn sich die AppSpec Datei dort nicht befindet, wird der Fehler „Datei nicht gefunden“ angezeigt.