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