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à.

# Creazione di un livello server Tomcat personalizzato
<a name="create-custom"></a>

**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 Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support).

**Nota**  
In questo argomento viene descritto come implementare un livello personalizzato per uno stack Linux. Tuttavia, i principi di base e parte del codice possono anche essere adattati allo scopo di implementare livelli personalizzati per gli stack Windows, soprattutto quelli nella sezione relativa alla distribuzione di app.

[Il modo più semplice per utilizzare pacchetti non standard sulle istanze OpsWorks Stacks consiste nell'estendere un livello esistente.](workingcookbook-extend-package.md) Questo approccio però comporta l'installazione e l'esecuzione sia di pacchetti standard sia di pacchetti non standard sulle istanze del livello, creando una situazione non sempre auspicabile. Un approccio più complesso, ma più efficace, consiste nell'implementazione di un livello personalizzato, in grado di offrirti un controllo quasi completo delle istanze del livello, incluse quelle indicate di seguito: 
+ Pacchetti installati
+ Configurazione di ogni pacchetto
+ Distribuzione di app da un repository sull'istanza

Utilizzando la console o l'API, puoi creare e gestire un livello personalizzato come qualsiasi altro livello, come descritto in [Livelli personalizzati](workinglayers-custom.md). Tuttavia, le ricette incorporate di un livello personalizzato eseguono solo alcune attività assolutamente di base, come l'installazione di un client Ganglia per la segnalazione dei parametri a un master Ganglia. Per rendere le istanze di un livello personalizzato più che minimamente funzionali, devi implementare uno o più libri di ricette personalizzati con ricette Chef e file correlati per gestire le attività di installazione e configurazione di pacchetti, distribuzione di app e così via. Tuttavia, non devi necessariamente implementare tutto da zero. Ad esempio, se archivi applicazioni in uno dei repository standard, puoi utilizzare le ricette di distribuzione integrate per gestire la maggior parte del lavoro di installazione delle applicazioni sulle istanze del livello.

**Nota**  
Se utilizzi Chef per la prima volta, leggi [Introduzione ai libri di ricette](cookbooks-101.md), un tutorial che introduce i concetti di base sull'implementazione di libri di ricette e l'esecuzione di varie attività comuni. 

Le seguenti procedure guidate illustrano come implementare un livello personalizzato che supporta un server di applicazioni Tomcat. Il livello si basa su un libro di ricette personalizzato denominato Tomcat che include, tra l'altro, ricette per gestire l'installazione e la distribuzione di pacchetti. La procedura guidata include estratti del libro di ricette Tomcat. [Puoi scaricare il ricettario completo dal suo repository. GitHub ](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat) Se non conosci [Opscode Chef](http://www.opscode.com/chef/), leggi [Libri di ricette e ricette](workingcookbook.md).

**Nota**  
OpsWorks Stacks include un [livello Java App Server](layers-java.md) completo per l'uso in produzione. Lo scopo del libro di ricette Tomcat è illustrare come implementare livelli personalizzati, pertanto supporta solo una versione limitata di Tomcat, che non include caratteristiche come il protocollo SSL. Per ottenere un esempio di implementazione completa, consulta il libro di ricette [opsworks\$1java](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.10/opsworks_java) integrato.

Il libro di ricette Tomcat supporta un livello personalizzato le cui istanze presentano le seguenti caratteristiche:
+ Supportano un server di applicazioni Java Tomcat con un front-end Apache.
+ Tomcat è configurato per consentire alle applicazioni di utilizzare un `DataSource` oggetto JDBC per connettersi a un'istanza MySQL separata, che funge da archivio dati di backend.

Il libro di ricette per questo progetto coinvolge diversi componenti chiave:
+ Il [file di attributi](create-custom-attributes.md) contiene impostazioni di configurazione utilizzate dalle diverse ricette.
+ Le [ricette di impostazione](create-custom-setup.md) sono assegnate all'[evento del ciclo di vita](workingcookbook-events.md) Setup del livello. Vengono eseguite dopo l'avvio di un'istanza ed eseguono attività quali l'installazione di pacchetti e la creazione di file di configurazione.
+ Le [ricette di configurazione](create-custom-configure.md) sono assegnate all'evento del ciclo di vita Configure del livello. Vengono eseguiti dopo le modifiche alla configurazione dello stack, principalmente quando le istanze sono online o offline, e gestiscono tutte le modifiche di configurazione richieste.
+ Le [ricette di ditribuzione](create-custom-deploy.md) sono assegnate all'evento del ciclo di vita Deploy del livello. Vengono eseguite dopo le ricette di impostazione e quando distribuisci manualmente un'app per installare il codice e i file correlati nelle istanze di un livello e per gestire le attività correlate, come il riavvio dei servizi.

La sezione finale descrive come creare uno stack che includa un livello personalizzato basato sul ricettario Tomcat e come distribuire ed eseguire una semplice applicazione JSP che visualizza i dati da un database MySQL in esecuzione su un'istanza che appartiene a un livello MySQL separato. [Creare uno stack ed eseguire un'applicazione](create-custom-stack.md)

**Nota**  
Le ricette del ricettario Tomcat dipendono da alcune ricette integrate in Stacks. OpsWorks Affinché l'origine di ogni ricetta sia chiara, questo argomento identifica ricette utilizzando la convenzione di Chef *1cookbookname*::*recipename*.

**Topics**
+ [File di attributi](create-custom-attributes.md)
+ [Ricette di impostazione](create-custom-setup.md)
+ [Ricette di configurazione](create-custom-configure.md)
+ [Ricette di ditribuzione](create-custom-deploy.md)
+ [Creare uno stack ed eseguire un'applicazione](create-custom-stack.md)

# File di attributi
<a name="create-custom-attributes"></a>

**Importante**  
Il AWS OpsWorks Stacks 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 Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support).

Prima di approfondire le ricette, è utile esaminare il file di attributi del libro di ricette Tomcat, che contiene diverse impostazioni di configurazione utilizzate dalle ricette. Gli attributi non sono necessari. Puoi semplicemente impostare come hardcoded tali valori nelle tue ricette o nei tuoi modelli. Tuttavia, se definisci le impostazioni di configurazione utilizzando gli attributi, puoi utilizzare la console o l'API OpsWorks Stacks per modificare i valori definendo attributi JSON personalizzati, un'operazione più semplice e flessibile rispetto alla riscrittura della ricetta o del codice del modello ogni volta che desideri modificare un'impostazione. Tale approccio ti consente, ad esempio, di utilizzare lo stesso libro di ricette per più stack, ma presuppone una diversa configurazione del server Tomcat per ogni stack. Per ulteriori informazioni sugli attributi e su come sostituirli, consulta [Sostituzione degli attributi](workingcookbook-attributes.md).

L'esempio seguente mostra il file degli attributi completo `default.rb`, presente nella directory `attributes` del libro di ricette Tomcat.

```
default['tomcat']['base_version'] = 6
default['tomcat']['port'] = 8080
default['tomcat']['secure_port'] = 8443
default['tomcat']['ajp_port'] = 8009
default['tomcat']['shutdown_port'] = 8005
default['tomcat']['uri_encoding'] = 'UTF-8'
default['tomcat']['unpack_wars'] = true
default['tomcat']['auto_deploy'] = true
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['java_opts'] = ''
when 'debian', 'ubuntu'
  default['tomcat']['java_opts'] = '-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC'
end
default['tomcat']['catalina_base_dir'] = "/etc/tomcat#{node['tomcat']['base_version']}"
default['tomcat']['webapps_base_dir'] = "/var/lib/tomcat#{node['tomcat']['base_version']}/webapps"
default['tomcat']['lib_dir'] = "/usr/share/tomcat#{node['tomcat']['base_version']}/lib"
default['tomcat']['java_dir'] = '/usr/share/java'
default['tomcat']['mysql_connector_jar'] = 'mysql-connector-java.jar'
default['tomcat']['apache_tomcat_bind_mod'] = 'proxy_http' # or: 'proxy_ajp'
default['tomcat']['apache_tomcat_bind_config'] = 'tomcat_bind.conf'
default['tomcat']['apache_tomcat_bind_path'] = '/tc/'
default['tomcat']['webapps_dir_entries_to_delete'] = %w(config log public tmp)
case node[:platform]
when 'centos', 'redhat', 'fedora', 'amazon'
  default['tomcat']['user'] = 'tomcat'
  default['tomcat']['group'] = 'tomcat'
  default['tomcat']['system_env_dir'] = '/etc/sysconfig'
when 'debian', 'ubuntu'
  default['tomcat']['user'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['group'] = "tomcat#{node['tomcat']['base_version']}"
  default['tomcat']['system_env_dir'] = '/etc/default'
end
```

Le impostazioni vengono descritte più avanti nella sezione correlata. In generale, si applicano le note seguenti:
+ Poiché tutte le definizioni di nodo sono del tipo `default`, puoi sostituirle con [gli attributi JSON personalizzati](workingcookbook-json-override.md).
+ Il file utilizza un'istruzione `case` per impostare condizionalmente alcuni valori di attributi in base al sistema operativo dell'istanza.

  Il nodo `platform` è generato dallo strumento Ohai di Chef e rappresenta il sistema operativo dell'istanza. 

# Ricette di impostazione
<a name="create-custom-setup"></a>

**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 Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support).

