Einrichtungsrezepte

Einrichtungsrezepte werden dem Setup-Lebenszyklusereignis des Layers zugeordnet und nach dem Start einer Instance ausgeführt. Sie führen Aufgaben wie das Installieren von Paketen, das Erstellen von Konfigurationsdateien und das Starten von Services durch. Nachdem die Setup-Rezepte nicht mehr ausgeführt wurden, AWS OpsWorks Stacks führt die Deploy-Rezepte aus, um alle Apps auf der neuen Instanz bereitzustellen.

tomcat::setup

Das tomcat::setup-Rezept ist dafür konzipiert, dem Setup-Lebenszyklusereignis eines Layer zugewiesen zu werden.

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'

Das tomcat::setup-Rezept ist weitestgehend ein Metarezept. Es enthält eine Reihe von abhängigen Rezepten, die die meisten Details der Installation und Konfiguration von Tomcat und zugehörigen Paketen verarbeiten. Der erste Teil von tomcat::setup führt die folgenden Rezepte aus, die zu einem späteren Zeitpunkt besprochen werden:

Der mittlere Teil von tomcat::setup ermöglicht und startet den Tomcat-Service:

Der letzte Teil von tomcat::setup erstellt Konfigurationsdateien und installiert und konfiguriert den Apache-Frontend-Server:

Die folgenden Abschnitte beschreiben die Einrichtungsrezepte des Tomcat-Rezeptbuch im Detail. Weitere Informationen zu den apache2-Rezepten finden Sie unter opsworks-cookbooks/apache2.

tomcat::install

Das tomcat::install Rezept installiert den Tomcat-ServerJDK, Open und eine Java-Connector-Bibliothek, die die Verbindung zum My-Server verwaltet. SQL

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'

Das Rezept führt die folgenden Aufgaben aus:

Das tomcat::remove_root_webapp Rezept entfernt die ROOT Webanwendung (/var/lib/tomcat6/webapps/ROOTstandardmäßig), um einige Sicherheitsprobleme zu vermeiden.

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

Die only_if-Anweisung stellt sicher, dass das Rezept die Datei nur dann entfernt, wenn sie vorhanden ist.

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

tomcat::service

Das tomcat::service-Rezept erstellt die Tomcat-Servicedefinition.

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

Das Rezept verwendet die service-Ressource von Chef, um den Tomcat-Servicenamen (standardmäßig "tomcat6") anzugeben, und das supports-Attribut, um zu definieren, wie Chef die Neustart-, Neulade- und Statusbefehle auf den verschiedenen Betriebssystemen verwaltet.

Beachten Sie, dass action auf :nothing festgelegt ist. Für jedes Lebenszyklusereignis AWS OpsWorks Stacks initiiert einen Chef-Lauf, um die entsprechenden Rezepte auszuführen. Das Tomcat-Rezeptbuch folgt einem allgemeinen Muster, das festlegt, dass ein Rezept die Servicedefinition erstellt, den aber Service nicht neu startet. Andere Rezepte in der Chef-Ausführung verarbeiten den Neustart, normalerweise mit einem notifies-Befehl in den template-Ressourcen, die zum Erstellen von Konfigurationsdateien verwendet werden. Benachrichtigungen sind eine komfortable Möglichkeit, einen Service neu zu starten, denn sie tun das nur, wenn die Konfiguration geändert wurde. Wenn eine Chef-Ausführung mehrere Neustartbenachrichtigungen für einen Service aufweist, startet Chef den Service zudem höchstens einmal neu. So werden Probleme vermieden, die auftreten können, wenn versucht wird, einen Service neu zu starten, der nicht voll betriebsbereit. Dies ist eine häufige Quelle von Fehlern bei Tomcat.

Der Tomcat-Service muss für jede Chef-Ausführung, die Neustartbenachrichtigungen verwendet, definiert werden. tomcat::service ist daher in mehreren Rezepten enthalten, um sicherzustellen, dass der Service für jede Chef-Ausführung definiert ist. Es entstehen keine Nachteile, wenn eine Chef-Ausführung mehrere Instances von tomcat::service umfasst, da Chef sicherstellt, dass ein Rezept nur einmal pro Ausführung ausgeführt wird, unabhängig davon, wie oft es enthalten ist.

tomcat::container_config

Das tomcat::container_config-Rezept erstellt Konfigurationsdateien von Rezeptbuch-Vorlagendateien.

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

Das Rezept ruft zuerst tomcat::service auf, das den Service bei Bedarf definiert. Der Großteil des Rezepts besteht aus zwei template-Ressourcen, von denen jede eine Konfigurationsdatei von einer der Vorlagendateien des Rezeptbuchs erstellt, die Dateieigenschaften festlegt und Chef anweist, den Service neu zu starten.

Tomcat-Umgebungskonfigurationsdatei

Die erste template-Ressource verwendet die Vorlagendatei tomcat_env_config.erb zum Erstellen einer Tomcat-Umgebungskonfigurationsdatei, die zum Festlegen von Umgebungsvariablen wie JAVA_HOME verwendet wird. Der Standardname ist das Argument der template-Ressource. tomcat::container_config verwendet ein path-Attribut, um den Standardwert zu überschreiben und der Konfigurationsdatei den Namen /etc/sysconfig/tomcat6 (Amazon Linux) oder /etc/default/tomcat6 (Ubuntu) zu geben. Die template-Ressource gibt zudem den Eigentümer, die Gruppe und die Moduseinstellungen der Datei an und weist Chef an, keine Sicherungsdateien zu erstellen.

