Questions fréquentes (FAQ) sur AWS CodeDeploy

Une application est un ensemble de logiciels et de configurations à déployer sur un groupe d'instances. En règle générale, les instances du groupe exécutent les mêmes logiciels. Par exemple, si vous disposez d'un important système distribué, le niveau Web constituera vraisemblablement une application et le niveau Données une autre application.

Une révision est la version spécifique d'un contenu déployable, tel qu'un code source, des artefacts post-développement, des pages Web, des fichiers exécutables, des scripts de déploiement ou encore un fichier AppSpec. L'agent AWS CodeDeploy peut accéder à une révision à partir de GitHub sur un compartiment Amazon S3.

Un groupe de déploiement est une entité AWS CodeDeploy pour le groupement d’instances EC2 ou de fonction AWS Lambda dans un déploiement CodeDeploy. Pour les déploiements EC2, il s’agit d’un ensemble d'instances associé à une application que vous ciblez dans le cadre d'un déploiement. Vous pouvez ajouter des instances à un groupe de déploiement en spécifiant une balise, un nom de groupe Auto Scaling ou les deux. Dans un déploiement AWS Lambda, un groupe de déploiement définit un ensemble de configurations AWS CodeDeploy pour un déploiement Lambda futur sans serveur vers le groupe, comme des alarmes et des rollbacks.

Pour une application, vous pouvez définir plusieurs groupes de déploiement comme la simulation et la production. Pour en savoir plus sur les balises, consultez Travailler avec des balises Amazon EC2 dans la console. Pour en savoir plus sur le déploiement sur des groupes Auto Scaling, consultez Intégration d'Auto Scaling.

Une configuration de déploiement spécifie la façon dont le déploiement doit se dérouler, notamment la façon de gérer les échecs de déploiement, pour un groupe de déploiement. Vous pouvez utiliser une configuration de déploiement pour réaliser des déploiements sans temps mort sur des groupes de déploiement multi-instances. Par exemple, si votre application requiert au moins 50 % des instances dans un groupe de déploiement pour pouvoir gérer correctement le trafic, vous pouvez spécifier cela dans votre configuration de déploiement de manière à ce qu'un déploiement ne cause pas de temps mort. Si aucune configuration de déploiement n'est associée au déploiement ou au groupe de déploiement, AWS CodeDeploy se déploiera sur une instance à la fois par défaut.  Pour en savoir plus sur la configuration de déploiement, consultez État de santé des instances.

Vous devez spécifier trois paramètres dans le cadre d'un déploiement :

1. La révision pour spécifier les éléments à déployer.
2. Le groupe de déploiement pour spécifier l'emplacement du déploiement.
3. La configuration de déploiement, paramètre facultatif qui spécifie comment déployer.

