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 Setup **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 Setup sont affectées à l'[événement de cycle de vie](workingcookbook-events.md) Setup de la couche et s'exécutent une fois qu'une instance a démarré. Elles exécutent des tâches telles que l'installation de packages, la création de fichiers de configuration et le démarrage de services. Une fois l'exécution des recettes d'installation terminée, OpsWorks Stacks exécute les [recettes de déploiement](create-custom-deploy.md) pour déployer toutes les applications sur la nouvelle instance. **Topics** + [tomcat::setup](#create-custom-setup-setup) + [tomcat::install](#create-custom-setup-install) + [tomcat::service](#create-custom-setup-service) + [tomcat::container\$1config](#create-custom-setup-config) + [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) ## tomcat::setup La recette `tomcat::setup` est destinée à être affectée à un événement du cycle de vie Setup de la couche. ``` include_recipe 'tomcat::install' include_recipe 'tomcat::service' service 'tomcat' do action :enable end # for EBS-backed instances we rely on autofs bash '(re-)start autofs earlier' do user 'root' code <<-EOC service autofs restart EOC notifies :restart, resources(:service => 'tomcat') end include_recipe 'tomcat::container_config' include_recipe 'apache2' include_recipe 'tomcat::apache_tomcat_bind' ``` La recette `tomcat::setup` est en grande partie une méta-recette. Elle contient un ensemble de recettes dépendantes qui gèrent la plupart des détails de l'installation et de la configuration de Tomcat et des packages associés. La première partie de `tomcat::setup` exécute les recettes suivantes, présentées en détail ultérieurement : + La recette [tomcat::install](#create-custom-setup-install) installe le package du serveur Tomcat. + La recette [tomcat::service](#create-custom-setup-service) configure le service Tomcat. La partie centrale de `tomcat::setup` active et démarre le service Tomcat : + La [ressource service](https://docs.chef.io/chef/resources.html#service) de Chef active le service Tomcat au démarrage. + La [ressource Chef bash](https://docs.chef.io/chef/resources.html#bash) exécute un script Bash pour démarrer le démon autofs, qui est nécessaire pour les instances soutenues par Amazon EBS. La ressource demande ensuite à la ressource `service` de redémarrer le service Tomcat. Pour plus d'informations, consultez [autofs](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html) (pour Amazon Linux) ou [Autofs](https://help.ubuntu.com/community/Autofs) (pour Ubuntu). La partie finale de `tomcat::setup` crée les fichiers de configuration, puis installe et configure le serveur frontal Apache : + La recette [tomcat::container\$1config](#create-custom-setup-config) crée les fichiers de configuration. + La `apache2` recette (qui est un raccourci pour`apache2::default`) est une recette intégrée à OpsWorks Stacks qui installe et configure un serveur Apache. + La recette [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) configure le serveur Apache pour qu'il fonctionne comme serveur frontal pour le serveur Tomcat. **Note** Vous pouvez souvent économiser du temps et des efforts en utilisant les recettes intégrées pour exécuter certaines tâches requises. Cette recette utilise la recette intégrée `apache2::default` pour installer Apache plutôt que de l'implémenter à partir de rien. Pour obtenir un autre exemple de l'utilisation des recettes intégrées, consultez [Recettes Deploy](create-custom-deploy.md). Les sections suivantes décrivent plus en détail les recettes Setup du livre de recettes Tomcat. Pour plus d'informations sur les recettes `apache2`, consultez [opsworks-cookbooks/apache2](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/apache2). ## tomcat::install La recette `tomcat::install ` installe le serveur Tomcat, OpenJDK et une bibliothèque de connecteurs Java qui gère la connexion au serveur MySQL. ``` tomcat_pkgs = value_for_platform( ['debian', 'ubuntu'] => { 'default' => ["tomcat#{node['tomcat']['base_version']}", 'libtcnative-1', 'libmysql-java'] }, ['centos', 'redhat', 'fedora', 'amazon'] => { 'default' => ["tomcat#{node['tomcat']['base_version']}", 'tomcat-native', 'mysql-connector-java'] }, 'default' => ["tomcat#{node['tomcat']['base_version']}"] ) tomcat_pkgs.each do |pkg| package pkg do action :install end end link ::File.join(node['tomcat']['lib_dir'], node['tomcat']['mysql_connector_jar']) do to ::File.join(node['tomcat']['java_dir'], node['tomcat']['mysql_connector_jar']) action :create end # remove the ROOT webapp, if it got installed by default include_recipe 'tomcat::remove_root_webapp' ``` La recette exécute les tâches suivantes : 1. Crée une liste de packages à installer, en fonction du système d'exploitation de l'instance. 1. Installe chaque package de la liste. La [ressource du package](https://docs.chef.io/chef/resources.html#id146) Chef utilise le fournisseur approprié (`yum`pour Amazon Linux et `apt-get` pour Ubuntu) pour gérer l'installation. Les fournisseurs de package installent OpenJDK comme dépendance Tomcat, mais la bibliothèque de connecteurs MySQL doit être installée explicitement. 1. Utilise une [ressource link](https://docs.chef.io/chef/resources.html#link) de Chef pour créer un lien symbolique entre le répertoire lib du serveur Tomcat et la bibliothèque de connecteurs MySQL du JDK. Selon les valeurs d'attribut par défaut, le répertoire lib Tomcat est `/usr/share/tomcat6/lib` et la bibliothèque de connecteurs MySQL (`mysql-connector-java.jar`) se trouve dans `/usr/share/java/`. La recette `tomcat::remove_root_webapp` supprime l'application web racine (`/var/lib/tomcat6/webapps/ROOT` par défaut) pour éviter certains problèmes de sécurité. ``` ruby_block 'remove the ROOT webapp' do block do ::FileUtils.rm_rf(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT'), :secure => true) end only_if { ::File.exists?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) && !::File.symlink?(::File.join(node['tomcat']['webapps_base_dir'], 'ROOT')) } end ``` L'instruction `only_if` garantit que la recette ne supprime le fichier que s'il existe. **Note** La version Tomcat est spécifiée par l'attribut `['tomcat']['base_version']`, défini sur 6 dans le fichier d'attributs. Pour installer Tomcat 7, vous pouvez utiliser des attributs JSON personnalisés pour remplacer l'attribut. [Modifiez simplement vos paramètres de pile](workingstacks-edit.md) et entrez le code JSON suivant dans la zone **Custom Chef JSON (JSON Chef personnalisé)**, ou ajoutez-le à un JSON personnalisé existant : ``` { 'tomcat' : { 'base_version' : 7 } } ``` L'attribut JSON personnalisé remplace l'attribut par défaut et définit la version Tomcat sur 7. Pour plus d'informations sur le remplacement des attributs, consultez [Remplacement des attributs](workingcookbook-attributes.md). ## tomcat::service La recette `tomcat::service` crée la définition du service Tomcat. ``` service 'tomcat' do service_name "tomcat#{node['tomcat']['base_version']}" case node[:platform] when 'centos', 'redhat', 'fedora', 'amazon' supports :restart => true, :reload => true, :status => true when 'debian', 'ubuntu' supports :restart => true, :reload => false, :status => true end action :nothing end ``` La recette utilise la [ressource service](https://docs.chef.io/chef/resources.html#service) de Chef pour spécifier le nom de service Tomcat (tomcat6, par défaut) et définit l'attribut `supports` pour définir la façon dont Chef gère le redémarrage du service, le rechargement et les commandes d'état sur les différents systèmes d'exploitation. + `true` indique que Chef peut utiliser le script init ou un autre fournisseur de services pour exécuter la commande. + `false` indique que le Chef doit tenter d'exécuter la commande par d'autres moyens. Notez que l'élément `action` est défini sur `:nothing`. Pour chaque événement du cycle de vie, OpsWorks Stacks lance une exécution [Chef pour exécuter](https://docs.chef.io/chef_client_overview.html#the-chef-client-run) l'ensemble de recettes approprié. Le livre de recettes Tomcat suit un modèle commun, selon lequel une recette crée la définition de service, mais ne redémarre pas le service. D'autres recettes de l'exécution Chef gèrent le redémarrage, généralement en incluant une commande `notifies` dans les ressources `template` utilisées pour créer les fichiers de configuration. Les notifications sont un moyen pratique de redémarrer un service, car elle ne le font que si la configuration a changé. En outre, si une exécution Chef comporte plusieurs notifications de redémarrage pour un service, Chef redémarre le service au plus une fois. Cette pratique évite les problèmes susceptibles de se produire lorsque vous tentez de redémarrer un service qui n'est pas pleinement opérationnel, ce qui est une source commune d'erreurs Tomcat. Le service Tomcat doit être défini pour toute exécution Chef qui utilise les notifications de redémarrage. `tomcat::service` est par conséquent inclus dans plusieurs recettes afin de garantir que le service soit défini pour chaque exécution Chef. Aucune pénalité ne s'applique si une exécution Chef inclut plusieurs instances de `tomcat::service`, car Chef garantit qu'une recette ne s'exécute qu'une seule fois par exécution Chef, quel que soit le nombre de fois où elle est incluse. ## tomcat::container\$1config La recette `tomcat::container_config` crée les fichiers de configuration à partir des fichiers modèles du livre de recettes. ``` include_recipe 'tomcat::service' template 'tomcat environment configuration' do path ::File.join(node['tomcat']['system_env_dir'], "tomcat#{node['tomcat']['base_version']}") source 'tomcat_env_config.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'tomcat') end template 'tomcat server configuration' do path ::File.join(node['tomcat']['catalina_base_dir'], 'server.xml') source 'server.xml.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'tomcat') end ``` La première recette appelle `tomcat::service`, qui définit le service si nécessaire. Le bloc principal de la recette se compose de deux [ressources template](https://docs.chef.io/chef/resources.html#template), chacune d'elles créant un fichier de configuration à partir de l'un des fichiers modèles du livre de recettes, définissant les propriétés du fichier et informant Chef de redémarrer le service. ### Fichier de configuration de l'environnement Tomcat La première ressource `template` utilise le fichier modèle `tomcat_env_config.erb` pour créer un fichier de configuration de l'environnement Tomcat, qui permet de définir les variables d'environnement telles que `JAVA_HOME`. Le nom de fichier par défaut est l'argument de la ressource `template`. `tomcat::container_config` utilise un attribut `path` pour remplacer la valeur par défaut et nommer le fichier de configuration `/etc/sysconfig/tomcat6` (Amazon Linux) ou `/etc/default/tomcat6` (Ubuntu). La ressource `template` spécifie également le propriétaire du fichier, le groupe et le mode, et demande à Chef de ne pas créer de fichiers de sauvegarde. Si vous regardez le code source, il existe de fait trois versions de `tomcat_env_config.erb`, chacune dans un sous-répertoire différent du répertoire `templates`. Les répertoires `ubuntu` et `amazon` contiennent les modèles de leurs systèmes d'exploitation respectifs. Le dossier `default` contient un modèle vide avec une seule ligne de commentaire, qui n'est utilisée que si vous tentez d'exécuter cette recette sur une instance dont le système d'exploitation n'est pas pris en charge. La recette `tomcat::container_config` n'a pas besoin de spécifier le modèle `tomcat_env_config.erb` à utiliser. Chef sélectionne automatiquement le répertoire approprié pour le système d'exploitation de l'instance en fonction des règles décrites dans [File Specificity](http://docs.chef.io/templates.html#file-specificity). Les fichiers `tomcat_env_config.erb` de cet exemple se composent essentiellement de commentaires. Pour définir des variables d'environnement supplémentaires, supprimez les marques de commentaire des lignes appropriées et fournissez vos valeurs préférées. **Note** Tout paramètre de configuration susceptible de changer doit être défini comme attribut plutôt que codé en dur dans le modèle. De cette façon, vous n'avez pas à réécrire le modèle pour modifier un paramètre et il vous suffit de remplacer l'attribut. Le modèle Amazon Linux définit une seule variable d'environnement, comme illustré dans l'extrait suivant. ``` ... # Use JAVA_OPTS to set java.library.path for libtcnative.so #JAVA_OPTS="-Djava.library.path=/usr/lib" JAVA_OPTS="${JAVA_OPTS} <%= node['tomcat']['java_opts'] %>" # What user should run tomcat #TOMCAT_USER="tomcat" ... ``` JAVA\$1OPTS permet de spécifier des options Java telles que le chemin d'accès de la bibliothèque. A l'aide des valeurs d'attribut par défaut, le modèle ne définit aucune option Java pour Amazon Linux. Vous pouvez définir vos propres options Java en remplaçant l'attribut `['tomcat']['java_opts']`, à l'aide, par exemple, des attributs JSON personnalisés. Pour obtenir un exemple, consultez [Créez une pile](create-custom-stack.md#create-custom-stack-stack). Le modèle Ubuntu définit plusieurs variables d'environnement, comme illustré dans l'extrait de modèle suivant. ``` # Run Tomcat as this user ID. Not setting this or leaving it blank will use the # default of tomcat<%= node['tomcat']['base_version'] %>. TOMCAT<%= node['tomcat']['base_version'] %>_USER=tomcat<%= node['tomcat']['base_version'] %> ... # Run Tomcat as this group ID. Not setting this or leaving it blank will use # the default of tomcat<%= node['tomcat']['base_version'] %>. TOMCAT<%= node['tomcat']['base_version'] %>_GROUP=tomcat<%= node['tomcat']['base_version'] %> ... JAVA_OPTS="<%= node['tomcat']['java_opts'] %>" <% if node['tomcat']['base_version'].to_i < 7 -%> # Unset LC_ALL to prevent user environment executing the init script from # influencing servlet behavior. See Debian bug #645221 unset LC_ALL <% end -%> ``` A l'aide des valeurs d'attribut par défaut, le modèle définit les variables d'environnement Ubuntu comme suit : + `TOMCAT6_USER` et `TOMCAT6_GROUP`, qui représentent le groupe et l'utilisateur Tomcat, sont tous deux définis sur `tomcat6`. Si vous définissez ['tomcat']['base\$1version'] sur `tomcat7`, les noms des variables sont résolus en `TOMCAT7_USER` et `TOMCAT7_GROUP`, et les deux sont définis sur `tomcat7`. + `JAVA_OPTS` a la valeur `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC` : + L'attribution à `-Djava.awt.headless` de la valeur `true` informe le moteur graphique que l'instance est sans périphérique de contrôle et sans console, ce qui prend en compte le comportement défaillant de certaines applications graphiques. + `-Xmx128m` garantit que la machine virtuelle Java dispose des ressources mémoire adéquates (128 Mo, dans cet exemple). + `-XX:+UseConcMarkSweepGC` spécifie le nettoyage de la mémoire « mark and sweep » simultané, ce qui aide à limiter les interruptions induites par le nettoyage de la mémoire. Pour plus d'informations, consultez : [Concurrent Mark Sweep Collector Enhancements](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html). + Si la version Tomcat est inférieure à la version 7, le modèle annule la définition de `LC_ALL`, ce qui résout un bogue Ubuntu. **Note** Avec les attributs par défaut, certaines variables d'environnement sont simplement définies sur leurs valeurs par défaut. Cependant, la définition explicite des variables d'environnement avec les attributs signifie que vous pouvez définir des attributs JSON personnalisés pour remplacer les attributs par défaut et fournir des valeurs personnalisées. Pour plus d'informations sur le remplacement des attributs, consultez [Remplacement des attributs](workingcookbook-attributes.md). Pour les fichiers modèles complets, consultez le [code source](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat). ### Fichier de configuration Server.xml La deuxième `template` ressource est utilisée `server.xml.erb` pour créer le [fichier `system.xml` de configuration](http://tomcat.apache.org/tomcat-7.0-doc/config/), qui configure le servlet/JSP conteneur. `server.xml.erb`ne contient aucun paramètre spécifique au système d'exploitation, il se trouve donc dans le `template` sous-répertoire du `default` répertoire. Le modèle utilise les paramètres standard, mais peut créer un fichier `system.xml` pour Tomcat 6 ou Tomcat 7. Par exemple, le code suivant de la section serveur du modèle configure les écouteurs de façon appropriée pour la version spécifiée. ``` <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> <% if node['tomcat']['base_version'].to_i < 7 -%> <% end -%> <% if node['tomcat']['base_version'].to_i > 6 -%> <% end -%> ``` Comme le modèle utilise des attributs à la place de paramètres codés en dur, vous pouvez facilement modifier les paramètres en définissant des attributs JSON personnalisés. Par exemple : ``` ``` Pour plus d'informations, consultez le [code source](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat). ## tomcat::apache\$1tomcat\$1bind La recette `tomcat::apache_tomcat_bind` permet au serveur Apache de faire office de serveur frontal de Tomcat : il reçoit les demandes entrantes, les transmet à Tomcat et retourne les réponses au client. Cet exemple utilise [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) comme proxy/passerelle Apache. ``` execute 'enable mod_proxy for apache-tomcat binding' do command '/usr/sbin/a2enmod proxy' not_if do ::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', 'proxy.load')) || node['tomcat']['apache_tomcat_bind_mod'] !~ /\Aproxy/ end end execute 'enable module for apache-tomcat binding' do command "/usr/sbin/a2enmod #{node['tomcat']['apache_tomcat_bind_mod']}" not_if {::File.symlink?(::File.join(node['apache']['dir'], 'mods-enabled', "#{node['tomcat']['apache_tomcat_bind_mod']}.load"))} end include_recipe 'apache2::service' template 'tomcat thru apache binding' do path ::File.join(node['apache']['dir'], 'conf.d', node['tomcat']['apache_tomcat_bind_config']) source 'apache_tomcat_bind.conf.erb' owner 'root' group 'root' mode 0644 backup false notifies :restart, resources(:service => 'apache2') end ``` Pour activer `mod_proxy`, vous devez activer le module `proxy` et un module basé sur le protocole. Vous avez deux options pour le module de protocole : + HTTP: `proxy_http` + [ JServ Protocole Apache](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) (AJP) : `proxy_ajp` AJP est un protocole Tomcat interne. Les deux [ressources execute](https://docs.chef.io/chef/resources.html#execute) de la recette exécutent la commande `a2enmod`, qui active le module spécifié en créant les liens symboliques requis : + La première ressource `execute` exécute le module `proxy`. + La seconde ressource `execute` active le module de protocole, défini sur `proxy_http` par défaut. Si vous préférez utiliser AJP, vous pouvez définir un JSON personnalisé pour remplacer l'attribut `apache_tomcat_bind_mod` et le définir sur `proxy_ajp`. La `apache2::service` recette est une recette intégrée à OpsWorks Stacks qui définit le service Apache. Pour plus d'informations, consultez la [recette](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb) dans le GitHub référentiel OpsWorks Stacks. La ressource `template` utilise `apache_tomcat_bind.conf.erb` pour créer un fichier de configuration, nommé `tomcat_bind.conf` par défaut. Elle place le fichier dans le répertoire `['apache']['dir']/.conf.d`. L'attribut `['apache']['dir']` est défini dans le fichier d'attributs `apache2` intégré et est défini par défaut sur `/etc/httpd` (Amazon Linux) ou `/etc/apache2` (Ubuntu). Si la ressource `template` crée ou modifie le fichier de configuration, la commande `notifies` planifie un redémarrage du service Apache. ``` <% if node['tomcat']['apache_tomcat_bind_mod'] == 'proxy_ajp' -%> ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/ ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> ajp://localhost:<%= node['tomcat']['ajp_port'] %>/ <% else %> ProxyPass <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/ ProxyPassReverse <%= node['tomcat']['apache_tomcat_bind_path'] %> http://localhost:<%= node['tomcat']['port'] %>/ <% end -%> ``` Le modèle utilise les [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse)directives [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass)et pour configurer le port utilisé pour transmettre le trafic entre Apache et Tomcat. Comme les deux serveurs sont sur la même instance, ils peuvent utiliser une URL localhost et sont tous deux définis par défaut sur `http://localhost:8080`.