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.
# CodeDeploy AppSpec référence de fichier
Cette section est fournie à des fins de référence uniquement. Pour une présentation conceptuelle du AppSpec fichier, voir[CodeDeploy fichiers de spécification de l'application (AppSpec)](application-specification-files.md).
Le fichier de spécification de l'application (AppSpec fichier) est un fichier au format [YAML](http://www.yaml.org) ou au format JSON utilisé pour gérer un déploiement. CodeDeploy
**Note**
Le AppSpec fichier d'un déploiement EC2/local doit être nommé`appspec.yml`, sauf si vous effectuez un déploiement local. Pour de plus amples informations, veuillez consulter [Création d'un déploiement local](deployments-local.md#deployments-local-deploy).
**Topics**
+ [
## AppSpec fichiers sur une plateforme de calcul Amazon ECS
](#appspec-reference-ecs)
+ [
## AppSpec fichiers sur une plate-forme AWS Lambda informatique
](#appspec-reference-lambda)
+ [
## AppSpec fichiers sur une plate-forme informatique EC2/sur site
](#appspec-reference-server)
+ [
# AppSpec Structure du fichier
](reference-appspec-file-structure.md)
+ [
# AppSpec Exemple de fichier
](reference-appspec-file-example.md)
+ [
## AppSpec Espacement des fichiers
](#reference-appspec-file-spacing)
+ [
# Validez votre AppSpec fichier et son emplacement
](reference-appspec-file-validate.md)
## AppSpec fichiers sur une plateforme de calcul Amazon ECS
Pour les applications de plate-forme de calcul Amazon ECS, le AppSpec fichier est utilisé CodeDeploy pour déterminer :
+ Votre fichier de définition de tâche Amazon ECS. Ceci est spécifié avec son ARN dans l'`TaskDefinition`instruction du AppSpec fichier.
+ Le conteneur et le port de votre ensemble de tâches de remplacement où votre Application Load Balancer ou Network Load Balancer redirige le trafic lors d'un déploiement. Ceci est spécifié dans les `LoadBalancerInfo` instructions du AppSpec fichier.
+ Informations facultatives concernant votre service Amazon ECS, telles que la version de plate-forme sur laquelle il s'exécute, ses sous-réseaux et ses groupes de sécurité.
+ Fonctions Lambda facultatives à exécuter pendant les hooks correspondant aux événements du cycle de vie lors d'un déploiement Amazon ECS. Pour de plus amples informations, veuillez consulter [AppSpec section « hooks » pour un déploiement Amazon ECS](reference-appspec-file-structure-hooks.md#appspec-hooks-ecs).
## AppSpec fichiers sur une plate-forme AWS Lambda informatique
Pour les applications de plate-forme de calcul AWS Lambda, le AppSpec fichier est utilisé pour CodeDeploy déterminer :
+ Quelle version de la fonction Lambda déployer.
+ Quelles fonctions Lambda utiliser comme tests de validation.
Un AppSpec fichier peut être au format YAML ou au format JSON. Vous pouvez également saisir le contenu d'un AppSpec fichier directement dans CodeDeploy la console lorsque vous créez un déploiement.
## AppSpec fichiers sur une plate-forme informatique EC2/sur site
Si votre application utilise la plate-forme de calcul EC2/on-premises, le AppSpec fichier doit être un fichier au format YAML nommé `appspec.yml` et il doit être placé à la racine de la structure de répertoires du code source de l'application. Dans le cas contraire, les déploiements échouent. Il est utilisé CodeDeploy pour déterminer :
+ Ce qu'il doit installer sur vos instances à partir de la révision de votre application dans Amazon S3 ou GitHub.
+ Quels hooks d'événement de cycle de vie exécuter en réponse à des événements de cycle de vie du déploiement.
Une fois AppSpec le fichier terminé, vous le regroupez, avec le contenu à déployer, dans un fichier d'archive (zip, tar ou tar compressé). Pour de plus amples informations, veuillez consulter [Travailler avec les révisions d'applications pour CodeDeploy](application-revisions.md).
**Note**
Les formats de fichier d'archive tar et tar compressé (.tar et .tar.gz) ne sont pas pris en charge pour les instances Windows Server.
Une fois que vous avez un fichier d'archive groupé (connu CodeDeploy sous le nom de *révision*), vous le chargez dans un bucket Amazon S3 ou un référentiel Git. Ensuite, vous utilisez CodeDeploy pour déployer la révision. Pour obtenir des instructions, veuillez consulter [Créez un déploiement avec CodeDeploy](deployments-create.md).
Le fichier appspec.yml pour un déploiement de plate-forme de calcul EC2/sur site est enregistré dans le répertoire racine de votre révision. Pour plus d’informations, consultez [Ajouter un AppSpec fichier pour un déploiement EC2/sur site](application-revisions-appspec-file.md#add-appspec-file-server) et [Planifier une révision pour CodeDeploy](application-revisions-plan.md).
# AppSpec Structure du fichier
Voici la structure de haut niveau d'un AppSpec fichier utilisé pour les déploiements sur les plateformes de calcul AWS Lambda et EC2/on-premises.
Une valeur d'un AppSpec fichier au format YAML qui est une chaîne ne doit pas être placée entre guillemets (« ») sauf indication contraire.
## AppSpec structure de fichiers pour les déploiements Amazon ECS
**Note**
Ce AppSpec fichier est écrit en YAML, mais vous pouvez utiliser la même structure pour en écrire un en JSON. Dans un AppSpec fichier au format JSON, une chaîne est toujours placée entre guillemets (« »).
```
version: 0.0
resources:
ecs-service-specifications
hooks:
deployment-lifecycle-event-mappings
```
Dans cette structure :
** **Version** **
Cette section indique la version du AppSpec fichier. Ne modifiez pas cette valeur. C'est obligatoire. Actuellement, la seule valeur autorisée est **0.0**. Il est réservé CodeDeploy pour une utilisation future.
Spécifiez **version** avec une chaîne.
** **resources** **
Cette section fournit des informations sur l'application Amazon ECS à déployer.
Pour de plus amples informations, veuillez consulter [AppSpec section « ressources » pour les déploiements Amazon ECS](reference-appspec-file-structure-resources.md#reference-appspec-file-structure-resources-ecs).
** **hooks** **
Cette section décrit les fonctions Lambda à exécuter lors d'événements spécifiques du cycle de vie du déploiement afin de valider le déploiement.
Pour de plus amples informations, veuillez consulter [Liste des hooks d'événements liés au cycle de vie pour un déploiement d'Amazon ECS](reference-appspec-file-structure-hooks.md#reference-appspec-file-structure-hooks-list-ecs).
## AppSpec structure de fichiers pour les AWS déploiements Lambda
**Note**
Ce AppSpec fichier est écrit en YAML, mais vous pouvez utiliser la même structure pour écrire un AppSpec fichier pour un déploiement Lambda en JSON. Dans un AppSpec fichier au format JSON, une chaîne est toujours placée entre guillemets (« »).
```
version: 0.0
resources:
lambda-function-specifications
hooks:
deployment-lifecycle-event-mappings
```
Dans cette structure :
** **Version** **
Cette section indique la version du AppSpec fichier. Ne modifiez pas cette valeur. C'est obligatoire. Actuellement, la seule valeur autorisée est **0.0**. Il est réservé CodeDeploy pour une utilisation future.
Spécifiez **version** avec une chaîne.
** **resources** **
Cette section fournit des informations sur la fonction Lambda à déployer.
Pour de plus amples informations, veuillez consulter [AppSpec section « ressources » (Amazon ECS et AWS Lambda déploiements uniquement)](reference-appspec-file-structure-resources.md).
** **hooks** **
Cette section décrit les fonctions Lambda à exécuter lors d'événements spécifiques du cycle de vie du déploiement afin de valider le déploiement.
Pour de plus amples informations, veuillez consulter [AppSpec section « crochets »](reference-appspec-file-structure-hooks.md).
## AppSpec structure de fichiers pour les déploiements EC2/sur site
```
version: 0.0
os: operating-system-name
files:
source-destination-files-mappings
permissions:
permissions-specifications
hooks:
deployment-lifecycle-event-mappings
```
Dans cette structure :
** **Version** **
Cette section indique la version du AppSpec fichier. Ne modifiez pas cette valeur. C'est obligatoire. Actuellement, la seule valeur autorisée est **0.0**. Il est réservé CodeDeploy pour une utilisation future.
Spécifiez **version** avec une chaîne.
** **os** **
Cette section spécifie la valeur du système d'exploitation de l'instance sur laquelle vous déployez. C'est obligatoire. Les valeurs suivantes peuvent être spécifiées :
+ **linux** — L'instance est une instance Amazon Linux, Ubuntu Server ou RHEL.
+ **windows** — L'instance est une instance Windows Server.
Spécifiez **os** avec une chaîne.
** **files** **
Cette section spécifie les noms des fichiers qui doivent être copiés sur l'instance au cours de l'événement **Install** du déploiement.
Pour de plus amples informations, veuillez consulter [AppSpec section « fichiers » (déploiements EC2/sur site uniquement)](reference-appspec-file-structure-files.md).
** **permissions** **
Cette section spécifie les autorisations spéciales éventuelles qui doivent être appliquées aux fichiers de la section `files` lorsqu'ils sont copiés vers l'instance. Cette section s'applique uniquement aux instances Amazon Linux, Ubuntu Server et Red Hat Enterprise Linux (RHEL).
Pour plus d'informations, voir,[AppSpec section « autorisations » (déploiements EC2/sur site uniquement)](reference-appspec-file-structure-permissions.md).
** **hooks** **
Cette section spécifie les scripts à exécuter lors d'événements spécifiques de cycle de vie de déploiement, au cours du déploiement.
Pour de plus amples informations, veuillez consulter [AppSpec section « crochets »](reference-appspec-file-structure-hooks.md).
**Topics**
+ [
## AppSpec structure de fichiers pour les déploiements Amazon ECS
](#ecs-appspec-structure)
+ [
## AppSpec structure de fichiers pour les AWS déploiements Lambda
](#lambda-appspec-structure)
+ [
## AppSpec structure de fichiers pour les déploiements EC2/sur site
](#server-appspec-structure)
+ [
# AppSpec section « fichiers » (déploiements EC2/sur site uniquement)
](reference-appspec-file-structure-files.md)
+ [
# AppSpec section « ressources » (Amazon ECS et AWS Lambda déploiements uniquement)
](reference-appspec-file-structure-resources.md)
+ [
# AppSpec section « autorisations » (déploiements EC2/sur site uniquement)
](reference-appspec-file-structure-permissions.md)
+ [
# AppSpec section « crochets »
](reference-appspec-file-structure-hooks.md)
# AppSpec section « fichiers » (déploiements EC2/sur site uniquement)
Fournit des informations CodeDeploy sur les fichiers issus de la révision de votre application qui doivent être installés sur l'instance lors de l'événement **Install** du déploiement. Cette section est obligatoire uniquement si vous copiez des fichiers à partir de votre révision dans des emplacements sur l'instance durant le déploiement.
Cette section a la structure suivante :
```
files:
- source: source-file-location-1
destination: destination-file-location-1
file_exists_behavior: DISALLOW|OVERWRITE|RETAIN
```
Plusieurs paires `source` et `destination` peuvent être définies.
L'instruction `source` identifie un fichier ou un répertoire de votre révision à copier sur l'instance :
+ Si `source` fait référence à un fichier, seuls les fichiers spécifiés sont copiés sur l'instance.
+ Si `source` fait référence à un répertoire, tous les fichiers figurant dans le répertoire sont copiés sur l'instance.
+ S'il s'`source`agit d'une barre oblique unique («/» pour les instances Amazon Linux, RHEL et Ubuntu Server, ou « \$1 » pour les instances Windows Server), tous les fichiers de votre révision sont copiés sur l'instance.
Les chemins utilisés dans `source` sont relatifs au `appspec.yml` fichier, qui doit se trouver à la racine de votre révision. Pour plus de détails sur la structure de fichier d'une révision, voir[Planifier une révision pour CodeDeploy](application-revisions-plan.md).
L'instruction `destination` identifie l'emplacement sur l'instance où les fichiers doivent être copiés. Il doit s'agir d'un chemin entièrement qualifié tel que `/root/destination/directory` (sous Linux, RHEL et Ubuntu) ou `c:\destination\folder` (sous Windows).
Les instructions `source` et `destination` sont spécifiées chacune avec une chaîne.
L'`file_exists_behavior`instruction est facultative et indique comment CodeDeploy gère les fichiers qui existent déjà dans un emplacement cible de déploiement mais qui ne faisaient pas partie du déploiement réussi précédent. Ce paramètre peut prendre l'une des valeurs suivantes :
+ INTERDIRE : le déploiement échoue. C'est également le comportement par défaut si aucune option n'est spécifiée.
+ REMPLACER : La version du fichier issue de la révision de l'application en cours de déploiement remplace la version déjà présente sur l'instance.
+ CONSERVER : La version du fichier déjà présente sur l'instance est conservée et utilisée dans le cadre du nouveau déploiement.
Lorsque vous utilisez le `file_exists_behavior` paramètre, sachez que celui-ci :
+ ne peut être spécifié qu'une seule fois et s'applique à tous les fichiers et répertoires répertoriés ci-dessous`files:`.
+ a priorité sur l'`--file-exists-behavior` AWS CLI option et l'option `fileExistsBehavior` API (qui sont également facultatives).
Voici un exemple de `files` section pour une instance Amazon Linux, Ubuntu Server ou RHEL.
```
files:
- source: Config/config.txt
destination: /webapps/Config
- source: source
destination: /webapps/myApp
```
Dans cet exemple, les deux opérations suivantes sont effectuées au cours de l'événement **Install** :
1. Copie du fichier `Config/config.txt` de votre révision vers le chemin `/webapps/Config/config.txt` sur l'instance.
1. Copie récursive de tous les fichiers du répertoire `source` de votre révision vers le répertoire `/webapps/myApp` sur l'instance.
## Exemples de sections « Fichiers »
Les exemples suivants montrent comment spécifier la section `files`. Bien que ces exemples décrivent les structures de fichiers et de répertoires (dossiers) de Windows Server, ils peuvent facilement être adaptés aux instances Amazon Linux, Ubuntu Server et RHEL.
**Note**
Seuls les déploiements EC2/sur site utilisent cette section. `files` Elle ne s'applique pas aux AWS déploiements Lambda.
Pour les exemples suivants, nous supposons que ces fichiers apparaissent dans le groupe à la racine de `source` :
+ `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
```
Pour les exemples suivants, nous supposons que `appspec.yml` apparaît dans le groupe à la racine de `source` avec un dossier nommé `my-folder` contenant trois fichiers :
+ `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 section « ressources » (Amazon ECS et AWS Lambda déploiements uniquement)
Le contenu de la `'resources'` section du AppSpec fichier varie en fonction de la plate-forme de calcul de votre déploiement. La `'resources'` section relative au déploiement d'Amazon ECS contient la définition de votre tâche Amazon ECS, le conteneur et le port pour acheminer le trafic vers votre ensemble de tâches Amazon ECS mis à jour, ainsi que d'autres informations facultatives. La `'resources'` section relative à un AWS Lambda déploiement contient le nom, l'alias, la version actuelle et la version cible d'une fonction Lambda.
**Topics**
+ [
## AppSpec section « ressources » pour les déploiements AWS Lambda
](#reference-appspec-file-structure-resources-lambda)
+ [
## AppSpec section « ressources » pour les déploiements Amazon ECS
](#reference-appspec-file-structure-resources-ecs)
## AppSpec section « ressources » pour les déploiements AWS Lambda
La `'resources'` section indique la fonction Lambda à déployer et présente la structure suivante :
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"
}
}
}
]
```
Chaque propriété est spécifiée avec une chaîne.
+ `name` : obligatoire. Il s'agit du nom de la fonction Lambda à déployer.
+ `alias` : obligatoire. Il s'agit du nom de l'alias de la fonction Lambda.
+ `currentversion` : obligatoire. Il s'agit de la version de la fonction Lambda vers laquelle le trafic pointe actuellement. Cette valeur doit être un entier positif valide.
+ `targetversion` : obligatoire. Il s'agit de la version de la fonction Lambda vers laquelle le trafic est transféré. Cette valeur doit être un entier positif valide.
## AppSpec section « ressources » pour les déploiements Amazon ECS
La `'resources'` section indique le service Amazon ECS à déployer et présente la structure suivante :
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
}
]
}
}
}
]
```
Chaque propriété est spécifiée par une chaîne à l'exception de`ContainerPort`, qui est un nombre.
+ `TaskDefinition` : obligatoire. Il s'agit de la définition de tâche à déployer pour le service Amazon ECS. Elle est spécifiée par l'ARN de la définition de tâche. Le format ARN est le suivant : `arn:aws:ecs:aws-region:account-id:task-definition/task-definition-family:task-definition-revision`. Pour plus d'informations, consultez [Amazon Resource Names (ARNs) et espaces AWS de noms de services](https://docs.aws.amazon.com/general/latest/gr/aws-arns-and-namespaces.html).
**Note**
La `:task-definition-revision` partie de l'ARN est facultative. S'il est omis, Amazon ECS utilise la dernière révision ACTIVE de la définition de tâche.
+ `ContainerName` : obligatoire. Il s'agit du nom du conteneur Amazon ECS qui contient votre application Amazon ECS. Il doit s'agir d'un conteneur spécifié dans votre définition de tâche Amazon ECS.
+ `ContainerPort` : obligatoire. Il s'agit du port du conteneur vers lequel le trafic sera acheminé.
+ `PlatformVersion`: Facultatif. Version de plateforme des tâches Fargate dans le service Amazon ECS déployé. Pour plus d'informations, consultez [Versions de plateforme AWS Fargate](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/platform_versions.html). S'il n'est pas spécifié, `LATEST` il est utilisé par défaut.
+ `NetworkConfiguration`: Facultatif. Sous `AwsvpcConfiguration`, vous pouvez spécifier les valeurs suivantes. Pour plus d'informations, consultez [AwsVpcConfiguration](https://docs.aws.amazon.com/AmazonECS/latest/APIReference/API_AwsVpcConfiguration.html)le manuel *Amazon ECS Container Service API Reference*.
+ `Subnets`: Facultatif. Liste séparée par des virgules d'un ou de plusieurs sous-réseaux de votre service Amazon ECS.
+ `SecurityGroups`: Facultatif. Liste séparée par des virgules d'un ou de plusieurs groupes de sécurité dans votre Amazon Elastic Container Service.
+ `AssignPublicIp`: Facultatif. Chaîne qui indique si l'interface Elastic network de votre service Amazon ECS reçoit une adresse IP publique. Les valeurs valides sont `ENABLED` et `DISABLED`.
**Note**
Sous `NetworkConfiguration`, tous les paramètres doivent être spécifiés ou aucun. Par exemple, si vous souhaitez spécifier `Subnets`, vous devez également spécifier `SecurityGroups` et `AssignPublicIp`. Si aucun n'est spécifié, CodeDeploy utilise les paramètres actuels du réseau Amazon ECS.
+ `CapacityProviderStrategy`: Facultatif. Liste des fournisseurs de capacité Amazon ECS que vous souhaitez utiliser pour votre déploiement. Pour plus d'informations, consultez les [fournisseurs de capacité Amazon ECS](https://docs.aws.amazon.com/AmazonECS/latest/developerguide/cluster-capacity-providers.html) dans le manuel *Amazon Elastic Container Service Developer Guide*. Pour chaque fournisseur de capacité, vous pouvez définir les paramètres suivants. Pour plus de détails sur ces paramètres, voir [AWS::ECS::ServiceCapacityProviderStrategyItem](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-ecs-service-capacityproviderstrategyitem.html)le *guide de AWS CloudFormation l'utilisateur*
+ `Base`: Facultatif. La valeur de base indique le nombre minimum de tâches à exécuter sur le fournisseur de capacité spécifié. Une base ne peut être définie que pour un seul fournisseur de capacité dans une stratégie de fournisseur de capacité. Si aucune valeur n'est spécifiée, la valeur par défaut de 0 est utilisée.
+ `CapacityProvider`: Facultatif. Nom abrégé du fournisseur de capacité. Exemple : *CapacityProvidera*
+ `Weight`: Facultatif.
La valeur de *poids* indique le pourcentage relatif du nombre total de tâches lancées devant utiliser le fournisseur de capacité spécifié. La valeur `weight` est prise en considération une fois que la valeur `base`, si elle est définie, est satisfaite.
Si aucune valeur `0` n'est spécifiée, la valeur par défaut de `weight` est utilisée. Lorsque plusieurs fournisseurs de capacité sont spécifiés dans le cadre d'une stratégie de fournisseur de capacité, au moins l'un des fournisseurs de capacité doit disposer d'une valeur de pondération supérieure à zéro ; les fournisseurs de capacité dont le poids est égal à `0` ne seront pas utilisés afin de placer des tâches. Si vous spécifiez, dans une stratégie, plusieurs fournisseurs de capacité qui possèdent tous un poids de `0`, toutes les actions `RunTask` ou `CreateService` utilisant la stratégie de fournisseur de capacité échoueront.
Un exemple de scénario d'utilisation des pondérations consiste à définir une stratégie contenant deux fournisseurs de capacité qui possèdent un poids de `1`. Puis, lorsque la `base` est satisfaite, les tâches sont réparties équitablement entre les deux fournisseurs de capacité. Dans la même logique, si vous spécifiez un poids de `1` pour *capacityProviderA* et un poids de `4` pour *capacityProviderB*, pour chaque tâche exécutée avec *capacityProviderA*, quatre tâches utiliseront *capacityProviderB*.
# AppSpec section « autorisations » (déploiements EC2/sur site uniquement)
La `'permissions'` section indique comment les autorisations spéciales, le cas échéant, doivent être appliquées aux fichiers et directories/folders à la `'files'` section après leur copie sur l'instance. Vous pouvez spécifier plusieurs instructions `object`. Cette section est facultative. Elle s'applique uniquement aux instances Amazon Linux, Ubuntu Server et RHEL.
**Note**
La `'permissions'` section est uniquement utilisée pour les déploiements EC2/sur site. Il n'est pas utilisé pour les AWS déploiements Lambda ou Amazon ECS.
Cette section a la structure suivante :
```
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
```
Les instructions sont les suivantes :
+ `object` : obligatoire. Il s'agit d'un ensemble d'objets de système de fichiers (fichiers ou répertoires/dossiers) auxquels les autorisations spécifiées sont appliquées après la copie des objets de système de fichiers sur l'instance.
Spécifiez `object` avec une chaîne.
+ `pattern` : facultatif. Spécifie un modèle pour appliquer des autorisations. Si elles ne sont pas spécifiées ou si elles sont spécifiées avec les caractères spéciaux **"\$1\$1"**, les autorisations sont appliquées à tous les fichiers ou répertoires correspondants, selon leur `type`.
Spécifiez `pattern` avec une chaîne placée entre guillemets ("").
+ `except` : facultatif. Spécifie les fichiers ou répertoires qui sont des exceptions par rapport à `pattern`
Spécifiez `except` avec une liste de chaînes séparées par des virgules entre crochets.
+ `owner` : facultatif. Nom du propriétaire de `object`. Si cette instruction n'est pas spécifiée, tous les propriétaires existants appliqués à la structure de fichiers ou de répertoires/dossiers d'origine restent inchangés après l'opération de copie.
Spécifiez `owner` avec une chaîne.
+ `group` : facultatif. Nom du groupe pour `object`. Si cette instruction n'est pas spécifiée, tous les groupes existants appliqués à la structure de fichiers ou de répertoires/dossiers d'origine restent inchangés après l'opération de copie.
Spécifiez `group` avec une chaîne.
+ `mode` : facultatif. Une valeur numérique spécifiant les autorisations à `object` appliquer. Le réglage du mode suit la syntaxe de la commande Linux chmod.
**Important**
Si la valeur inclut un zéro initial, vous devez l'entourer de guillemets doubles ou supprimer le zéro initial afin qu'il ne reste que trois chiffres.
**Note**
La notation symbolique telle que celle-ci n'**u\$1x**est pas prise en charge pour le `mode` paramètre.
Exemples :
+ `mode: "0644"`donne des autorisations de lecture et d'écriture au propriétaire de l'objet (6), des autorisations de lecture seule au groupe (4) et des autorisations de lecture seule à tous les autres utilisateurs (4).
+ `mode: 644`accorde les mêmes autorisations que`mode: "0644"`.
+ `mode: 4755`définit l'attribut setuid (4), donne des autorisations de contrôle complètes au propriétaire (7), donne des autorisations de lecture et d'exécution au groupe (5) et donne des autorisations de lecture et d'exécution à tous les autres utilisateurs (5).
Pour plus d'exemples, consultez la documentation de la commande Linux chmod.
Si aucun mode n'est spécifié, tous les modes existants appliqués à la structure de fichier ou de dossier d'origine restent inchangés après l'opération de copie.
+ `acls` : facultatif. Liste de chaînes de caractères représentant une ou plusieurs entrées de liste de contrôle d'accès (ACL) appliquées à `object`. Par exemple, **u:bob:rw** représente des autorisations de lecture et d'écriture pour l'utilisateur **bob**. (Pour plus d'exemples, consultez les exemples de formats d'entrées ACL dans la documentation relative à la commande Linux `setfacl`.) Vous pouvez spécifier plusieurs entrées ACL. Si `acls` ce n'est pas spécifié, tout élément existant ACLs appliqué au fichier ou à la directory/folder structure d'origine reste inchangé après l'opération de copie. Elles remplacent toutes celles qui existent déjà ACLs.
Spécifiez `acls` avec un tiret (-) suivi d'un espace, puis d'une chaîne (par exemple, `- u:jane:rw`). Si vous avez plusieurs listes ACL, chacune est spécifiée sur une ligne distincte.
**Note**
La définition d'utilisateurs anonymes, de groupes anonymes ou d'autres entrées ACL similaires entraîne l'échec du AppSpec fichier. Utilisez `mode` pour spécifier ces types d'autorisations à la place.
+ `context` : facultatif. Pour les instances compatibles Security-Enhanced Linux (SELinux), liste d'étiquettes contextuelles relatives à la sécurité à appliquer aux objets copiés. Les étiquettes sont spécifiées en tant que clés contenant `user`, `type` et `range`. (Pour plus d'informations, consultez la SELinux documentation.) Chaque clé est entrée avec une chaîne. Si elles ne sont pas spécifiées, toutes les étiquettes existantes appliquées au fichier ou à la directory/folder structure d'origine restent inchangées après l'opération de copie.
+ `user` : facultatif. L' SELinux utilisateur.
+ `type` : facultatif. Le nom du SELinux type.
+ `range` : facultatif. Le spécificateur SELinux de plage. Cette instruction n'a aucun effet, sauf si Multi-Level Security (MLS) et Multi-Category Security (MCS) sont activés sur la machine. Si ces options ne sont pas activées, `range` prend par défaut la valeur **s0**.
Spécifiez `context` avec une chaîne (par exemple, `user: unconfined_u`). Chaque instruction `context` est spécifiée sur une ligne distincte.
+ `type` : facultatif. Types d'objets auxquels appliquer les autorisations spécifiées. `type` est une chaîne qui peut être définie sur **file** ou **directory**. Si **file** est spécifié, les autorisations sont appliquées uniquement aux fichiers contenus immédiatement dans `object` après l'opération de copie (et non à `object` proprement dit). Si cette **directory** option est spécifiée, les autorisations sont appliquées de manière récursive à tous directories/folders ceux qui se trouvent n'importe où `object` après l'opération de copie (mais pas à `object` elle-même).
Spécifiez `type` avec un tiret (-) suivi d'un espace, puis d'une chaîne (par exemple, `- file`).
## Exemple de section « Autorisations »
L'exemple suivant montre comment spécifier la section `'permissions'` avec les instructions `object`, `pattern`, `except`, `owner`, `mode` et `type`. Cet exemple s'applique uniquement aux instances Amazon Linux, Ubuntu Server et RHEL. Dans cet exemple, supposez que les fichiers et dossiers suivants sont copiés vers l'instance dans la hiérarchie :
```
/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
```
Le AppSpec fichier suivant indique comment définir des autorisations sur ces fichiers et dossiers une fois qu'ils ont été copiés :
```
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
```
Les autorisations obtenues sont les suivantes :
```
-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
```
L'exemple suivant montre comment spécifier la section `'permissions'` avec l'ajout des instructions `acls` et `context`. Cet exemple s'applique uniquement aux instances Amazon Linux, Ubuntu Server et RHEL.
```
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 section « crochets »
Le contenu de la `'hooks'` section du AppSpec fichier varie en fonction de la plate-forme de calcul utilisée pour votre déploiement. La `'hooks'` section relative à un déploiement EC2/sur site contient des mappages qui relient les hooks d'événements du cycle de vie du déploiement à un ou plusieurs scripts. La `'hooks'` section relative à un déploiement Lambda ou Amazon ECS indique les fonctions de validation Lambda à exécuter lors d'un événement du cycle de vie du déploiement. Si aucun hook d'événement n'est présent, aucune opération n'est exécutée pour cet événement. Cette section est obligatoire uniquement si vous exécutez des scripts ou des fonctions de validation Lambda dans le cadre du déploiement.
**Topics**
+ [
## AppSpec section « hooks » pour un déploiement Amazon ECS
](#appspec-hooks-ecs)
+ [
## AppSpec section « hooks » pour un déploiement AWS Lambda
](#appspec-hooks-lambda)
+ [
## AppSpec section « hooks » pour un déploiement EC2/sur site
](#appspec-hooks-server)
## AppSpec section « hooks » pour un déploiement Amazon ECS
**Topics**
+ [
### Liste des hooks d'événements liés au cycle de vie pour un déploiement d'Amazon ECS
](#reference-appspec-file-structure-hooks-list-ecs)
+ [
### Exécutez l'ordre des hooks dans un déploiement Amazon ECS.
](#reference-appspec-file-structure-hooks-run-order-ecs)
+ [
### Structure de la section « crochets »
](#reference-appspec-file-structure-hooks-section-structure-ecs)
+ [
### Exemple de fonction « hooks » Lambda
](#reference-appspec-file-structure-hooks-section-structure-ecs-sample-function)
### Liste des hooks d'événements liés au cycle de vie pour un déploiement d'Amazon ECS
Un hook AWS Lambda est une fonction Lambda spécifiée par une chaîne sur une nouvelle ligne après le nom de l'événement du cycle de vie. Chaque hook est exécuté une fois par déploiement. Vous trouverez ci-dessous les descriptions des événements du cycle de vie au cours desquels vous pouvez exécuter un hook lors d'un déploiement d'Amazon ECS.
+ `BeforeInstall`— À utiliser pour exécuter des tâches avant la création de l'ensemble de tâches de remplacement. Un groupe cible est associé à l'ensemble de tâches d'origine. Si un écouteur de test facultatif est spécifié, il est associé à l'ensemble de tâches d'origine. Aucune restauration n'est possible à ce stade.
+ `AfterInstall`— À utiliser pour exécuter des tâches une fois que l'ensemble de tâches de remplacement a été créé et que l'un des groupes cibles y est associé. Si un écouteur de test facultatif est spécifié, il est associé à l'ensemble de tâches d'origine. Les résultats de la fonction hook de cet événement du cycle de vie peuvent entraîner une restauration.
+ `AfterAllowTestTraffic`— À utiliser pour exécuter des tâches une fois que le récepteur de test a acheminé le trafic vers l'ensemble de tâches de remplacement. À ce stade, les résultats de la fonction hook peuvent entraîner une restauration.
+ `BeforeAllowTraffic`— À utiliser pour exécuter des tâches une fois que le deuxième groupe cible est associé à l'ensemble de tâches de remplacement, mais avant que le trafic ne soit transféré vers l'ensemble de tâches de remplacement. Les résultats de la fonction hook de cet événement du cycle de vie peuvent entraîner une restauration.
+ `AfterAllowTraffic`— À utiliser pour exécuter des tâches une fois que le deuxième groupe cible a acheminé le trafic vers l'ensemble de tâches de remplacement. Les résultats de la fonction hook de cet événement du cycle de vie peuvent entraîner une restauration.
Pour plus d’informations, consultez [Que se passe-t-il lors d'un déploiement d'Amazon ECS](deployment-steps-ecs.md#deployment-steps-what-happens) et [Tutoriel : Déployer un service Amazon ECS avec un test de validation](tutorial-ecs-deployment-with-hooks.md).
### Exécutez l'ordre des hooks dans un déploiement Amazon ECS.
Dans un déploiement Amazon ECS, les hooks d'événements s'exécutent dans l'ordre suivant :
![\[Ordre des accrochages d'événements dans un déploiement Amazon ECS.\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/images/lifecycle-event-order-ecs.png)
**Note**
Les événements de **début **TestTraffic**AllowTraffic******, d'**installation** et de **fin** du déploiement ne peuvent pas être scriptés, c'est pourquoi ils apparaissent en gris dans ce diagramme.
### Structure de la section « crochets »
Voici des exemples de structure de la section `'hooks'`.
En utilisant YAML :
```
Hooks:
- BeforeInstall: "BeforeInstallHookFunctionName"
- AfterInstall: "AfterInstallHookFunctionName"
- AfterAllowTestTraffic: "AfterAllowTestTrafficHookFunctionName"
- BeforeAllowTraffic: "BeforeAllowTrafficHookFunctionName"
- AfterAllowTraffic: "AfterAllowTrafficHookFunctionName"
```
En utilisant JSON :
```
"Hooks": [
{
"BeforeInstall": "BeforeInstallHookFunctionName"
},
{
"AfterInstall": "AfterInstallHookFunctionName"
},
{
"AfterAllowTestTraffic": "AfterAllowTestTrafficHookFunctionName"
},
{
"BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName"
},
{
"AfterAllowTraffic": "AfterAllowTrafficHookFunctionName"
}
]
}
```
### Exemple de fonction « hooks » Lambda
Utilisez `'hooks'` cette section pour spécifier une fonction Lambda qui CodeDeploy peut être appelée pour valider un déploiement Amazon ECS. Vous pouvez utiliser la même fonction ou une autre pour les événements du cycle de vie du `AfterAllowTraffic` déploiement `BeforeInstall` `AfterInstall` `AfterAllowTestTraffic``BeforeAllowTraffic`,,,. Une fois les tests de validation terminés, la `AfterAllowTraffic` fonction Lambda rappelle CodeDeploy et fournit un résultat de `Succeeded` ou. `Failed`
**Important**
Le déploiement est considéré comme ayant échoué s'il n' CodeDeploy est pas notifié par la fonction de validation Lambda dans un délai d'une heure.
Avant d'appeler une fonction de hook Lambda, le serveur doit être informé de l'ID de déploiement et de l'ID d'exécution du hook d'événement du cycle de vie à l'aide `putLifecycleEventHookExecutionStatus` de la commande.
Voici un exemple de fonction de crochet Lambda écrite dans le fichier Node.js.
```
'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 section « hooks » pour un déploiement AWS Lambda
**Topics**
+ [
### Liste des hooks d'événements du cycle de vie pour un déploiement AWS Lambda
](#reference-appspec-file-structure-hooks-list-lambda)
+ [
### Ordre d'exécution des hooks dans le déploiement d'une version de fonction Lambda
](#reference-appspec-file-structure-hooks-run-order-lambda)
+ [
### Structure de la section « crochets »
](#reference-appspec-file-structure-hooks-section-structure-lambda)
+ [
### Exemple de fonction « hooks » Lambda
](#reference-appspec-file-structure-hooks-section-structure-lambda-sample-function)
### Liste des hooks d'événements du cycle de vie pour un déploiement AWS Lambda
Un hook AWS Lambda est une fonction Lambda spécifiée par une chaîne sur une nouvelle ligne après le nom de l'événement du cycle de vie. Chaque hook est exécuté une fois par déploiement. Voici les descriptions des crochets pouvant être utilisés dans votre AppSpec fichier.
+ **BeforeAllowTraffic**— À utiliser pour exécuter des tâches avant que le trafic ne soit transféré vers la version de la fonction Lambda déployée.
+ **AfterAllowTraffic**— À utiliser pour exécuter des tâches une fois que tout le trafic est transféré vers la version de la fonction Lambda déployée.
### Ordre d'exécution des hooks dans le déploiement d'une version de fonction Lambda
Dans le cadre d'un déploiement de la version d'une fonction Lambda sans serveur, les hooks d'événements s'exécutent dans l'ordre suivant :
![\[Ordre des hooks d'événements dans un déploiement Lambda.\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/images/lifecycle-event-order-lambda.png)
**Note**
Les événements de **début** et de **fin** du déploiement ne peuvent pas être scriptés, c'est pourquoi ils apparaissent en gris dans ce diagramme. **AllowTraffic**
### Structure de la section « crochets »
Voici des exemples de structure de la section « hooks ».
En utilisant YAML :
```
hooks:
- BeforeAllowTraffic: BeforeAllowTrafficHookFunctionName
- AfterAllowTraffic: AfterAllowTrafficHookFunctionName
```
En utilisant JSON :
```
"hooks": [{
"BeforeAllowTraffic": "BeforeAllowTrafficHookFunctionName"
},
{
"AfterAllowTraffic": "AfterAllowTrafficHookFunctionName"
}]
```
### Exemple de fonction « hooks » Lambda
Utilisez la section « hooks » pour spécifier une fonction Lambda qui CodeDeploy peut être appelée pour valider un déploiement Lambda. Vous pouvez utiliser la même fonction ou une fonction différente pour les événements du cycle de vie `BeforeAllowTraffic` et de `AfterAllowTraffic` déploiement. Une fois les tests de validation terminés, la fonction de validation Lambda rappelle CodeDeploy et fournit un résultat de `Succeeded` ou. `Failed`
**Important**
Le déploiement est considéré comme ayant échoué s'il n' CodeDeploy est pas notifié par la fonction de validation Lambda dans un délai d'une heure.
Avant d'appeler une fonction de hook Lambda, le serveur doit être informé de l'ID de déploiement et de l'ID d'exécution du hook d'événement du cycle de vie à l'aide `putLifecycleEventHookExecutionStatus` de la commande.
Voici un exemple de fonction de crochet Lambda écrite dans le fichier Node.js.
```
'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 section « hooks » pour un déploiement EC2/sur site
**Topics**
+ [
### Liste des hooks d'événements liés au cycle de vie
](#reference-appspec-file-structure-hooks-list)
+ [
### Disponibilité du carnet d'événements du cycle de vie
](#reference-appspec-file-structure-hooks-availability)
+ [
### Exécuter l'ordre des hooks dans un déploiement
](#reference-appspec-file-structure-hooks-run-order)
+ [
### Structure de la section « crochets »
](#reference-appspec-file-structure-hooks-section-structure)
+ [
### Référencement de fichiers dans vos scripts hook
](#codedeploy-agent-working-directory)
+ [
### Disponibilité des variables d'environnement pour les hooks
](#reference-appspec-file-structure-environment-variable-availability)
+ [
### Exemple de crochets
](#reference-appspec-file-structure-hooks-example)
### Liste des hooks d'événements liés au cycle de vie
Un hook de déploiement EC2/sur site est exécuté une fois par déploiement sur une instance. Vous pouvez spécifier un ou plusieurs scripts dans un hook. Chaque hook pour un événement de cycle de vie est spécifié avec une chaîne sur une ligne distincte. Voici les descriptions des crochets pouvant être utilisés dans votre AppSpec fichier.
Pour plus d'informations sur les hooks d'événement de cycle de vie qui sont valides pour des types de déploiement et de restauration spécifiques, consultez [Disponibilité du carnet d'événements du cycle de vie](#reference-appspec-file-structure-hooks-availability).
+ `ApplicationStop`— Cet événement du cycle de vie du déploiement se produit avant même le téléchargement de la révision de l'application. Vous pouvez spécifier des scripts pour que cet événement arrête l'application sans heurt ou supprime les packages actuellement installés en vue d'un déploiement. Le AppSpec fichier et les scripts utilisés pour cet événement du cycle de vie du déploiement proviennent de la version précédente de l'application déployée avec succès.
**Note**
Aucun AppSpec fichier n'existe sur une instance avant que vous ne le déployiez. Pour cette raison, le hook `ApplicationStop` ne s'exécute pas la première fois que vous effectuez un déploiement sur cette instance. Vous pouvez utiliser le hook `ApplicationStop` la deuxième fois que vous effectuez un déploiement sur une instance.
Pour déterminer l'emplacement de la dernière révision d'application déployée avec succès, l' CodeDeploy agent recherche l'emplacement indiqué dans le `deployment-group-id_last_successful_install` fichier. Ce fichier se trouve dans :
`/opt/codedeploy-agent/deployment-root/deployment-instructions`dossier sur les instances Amazon Linux, Ubuntu Server et RHEL Amazon EC2.
`C:\ProgramData\Amazon\CodeDeploy\deployment-instructions`dossier sur les instances Amazon EC2 de Windows Server.
Pour dépanner un déploiement qui échoue au cours de l'événement de cycle de vie de déploiement `ApplicationStop`, consultez [Résolution des problèmes liés à un échec ApplicationStop ou à un événement lié AfterBlockTraffic au cycle de vie du déploiement BeforeBlockTraffic](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures).
+ `DownloadBundle`— Au cours de cet événement du cycle de vie du déploiement, l' CodeDeploy agent copie les fichiers de révision de l'application dans un emplacement temporaire :
`/opt/codedeploy-agent/deployment-root/deployment-group-id/deployment-id/deployment-archive`dossier sur les instances Amazon Linux, Ubuntu Server et RHEL Amazon EC2.
`C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archive`dossier sur les instances Amazon EC2 de Windows Server.
Cet événement est réservé à l' CodeDeploy agent et ne peut pas être utilisé pour exécuter des scripts.
Pour dépanner un déploiement qui échoue au cours de l'événement de cycle de vie de déploiement `DownloadBundle`, consultez [Résolution des problèmes liés à un échec du cycle de vie d'un DownloadBundle déploiement avec UnknownError : non ouvert pour lecture](troubleshooting-deployments.md#troubleshooting-deployments-downloadbundle).
+ `BeforeInstall`— Vous pouvez utiliser cet événement du cycle de vie du déploiement pour les tâches de préinstallation, telles que le déchiffrement de fichiers et la création d'une sauvegarde de la version actuelle.
+ `Install`— Au cours de cet événement du cycle de vie du déploiement, l' CodeDeployagent copie les fichiers de révision de l'emplacement temporaire vers le dossier de destination final. Cet événement est réservé à l' CodeDeploy agent et ne peut pas être utilisé pour exécuter des scripts.
+ `AfterInstall`— Vous pouvez utiliser cet événement du cycle de vie du déploiement pour des tâches telles que la configuration de votre application ou la modification des autorisations des fichiers.
+ `ApplicationStart`— Vous utilisez généralement cet événement du cycle de vie du déploiement pour redémarrer les services qui ont été interrompus pendant le déploiement`ApplicationStop`.
+ `ValidateService`— Il s'agit du dernier événement du cycle de vie du déploiement. Il permet de vérifier que le déploiement a réussi.
+ `BeforeBlockTraffic`— Vous pouvez utiliser cet événement du cycle de vie du déploiement pour exécuter des tâches sur des instances avant qu'elles ne soient désenregistrées d'un équilibreur de charge.
Pour dépanner un déploiement qui échoue au cours de l'événement de cycle de vie de déploiement `BeforeBlockTraffic`, consultez [Résolution des problèmes liés à un échec ApplicationStop ou à un événement lié AfterBlockTraffic au cycle de vie du déploiement BeforeBlockTraffic](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures).
+ `BlockTraffic`— Au cours de cet événement du cycle de vie du déploiement, le trafic Internet est empêché d'accéder aux instances qui servent actuellement du trafic. Cet événement est réservé à l' CodeDeploy agent et ne peut pas être utilisé pour exécuter des scripts.
+ `AfterBlockTraffic`— Vous pouvez utiliser cet événement du cycle de vie du déploiement pour exécuter des tâches sur des instances après leur désenregistrement de leur équilibreur de charge respectif.
Pour dépanner un déploiement qui échoue au cours de l'événement de cycle de vie de déploiement `AfterBlockTraffic`, consultez [Résolution des problèmes liés à un échec ApplicationStop ou à un événement lié AfterBlockTraffic au cycle de vie du déploiement BeforeBlockTraffic](troubleshooting-deployments.md#troubleshooting-deployments-lifecycle-event-failures).
+ `BeforeAllowTraffic`— Vous pouvez utiliser cet événement du cycle de vie du déploiement pour exécuter des tâches sur des instances avant qu'elles ne soient enregistrées auprès d'un équilibreur de charge.
+ `AllowTraffic`— Au cours de cet événement du cycle de vie du déploiement, le trafic Internet est autorisé à accéder aux instances après un déploiement. Cet événement est réservé à l' CodeDeploy agent et ne peut pas être utilisé pour exécuter des scripts.
+ `AfterAllowTraffic`— Vous pouvez utiliser cet événement du cycle de vie du déploiement pour exécuter des tâches sur des instances après leur enregistrement auprès d'un équilibreur de charge.
### Disponibilité du carnet d'événements du cycle de vie
Le tableau suivant répertorie les hooks d'événement de cycle de vie disponibles pour chaque scénario de déploiement et de restauration.
| Nom de l'événement de cycle de vie | Déploiement de lancement d'Auto Scaling¹ | Arrêt du déploiement d'Auto Scaling¹ | Déploiement sur place² | Déploiement bleu/vert : Instances d'origine | Déploiement bleu/vert : Instances de remplacement | Restauration de déploiement bleu/vert : Instances d'origine | Restauration de déploiement bleu/vert : Instances de remplacement |
| --- | --- | --- | --- | --- | --- | --- | --- |
| ApplicationStop | ✓ | ✓ | ✓ | | ✓ | | |
| DownloadBundle³ | ✓ | | ✓ | | ✓ | | |
| BeforeInstall | ✓ | | ✓ | | ✓ | | |
| Installez ³ | ✓ | | ✓ | | ✓ | | |
| AfterInstall | ✓ | | ✓ | | ✓ | | |
| ApplicationStart | ✓ | | ✓ | | ✓ | | |
| ValidateService | ✓ | | ✓ | | ✓ | | |
| BeforeBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ |
| BlockTraffic³ | | ✓ | ✓ | ✓ | | | ✓ |
| AfterBlockTraffic | | ✓ | ✓ | ✓ | | | ✓ |
| BeforeAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | |
| AllowTraffic³ | ✓ | | ✓ | | ✓ | ✓ | |
| AfterAllowTraffic | ✓ | | ✓ | | ✓ | ✓ | |
| ¹ Pour plus d'informations sur les déploiements d'Amazon EC2 Auto Scaling, consultez. [Comment fonctionne Amazon EC2 Auto Scaling avec CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors) ² S'applique également à l'annulation d'un déploiement sur place. ³ Réservé aux CodeDeploy opérations. Ne peut pas être utilisé pour exécuter des scripts. |
### Exécuter l'ordre des hooks dans un déploiement
**Déploiements de lancement d'Auto Scaling**
Lors d'un déploiement de lancement d'Auto Scaling, CodeDeploy exécute les hooks d'événements dans l'ordre suivant.
Pour plus d'informations sur les déploiements de lancement d'Auto Scaling, consultez[Comment fonctionne Amazon EC2 Auto Scaling avec CodeDeploy](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors).
![\[Ordre des accrochages d'événements lors d'un déploiement de lancement d'Auto Scaling.\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/images/lifecycle-event-order-scale-out.png)
**Note**
Les événements de **début **DownloadBundle****, d'**installation** et de **fin** du déploiement ne peuvent pas être scriptés, c'est pourquoi ils apparaissent en gris dans ce diagramme. **AllowTraffic** Vous pouvez toutefois modifier la `'files'` section du AppSpec fichier pour spécifier ce qui est installé lors de l'événement d'**installation**.
**Déploiements de terminaison Auto Scaling**
Lors d'un déploiement de terminaison d'Auto Scaling, CodeDeploy exécute les hooks d'événements dans l'ordre suivant.
Pour plus d'informations sur les déploiements de terminaison Auto Scaling, consultez[Permettre les déploiements de terminaison lors d'événements de scale-in d'Auto Scaling](integrations-aws-auto-scaling.md#integrations-aws-auto-scaling-behaviors-hook-enable).
![\[Ordre des accrochages d'événements lors d'un déploiement final d'Auto Scaling.\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/images/lifecycle-event-order-scale-in.png)
**Note**
Les événements de **début** et de **fin** du déploiement ne peuvent pas être scriptés, c'est pourquoi ils apparaissent en gris dans ce diagramme. **BlockTraffic**
**Déploiements sur place**
Dans un déploiement sur place, y compris la restauration d'un déploiement sur place, les hooks d'événement sont exécutés dans l'ordre suivant :
**Note**
Pour les déploiements sur place, les six hooks liés au blocage et à l'autorisation du trafic s'appliquent uniquement si vous spécifiez un Classic Load Balancer, un Application Load Balancer ou un Network Load Balancer d'Elastic Load Balancing dans le groupe de déploiement.
![\[L'ordre des événements s'accroche lors de l'annulation d'un déploiement sur place.\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/images/lifecycle-event-order-in-place.png)
**Note**
Les événements de **début **DownloadBundle****, d'**installation** et de **fin** du déploiement ne peuvent pas être scriptés, c'est pourquoi ils apparaissent en gris dans ce diagramme. Vous pouvez toutefois modifier la `'files'` section du AppSpec fichier pour spécifier ce qui est installé lors de l'événement d'**installation**.
**Déploiements bleu/vert**
Lors d'un blue/green déploiement, les hooks d'événements sont exécutés dans l'ordre suivant :
![\[L'ordre des accrochages d'événements dans un blue/green déploiement.\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/images/lifecycle-event-order-blue-green.png)
**Note**
Les événements de **début **DownloadBundle****, d'**installation** et de **fin** du déploiement ne peuvent pas être scriptés, c'est pourquoi ils apparaissent en gris dans ce diagramme. **BlockTraffic**AllowTraffic**** Cependant, vous pouvez modifier la section « fichiers » du AppSpec fichier pour spécifier ce qui est installé lors de l'événement d'**installation**.
### Structure de la section « crochets »
La section `'hooks'` a la structure suivante :
```
hooks:
deployment-lifecycle-event-name:
- location: script-location
timeout: timeout-in-seconds
runas: user-name
```
Vous pouvez inclure les éléments suivants dans une entrée **hook** après le nom de l'événement de cycle de vie de déploiement :
** location **
Obligatoire. Emplacement dans le groupe du fichier de script pour la révision. L'emplacement des scripts que vous spécifiez dans `hooks` cette section est relatif à la racine du bundle de révision de l'application. Pour de plus amples informations, veuillez consulter [Planifier une révision pour CodeDeploy](application-revisions-plan.md).
** timeout **
Facultatif. Nombre de secondes permettant au script de s'exécuter avant qu'il soit considéré comme ayant échoué. La valeur par défaut est de 3600 secondes (1 heure).
La durée de 3600 secondes (1 heure) représente le laps de temps maximal autorisé pour l'exécution du script pour chaque événement du cycle de vie de déploiement. Si des scripts dépassent cette limite, le déploiement s'arrête et le déploiement vers l'instance échoue. Veillez à ce que le nombre total de secondes spécifié dans **timeout** pour tous les scripts de chaque événement du cycle de vie de déploiement ne dépasse pas cette limite.
** runas **
Facultatif. Utilisateur dont vous empruntez l'identité lorsque vous exécutez le script. Par défaut, il s'agit de l' CodeDeploy agent exécuté sur l'instance. CodeDeploy ne stocke pas les mots de passe, de sorte que l'utilisateur ne peut pas être usurpé si l'utilisateur **runas** a besoin d'un mot de passe. Cet élément s'applique uniquement aux instances Amazon Linux et Ubuntu Server.
### Référencement de fichiers dans vos scripts hook
Si vous associez un script à un événement CodeDeploy du cycle de vie comme décrit dans[AppSpec section « crochets »](#reference-appspec-file-structure-hooks), et que vous souhaitez référencer un fichier (par exemple,`helper.sh`) dans votre script, vous devez spécifier `helper.sh` en utilisant :
+ (Recommandé) Un chemin absolu. Consultez [Utilisation de chemins absolus](#codedeploy-agent-working-dir-absolute).
+ Un chemin relatif. Consultez [Utilisation de chemins relatifs](#codedeploy-agent-working-dir-relative).
#### Utilisation de chemins absolus
Pour référencer un fichier à l'aide de son chemin *absolu*, vous pouvez soit :
+ Spécifiez le chemin absolu dans la `files` section du AppSpec fichier, dans la `destination` propriété. Spécifiez ensuite le même chemin absolu dans votre script hook. Pour de plus amples informations, veuillez consulter [AppSpec section « fichiers » (déploiements EC2/sur site uniquement)](reference-appspec-file-structure-files.md).
+ Spécifiez un chemin absolu dynamique dans votre script hook. Pour plus d'informations, consultez la section [Emplacement de l'archive de déploiement](#codedeploy-agent-working-dir-archive).
**Emplacement de l'archive de déploiement**
Au cours de l'événement du [DownloadBundle](#reference-appspec-file-structure-hooks-list)cycle de vie, l' CodeDeploy agent extrait la [révision](application-revisions.md) pour le déploiement dans un répertoire au format suivant :
`root-directory/deployment-group-id/deployment-id/deployment-archive`
La *root-directory* partie du chemin est toujours définie sur la valeur par défaut indiquée dans le tableau suivant ou est contrôlée par le paramètre `:root_dir` de configuration. Pour plus d'informations sur les paramètres de configuration, consultez[CodeDeploy référence de configuration de l'agent](reference-agent-configuration.md).
| Plateforme d'agents | Répertoire racine par défaut |
| --- | --- |
| Linux : toutes les distributions rpm | /opt/codedeploy-agent/deployment-root |
| Ubuntu Server — toutes les distributions deb | /opt/codedeploy-agent/deployment-root |
| Windows Server | %ProgramData%\$1Amazon\$1CodeDeploy |
À partir de vos scripts hook, vous pouvez accéder à l'archive de déploiement actuelle en utilisant le chemin du répertoire racine `DEPLOYMENT_ID` et les variables d'`DEPLOYMENT_GROUP_ID`environnement. Pour plus d'informations sur les variables que vous pouvez utiliser, consultez[Disponibilité des variables d'environnement pour les hooks](#reference-appspec-file-structure-environment-variable-availability).
Par exemple, voici comment accéder à un `data.json` fichier qui se trouve à la racine de votre révision sous Linux :
```
#!/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)
```
Autre exemple, voici comment accéder à un `data.json` fichier qui se trouve à la racine de votre révision à l'aide de Powershell sous Windows :
```
$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)
```
#### Utilisation de chemins relatifs
Pour référencer un fichier à l'aide de son chemin *relatif*, vous devez connaître le répertoire de travail de l' CodeDeploy agent. Les chemins de fichiers sont relatifs à ce répertoire.
Le tableau suivant indique le répertoire de travail pour chaque plate-forme prise en charge par l' CodeDeploy agent.
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/fr_fr/codedeploy/latest/userguide/reference-appspec-file-structure-hooks.html)
### Disponibilité des variables d'environnement pour les hooks
Au cours de chaque événement du cycle de vie de déploiement, les scripts de hook peuvent accéder aux variables d'environnement suivantes :
** APPLICATION\$1NAME **
Le nom de l'application CodeDeploy qui y figure fait partie du déploiement en cours (par exemple,`WordPress_App`).
** DEPLOYMENT\$1ID **
L'ID CodeDeploy a été attribué au déploiement en cours (par exemple,`d-AB1CDEF23`).
** DEPLOYMENT\$1GROUP\$1NAME **
Le nom du groupe de déploiement CodeDeploy qui fait partie du déploiement en cours (par exemple,`WordPress_DepGroup`).
** DEPLOYMENT\$1GROUP\$1ID **
L'ID du groupe de déploiement CodeDeploy qui fait partie du déploiement en cours (par exemple,`b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE`).
** LIFECYCLE\$1EVENT **
Nom de l'événement de cycle de vie de déploiement actuel (par exemple, `AfterInstall`).
Ces variables d'environnement sont locales à chaque événement de cycle de vie de déploiement.
Des variables d'environnement supplémentaires sont disponibles pour connecter les scripts en fonction de la source du bundle de déploiement :
**Bundle d'Amazon S3**
+ **BUNDLE\$1BUCKET**
Le nom du compartiment Amazon S3 à partir duquel le bundle de déploiement a été téléchargé (par exemple,`my-s3-bucket`).
+ **BUNDLE\$1KEY**
La clé d'objet du bundle téléchargé dans le compartiment Amazon S3 (par exemple,`WordPress_App.zip`).
+ **VERSION DU BUNDLE**
Version de l'objet pour le bundle (par exemple,`3sL4kqtJlcpXroDTDmJ+rmSpXd3dIbrHY+MTRCxf3vjVBH40Nr8X8gdRQBpUMLUo`). Cette variable n'est définie que si le contrôle de [version des objets](https://docs.aws.amazon.com/AmazonS3/latest/userguide/Versioning.html) est activé dans le compartiment Amazon S3.
+ **BUNDLE\$1ETAG**
L'étiquette d'objet du bundle (par exemple,`b10a8db164e0754105b7a99be72e3fe5-4`).
**Offre groupée provenant de GitHub**
+ **BUNDLE\$1COMMIT**
Le hachage de SHA256 validation du bundle généré par Git (par exemple,`d2a84f4b8b650937ec8f73cd8be2c74add5a911ba64df27458ed8229da804a26`).
Le script suivant modifie le port d'écoute sur un serveur Apache HTTP en spécifiant 9090 à la place de 80 si la valeur de **DEPLOYMENT\$1GROUP\$1NAME** est égale à `Staging`. Ce script doit être appelé au cours de l'événement de cycle de vie de déploiement `BeforeInstall` :
```
if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
sed -i -e 's/Listen 80/Listen 9090/g' /etc/httpd/conf/httpd.conf
fi
```
L'exemple de script suivant modifie le niveau de détail des messages enregistrés dans son journal des erreurs et le fait passer d'avertissement à débogage si la valeur de la variable d'environnement **DEPLOYMENT\$1GROUP\$1NAME** est égale à `Staging`. Ce script doit être appelé au cours de l'événement de cycle de vie de déploiement `BeforeInstall` :
```
if [ "$DEPLOYMENT_GROUP_NAME" == "Staging" ]
then
sed -i -e 's/LogLevel warn/LogLevel debug/g' /etc/httpd/conf/httpd.conf
fi
```
L'exemple de script suivant remplace le texte de la page Web spécifiée par un texte qui affiche la valeur de ces variables d'environnement. Ce script doit être appelé au cours de l'événement de cycle de vie de déploiement `AfterInstall` :
```
#!/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()
```
### Exemple de crochets
Voici un exemple d'entrée **hooks** qui spécifie deux hooks pour l'événement de cycle de vie `AfterInstall` :
```
hooks:
AfterInstall:
- location: Scripts/RunResourceTests.sh
timeout: 180
- location: Scripts/PostDeploy.sh
timeout: 180
```
Le script `Scripts/RunResourceTests.sh` s'exécute au cours de la phase `AfterInstall` du processus de déploiement. Le déploiement échoue si l'exécution du script dure plus de 180 secondes (3 minutes).
L'emplacement des scripts que vous spécifiez dans la section « hooks » est relatif à la racine du groupe de révision d'application. Dans l'exemple précédent, un fichier nommé `RunResourceTests.sh` se trouve dans un répertoire nommé `Scripts`. Le répertoire `Scripts` est à la racine du groupe. Pour de plus amples informations, veuillez consulter [Planifier une révision pour CodeDeploy](application-revisions-plan.md).
# AppSpec Exemple de fichier
Cette rubrique fournit des AppSpec fichiers d'exemple pour un déploiement AWS Lambda et EC2/on-premises.
**Topics**
+ [
## AppSpec Exemple de fichier pour un déploiement Amazon ECS
](#appspec-file-example-ecs)
+ [
## AppSpec Exemple de fichier pour un déploiement AWS Lambda
](#appspec-file-example-lambda)
+ [
## AppSpec Exemple de fichier pour un déploiement EC2/sur site
](#appspec-file-example-server)
## 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'`LambdaFunctionToValidateBeforeInstall`exécute.
1. 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'`LambdaFunctionToValidateAfterInstall`exécute.
1. 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é.
1. 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'`LambdaFunctionToValidateBeforeAllowingProductionTraffic`exécute.
1. 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'`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 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.
1. 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é.
1. 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`.
1. Si le script précédent a retourné un code de sortie 0 (réussite), exécutez le script situé dans `Scripts/UnzipDataBundle.sh`.
1. Copiez le fichier du chemin d'accès `Config/config.txt` vers le chemin d'accès `/webapps/Config/config.txt`.
1. Copiez de façon récursive tous les fichiers du répertoire `source` dans le répertoire `/webapps/myApp`.
1. Exécutez le script situé dans `Scripts/RunResourceTests.sh` avec un délai de 180 secondes (3 minutes).
1. Exécutez le script situé dans `Scripts/RunFunctionalTests.sh` avec un délai de 3600 secondes (1 heure).
1. Exécutez le script situé dans `Scripts/MonitorService.sh` en tant qu'utilisateur `codedeploy` avec un délai de 3600 secondes (1 heure).
## AppSpec Espacement des fichiers
Voici le format correct pour l'espacement des AppSpec fichiers. Les chiffres entre crochets indiquent le nombre d'espaces qui doivent figurer entre les éléments. Par exemple, `[4]` cela signifie insérer quatre espaces entre les éléments. CodeDeploy génère une erreur qui peut être difficile à déboguer si les emplacements et le nombre d'espaces dans un AppSpec fichier ne sont pas corrects.
```
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
```
Voici un exemple de AppSpec fichier correctement espacé :
```
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
```
Pour plus d'informations sur l'espacement, consultez la spécification [YAML](http://www.yaml.org).
# Validez votre AppSpec fichier et son emplacement
**Syntaxe du fichier**
Vous pouvez utiliser le script AppSpec Assistant AWS fourni pour valider le contenu d'un AppSpec fichier. Vous pouvez trouver le script ainsi que les modèles de AppSpec fichiers sur [GitHub](https://github.com/aws-samples/aws-codedeploy-appspec-assistant).
Vous pouvez également utiliser un outil basé sur un navigateur tel que [YAML lint](http://www.yamllint.com/) ou [Online YAML parser](http://yaml-online-parser.appspot.com/) pour vérifier votre syntaxe YAML.
**Emplacement du fichier**
Pour vérifier que vous avez placé votre AppSpec fichier dans le répertoire racine de la structure de répertoires du contenu source de l'application, exécutez l'une des commandes suivantes :
Sur les instances Linux, macOS ou Unix locales :
```
ls path/to/root/directory/appspec.yml
```
Si le AppSpec fichier ne s'y trouve pas, le message d'erreur « Aucun fichier ou répertoire de ce type » s'affiche.
Sur les instances Windows locales :
```
dir path\to\root\directory\appspec.yml
```
Si le AppSpec fichier ne s'y trouve pas, le message d'erreur « Fichier introuvable » s'affiche.