Le ricette di impostazione sono assegnate all'evento del [ciclo di vita](workingcookbook-events.md) 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, OpsWorks Stacks esegue le [ricette Deploy per distribuire](create-custom-deploy.md) qualsiasi app nella nuova istanza.

**Topics**
+ [tomcat::setup](#create-custom-setup-setup)
+ [tomcat::install](#create-custom-setup-install)
+ [tomcat::service](#create-custom-setup-service)
+ [tomcat::container\$1config](#create-custom-setup-config)
+ [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind)

## tomcat::setup
<a name="create-custom-setup-setup"></a>

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](#create-custom-setup-install) installa il pacchetto del server Tomcat.
+ La ricetta [tomcat::service](#create-custom-setup-service) configura il servizio Tomcat.

La parte centrale di `tomcat::setup` abilita e avvia il servizio Tomcat:
+ La [risorsa del servizio](https://docs.chef.io/chef/resources.html#service) Chef abilita il servizio Tomcat all'avvio.
+ La [risorsa Chef bash](https://docs.chef.io/chef/resources.html#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](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html) (per Amazon Linux) o [Autofs](https://help.ubuntu.com/community/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\$1config](#create-custom-setup-config) crea file di configurazione.
+ La `apache2` ricetta (abbreviazione di) è una ricetta integrata di Stacks che installa e configura un `apache2::default` OpsWorks server Apache.
+ La ricetta [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-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](create-custom-deploy.md).

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](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/apache2).

## tomcat::install
<a name="create-custom-setup-install"></a>

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.

1. Installa ogni pacchetto nell'elenco.

   La [risorsa del pacchetto](https://docs.chef.io/chef/resources.html#id146) 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.

1. Utilizza una [risorsa link](https://docs.chef.io/chef/resources.html#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](workingstacks-edit.md) 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](workingcookbook-attributes.md).

## tomcat::service
<a name="create-custom-setup-service"></a>

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](https://docs.chef.io/chef/resources.html#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, OpsWorks Stacks avvia un'esecuzione [Chef per eseguire](https://docs.chef.io/chef_client_overview.html#the-chef-client-run) 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\$1config
<a name="create-custom-setup-config"></a>

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](https://docs.chef.io/chef/resources.html#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
<a name="create-custom-setup-config-env"></a>

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](http://docs.chef.io/templates.html#file-specificity).

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\$1OPTS 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](create-custom-stack.md#create-custom-stack-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\$1version'] 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](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html).
+ 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](workingcookbook-attributes.md).

Per completare i file modello, consulta il [codice sorgente](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

### File di configurazione Server.xml
<a name="create-custom-setup-config-server"></a>

La seconda `template` risorsa viene utilizzata `server.xml.erb` per creare il [file di `system.xml` configurazione](http://tomcat.apache.org/tomcat-7.0-doc/config/), che configura il contenitore. servlet/JSP `server.xml.erb`non contiene impostazioni specifiche del sistema operativo, quindi si trova nella `template` sottodirectory della directory. `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 hardcoded affinché tu possa facilmente modificare le impostazioni mediante la definizione di attributi JSON personalizzati. 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](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

## tomcat::apache\$1tomcat\$1bind
<a name="create-custom-setup-bind"></a>

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\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) 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: 
+ HTTP: `proxy_http`
+ [ JServ Protocollo Apache](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) (AJP): `proxy_ajp`

  AJP è un protocollo di Tomcat interno.

Entrambe le [risorse execute](https://docs.chef.io/chef/resources.html#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 di OpsWorks Stacks che definisce il servizio Apache. Per ulteriori informazioni, consulta la [ricetta nel repository](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb) 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 [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse)direttive [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass)and 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.

# Ricette di configurazione
<a name="create-custom-configure"></a>

**Importante**  
Il AWS OpsWorks Stacks 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 Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support).

Le ricette di configurazione sono assegnate all'evento del [ciclo di vita](workingcookbook-events.md) Configure del livello, che si verifica su tutte le istanze dello stack ogni volta che un'istanza entra o esce dallo stato online. Puoi utilizzare le ricette di configurazione per regolare la configurazione di un'istanza in modo da rispondere alla modifica in maniera appropriata. Quando implementi una ricetta Configure, tieni presente che la modifica della configurazione di uno stack potrebbe coinvolgere istanze che non hanno nulla a che fare con questo livello. La ricetta deve essere in grado di rispondere in modo appropriato, che in alcuni casi potrebbe significare non fare nulla.

## tomcat::configure
<a name="create-custom-configure-configure"></a>

La ricetta `tomcat::configure` è destinata a un evento del ciclo di vita Configure del livello.

```
include_recipe 'tomcat::context'
# Optional: Trigger a Tomcat restart in case of a configure event, if relevant
# settings in custom JSON have changed (e.g. java_opts/JAVA_OPTS):
#include_recipe 'tomcat::container_config'
```

La ricetta `tomcat::configure` è fondamentalmente un meta-ricetta che esegue due ricette dipendenti.

1. La ricetta `tomcat::context` crea un file di configurazione del contesto dell'app Web.

   Questo file configura le risorse JDBC che le applicazioni utilizzano per comunicare con l'istanza MySQL, come illustrato nella sezione successiva. Eseguire questa ricetta in risposta a un evento di configurazione consente al livello di aggiornare il file di configurazione del contesto dell'app Web se il livello del database è stato modificato.

1. La ricetta Setup `tomcat::container_config` viene eseguita nuovamente per acquisire eventuali modifiche apportate alla configurazione del container.

In questo esempio viene commentato `include` per `tomcat::container_config`. Se desideri utilizzare un JSON personalizzato per modificare le impostazioni di Tomcat, puoi rimuovere il commento. Un evento del ciclo di vita Configure esegue quindi `tomcat::container_config`, che aggiorna i file di configurazione correlati a Tomcat, come descritto in [tomcat::container\$1config](create-custom-setup.md#create-custom-setup-config) e riavvia il servizio Tomcat.

## tomcat::context
<a name="create-custom-configure-context"></a>

[Il ricettario Tomcat consente alle applicazioni di accedere a un server di database MySQL, che può essere eseguito su un'istanza separata, utilizzando un oggetto J2EE. DataSource](http://docs.oracle.com/javase/tutorial/jdbc/basics/sqldatasources.html) Con Tomcat, puoi abilitare la connessione mediante la creazione e l'installazione di un file di configurazione del contesto dell'app Web per ogni applicazione. Questo file definisce il rapporto tra l'applicazione e la risorsa JDBC che verrà utilizzata dall'applicazione per comunicare con il database. Per maggiori informazioni, consulta [The Context Container](http://tomcat.apache.org/tomcat-7.0-doc/config/context.html).

Lo scopo primario della ricetta `tomcat::context` è creare questo file di configurazione.

```
include_recipe 'tomcat::service'

node[:deploy].each do |application, deploy|
  context_name = deploy[:document_root].blank? ? application : deploy[:document_root]

  template "context file for #{application} (context name: #{context_name})" do
    path ::File.join(node['tomcat']['catalina_base_dir'], 'Catalina', 'localhost', "#{context_name}.xml")
    source 'webapp_context.xml.erb'
    owner node['tomcat']['user']
    group node['tomcat']['group']
    mode 0640
    backup false
    only_if { node['datasources'][context_name] }
    variables(:resource_name => node['datasources'][context_name], :webapp_name => application)
    notifies :restart, resources(:service => 'tomcat')
  end
end
```

Oltre agli attributi del libro di cucina Tomcat, questa ricetta utilizza gli attributi di [configurazione e distribuzione dello stack che Stacks installa](workingcookbook-json.md) con l'evento Configure. OpsWorks Il servizio OpsWorks Stacks aggiunge attributi all'oggetto nodo di ogni istanza che contengono le informazioni che le ricette in genere otterrebbero utilizzando i data bag o la ricerca e installa gli attributi su ogni istanza. Gli attributi contengono informazioni dettagliate sulla configurazione dello stack, sulle app distribuite e sui dati personalizzati che un utente desidera includere. Le ricette possono ottenere dati da attributi di configurazione e di distribuzione dello stack utilizzando una sintassi del nodo Chef standard. Per ulteriori informazioni, consulta [Attributi di configurazione e distribuzione dello stack](workingcookbook-json.md). Con gli stack Chef 11.10, puoi usare la ricerca Chef per ottenere i dati di configurazione e distribuzione dello stack. Per ulteriori informazioni, consulta [Utilizzo della ricerca di Chef](workingcookbook-chef11-10.md#workingcookbook-chef11-10-search).

`deploy`attributes si riferisce allo spazio dei `[:deploy]` nomi, che contiene gli attributi relativi alla distribuzione definiti tramite la console o l'API o generati dal servizio Stacks. OpsWorks L'attributo `deploy` include un attributo per ogni app distribuita, denominata con il nome breve dell'app. Ogni attributo di app contiene un set di attributi che caratterizzano l'app, ad esempio la radice del documento (`[:deploy][:appname][:document_root]`).

La ricetta `context` innanzitutto assicura che il servizio viene definito per questa esecuzione Chef chiamando [tomcat::service](create-custom-setup.md#create-custom-setup-service). Quindi definisce una variabile `context_name` che rappresenta il nome del file di configurazione, esclusa l'estensione `.xml`. Se utilizzi la radice del documento predefinita, `context_name` viene impostato sul nome breve dell'app. In alternativa, viene impostato sulla radice del documento specificato. L'esempio illustrato in [Creare uno stack ed eseguire un'applicazione](create-custom-stack.md) imposta la radice del documento su `"ROOT"`, pertanto il contesto è ROOT e il file di configurazione viene denominato `ROOT.xml`.

Il blocco principale della ricetta scorre l'elenco delle app distribuite e, per ogni app, usa il modello `webapp_context.xml.erb` per creare un file di configurazione del contesto. L'esempio distribuisce solo un'app, ma la definizione dell'attributo `deploy` richiede di trattarla come un elenco di applicazioni.

Il modello `webapp_context.xml.erb` non è specifico del sistema operativo, pertanto si trova nella sottodirectory `templates` della directory `default`.

La ricetta crea il file di configurazione come segue:
+ Grazie a valori di attributo predefiniti, il nome del file di configurazione viene impostato su `context_name.xml` e installato nella directory `/etc/tomcat6/Catalina/localhost/`. 

  Il nodo `['datasources']` degli attributi di configurazione dello stack contiene uno o più attributi, ciascuno dei quali mappa un nome di contesto alla risorsa di dati JDBC che l'applicazione associata utilizzerà per comunicare con il database. Il nodo e i relativi contenuti vengono definiti con un JSON personalizzato al momento della creazione dello stack, come descritto di seguito in [Creare uno stack ed eseguire un'applicazione](create-custom-stack.md). L'esempio dispone di un singolo attributo che associa il nome di contesto ROOT a una risorsa JDBC denominata jdbc/mydb.
+ Mediante l'utilizzo di valori di attributo predefiniti, il gruppo e l'utente del file sono entrambi impostati sui valori definiti dal pacchetto Tomcat: `tomcat` (Amazon Linux) o `tomcat6` (Ubuntu).
+ La risorsa `template` crea il file di configurazione solo se il nodo `['datasources']` esiste e include un attributo `context_name`.
+ La risorsa `template` definisce due variabili: `resource_name` e `webapp_name`.

  `resource_name` è impostato sul nome di risorsa associato a `context_name` mentre `webapp_name` è impostato sul nome breve dell'app.
+ La risorsa modello riavvia il servizio Tomcat per caricare e attivare le modifiche.

Il modello `webapp_context.xml.erb` è costituito da un elemento `Context` che contiene un elemento `Resource` con il relativo set di attributi.

Gli attributi caratterizzano la configurazione del contesto: `Resource`
+ **name**: il nome della risorsa JDBC, impostato sul `resource_name` valore definito in. `tomcat::context`

  Ad esempio, il nome della risorsa è impostato su jdbc/mydb.
+ **auth** e **type**: si tratta di impostazioni standard per le connessioni JDBC. `DataSource`
+ **MaxActive**, **MaxIdle** e **MaxWait: il numero massimo di connessioni attive e inattive e il tempo di attesa** massimo per la restituzione di una connessione.
+ **nome utente** e **password**: nome utente e password root del database, ottenuti dagli attributi. `deploy`
+ **driverClassName**—Il nome della classe del driver JDBC, impostato sul driver MySQL.
+ **url: l'URL di connessione.**

  Il prefisso dipende dal database. Deve essere impostato su `jdbc:mysql` per MySQL, su `jdbc:postgresql` per Postgres e su `jdbc:sqlserver` per SQL Server. L'esempio imposta l'URL su`jdbc:mysql://host_IP_Address:3306:simplejsp`, where *simplejsp* è il nome breve dell'app.
+ **factory**: la `DataSource` fabbrica, necessaria per i database MySQL.

[Per ulteriori informazioni su questo file di configurazione, consulta l'argomento Utilizzo del wiki di Tomcat. DataSources](http://wiki.apache.org/tomcat/UsingDataSources)

# Ricette di ditribuzione
<a name="create-custom-deploy"></a>

**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 Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support).

Le ricette di ditribuzione sono assegnate all'evento del [ciclo di vita](workingcookbook-events.md) Deploy del livello. In genere si verifica su tutte le istanze dello stack ogni volta che si distribuisce un'app, sebbene sia possibile facoltativamente limitare l'evento solo a istanze specifiche. OpsWorks Stacks esegue anche le ricette Deploy su nuove istanze, dopo il completamento delle ricette di installazione. Lo scopo primario delle ricette di ditribuzione è distribuire codice e file correlati da un repository alle istanze del livello del server di applicazioni. Tuttavia, esegui spesso ricette di ditribuzione anche su altri livelli. Questo consente alle istanze di tali livelli, ad esempio, di aggiornare la propria configurazione per includere l'app appena distribuita. Quando implementi una ricetta Deploy, ricorda che un evento Deploy non significa necessariamente che le app vengono distribuite nell'istanza. Potrebbe trattarsi semplicemente di una notifica del fatto che le app vengono distribuite in altre istanze dello stack per consentire all'istanza di effettuare gli aggiornamenti necessari. La ricetta deve essere in grado di rispondere in modo appropriato, che potrebbe significare anche non fare nulla.

OpsWorks Stacks distribuisce automaticamente le app dei tipi di app standard nei corrispondenti livelli di server di applicazioni integrati. Per distribuire app in un livello personalizzato, devi implementare ricette di ditribuzione personalizzate che eseguono il download dei file dell'app da un repository nel percorso appropriato sull'istanza. Tuttavia, spesso puoi limitare la quantità di codice che devi scrivere utilizzando il [libro di ricette di ditribuzione](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy) integrato per gestire alcuni aspetti della distribuzione. Ad esempio, se archivi i tuoi file in uno dei repository supportati, il libro di ricette integrato può gestire i dettagli del download dei file dal repository nelle istanze del livello. 

La ricetta `tomcat::deploy` è concepita per essere assegnata all'evento del ciclo di vita Deploy.

```
include_recipe 'deploy'

node[:deploy].each do |application, deploy|
  opsworks_deploy_dir do
    user deploy[:user]
    group deploy[:group]
    path deploy[:deploy_to]
  end

  opsworks_deploy do
    deploy_data deploy
    app application
  end
...
```

La ricetta `tomcat::deploy` utilizza il libro di ricette di ditribuzione integrato per aspetti della distribuzione che non sono specifici dell'applicazione. La ricetta `deploy` (forma abbreviata per la ricetta `deploy::default` integrata) è una ricetta integrata che gestisce i dettagli di configurazione di utenti, gruppi e così via, in base ai dati degli attributi `deploy`.

La ricetta usa due definizioni Chef integrate, `opsworks_deploy_dir` e `opworks_deploy`, per installare l'applicazione. 

La definizione `opsworks_deploy_dir` configura la struttura della directory in base ai dati del JSON di distribuzione dell'app. Le definizioni sono molto utili per creare un pacchetto con le definizioni delle risorse e si trovano nella directory `definitions` di un libro di ricette. Le ricette possono utilizzare le definizioni in modo analogo alle risorse, tuttavia la definizione stessa non ha un provider associato, ma solo le risorse incluse nella definizione. Puoi definire variabili nella ricetta, che vengono passate alle definizioni di risorse sottostanti. La ricetta `tomcat::deploy` imposta le variabili `user`, `group` e `path` in base ai dati del JSON di distribuzione. Questi vengono passati alla [risorsa di directory](https://docs.chef.io/chef/resources.html#directory) della definizione, che gestisce le directory. 

**Nota**  
L'utente e il gruppo dell'app distribuita sono determinati dagli `[:opsworks][:deploy_user][:group]` attributi `[:opsworks][:deploy_user][:user]` e, definiti nel file degli attributi del [cookbook di deploy integrato](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb). `deploy.rb` Il valore predefinito di `[:opsworks][:deploy_user][:user]` è `deploy`. Il valore predefinito di `[:opsworks][:deploy_user][:group]` dipende dal sistema operativo dell'istanza:  
Per le istanze Ubuntu, il gruppo predefinito è `www-data`.
Per le istanze Amazon Linux che sono membri di un livello Rails App Server che utilizza Nginx e Unicorn, il gruppo predefinito è. `nginx`
Per tutte le altre istanze Amazon Linux, il gruppo predefinito è `apache`.
Puoi modificare le impostazioni utilizzando un JSON personalizzato o un file di attributi personalizzato per sostituire l'attributo appropriato. Per ulteriori informazioni, consulta [Sostituzione degli attributi](workingcookbook-attributes.md).

L'altra definizione, `opsworks_deploy`, gestisce i dettagli di verifica del codice dell'app e dei file correlati del repository e della loro distribuzione nell'istanza, in base ai dati degli attributi `deploy`. Puoi utilizzare questa definizione per qualsiasi tipo di app. I dettagli di distribuzione, come i nomi di directory, sono specificati nella console o tramite l'API e inseriti negli attributi `deploy`. Tuttavia, `opsworks_deploy` funziona solo per i quattro [tipi di repository supportati](workingcookbook-installingcustom-repo.md): Git, Subversion, S3 e HTTP. Se desideri utilizzare un altro tipo di repository, devi implementare personalmente questo codice.

Installi file di un'app nella directory `webapps` di Tomcat. Una procedura classica consiste nel copiare i file direttamente in `webapps`. Tuttavia, la distribuzione di OpsWorks Stacks è progettata per conservare fino a cinque versioni di un'app su un'istanza, quindi puoi tornare a una versione precedente se necessario. OpsWorks Stacks esegue quindi le seguenti operazioni:

1. Distribuisce app in una directory distinta il cui nome include un timestamp, come `/srv/www/my_1st_jsp/releases/20130731141527`.

1. Crea un collegamento simbolico denominato `current`, ad esempio `/srv/www/my_1st_jsp/current`, a questa directory univoca.

1. Se non esiste già, crea un collegamento simbolico dalla directory `webapps` al collegamento simbolico `current` creato al Passaggio 2.

Se devi eseguire il rollback a una versione precedente, modifica il collegamento simbolico `current` in modo che punti a una directory distinta contenente il timestamp appropriato modificando, ad esempio, la destinazione del collegamento di `/srv/www/my_1st_jsp/current`.

La sezione centrale di `tomcat::deploy` configura il collegamento simbolico. 

```
  ...
  current_dir = ::File.join(deploy[:deploy_to], 'current')
  webapp_dir = ::File.join(node['tomcat']['webapps_base_dir'], deploy[:document_root].blank? ? application : deploy[:document_root])

  # opsworks_deploy creates some stub dirs, which are not needed for typical webapps
  ruby_block "remove unnecessary directory entries in #{current_dir}" do
    block do
      node['tomcat']['webapps_dir_entries_to_delete'].each do |dir_entry|
        ::FileUtils.rm_rf(::File.join(current_dir, dir_entry), :secure => true)
      end
    end
  end

  link webapp_dir do
    to current_dir
    action :create
  end
  ...
```

La ricetta prima crea due variabili, `current_dir` e `webapp_dir`, per rappresentare, rispettivamente, le directory `current` e `webapp`. Quindi, utilizza una risorsa `link` per collegare `webapp_dir` a `current_dir`. La `deploy::default` ricetta OpsWorks Stacks crea alcune directory di stub che non sono necessarie per questo esempio, quindi la parte centrale dell'estratto le rimuove.

La parte finale di `tomcat::deploy` riavvia il servizio Tomcat, se necessario.

```
  ...
  include_recipe 'tomcat::service'

  execute 'trigger tomcat service restart' do
    command '/bin/true'
    not_if { node['tomcat']['auto_deploy'].to_s == 'true' }
    notifies :restart, resources(:service => 'tomcat')
  end
end

include_recipe 'tomcat::context'
```

La ricetta innanzitutto esegue `tomcat::service` per garantire che il servizio venga definito per questa esecuzione di Chef. Quindi, utilizza una [risorsa execute](https://docs.chef.io/chef/resources.html#execute) per notificare il riavvio al servizio, ma solo se `['tomcat']['auto_deploy']` è impostato su `'true'`. In alternativa, Tomcat ascolta le modifiche nella propria directory `webapps`, che rende superfluo un riavvio esplicito del servizio Tomcat. 

**Nota**  
La risorsa `execute` non esegue effettivamente niente di sostanziale. `/bin/true` è uno script di shell fittizio che restituisce semplicemente un codice di successo. Qui è utilizzato semplicemente come un metodo utile per generare una notifica di riavvio. Come accennato in precedenza, l'utilizzo di notifiche garantisce che i servizi non vengano riavviati troppo frequentemente.

Infine, `tomcat::deploy` esegue `tomcat::context`, che aggiorna il file di configurazione del contesto dell'app Web se hai modificato il database di back-end. 

# Creare uno stack ed eseguire un'applicazione
<a name="create-custom-stack"></a>

**Importante**  
Il AWS OpsWorks Stacks 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 Supporto AWS Team su [AWS re:post](https://repost.aws/) o tramite Premium [AWS Support](https://aws.amazon.com/support).

In questa sezione viene illustrato come utilizzare il libro di ricette Tomcat per implementare una configurazione di base dello stack che esegue una semplice applicazione Java Server Pages (JSP) denominata SimpleJSP. Lo stack è costituito da un livello personalizzato basato su Tomcat denominato e da TomCustom un livello MySQL. SimpleJSP viene distribuito TomCustom e visualizza alcune informazioni dal database MySQL. Se non hai già familiarità con le nozioni di base su come usare OpsWorks Stacks, dovresti prima leggere. [Nozioni di base sugli stack Linux Chef 11](gettingstarted.md)

## Applicazione SimpleJSP
<a name="create-custom-stack-jsp"></a>

L'applicazione SimpleJSP illustra le basi della configurazione di una connessione di database e del recupero di dati dal database MySQL dello stack.

```
<html>
  <head>
    <title>DB Access</title>
  </head>
  <body>
    <%@ page language="java" import="java.sql.*,javax.naming.*,javax.sql.*" %>
    <%
      StringBuffer output = new StringBuffer();
      DataSource ds = null;
      Connection con = null;
      Statement stmt = null;
      ResultSet rs = null;
      try {
        Context initCtx = new InitialContext();
        ds = (DataSource) initCtx.lookup("java:comp/env/jdbc/mydb");
        con = ds.getConnection();
        output.append("Databases found:<br>");
        stmt = con.createStatement();
        rs = stmt.executeQuery("show databases");
        while (rs.next()) {
          output.append(rs.getString(1));
          output.append("<br>");
        }
      }
      catch (Exception e) {
        output.append("Exception: ");
        output.append(e.getMessage());
        output.append("<br>");
      }
      finally {
        try {
          if (rs != null) {
            rs.close();
          }
          if (stmt != null) {
            stmt.close();
          }
          if (con != null) {
            con.close();
          }
        }
        catch (Exception e) {
          output.append("Exception (during close of connection): ");
          output.append(e.getMessage());
          output.append("<br>");
        }
      }
    %>
    <%= output.toString() %>
  </body>
</html>
```

SimpleJSP utilizza un oggetto `DataSource` per comunicare con il database MySQL. Tomcat usa i dati nel [file di configurazione del contesto dell'app Web](create-custom-configure.md#create-custom-configure-context) per creare e inizializzare un oggetto `DataSource` e associarlo a un nome logico. Quindi, registra il nome logico con un servizio di denominazione JNDI (Java Naming and Directory Interface). Per ottenere un'istanza dell'oggetto `DataSource` appropriato, devi creare un oggetto `InitialContext` e passare il nome logico della risorsa al metodo `lookup` dell'oggetto, che recupera l'oggetto appropriato. Il nome logico dell'esempio SimpleJSP, `java:comp/env/jdbc/mydb`, ha i seguenti componenti:
+ Lo spazio dei nomi radice, `java`, che è separato dal resto del nome da due punti (:). 
+ Eventuali spazi dei nomi aggiuntivi, separati da barre (/).

  Tomcat aggiunge automaticamente le risorse allo spazio dei nomi `comp/env`.
+ Il nome della risorsa, definito nel file di configurazione del contesto dell'app Web e separato dagli spazi dei nomi per mezzo di una barra.

  In questo esempio il nome della risorsa è `jdbc/mydb`. 

Per stabilire una connessione al database, SimpleJSP esegue le seguenti operazioni:

1. Chiama il metodo `DataSource` dell'oggetto `getConnection`, che restituisce un oggetto `Connection`.

1. Chiama il metodo `Connection` dell'oggetto `createStatement` per creare un oggetto `Statement`, che puoi utilizzare per comunicare con il database.

1. Comunica con il database chiamando il metodo `Statement` appropriato.

   SimpleJSP chiama `executeQuery` per eseguire una query SHOW DATABASES, che elenca i database del server.

Il metodo `executeQuery` restituisce un oggetto `ResultSet`, che contiene i risultati delle query. SimpleJSP ottiene i nomi dei database dall'oggetto `ResultSet` restituito e li concatena per creare una stringa di output. Infine, l'esempio chiude gli oggetti `ResultSet`, `Statement` e `Connection`. [Per ulteriori informazioni su JSP e JDBC, vedere rispettivamente [JavaServer Pages Technology](http://docs.oracle.com/javaee/5/tutorial/doc/bnagx.html) e JDBC Basics.](http://docs.oracle.com/javase/tutorial/jdbc/basics/)

Per usare SimpleJSP con uno stack, devi inserirlo in un repository. Puoi utilizzare uno qualsiasi dei repository supportati, ma per utilizzare SimpleJSP con lo stack di esempio illustrato nella sezione seguente, devi inserirlo in un archivio S3 pubblico. Per informazioni su come utilizzare gli altri repository standard, consulta [Repository dei libri di ricette](workingcookbook-installingcustom-repo.md).

**Per inserire SimpleJSP in un repository di archiviazione S3**

1. Copiare il codice di esempio in un file denominato `simplejsp.jsp` e inserire il file in una directory denominata `simplejsp`.

1. Creare un archivio `.zip` della directory `simplejsp`.

1. Crea un bucket Amazon S3 pubblico, caricalo `simplejsp.zip` nel bucket e rendi pubblico il file.

   Per sapere come eseguire questa attività, consulta [Nozioni di base su Amazon Simple Storage Service](https://docs.aws.amazon.com/AmazonS3/latest/gsg/GetStartedWithS3.html).

## Creare uno stack
<a name="create-custom-stack-stack"></a>

Per eseguire SimpleJSP hai bisogno di uno stack con i seguenti livelli.
+ Un livello MySQL, che supporta il server MySQL di back-end.
+ Un livello personalizzato che utilizza il libro di ricette Tomcat per supportare istanze server Tomcat.

**Per creare lo stack**

1. Nella dashboard OpsWorks Stacks, fai clic su **Aggiungi stack per creare un nuovo stack** e fai clic su **Avanzato** >> per visualizzare tutte le opzioni. Configurare lo stack come segue.
   + **Nome: un nome** di stack definito dall'utente; in questo esempio viene utilizzato. TomStack
   + **Usa libri di cucina personalizzati per Chef**: imposta l'interruttore su **Sì**, che mostra alcune opzioni aggiuntive.
   + **Tipo di repository** —Git.
   + **URL del repository:.** `git://github.com/amazonwebservices/opsworks-example-cookbooks.git`
   + **Custom Chef JSON**: aggiungi il seguente JSON:

     ```
     {
       "tomcat": {
         "base_version": 7,
         "java_opts": "-Djava.awt.headless=true -Xmx256m"
       },
       "datasources": {
         "ROOT": "jdbc/mydb"
       }
     }
     ```

   Per le opzioni rimanenti, puoi accettare le impostazioni predefinite.

   Il JSON personalizzato esegue le operazioni seguenti:
   + Ignora l'attributo `['base_version']` del libro di ricette Tomcat per impostare la versione di Tomcat su 7. Il valore predefinito è 6.
   + Ignora l'attributo `['java_opts']` del libro di ricette Tomcat per specificare che l'istanza è headless e impostare la dimensione heap massima di JVM su 256 MB. Il valore predefinito non prevede l'impostazione di opzioni per le istanze che eseguono Amazon Linux.
   + Specifica il valore dell'attributo `['datasources]`, che assegna un nome di risorsa JDBC (jdbc/mydb) al nome del contesto dell'app Web (ROOT), come descritto in [tomcat::context](create-custom-configure.md#create-custom-configure-context).

     Quest'ultimo attributo non dispone di un valore predefinito, pertanto devi impostarlo con un JSON personalizzato.  
![\[Configuration Management interface showing Chef version options and custom JSON input field.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/tom_add_stack.png)

1. Fare clic su **Add a layer (Aggiungi un livello)**. Per **Layer type (Tipo di livello)**, selezionare **MySQL**. Quindi, fare clic su **Add Layer (Aggiungi livello)**.

1. Fare clic su **Instances (Istanze)** nel riquadro di navigazione, quindi fare clic su **Add an instance (Aggiungi un'istanza)**. Fare clic su **Add Instance (Aggiungi istanza)** per accettare le impostazioni predefinite. Sulla riga dell'istanza, fare clic su **start (avvia)**.

1. Tornare alla pagina **Layers (Livelli)** e fare clic su **\$1 Layer (\$1 Livello)** per aggiungere un livello. Per **Layer type (Tipo di livello)**, fare clic su **Custom (Personalizzato)**. L'esempio utilizza **TomCustom** e **tomcustom**, rispettivamente, come nome e nome abbreviato del livello.  
![\[Add Layer form with Custom layer type, Name, and Short name fields for creating a customized layer.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/tom_add_custom_layer.png)

1. Nella pagina **Layers (Livelli)**, per il livello personalizzato, fare clic su **Recipes (Ricette)**, quindi fare clic su **Edit (Modifica)**. In **Custom Chef Recipes (Ricette Chef personalizzate)**, assegnare le ricette del libro di ricette Tomcat agli eventi del ciclo di vita del livello, nel modo seguente:
   + Per **Setup (Installazione)**, digitare **tomcat::setup** e fare clic su **\$1**.
   + Per **Configure (Configurazione)**, digitare **tomcat::configure** e fare clic su **\$1**.
   + Per **Deploy (Distribuzione)**, digitare **tomcat::deploy** e fare clic su **\$1**. Quindi, fare clic su **Save (Salva)**.

     .  
![\[Custom Chef Recipes interface showing setup, configure, and deploy steps with options.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/tom_events.png)

1. Fare clic su **Apps (App)** nel riquadro di navigazione, quindi fare clic su **Add an app (Aggiungi un'app)**. Specificare le seguenti opzioni e fare clic su **Add App (Aggiungi app)**:
   + **Nome**: il nome dell'app; l'esempio utilizza SimpleJSP e il nome breve generato da Stacks sarà simplejsp. OpsWorks 
   + **Tipo di app****: imposta questa opzione su Altro.**

     OpsWorks Stacks distribuisce automaticamente i tipi di app standard nelle istanze del server associate. Se si imposta **App type (Tipo di app)** su un'opzione diversa, OpsWorks Stacks esegue semplicemente le ricette di distribuzione e consente loro di gestire la distribuzione.
   + **Document root**: imposta questa opzione su. **ROOT**

     Il valore **Document root (Radice documento)** specifica il nome del contesto.
   + **Tipo di repository****: imposta questa opzione su S3 Archive.**
   + **URL del repository**: imposta questo valore sull'URL Amazon S3 dell'app che hai creato in precedenza.

   Utilizzare le impostazioni predefinite per le altre opzioni.  
![\[Application settings form with fields for name, app type, document root, and source details.\]](http://docs.aws.amazon.com/it_it/opsworks/latest/userguide/images/tom_app.png)

1. Utilizza la pagina **Istanze** per aggiungere un'istanza al TomCustom layer e avviarla. OpsWorks Stacks esegue automaticamente le ricette Deploy su una nuova istanza al termine delle ricette di installazione, quindi l'avvio dell'istanza distribuisce anche SimpleJSP.

1. Quando l' TomCustom istanza è online, fai clic sul nome dell'istanza nella pagina **Istanze per visualizzarne i dettagli.** Copiare l'indirizzo IP pubblico. Quindi costruisci un URL come segue: http://*publicIP*/tc/. *appname.jsp* Ad esempio, l'URL sarà simile al seguente: **http://50.218.191.172/tc/simplejsp.jsp**.
**Nota**  
L'URL Apache che inoltra le richieste a Tomcat è impostato sull'attributo `['tomcat']['apache_tomcat_bind_path']` predefinito, `/tc/`. La radice del documento SimpleJSP è impostata su `ROOT`, un valore speciale che si risolve su `/`. L'URL è quindi ".../tc/simplejsp.jsp".

1. Incollare nel browser l'URL copiato al passaggio precedente. Verrà visualizzato un codice analogo al seguente:

   ```
   Databases found:
   information_schema
   simplejsp
   test
   ```
**Nota**  
Se il tuo stack ha un'istanza MySQL OpsWorks , Stacks crea automaticamente un database per ogni app, denominato con il nome breve dell'app.