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 ou via le AWS Support Premium.

Les recettes Deploy sont attribuées à l'événement de cycle de vie 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. 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 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 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 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 plus d’informations, consultez 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 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 : 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 AWS 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. 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. La deploy::default recette AWS 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 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.