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 exemples de AppSpec fichiers pour un déploiement AWS Lambda et EC2 /On-Premises.

AppSpec Exemple de fichier pour un ECS déploiement Amazon

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

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 une version de l'exemple précédent écrit enJSON.

{ "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'ECSapplication Amazon 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'ECSapplication Amazon 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'ECSapplication Amazon 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 transmis à l'ECSapplication Amazon mise à jour, la fonction Lambda appelée s'LambdaFunctionToValidateBeforeAllowingProductionTrafficexécute.

  5. Une fois que le trafic de production est envoyé à l'ECSapplication Amazon 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 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 une version de l'exemple précédent écrit enJSON.

{ "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 /On-Premises

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

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).