AppSpec section « crochets » - AWS CodeDeploy
AppSpec section « hooks » pour un déploiement Amazon ECSAppSpec section « hooks » pour un déploiement AWS LambdaAppSpec section « hooks » pour un déploiement EC2/sur site

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

AppSpec section « hooks » pour un déploiement Amazon ECS

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 et Tutoriel : Déployer un service Amazon ECS avec un test de validation.

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

Les événements de début TestTrafficAllowTraffic, 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 AfterAllowTestTrafficBeforeAllowTraffic,,,. 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

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

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.

  • 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

    Un AppSpec fichier n'existe pas 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-instructionsdossier sur les instances Amazon Linux, Ubuntu Server et RHEL Amazon EC2.

    C:\ProgramData\Amazon\CodeDeploy\deployment-instructionsdossier 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.

  • 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-archivedossier sur les instances Amazon Linux, Ubuntu Server et RHEL Amazon EC2.

    C:\ProgramData\Amazon\CodeDeploy\deployment-group-id\deployment-id\deployment-archivedossier 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.

  • 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éploiementApplicationStop.

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

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

  • 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

² 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, consultezComment fonctionne Amazon EC2 Auto Scaling avec CodeDeploy.

Ordre des accrochages d'événements lors d'un déploiement de lancement d'Auto Scaling.
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, consultezPermettre les déploiements de terminaison lors d'événements de scale-in d'Auto Scaling.

Ordre des accrochages d'événements lors d'un déploiement final d'Auto Scaling.
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.
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

Dans un déploiement bleu/vert, les hooks d'événement sont exécutés dans l'ordre suivant :

L'ordre des événements s'accroche dans un déploiement bleu/vert.
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. BlockTrafficAllowTraffic 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 plus d’informations, consultez Planifier une révision pour CodeDeploy.

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

Note

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 dansAppSpec section « crochets », et que vous souhaitez référencer un fichier (par exemple,helper.sh) dans votre script, vous devez spécifier helper.sh en utilisant :

Utilisation de chemins absolus

Pour référencer un fichier à l'aide de son chemin absolu, vous pouvez soit :

Emplacement de l'archive de déploiement

Au cours de l'événement du DownloadBundlecycle de vie, l' CodeDeploy agent extrait la révision pour le déploiement dans un répertoire au format suivant :

root-directory/deployment-group-id/deployment-id/deployment-archive

La partie du répertoire racine 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 de :root_dir configuration. Pour plus d'informations sur les paramètres de configuration, consultezCodeDeploy référence de configuration de l'agent.

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%\Amazon\CodeDeploy

À 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_IDenvironnement. Pour plus d'informations sur les variables que vous pouvez utiliser, consultezDisponibilité des variables d'environnement pour les hooks.

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.

Plateforme d'agents Méthode de gestion des processus Répertoire de travail pour les scripts d'événements du cycle de vie
Linux : toutes les distributions rpm systemd (par défaut) /
init.d — En savoir plus /opt/codedeploy-agent
Ubuntu Server — toutes les distributions Debian Tout /opt/codedeploy-agent
Windows Server ne s'applique pas C:\Windows\System32

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_NAME

Le nom de l'application CodeDeploy qui y figure fait partie du déploiement en cours (par exemple,WordPress_App).

DEPLOYMENT_ID

L'ID CodeDeploy a été attribué au déploiement en cours (par exemple,d-AB1CDEF23).

DEPLOYMENT_GROUP_NAME

Le nom du groupe de déploiement CodeDeploy qui fait partie du déploiement en cours (par exemple,WordPress_DepGroup).

DEPLOYMENT_GROUP_ID

L'ID du groupe de déploiement CodeDeploy qui fait partie du déploiement en cours (par exemple,b1a2189b-dd90-4ef5-8f40-4c1c5EXAMPLE).

LIFECYCLE_EVENT

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_BUCKET

    Le nom du compartiment Amazon S3 à partir duquel le bundle de déploiement a été téléchargé (par exemple,my-s3-bucket).

  • BUNDLE_KEY

    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 est activé dans le compartiment Amazon S3.

  • BUNDLE_ETAG

    L'étiquette d'objet pour le bundle (par exemple,b10a8db164e0754105b7a99be72e3fe5-4).

Bundle de GitHub

  • BUNDLE_COMMIT

    Le hachage de validation SHA256 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_GROUP_NAME 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_GROUP_NAME 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="<h2>This application was deployed using CodeDeploy.</h2>"
strToReplace="<h2>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.</h2>"
 
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 plus d’informations, consultez Planifier une révision pour CodeDeploy.