Un fichier AppSpec est un fichier de configuration qui spécifie les fichiers à copier et les scripts à exécuter. Le fichier AppSpec est au format YAML, et vous l'incluez dans le répertoire racine de votre révision. Le fichier AppSpec est utilisé par l'agent AWS CodeDeploy et comprend deux sections. La section Fichiers spécifie les fichiers sources de votre révision à copier et le dossier de destination sur chaque instance. La section Points d'accroche spécifie l'emplacement (en tant que chemins relatifs partant de la racine de l'offre groupée de révisions) des scripts à exécuter durant chaque phase du déploiement. Chaque phase d'un déploiement se nomme Événement de cycle de vie du déploiement. Vous trouverez ci-dessous un exemple de fichier AppSpec. Pour en savoir plus sur le fichier AppSpec, y compris toutes les options qu'il est possible de spécifier, consultez Référence du fichier AppSpec.

os: linux

files: 

# You can specify one or more mappings in the files section.

  - source: /

    destination: /var/www/html/WordPress

hooks:

 # The lifecycle hooks sections allows you to specify deployment scripts.

ApplicationStop 

# Step 1: Stop Apache and MySQL if running.

    - location: helper_scripts/stop_server.sh

BeforeInstall: 

# Step 2: Install Apache and MySQL.

# You can specify one or more scripts per deployment lifecycle event.

    - location: deploy_hooks/puppet-apply-apache.sh

    - location: deploy_hooks/puppet-apply-mysql.sh 

 AfterInstall: 

# Step 3: Set permissions.

    - location: deploy_hooks /change_permissions.sh

      timeout: 30

      runas: root

# Step 4: Start the server.

    - location: helper_scripts/start_server.sh

      timeout: 30

      runas: root

Un déploiement s'articule autour de phases prédéfinies appelées événements de cycle de vie du déploiement. Un événement de cycle de vie du déploiement vous offre l'opportunité d'exécuter un code en tant que composant du déploiement. Le tableau suivant dresse la liste des différents événements de cycle de vie du déploiement actuellement pris en charge, par ordre d'exécution, et vous indique quand vous pouvez les utiliser.

Événement de cycle de vie du déploiement

• ApplicationStop

  • Il s'agit du premier événement de cycle de vie du déploiement qui se produit avant même le téléchargement de la révision. Le fichier AppSpec et les scripts utilisés lors de cet événement de cycle de vie du déploiement sont ceux de la dernière révision déployée avec succès.  

    Vous pouvez utiliser l'événement de cycle de vie du déploiement ApplicationStop si vous souhaitez arrêter l'application sans heurts ou supprimer des packages actuellement installés, en vue d'un déploiement.

• DownloadBundle

  • Durant cet événement de cycle de vie du déploiement, l'agent copie les fichiers de révision vers un emplacement temporaire sur l'instance. Cet événement de cycle de vie du déploiement est réservé à l'agent et ne peut être utilisé pour exécuter des scripts utilisateurs.

• BeforeInstall

  • Vous pouvez utiliser cet événement de cycle de vie du déploiement pour des tâches préalables à l'installation comme le déchiffrement de fichiers et la création d'une sauvegarde de la version actuelle.

• Installer

  • Durant cet événement de cycle de vie du déploiement, l'agent copie les fichiers de révision de l'emplacement temporaire vers le dossier de destination finale. Cet événement de cycle de vie du déploiement est réservé à l'agent et ne peut être utilisé pour exécuter des scripts utilisateurs.

• AfterInstall

  • Vous pouvez utiliser l'événement de cycle de vie du déploiement AfterInstall dans le cadre de tâches telles que la configuration de votre application ou la modification des autorisations d'accès aux fichiers.

• ApplicationStart

  • L'événement de cycle de vie du déploiement ApplicationStart s'utilise généralement pour redémarrer des services interrompus pendant l'événement ApplicationStop.

• ValidateService

  • ValidateService est le dernier événement de cycle de vie du déploiement et permet de vérifier que le déploiement s'est terminé avec succès.

 

 

Vous pouvez vous connecter à AWS Management Console et commencer à utiliser AWS CodeDeploy. Si vous recherchez une présentation rapide du système, consultez la Mise en route, qui vous propose un didacticiel étape par étape.

L'instance Amazon EC2 doit être associée à un profil d'instance IAM et doit exécuter un système d'exploitation pris en charge. Pour en savoir plus, consultez Utiliser une instance Amazon EC2 existante.

Le diagramme suivant montre les étapes classiques d'un déploiement. La création d'une application et d'un groupe de déploiement (consultez la section Concepts pour obtenir une explication de ces termes) est en général une tâche unique par application. Les actions récurrentes sont le téléchargement d'une révision et son déploiement. Pour obtenir des explications détaillées et des instructions étape par étape pour chacune de ces tâches, consultez Déploiements.

L'accès à AWS CodeDeploy s'effectue à l'aide d'AWS Management Console, de l'interface de ligne de commande AWS, des kits de développement logiciel AWS et des API AWS CodeDeploy.

Aucun changement n'est nécessaire. Vous ajoutez tout simplement un fichier de configuration (appelé fichier AppSpec) dans le répertoire racine de votre offre groupée de révisions, qui spécifie les fichiers à copier et les scripts à exécuter.

Si vous utilisez GitHub, vous pouvez déployer une révision au format .zip, .tar ou .tar.gz à partir de votre référentiel, directement vers des instances. Pour d'autres systèmes de contrôle de sources, vous pouvez grouper et charger la révision vers un compartiment Amazon S3 au format .zip, .rar ou .tar.gz et spécifier l'emplacement Amazon S3 en cas de déploiement. Si votre application nécessite une étape de développement, assurez-vous que le référentiel GitHub ou que le compartiment Amazon S3 contiennent les artefacts post-développement. Pour en savoir plus sur l'utilisation de GitHub avec AWS CodeDeploy, consultez la page Intégrations de produits. Pour en savoir plus sur l'utilisation d'Amazon S3 pour stocker des révisions, consultez Pousser une révision.

Vous pouvez appeler votre outil de gestion de la configuration à partir de n'importe quel point d'accroche d'un événement de cycle de vie du déploiement dans le fichier AppSpec. Par exemple, si vous souhaitez exécuter une recette Chef en tant que composant du déploiement, vous pouvez le faire en le spécifiant dans le point d'accroche adéquat de l'événement de cycle de vie du déploiement dans le fichier AppSpec. De plus, vous pouvez utiliser votre système de gestion de la configuration pour installer l'agent AWS CodeDeploy sur des instances. Pour visualiser des exemples qui illustrent l'utilisation d’AWS CodeDeploy avec des systèmes de gestion de la configuration tels que Chef, Puppet, Ansible et Saltstack, consultez notre pageIntégration de produits.

Oui. Vous pouvez intégrer AWS CodeDeploy avec vos systèmes d'intégration et de déploiement continus en appelant les API publiques à l'aide de l'interface de ligne de commande AWS ou des kits de développement logiciel AWS. Vous trouverez des intégrations prédéfinies et des exemples sur notre page Intégrations de produits.

Déployez la dernière révision sur le groupe de déploiement des instances nouvellement ajoutées pour exploiter votre application. A l'exception des instances Amazon EC2 lancées en tant que composant du groupe Auto Scaling, AWS CodeDeploy ne déploie pas automatiquement la dernière révision sur les instances nouvellement ajoutées.

Vous pouvez associer un groupe Auto Scaling à un groupe de déploiement pour vous assurer que les instances nouvellement lancées exploitent toujours la dernière version de votre application. A chaque lancement d'une nouvelle instance Amazon EC2 pour ce groupe Auto Scaling, elle sera la première à être placée en attente, et un déploiement de la dernière révision avec succès pour ce groupe de déploiement sera déclenché sur cette instance Amazon EC2. Si le déploiement s'est terminé avec succès, l'état de l'instance Amazon EC2 passe à InService. Si le déploiement échoue, l'instance Amazon EC2 est clôturée, une nouvelle instance Amazon EC2 est lancée avec le statut Pending et un déploiement est déclenché pour l'instance Amazon EC2 nouvellement lancée. Pour en savoir plus sur les événements de cycle de vie des instances d'un groupe Auto Scaling, consultez Cycle de vie d'un groupe Auto Scaling.

Vous pouvez suivre l'état d'un déploiement à l'aide de l'AWS Management Console, de l'interface de ligne de commande AWS (AWS CLI), des kits SDK AWS et des API AWS CodeDeploy. Vous pouvez consulter l'état général d'un déploiement et effectuer des recherches plus détaillées pour voir l'état de chaque instance et l'état de chaque événement du cycle de vie du déploiement pour l'instance. Vous pouvez également consulter les entrées de journal correspondant aux défaillances, pour faciliter le débogage des problèmes de déploiement sans avoir à vous connecter à l'instance.

Oui. Lorsque vous interrompez un déploiement en vol, le service AWS CodeDeploy donnera à l'agent l'instruction d'interrompre l'exécution de scripts supplémentaires sur chaque instance. Pour redonner un statut cohérent à votre application, vous pouvez soit redéployer la révision, soit déployer une autre révision.

Pour revenir à la révision antérieure d'une application, il vous suffit de déployer la révision en question. AWS CodeDeploy garde une trace des fichiers copiés lors de la révision précédente et les supprime avant de démarrer un nouveau déploiement. Il n'existe donc aucune différence entre un redéploiement et un retour en arrière. Vous devez cependant vous assurer que les révisions précédentes sont disponibles pour un retour en arrière.

Oui. Vous pouvez utiliser un compartiment Amazon S3 faisant l'objet d'un contrôle de version et spécifier l'ID de la version pour identifier la révision de manière unique.

Pour en savoir plus sur les limites du service, consultez l'article Limites. Pour augmenter vos limites de service, soumettez une demande par le biais du Centre de support AWS.

Oui. Pour obtenir un historique des appels d'API AWS CodeDeploy réalisés sur votre compte, il vous suffit d'activer AWS CloudTrail dans AWS Management Console.

Vous pouvez créer des notifications pour des événements influençant vos déploiements. Les notifications se présenteront sous la forme de notifications Amazon SNS. Chaque notification inclura un message d'état, ainsi qu'un lien vers les ressources dont l'événement a généré cette notification. Les notifications n’entraînent pas de coûts supplémentaires, mais il se peut que d’autres services AWS utilisés par les notifications, comme Amazon SNS, vous soient facturés. Pour découvrir comment démarrer avec les notifications, consultez le guide d'utilisation des notifications. De plus, les clients qui utilisent AWS Chatbot peuvent configurer des notifications à envoyer à leurs canaux Slack ou à leurs salons de discussion Amazon Chime. Pour en savoir plus, cliquez ici.

Oui, mais l'agent AWS CodeDeploy installé sur les instances Amazon EC2 doit pouvoir accéder aux points de terminaison publics AWS CodeDeploy et Amazon S3. Pour en savoir plus, consultez Points de terminaison AWS CodeDeploy et Points de terminaison Amazon S3.

Oui. AWS CodeDeploy prend en charge les autorisations au niveau des ressources. Pour chaque ressource AWS CodeDeploy, vous pouvez spécifier quel utilisateur a accès à quelle action. Par exemple, vous pouvez définir une politique IAM pour permettre à un utilisateur de déployer une application en particulier, mais seulement de référencer les révisions pour d'autres applications. Ceci vous permet d'éviter que des utilisateurs effectuent des modifications par inadvertance dans la mauvaise application. Pour en savoir plus sur l'utilisation d’IAM avec AWS CodeDeploy, consultez la Référence sur les autorisations d'accès.

Pour plus d'informations sur la disponibilité de CodeDeploy par région, reportez-vous à la section relative aux produits et services régionaux.

AWS CodeDeploy effectue des déploiements avec des ressources AWS situées dans la même région. Pour déployer une application dans plusieurs régions, définissez l'application dans vos régions cibles, copiez l'offre groupée d'applications vers un compartiment Amazon S3 pour chaque région, puis démarrez les déploiements en utilisant soit un lancement en série, soit un lancement parallèle sur les différentes régions.

Les déploiements de codes sur des instances Amazon EC2 par l'intermédiaire d'AWS CodeDeploy n'entraînent aucun coût supplémentaire. Chaque mise à jour d'instance sur site à l'aide d'AWS CodeDeploy est facturée 0,02 USD. Pour plus d'informations, consultez la page Tarification.