Ricette di impostazione - AWS OpsWorks

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 AWS Supporto Premium.

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 (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à:

  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 fornitori di pacchetti installano Open JDK come dipendenza di Tomcat, ma la libreria My SQL connector deve essere installata in modo esplicito.

  3. 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/ROOTper 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 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 di 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 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 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.

    • -Xmx128massicura 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 configurazione, che configura il servlet/ container. JSP server.xml.erbnon 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 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 utilizzarloAJP, puoi definire custom JSON per sovrascrivere l'apache_tomcat_bind_modattributo 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 nel AWS OpsWorks GitHub Archivio 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é entrambi i server si trovano sulla stessa istanza, possono utilizzare un localhost URL e sono entrambi impostati di default su. http://localhost:8080