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 il servizio ha raggiunto la fine del ciclo di vita il 26 maggio 2024 ed è stato disattivato 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 Squadra su AWS Re:post o tramite
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.
Argomenti
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 ricetta tomcat::install installa il pacchetto del server Tomcat.
-
La ricetta tomcat::service configura il servizio Tomcat.
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 (che è l'abbreviazione di) èapache2::default
AWS OpsWorks Ricetta integrata di Stacks che installa e configura un 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 tomcat::install
ricetta installa il server TomcatJDK, Open e una libreria di connettori Java che gestisce la connessione al server My. 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'
La ricetta esegue le seguenti attività:
-
Crea un elenco di pacchetti da installare, a seconda del sistema operativo dell'istanza.
-
Installa ogni pacchetto nell'elenco.
La risorsa del pacchetto
Chef utilizza il provider appropriato, yum
per Amazon Linux eapt-get
Ubuntu, per gestire l'installazione. I fornitori di pacchetti installano Open JDK come dipendenza di Tomcat, ma la libreria My SQL connector deve essere installata in modo esplicito. -
Utilizza una risorsa di collegamento
Chef per creare un collegamento simbolico nella directory lib del server Tomcat alla libreria My connector in. SQL JDK Utilizzando i valori degli attributi predefiniti, si trova la directory Tomcat lib
/usr/share/tomcat6/lib
e la libreria My SQL connector () è attiva.mysql-connector-java.jar
/usr/share/java/
La tomcat::remove_root_webapp
ricetta rimuove l'applicazione ROOT web (/var/lib/tomcat6/webapps/ROOT
per impostazione predefinita) per evitare alcuni problemi di 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, è possibile utilizzare JSON attributi personalizzati per sovrascrivere l'attributo. Basta modificare le impostazioni dello stack e inserire quanto segue JSON nella JSON casella Custom Chef o aggiungerlo a qualsiasi personalizzazione esistente: JSON
{ 'tomcat' : { 'base_version' : 7 } }
L'JSONattributo 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 servicesupports
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 di Chef per eseguirenotifies
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
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 usato per specificare opzioni Java come il percorso della libreria. Utilizzando valori di attributi predefiniti, il modello non imposta alcuna opzione Java per Amazon Linux. È possibile impostare le proprie opzioni Java sovrascrivendo l'['tomcat']['java_opts']
attributo, ad esempio utilizzando JSON attributi 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
eTOMCAT6_GROUP
, che rappresentano l'utente e il gruppo di Tomcat, sono entrambe impostate sutomcat6
.Se imposti ['tomcat']['base_version'] su
tomcat7
, i nomi delle variabili si risolvono inTOMCAT7_USER
eTOMCAT7_GROUP
ed entrambi sono impostati sutomcat7
. -
JAVA_OPTS
è impostato su-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC
:-
L'impostazione di
-Djava.awt.headless
sutrue
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
assicura che JVM disponga di risorse di memoria adeguate, 128 MB per questo esempio. -
-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 significa che è possibile definire JSON attributi personalizzati per sovrascrivere 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 template
risorsa viene utilizzata server.xml.erb
per creare il file di system.xml
configurazioneserver.xml.erb
non contiene impostazioni specifiche del sistema operativo, quindi si trova nella sottodirectory della directory. template
default
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 codificate in modo da poter modificare facilmente le impostazioni definendo attributi personalizzati. JSON 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
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:
-
HTTP:
proxy_http
-
JServProtocollo Apache
(): AJP proxy_ajp
AJPè un protocollo Tomcat interno.
Entrambe le risorse executea2enmod
, che abilita il modulo specificato mediante la creazione dei collegamenti simbolici richiesti:
-
La prima risorsa
execute
abilita il moduloproxy
. -
La seconda risorsa
execute
abilita il modulo del protocollo, che è configurato suproxy_http
per impostazione predefinita.Se preferisci utilizzarloAJP, puoi definire custom JSON per sovrascrivere l'
apache_tomcat_bind_mod
attributo e impostarlo su.proxy_ajp
La apache2::service
ricetta è una AWS OpsWorks Ricetta integrata di Stacks che definisce il servizio Apache. Per ulteriori informazioni, consulta la ricetta
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 ProxyPassReversehttp://localhost:8080