Ricette di impostazione - AWS OpsWorks
tomcat::setuptomcat::installtomcat::servicetomcat::container_configtomcat::apache_tomcat_bind

Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.

Ricette di impostazione

Importante

Il AWS OpsWorks Stacks servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disabilitato sia per i clienti nuovi che per quelli esistenti. Consigliamo vivamente ai clienti di migrare i propri carichi di lavoro verso altre soluzioni il prima possibile. Se hai domande sulla migrazione, contatta il AWS Support Team su AWS re:post o tramite Premium AWS Support.

Le ricette di impostazione sono assegnate all'evento del ciclo di vita Setup del livello e vengono eseguite dopo l'avvio di un'istanza. Eseguono attività quali l'installazione di pacchetti, la creazione di file di configurazione e l'avvio di servizi. Al termine dell'esecuzione delle ricette di installazione, AWS OpsWorks Stacks esegue le ricette Deploy per distribuire qualsiasi app nella nuova istanza.

tomcat::setup

La ricetta tomcat::setup è stata concepita per essere assegnata a un evento del ciclo di vita Setup del livello.


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 ricetta tomcat::setup è in gran parte una meta-ricetta. Include un set di ricette dipendenti che gestiscono la maggior parte dei dettagli di installazione e configurazione di Tomcat e dei pacchetti correlati. La prima parte di tomcat::setup esegue le seguenti ricette, descritte più avanti:

La parte centrale di tomcat::setup abilita e avvia il servizio Tomcat:

  • La risorsa del servizio Chef abilita il servizio Tomcat all'avvio.

  • La risorsa Chef bash esegue uno script Bash per avviare il demone autofs, necessario per le istanze supportate da Amazon EBS. La risorsa, quindi, comunica alla risorsa service di riavviare il servizio Tomcat.

    Per ulteriori informazioni, consulta: autofs (per Amazon Linux) o Autofs (per Ubuntu).

La parte finale di tomcat::setup crea i file di configurazione e installa e configura il server front-end Apache:

  • La ricetta tomcat::container_config crea file di configurazione.

  • La apache2 ricetta (abbreviazione di) è una ricetta integrata di Stacks che installa e configura un apache2::default AWS OpsWorks server Apache.

  • La ricetta tomcat::apache_tomcat_bind configura il server Apache affinché funga da front-end per il server Tomcat.

Nota

Spesso puoi risparmiare tempo e risorse utilizzando ricette integrate per eseguire alcune delle attività necessarie. Questa ricetta utilizza la ricetta apache2::default integrata per installare Apache anziché implementarlo da zero. Per un altro esempio di come utilizzare ricette integrate, consulta Ricette di ditribuzione.

Nelle seguenti sezioni vengono descritte nel dettaglio le ricette di impostazione del libro di ricette Tomcat. Per ulteriori informazioni sulle ricette apache2, consulta opsworks-cookbooks/apache2.

tomcat::install

La ricetta tomcat::install installa il server Tomcat, OpenJDK e una libreria di connettori Java che gestisce la connessione al server 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 ricetta esegue le seguenti attività:

  1. Crea un elenco di pacchetti da installare, a seconda del sistema operativo dell'istanza.

  2. Installa ogni pacchetto nell'elenco.

    La risorsa del pacchetto Chef utilizza il provider appropriato, yum per Amazon Linux e apt-get Ubuntu, per gestire l'installazione. I provider di pacchetti installano OpenJDK come dipendenza Tomcat, ma la libreria di connettori MySQL deve essere installata in modo esplicito.

  3. Utilizza una risorsa link di Chef per creare un collegamento simbolico nella directory lib del server Tomcat alla libreria dei connettori MySQL in JDK.

    In base ai valori degli attributi predefiniti, la directory lib di Tomcat è /usr/share/tomcat6/lib e la libreria dei connettori MySQL (mysql-connector-java.jar) è in /usr/share/java/.

La ricetta tomcat::remove_root_webapp rimuove l'applicazione Web ROOT (/var/lib/tomcat6/webapps/ROOT per impostazione predefinita) per evitare alcune problematiche relative alla sicurezza.

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'istruzione only_if garantisce che la ricetta rimuoverà il file solo se esistente.

Nota

La versione di Tomcat viene specificata dall'attributo ['tomcat']['base_version'], impostato su 6 nel file degli attributi. Per installare Tomcat 7, puoi sostituire l'attributo con gli attributi JSON personalizzati. È sufficiente che modifichi le impostazioni dello stack e inserisci il seguente JSON nella casella Custom Chef JSON (JSON Chef personalizzato) oppure lo aggiungi a un JSON personalizzato esistente:


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

