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. # Recettes Deploy **Important** Le AWS OpsWorks Stacks service a atteint sa fin de vie le 26 mai 2024 et a été désactivé tant pour les nouveaux clients que pour les clients existants. Nous recommandons vivement aux clients de migrer leurs charges de travail vers d'autres solutions dès que possible. Si vous avez des questions sur la migration, contactez l' AWS Support équipe sur [AWS Re:Post](https://repost.aws/) ou via le [AWS Support](https://aws.amazon.com/support) Premium. Les recettes Deploy sont attribuées à l'[événement de cycle de vie](workingcookbook-events.md) Deploy de la couche. Cela se produit généralement sur toutes les instances de la pile chaque fois que vous déployez une application, bien que vous puissiez éventuellement limiter l'événement aux instances spécifiées uniquement. OpsWorks Stacks exécute également les recettes de déploiement sur les nouvelles instances, une fois les recettes de configuration terminées. Les recettes Deploy ont pour objectif principal de déployer le code et les fichiers associés d'un référentiel sur les instances de la couche serveur de l'application. Cependant, vous exécutez souvent les recettes sur d'autres couches également. Cela permet aux instances des couches de mettre à jour leur configuration, par exemple, pour accueillir l'application nouvellement déployée. Lorsque vous implémentez une recette Deploy, gardez à l'esprit qu'un événement Deploy ne signifie pas nécessairement que les applications sont déployées sur l'instance. Il peut s'agir d'une simple notification que les applications sont déployées sur d'autres instances de la pile pour permettre à l'instance effectuer les mises à jour nécessaires. La recette doit être capable de répondre de manière appropriée, ce qui implique de ne rien faire. OpsWorks Stacks déploie automatiquement les applications des types d'applications standard sur les couches de serveur d'applications intégrées correspondantes. Pour déployer les applications sur une couche personnalisée, vous devez implémenter les recettes Deploy personnalisées qui téléchargent les fichiers de l'application depuis un référentiel sur l'emplacement approprié de l'instance. Cependant, vous pouvez souvent limiter la quantité de code que vous devez écrire à l'aide du [livre de recettes Deploy](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy) intégré pour gérer certains aspects de déploiement. Par exemple, si vous stockez vos fichiers dans l'un des référentiels pris en charge, le livre de recettes intégré peut gérer les détails du téléchargement des fichiers depuis le référentiel sur les instances de la couche. La recette `tomcat::deploy` est destinée à être assignée à l'événement de cycle de vie Deploy. ``` include_recipe 'deploy' node[:deploy].each do |application, deploy| opsworks_deploy_dir do user deploy[:user] group deploy[:group] path deploy[:deploy_to] end opsworks_deploy do deploy_data deploy app application end ... ``` La recette `tomcat::deploy` utilise le livre de recettes Deploy intégré pour les aspects du déploiement qui ne sont pas spécifiques à l'application. La recette `deploy` (qui est un raccourci de la recette `deploy::default` intégrée) est une recette intégrée qui gère les détails de la configuration des utilisateurs, groupes, etc., selon les données des attributs `deploy`. La recette utilise deux définitions Chef intégrées, `opsworks_deploy_dir` et `opworks_deploy` pour installer l'application. La définition `opsworks_deploy_dir` configure la structure du répertoire, à partir des données du déploiement JSON de l'application. Les définitions sont essentiellement un moyen pratique d'empaqueter les définitions des ressources et se trouvent dans le répertoire `definitions` d'un livre de recettes. Les recettes peuvent utiliser les définitions tout comme les ressources, mais la définition elle-même n'a pas de fournisseur associé, seules les ressources qui sont incluses dans la définition. Vous pouvez définir les variables dans la recette, qui sont transmises aux définitions de ressources sous-jacentes. La recette `tomcat::deploy` définit les variables `user`, `group` et `path` en fonction des données du déploiement JSON. Elles sont transmises à la [ressource directory](https://docs.chef.io/chef/resources.html#directory) de la définition, qui gère les répertoires. **Note** Le groupe et l'utilisateur de votre application déployée sont déterminés par les attributs `[:opsworks][:deploy_user][:user]` et `[:opsworks][:deploy_user][:group]`, qui sont définis dans le [fichier d'attributs `deploy.rb` du livre de recettes Deploy intégré](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb). La valeur par défaut de `[:opsworks][:deploy_user][:user]` est `deploy`. La valeur par défaut de `[:opsworks][:deploy_user][:group]` dépend du système d'exploitation de l'instance : Pour les instances Ubuntu, le groupe par défaut est `www-data`. Pour les instances Amazon Linux membres d'une couche Rails App Server utilisant Nginx et Unicorn, le groupe par défaut est. `nginx` Pour toutes les autres instances Amazon Linux, le groupe par défaut est `apache`. Vous pouvez changer les deux paramètres à l'aide d'un JSON personnalisé ou d'un fichier d'attributs personnalisés pour remplacer l'attribut approprié. Pour de plus amples informations, veuillez consulter [Remplacement des attributs](workingcookbook-attributes.md). L'autre définition, `opsworks_deploy`, gère les détails de la vérification du code de l'application et des fichiers associés du référentiel et de leur déploiement sur l'instance, selon les données des attributs `deploy`. Vous pouvez utiliser cette définition pour tout type d'application ; les détails du déploiement tels que les noms de répertoire sont spécifiés dans la console ou via l'API, et placés dans les attributs `deploy`. Toutefois, `opsworks_deploy` fonctionne uniquement pour les quatre [types de référentiel pris en charge](workingcookbook-installingcustom-repo.md) : Git, Subversion, S3 et HTTP. Vous devez implémenter ce code vous-même si vous souhaitez utiliser un autre type de référentiel. Vous installez les fichiers d'une application dans le répertoire Tomcat `webapps`. Une pratique classique consiste à copier les fichiers directement sur `webapps`. Cependant, le déploiement de OpsWorks Stacks est conçu pour conserver jusqu'à cinq versions d'une application sur une instance. Vous pouvez donc revenir à une version antérieure si nécessaire. OpsWorks Stacks effectue donc ce qui suit : 1. Déploie les applications sur un répertoire distinct dont le nom contient un horodatage, comme `/srv/www/my_1st_jsp/releases/20130731141527`. 1. Crée un lien symbolique nommé `current`, tel que `/srv/www/my_1st_jsp/current`, avec ce répertoire unique. 1. S'il n'existe pas déjà, crée un lien symbolique depuis le répertoire `webapps` vers le lien symbolique `current` créé à l'étape 2. Si vous devez revenir à une version antérieure, modifiez le lien symbolique `current` pour pointer sur un répertoire distinct contenant l'horodatage approprié en changeant, par exemple, la cible du lien de `/srv/www/my_1st_jsp/current`. La section centrale de `tomcat::deploy` définit le lien symbolique. ``` ... current_dir = ::File.join(deploy[:deploy_to], 'current') webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root]) # opsworks_deploy creates some stub dirs, which are not needed for typical webapps ruby_block "remove unnecessary directory entries in #{current_dir}" do block do node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry| ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true) end end end link webapp_dir do to current_dir action :create end ... ``` La recette crée d'abord deux variables, `current_dir` et `webapp_dir`, pour représenter les répertoires `current` et `webapp`, respectivement. Elle utilise ensuite une ressource `link` pour lier `webapp_dir` à `current_dir`. La `deploy::default` recette OpsWorks Stacks crée des répertoires stub qui ne sont pas obligatoires dans cet exemple, de sorte que la partie centrale de l'extrait les supprime. La partie finale de `tomcat::deploy` redémarre le service Tomcat, si nécessaire. ``` ... include_recipe 'tomcat::service' execute 'trigger tomcat service restart' do command '/bin/true' not_if { node['tomcat']['auto_deploy'].to_s == 'true' } notifies :restart, resources(:service => 'tomcat') end end include_recipe 'tomcat::context' ``` La recette exécute d'abord `tomcat::service`, afin de s'assurer que le service est défini pour cette exécution Chef. Elle utilise ensuite une [ressource execute](https://docs.chef.io/chef/resources.html#execute) pour demander au service de redémarrer, mais seulement si `['tomcat']['auto_deploy']` est défini sur `'true'`. Sinon, Tomcat écoute les modifications dans son répertoire `webapps`, ce qui rend superflu le redémarrage explicite du service Tomcat. **Note** La ressource `execute` n'exécute pas réellement quelque chose de substantiel ; `/bin/true` est un script shell factice qui retourne simplement un code de réussite. Il est utilisé ici simplement comme moyen pratique de générer une notification de redémarrage. Comme mentionné précédemment, l'utilisation des notifications garantit que les services ne soient pas trop souvent redémarrés. Enfin, `tomcat::deploy` exécute `tomcat::context`, qui met à jour le fichier de configuration du contexte de l'application web si vous avez modifié la base de données principale.