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.
Rubriques
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 :
-
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'
LambdaFunctionToValidateBeforeInstall
exécute. -
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'
LambdaFunctionToValidateAfterInstall
exécute. -
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é. -
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'LambdaFunctionToValidateBeforeAllowingProductionTraffic
exécute. -
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'
LambdaFunctionToValidateAfterAllowingProductionTraffic
exé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 :
-
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éeLambdaFunctionToValidateBeforeTrafficShift
qui valide que le déploiement est prêt à démarrer le transfert de trafic. -
Si
LambdaFunctionToValidateBeforeTrafficShift
retourne un code de sortie de 0 (succès), commencez à déplacer le trafic vers la version 2 demyLambdaFunction
. La configuration de ce déploiement détermine le débit auquel le trafic est déplacé. -
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éeLambdaFunctionToValidateAfterTrafficShift
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 :
-
Exécutez le script situé dans
Scripts/UnzipResourceBundle.sh
. -
Si le script précédent a retourné un code de sortie 0 (réussite), exécutez le script situé dans
Scripts/UnzipDataBundle.sh
. -
Copiez le fichier du chemin d'accès
Config/config.txt
vers le chemin d'accès/webapps/Config/config.txt
. -
Copiez de façon récursive tous les fichiers du répertoire
source
dans le répertoire/webapps/myApp
. -
Exécutez le script situé dans
Scripts/RunResourceTests.sh
avec un délai de 180 secondes (3 minutes). -
Exécutez le script situé dans
Scripts/RunFunctionalTests.sh
avec un délai de 3600 secondes (1 heure). -
Exécutez le script situé dans
Scripts/MonitorService.sh
en tant qu'utilisateurcodedeploy
avec un délai de 3600 secondes (1 heure).