L'attributo JSON personalizzato sostituisce l'attributo predefinito e imposta la versione di Tomcat su 7. Per ulteriori informazioni sulla sostituzione di attributi, consulta Sostituzione degli attributi.

tomcat::service

La ricetta tomcat::service crea la definizione del servizio 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 ricetta usa la risorsa service di Chef per specificare il nome di servizio Tomcat (tomcat6, per impostazione predefinita) e imposta l'attributo supports per definire in che modo Chef gestisce il riavvio, il ricaricamento e i comandi di stato del servizio sui vari sistemi operativi.

  • true indica che Chef può utilizzare lo script init o un altro provider di servizi per eseguire il comando

  • false indica che Chef deve tentare di eseguire il comando con altri mezzi.

action è impostato su :nothing. Per ogni evento del ciclo di vita, AWS OpsWorks Stacks avvia un'esecuzione Chef per eseguire il set di ricette appropriato. Il libro di ricette Tomcat segue un modello comune in base al quale una ricetta crea la definizione del servizio, ma non lo riavvia. Altre ricette nell'esecuzione Chef gestiscono il riavvio, di solito includendo un comando notifies nelle risorse template utilizzate per creare i file di configurazione. Le notifiche sono utili per riavviare un servizio poiché lo fanno solo se la configurazione è cambiata. Inoltre, se un'esecuzione Chef include più notifiche di riavvio per un servizio, Chef riavvia il servizio non più di una volta. Questa pratica evita i problemi che possono verificarsi durante il tentativo di riavvio di un servizio non completamente operativo, fonte comune di errori Tomcat.

Il servizio Tomcat deve essere definito per qualsiasi esecuzione di Chef che utilizza le notifiche di riavvio. tomcat::service pertanto è incluso in diverse ricette, per assicurare che il servizio sia definito per ogni esecuzione di Chef. Non vi è alcuna sanzione se un'esecuzione Chef include più istanze di tomcat::service perché Chef garantisce una singola esecuzione per ricetta, indipendentemente dal numero di volte che tale ricetta viene inclusa.

tomcat::container_config

La ricetta tomcat::container_config crea file di configurazione dai file modello del libro di ricette.


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

Innanzitutto la ricetta chiama tomcat::service, che definisce il servizio, se necessario. Il blocco principale della ricetta consiste di due risorse template, ciascuna delle quali crea un file di configurazione da uno dei file modello del libro di ricette, imposta le proprietà del file e comunica a Chef di riavviare il servizio.

File di configurazione dell'ambiente Tomcat

La prima risorsa template usa il file modello tomcat_env_config.erb per creare un file di configurazione dell'ambiente Tomcat, utilizzato per impostare variabili di ambiente, come JAVA_HOME. Il nome file predefinito è l'argomento della risorsa template. tomcat::container_config utilizza un attributo path per sostituire il valore predefinito e nominare il file di configurazione /etc/sysconfig/tomcat6 (Amazon Linux) o /etc/default/tomcat6 (Ubuntu). La risorsa template specifica inoltre il proprietario del file, il gruppo e la modalità e indica a Chef di non creare file di backup.

Se esamini il codice sorgente, vedrai che esistono di fatto tre versioni di tomcat_env_config.erb, ognuna in una sottodirectory diversa della directory templates. Le directory ubuntu e amazon contengono i modelli per i rispettivi sistemi operativi. La cartella default contiene un modello fittizio con una singola riga di commento, che viene utilizzato solo se cerchi di eseguire questa ricetta su un'istanza con un sistema operativo non supportato. Per la ricetta tomcat::container_config non è necessario specificare quale tomcat_env_config.erb utilizzare. Chef seleziona automaticamente la directory appropriata al sistema operativo dell'istanza in funzione delle regole descritte in Specificità file.

I file tomcat_env_config.erb di questo esempio consistono in gran parte di commenti. Per impostare ulteriori variabili di ambiente, annulla semplicemente i commenti delle righe appropriate e fornisci i valori che preferisci.

Nota

Qualsiasi impostazione di configurazione che potrebbe cambiare deve essere definita come attributo anziché come impostazione hardcoded nel modello. In questo modo, non dovrai riscrivere il modello per modificare un'impostazione, ma semplicemente sostituire l'attributo.

Il modello di Amazon Linux imposta solo una variabile di ambiente, come illustrato nel seguente estratto.


...
# 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 può essere utilizzato per specificare opzioni Java, come il percorso della libreria. Utilizzando valori di attributi predefiniti, il modello non imposta alcuna opzione Java per Amazon Linux. Puoi impostare le tue opzioni Java sostituendo l'attributo ['tomcat']['java_opts'], ad esempio, con gli attributi JSON personalizzati. Per vedere un esempio, consulta Creare uno stack.

