AppSpec Exemple de fichier - AWS CodeDeploy

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

AppSpec Exemple de fichier

Cette rubrique fournit des AppSpec fichiers d'exemple pour un déploiement AWS Lambda et EC2/on-premises.

AppSpec Exemple de fichier pour un déploiement Amazon ECS

Voici un exemple de AppSpec fichier écrit en YAML pour déployer un service Amazon ECS.

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"

Voici la version JSON de l'exemple précédent.

{ "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" } ] }

Voici la séquence d'événements durant le déploiement :

  1. Avant que l'application Amazon ECS mise à jour ne soit installée sur l'ensemble de tâches de remplacement, la fonction Lambda appelée s'LambdaFunctionToValidateBeforeInstallexécute.

  2. Une fois que l'application Amazon ECS mise à jour est installée sur l'ensemble de tâches de remplacement, mais avant qu'elle ne reçoive le moindre trafic, la fonction Lambda appelée s'LambdaFunctionToValidateAfterInstallexécute.

  3. Une fois que l'application Amazon ECS associée à l'ensemble de tâches de remplacement commence à recevoir du trafic en provenance de l'écouteur de test, la fonction LambdaFunctionToValidateAfterTestTrafficStarts Lambda appelée s'exécute. Cette fonction exécute fréquemment des tests de validation pour déterminer si le déploiement se poursuit. Si aucun écouteur de test n'est défini dans votre groupe de déploiement, le hook est ignoré.

  4. Une fois tous les tests de validation effectués dans le AfterAllowTestTraffic hook et avant que le trafic de production ne soit envoyé à l'application Amazon ECS mise à jour, la fonction Lambda appelée s'LambdaFunctionToValidateBeforeAllowingProductionTrafficexécute.

  5. Une fois que le trafic de production est envoyé à l'application Amazon ECS mise à jour sur l'ensemble de tâches de remplacement, la fonction Lambda appelée s'LambdaFunctionToValidateAfterAllowingProductionTrafficexécute.

Les fonctions Lambda qui s'exécutent pendant n'importe quel hook peuvent effectuer des tests de validation ou collecter des métriques de trafic.

AppSpec Exemple de fichier pour un déploiement AWS Lambda

Voici un exemple de AppSpec fichier écrit en YAML pour déployer une version de fonction Lambda.

version: 0.0 Resources: - myLambdaFunction: Type: AWS::Lambda::Function Properties: Name: "myLambdaFunction" Alias: "myLambdaFunctionAlias" CurrentVersion: "1" TargetVersion: "2" Hooks: - BeforeAllowTraffic: "LambdaFunctionToValidateBeforeTrafficShift" - AfterAllowTraffic: "LambdaFunctionToValidateAfterTrafficShift"

Voici la version JSON de l'exemple précédent.

{ "version": 0.0, "Resources": [{ "myLambdaFunction": { "Type": "AWS::Lambda::Function", "Properties": { "Name": "myLambdaFunction", "Alias": "myLambdaFunctionAlias", "CurrentVersion": "1", "TargetVersion": "2" } } }], "Hooks": [{ "BeforeAllowTraffic": "LambdaFunctionToValidateBeforeTrafficShift" }, { "AfterAllowTraffic": "LambdaFunctionToValidateAfterTrafficShift" } ] }

Voici la séquence d'événements durant le déploiement :

  1. Avant de transférer le trafic de la version 1 d'une fonction Lambda appelée myLambdaFunction vers la version 2, exécutez une fonction Lambda appelée LambdaFunctionToValidateBeforeTrafficShift qui valide que le déploiement est prêt à démarrer le transfert de trafic.

  2. Si LambdaFunctionToValidateBeforeTrafficShift retourne un code de sortie de 0 (succès), commencez à déplacer le trafic vers la version 2 de myLambdaFunction. La configuration de ce déploiement détermine le débit auquel le trafic est déplacé.

  3. Une fois le transfert du trafic de la version 1 d'une fonction Lambda appelée myLambdaFunction à la version 2 terminé, exécutez une fonction Lambda appelée LambdaFunctionToValidateAfterTrafficShift qui valide que le déploiement a été effectué avec succès.

AppSpec Exemple de fichier pour un déploiement EC2/sur site

Voici un exemple de AppSpec fichier pour un déploiement sur place sur une instance Amazon Linux, Ubuntu Server ou RHEL.

Note

Les déploiements sur des instances Windows Server ne prennent pas en charge runas cet élément. Si vous effectuez un déploiement sur des instances Windows Server, ne l'incluez pas dans votre AppSpec fichier.

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

Pour une instance Windows Server, passez os: linux àos: windows. En outre, vous devez utiliser des noms qualifiés complets pour les chemins destination (par exemple, c:\temp\webapps\Config et c:\temp\webapps\myApp). N'incluez pas l'élément runas.

Voici la séquence d'événements durant le déploiement :

  1. Exécutez le script situé dans Scripts/UnzipResourceBundle.sh.

  2. Si le script précédent a retourné un code de sortie 0 (réussite), exécutez le script situé dans Scripts/UnzipDataBundle.sh.

  3. Copiez le fichier du chemin d'accès Config/config.txt vers le chemin d'accès /webapps/Config/config.txt.

  4. Copiez de façon récursive tous les fichiers du répertoire source dans le répertoire /webapps/myApp.

  5. Exécutez le script situé dans Scripts/RunResourceTests.sh avec un délai de 180 secondes (3 minutes).

  6. Exécutez le script situé dans Scripts/RunFunctionalTests.sh avec un délai de 3600 secondes (1 heure).

  7. Exécutez le script situé dans Scripts/MonitorService.sh en tant qu'utilisateur codedeploy avec un délai de 3600 secondes (1 heure).