tomcat::setup tomcat::install tomcat::service tomcat::container_config tomcat::apache_tomcat_bind

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

Les recettes Setup sont affectées à l'événement de cycle de vie 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, AWS OpsWorks Stacks exécute les recettes de déploiement pour déployer toutes les applications sur la nouvelle instance.

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 installe le package du serveur Tomcat.
La recette tomcat::service configure le service Tomcat.

La partie centrale de tomcat::setup active et démarre le service Tomcat :

La ressource service de Chef active le service Tomcat au démarrage.
La ressource Chef 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 (pour Amazon Linux) ou 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_config crée les fichiers de configuration.
La apache2 recette (qui est un raccourci pourapache2::default) est une recette intégrée à AWS OpsWorks Stacks qui installe et configure un serveur Apache.
La recette tomcat::apache_tomcat_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.

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.

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 :

Crée une liste de packages à installer, en fonction du système d'exploitation de l'instance.
Installe chaque package de la liste.

La ressource du package Chef utilise le fournisseur approprié (yumpour 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.
Utilise une ressource 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 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.

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 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, AWS OpsWorks Stacks lance une exécution Chef pour exécuter 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_config

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, 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.

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_OPTS 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.

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_version'] 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.
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.

Pour les fichiers modèles complets, consultez le code source.

Fichier de configuration Server.xml

La deuxième ressource template utilise server.xml.erb pour créer le fichier de configuration system.xml, qui configure le conteneur servlet/JSP. Comme server.xml.erb ne contient aucun paramètre spécifique au système d'exploitation, il se trouve dans le sous-répertoire default du répertoire template.

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 -%>
  <!-- Security listener. Documentation at /docs/config/listeners.html
  <Listener className="org.apache.catalina.security.SecurityListener" />
  -->
<% end -%>
  <!--APR library loader. Documentation at /docs/apr.html -->
  <Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
  <!--Initialize Jasper prior to webapps are loaded. Documentation at /docs/jasper-howto.html -->
  <Listener className="org.apache.catalina.core.JasperListener" />
  <!-- Prevent memory leaks due to use of particular java/javax APIs-->
  <Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener" />
<% if node['tomcat']['base_version'].to_i < 7 -%>
  <!-- JMX Support for the Tomcat server. Documentation at /docs/non-existent.html -->
  <Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<% end -%>
  <Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<% if node['tomcat']['base_version'].to_i > 6 -%>
  <Listener className="org.apache.catalina.core.ThreadLocalLeakPreventionListener" />
<% 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 :



<Connector port="<%= node['tomcat']['port'] %>" protocol="HTTP/1.1"
           connectionTimeout="20000"
           URIEncoding="<%= node['tomcat']['uri_encoding'] %>"
           redirectPort="<%= node['tomcat']['secure_port'] %>" />

Pour plus d'informations, consultez le code source.

tomcat::apache_tomcat_bind

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_proxy 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
Apache JServ Protocol (AJP) : proxy_ajp

AJP est un protocole Tomcat interne.

Les deux ressources 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 à AWS OpsWorks Stacks qui définit le service Apache. Pour plus d'informations, consultez la recette dans le GitHub référentiel AWS 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 ProxyPassReversedirectives ProxyPasset 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.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Fichiers d'attributs

Recettes Configure