Recettes Deploy - AWS OpsWorks

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 le service a pris fin 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 le AWS Support L'équipe sur AWS Re:post ou via AWS Support premium.

Les recettes Deploy sont attribuées à l'événement de cycle de vie Deploy de la couche. Il se produit généralement sur toutes les instances de la pile chaque fois que vous déployez une application, même si vous pouvez, le cas échéant, restreindre l'événement aux seules instances spécifiées. AWS 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.

AWS 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 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 opsworks_deploy_dir définition définit la structure du répertoire, en fonction des données issues du déploiement de l'applicationJSON. 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. Les ensembles de tomcat::deploy user recettes et group les path variables basés sur les données du déploiementJSON. Elles sont transmises à la ressource 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é. 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 modifier l'un ou l'autre des paramètres en utilisant un fichier d'attributs personnalisé JSON ou un fichier d'attributs personnalisés pour remplacer l'attribut approprié. Pour de plus amples informations, veuillez consulter Remplacement des attributs.

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 n'importe quel type d'application ; les détails du déploiement, tels que les noms des répertoires, sont spécifiés dans la API console ou par le biais des deploy attributs. Cependant, il ne opsworks_deploy fonctionne que pour les quatre types de référentiels pris en charge : Git, Subversion, S3 etHTTP. 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, AWS OpsWorks Le déploiement de Stacks est conçu pour conserver jusqu'à cinq versions d'une application sur une instance, afin que vous puissiez revenir à une version antérieure si nécessaire. AWS 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.

  2. Crée un lien symbolique nommé current, tel que /srv/www/my_1st_jsp/current, avec ce répertoire unique.

  3. 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. Le AWS OpsWorks deploy::defaultLa recette Stacks crée des répertoires stub qui ne sont pas obligatoires pour 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 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.