Il modello di Ubuntu imposta diverse variabili di ambiente, come illustrato nel seguente estratto del modello.


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

Utilizzando valori di attributi predefiniti, il modello imposta le variabili dell'ambiente Ubuntu come segue:

  • TOMCAT6_USER e TOMCAT6_GROUP, che rappresentano l'utente e il gruppo di Tomcat, sono entrambe impostate su tomcat6.

    Se imposti ['tomcat']['base_version'] su tomcat7, i nomi delle variabili si risolvono in TOMCAT7_USER e TOMCAT7_GROUP ed entrambi sono impostati su tomcat7.

  • JAVA_OPTS è impostato su -Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC:

    • L'impostazione di -Djava.awt.headless su true informa il motore di grafica che l'istanza è headless e non dispone di una console, che risolve il comportamento errato di alcune applicazioni grafiche.

    • -Xmx128m garantisce che JVM dispone di adeguate risorse di memoria, in questo esempio 128 MB.

    • -XX:+UseConcMarkSweepGC specifica la garbage collection Concurrent Mark Sweep (CMS), che consente di limitare le pause indotte da garbage collection.

      Per ulteriori informazioni, consulta Concurrent Mark Sweep Collector Enhancements.

  • Se la versione di Tomcat è precedente alla 7, il modello annulla l'impostazione LC_ALL, che risolve un bug di Ubuntu.

Nota

Con gli attributi predefiniti, alcune di queste variabili di ambiente sono semplicemente impostate sui valori predefiniti. Tuttavia, l'impostazione esplicita delle variabili di ambiente sugli attributi indica che puoi definire attributi JSON personalizzati con cui sostituire gli attributi predefiniti e fornire valori personalizzati. Per ulteriori informazioni sulla sostituzione di attributi, consulta Sostituzione degli attributi.

Per completare i file modello, consulta il codice sorgente.

File di configurazione Server.xml

La seconda risorsa template utilizza server.xml.erb per creare il file di configurazione system.xml, che configura il container servlet/JSP. server.xml.erb non contiene impostazioni specifiche del sistema operativo, per cui si trova nella sottodirectory default della directory template.

Il modello utilizza le impostazioni standard, ma può creare un file system.xml per Tomcat 6 o Tomcat 7. Ad esempio, il codice seguente della sezione server del modello configura i listener in modo appropriato per la versione specificata.


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

Il modello utilizza gli attributi al posto delle impostazioni hardcoded affinché tu possa facilmente modificare le impostazioni mediante la definizione di attributi JSON personalizzati. Per esempio:


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

Per ulteriori informazioni, consulta il codice sorgente.

tomcat::apache_tomcat_bind

La ricetta tomcat::apache_tomcat_bind consente al server Apache di funzionare come front-end di Tomcat, in quanto riceve le richieste in arrivo e le inoltra a Tomcat per poi inviare le risposte al client. Questo esempio utilizza mod_proxy come proxy/gateway 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

Per abilitare mod_proxy, devi abilitare il modulo proxy e un modulo basato sul protocollo. Per il modulo del protocollo sono disponibili due opzioni:

Entrambe le risorse execute della ricetta eseguono il comando a2enmod, che abilita il modulo specificato mediante la creazione dei collegamenti simbolici richiesti:

  • La prima risorsa execute abilita il modulo proxy.

  • La seconda risorsa execute abilita il modulo del protocollo, che è configurato su proxy_http per impostazione predefinita.

    Se preferisci utilizzare AJP, puoi definire un JSON personalizzato per sostituire l'attributo apache_tomcat_bind_mod e impostarlo su proxy_ajp.

La apache2::service ricetta è una ricetta integrata in AWS OpsWorks Stacks che definisce il servizio Apache. Per ulteriori informazioni, consulta la ricetta nel repository AWS OpsWorks GitHub Stacks.

La risorsa template utilizza apache_tomcat_bind.conf.erb per creare un file di configurazione, denominato tomcat_bind.conf per impostazione predefinita. Colloca il file nella directory ['apache']['dir']/.conf.d. L'attributo ['apache']['dir'] viene definito nel file di attributi apache2 integrato ed è configurato su /etc/httpd (Amazon Linux) oppure su /etc/apache2 (Ubuntu) per impostazione predefinita. Se la risorsa template crea o modifica il file di configurazione, il comando notifies pianifica un riavvio del servizio 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 -%>

Il modello utilizza le ProxyPassReversedirettive ProxyPassand per configurare la porta utilizzata per far passare il traffico tra Apache e Tomcat. Poiché sono sulla stessa istanza, entrambi i server possono utilizzare un URL localhost ed essere configurati su http://localhost:8080 per impostazione predefinita.