Wenn Sie sich den Quellcode ansehen, gibt es tatsächlich drei Versionen von tomcat_env_config.erb, in jeweils unterschiedlichen Unterverzeichnissen des templates-Verzeichnisses. Die Verzeichnisse ubuntu und amazon enthalten die Vorlagen für die jeweiligen Betriebssysteme. Der Ordner default enthält eine Dummy-Vorlage mit einer einzigen Kommentarzeile, die nur verwendet wird, wenn Sie versuchen, dieses Rezept für eine Instance mit einem nicht unterstützten Betriebssystem auszuführen. Das Rezept tomcat::container_config muss nicht angeben, welche Datei tomcat_env_config.erb zu verwenden ist. Chef wählt automatisch das entsprechende Verzeichnis für das Betriebssystem der Instance aus, basierend auf den unter File Specificity beschriebenen Regeln.

Die tomcat_env_config.erb-Dateien für dieses Beispiel bestehen größtenteils aus Kommentaren. Um zusätzliche Umgebungsvariablen festzulegen, heben Sie die Auskommentierung der entsprechenden Zeilen auf und stellen Sie Ihre bevorzugten Werte bereit.

Die Amazon Linux-Vorlage legt nur eine Umgebungsvariable fest, wie im folgenden Auszug gezeigt.

...
# 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 kann verwendet werden, um Java-Optionen wie den Bibliothekspfad anzugeben. Mithilfe der standardmäßigen Attributwerte legt die Vorlage keine Java-Optionen für Amazon Linux fest. Sie können Ihre eigenen Java-Optionen festlegen, indem Sie das ['tomcat']['java_opts'] Attribut überschreiben, z. B. indem Sie benutzerdefinierte JSON Attribute verwenden. Ein Beispiel finden Sie unter Erstellen eines Stacks.

Die Ubuntu-Vorlage legt verschiedene Umgebungsvariablen fest, wie im folgenden Auszug aus der Vorlage gezeigt.

# 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 -%>

Mithilfe von standardmäßigen Attributwerten legt die Vorlage die Ubuntu-Umgebungsvariablen wie folgt fest:

Vollständige Vorlagendateien finden Sie im Quellcode.

Konfigurationsdatei "Server.xml"

Die zweite template Ressource wird verwendetserver.xml.erb, um die system.xmlKonfigurationsdatei zu erstellen, die das Servlet/den Container JSP konfiguriert. server.xml.erbenthält keine betriebssystemspezifischen Einstellungen und befindet sich daher im Unterverzeichnis des Verzeichnisses. template default

Die Vorlage verwendet Standardeinstellungen, kann jedoch eine Datei system.xml für Tomcat 6 oder für Tomcat 7 erstellen. Der folgende Code aus dem Serverabschnitt der Vorlage konfiguriert beispielsweise die entsprechenden Listener für die angegebene Version.

<% 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 -%>

Die Vorlage verwendet Attribute anstelle von fest codierten Einstellungen, sodass Sie die Einstellungen einfach ändern können, indem Sie benutzerdefinierte Attribute definieren. JSON Beispielsweise:

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

Weitere Informationen finden Sie im Quellcode.

tomcat::apache_tomcat_bind

Das tomcat::apache_tomcat_bind-Rezept ermöglicht dem Apache-Server, als Tomcat-Frontend zu agieren, eingehende Anforderungen zu erhalten und sie an Tomcat weiterzuleiten sowie die Antworten an den Client zurückzugeben. Dieses Beispiel verwendet mod_proxy als Apache-Proxy/Gateway.

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

Um mod_proxy zu aktivieren, müssen Sie das proxy-Modul und ein protokollbasiertes Modul aktivieren. Es gibt zwei Möglichkeiten für das Protokollmodul:

Beide execute-Ressourcen des Rezepts führen den a2enmod-Befehl aus, der das angegebene Modul aktiviert, indem die erforderlichen symbolischen Links (symlinks) erstellt werden:

Das apache2::service Rezept ist ein AWS OpsWorks Stacks integriertes Rezept, das den Apache-Dienst definiert. Weitere Informationen finden Sie im Rezept im AWS OpsWorks GitHub Stacks-Repository.

Die template-Ressource verwendet apache_tomcat_bind.conf.erb zum Erstellen einer Konfigurationsdatei, die standardmäßig tomcat_bind.conf benannt wird. Die Datei wird im Verzeichnis ['apache']['dir']/.conf.d abgelegt. Das ['apache']['dir']-Attribut ist in der integrierten apache2-Attributdatei definiert und standardmäßig auf /etc/httpd (Amazon Linux) bzw. /etc/apache2 (Ubuntu) festgelegt. Wenn die template-Ressource die Konfigurationsdatei erstellt oder ändert, plant der notifies-Befehl einen Neustart des Apache-Services.

<% 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 -%>

Die Vorlage verwendet die ProxyPassReverseAnweisungen ProxyPassund, um den Port zu konfigurieren, der für die Weiterleitung des Datenverkehrs zwischen Apache und Tomcat verwendet wird. Da sich beide Server auf derselben Instanz befinden, können sie einen Localhost verwenden URL und beide sind standardmäßig auf eingestellt. http://localhost:8080