Recettes Setup

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 partie centrale de tomcat::setup active et démarre le service Tomcat :

La partie finale de tomcat::setup crée les fichiers de configuration, puis installe et configure le serveur frontal Apache :

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 tomcat::install recette installe le serveur Tomcat, l'Open JDK et une bibliothèque de connecteurs Java qui gère la connexion au My SQL server.

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 :

La tomcat::remove_root_webapp recette supprime l'application ROOT Web (/var/lib/tomcat6/webapps/ROOTpar 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.

{
  'tomcat' : {
    'base_version' : 7
  }
}

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.

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.

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 peut être utilisé pour spécifier des options Java telles que le chemin 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'['tomcat']['java_opts']attribut, par exemple en utilisant des JSON attributs 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 :

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

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, qui configure le JSP servlet/conteneur. server.xml.erbne 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 -%>
  <!-- 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 -%>

Le modèle utilise des attributs à la place des paramètres codés en dur afin que vous puissiez facilement modifier les paramètres en définissant des JSON attributs 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 :

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 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 se trouvent sur la même instance, ils peuvent utiliser un localhost URL et sont tous deux définis par défaut surhttp://localhost:8080.