

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

# Recetas de instalación
<a name="create-custom-setup"></a>

**importante**  
El AWS OpsWorks Stacks servicio finalizó su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en [AWS Re:post](https://repost.aws/) o a través de Premium [AWS Support](https://aws.amazon.com/support).

Las recetas de instalación se asignan al evento Setup del [ciclo de vida](workingcookbook-events.md) de la capa y se ejecutan después de que se arranca una instancia. Realizan tareas como instalar paquetes, crear los archivos de configuración e iniciar servicios. Cuando terminen de ejecutarse las recetas de configuración, OpsWorks Stacks ejecuta las [recetas de implementación](create-custom-deploy.md) para implementar cualquier aplicación en la nueva instancia.

**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 receta `tomcat::setup` se asignará a un evento Setup del ciclo de vida de la capa.

```
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 receta `tomcat::setup` es, en gran medida, una metarreceta. Incluye un conjunto de recetas dependientes que controlan la mayoría de los detalles de instalación y configuración de Tomcat y los paquetes relacionados. La primera parte de `tomcat::setup` ejecuta las siguientes recetas, que se tratarán más adelante: 
+ La receta [tomcat::install](#create-custom-setup-install) instala el paquete del servidor Tomcat.
+ La receta [tomcat::service](#create-custom-setup-service) configura el servicio de Tomcat.

La parte central de `tomcat::setup` habilita e inicia el servicio de Tomcat:
+ El [recurso de servicio](https://docs.chef.io/chef/resources.html#service) de Chef habilita el servicio de Tomcat en el arranque.
+ El [recurso bash](https://docs.chef.io/chef/resources.html#bash) de Chef ejecuta un script de Bash para iniciar el daemon autofs, necesario para las instancias respaldadas por Amazon EBS. El recurso, a continuación, notifica al recurso `service` que reinicie el servicio de Tomcat.

  Para obtener más información, consulte: [autofs](https://access.redhat.com/site/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Storage_Administration_Guide/s2-nfs-config-autofs.html) (para Amazon Linux) o [Autofs](https://help.ubuntu.com/community/Autofs) (para Ubuntu).

La última parte de `tomcat::setup` crea archivos de configuración, e instala y configura el servidor front-end de Apache:
+ La receta [tomcat::container\$1config](#create-custom-setup-config) crea los archivos de configuración.
+ La `apache2` receta (que es la abreviatura de`apache2::default`) es una receta integrada de OpsWorks Stacks que instala y configura un servidor Apache.
+ La receta [tomcat:: apache\$1tomcat\$1bind](#create-custom-setup-bind) configura el servidor Apache para que actúe como front-end para el servidor Tomcat.

**nota**  
A menudo ahorrará tiempo y esfuerzo si utiliza recetas integradas para realizar algunas de las tareas necesarias. Esta receta utiliza la receta `apache2::default` integrada para instalar Apache en lugar de implementarlo desde cero. Para ver otro ejemplo del uso de las recetas integradas, consulte [Recetas de implementación](create-custom-deploy.md).

En las siguientes secciones se describen más en detalle las recetas de configuración de los libros de recetas de Tomcat. Para obtener más información acerca de las recetas de `apache2`, consulte [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 receta `tomcat::install `instala el servidor Tomcat, el OpenJDK y una biblioteca de conectores de Java que administra la conexión con el servidor 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 receta lleva a cabo las siguientes tareas:

1. Crea una lista de paquetes que se van a instalar según el sistema operativo de la instancia.

1. Instala cada paquete de la lista.

   El [paquete de recursos](https://docs.chef.io/chef/resources.html#id146) de Chef utiliza el proveedor adecuado (`yum` para Amazon Linux y `apt-get` para Ubuntu) para controlar la instalación. Los proveedores de paquetes instalan OpenJDK como una dependencia de Tomcat, pero la biblioteca de conectores de MySQL debe instalarse de forma explícita.

1. Utiliza un [recurso de enlace](https://docs.chef.io/chef/resources.html#link) de Chef para crear un symlink en el directorio de bibliotecas del servidor Tomcat con la biblioteca de conectores de MySQL en el JDK.

   Utilizando los valores de los atributos predeterminados, el directorio de las bibliotecas de Tomcat es `/usr/share/tomcat6/lib` y la biblioteca de conectores de MySQL (`mysql-connector-java.jar`) está en `/usr/share/java/`.

La receta `tomcat::remove_root_webapp` elimina la aplicación web ROOT (`/var/lib/tomcat6/webapps/ROOT` de forma predeterminada) para evitar problemas de seguridad.

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

La declaración `only_if` garantiza que la receta elimine el archivo únicamente si existe.

**nota**  
La versión de Tomcat se especifica mediante el atributo `['tomcat']['base_version']`, que está establecido en 6 en el archivo de atributos. Para instalar Tomcat 7, utilice los atributos de JSON personalizado que anulan el atributo. Solo tiene que [editar la configuración de la pila](workingstacks-edit.md) e introducir el siguiente JSON en el cuadro **Custom Chef JSON (JSON de Chef personalizado)** o añadirlo a otro JSON personalizado existente:  

```
{
  'tomcat' : {
    'base_version' : 7
  }
}
```
El atributo de JSON personalizado anula el atributo predeterminado y establece la versión de Tomcat en 7. Para obtener más información acerca de la anulación de atributos, consulte [Anulación de atributos](workingcookbook-attributes.md).

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

La receta `tomcat::service` crea la definición de servicio de 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 receta utiliza los [recursos de servicio](https://docs.chef.io/chef/resources.html#service) de Chef para especificar el nombre del servicio de Tomcat (tomcat6, de manera predeterminada) y establece el atributo `supports` para definir el modo en que Chef controla el reinicio, la recarga y los comandos de estado del servicio en los diferentes sistemas operativos.
+ `true` indica que Chef puede utilizar el script init u otro proveedor de servicios para ejecutar el comando.
+ `false` indica que Chef debe intentar ejecutar el comando por otros medios.

Observe que `action` está establecido en `:nothing`. Para cada evento del ciclo de vida, OpsWorks Stacks inicia una ejecución de [Chef para ejecutar](https://docs.chef.io/chef_client_overview.html#the-chef-client-run) el conjunto de recetas adecuado. El libro de recetas de Tomcat sigue el mismo patrón de hacer que una receta cree la definición del servicio, pero no reinicie el servicio. Otras recetas de la ejecución de Chef controlan el reinicio, normalmente incluyendo un comando `notifies` en los recursos `template` que se utilizan para crear los archivos de configuración. Las notificaciones resultan cómodas para reiniciar un servicio, ya que solo lo hacen si la configuración ha cambiado. Además, si una ejecución de Chef tiene varias notificaciones de reinicio de un servicio, Chef lo reinicia como máximo una vez. Esta práctica evita problemas que podrían producirse si se intenta reiniciar un servicio que no está totalmente operativo, una fuente común de errores en Tomcat.

 El servicio de Tomcat debe definirse para cualquier ejecución de Chef que utilice notificaciones de reinicio. Por lo tanto, `tomcat::service` viene incluido en varias recetas para garantizar que se defina el servicio con cada ejecución de Chef. Si una ejecución de Chef incluye varias instancias de `tomcat::service`, no se produce penalización alguna, ya que Chef garantiza que la receta se ejecute solo una vez por ejecución, independientemente del número de veces que esté incluida.

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

La receta `tomcat::container_config` crea los archivos de configuración a partir de los archivos de plantilla del libro de recetas.

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

La receta llama primero a `tomcat::service`, que define el servicio si es necesario. La mayor parte de la receta consiste en dos [recursos de plantilla](https://docs.chef.io/chef/resources.html#template), cada uno de los cuales crea un archivo de configuración a partir de uno de los archivos de plantilla del libro de recetas, establece las propiedades del archivo y notifica a Chef que reinicie el servicio.

### Archivo de configuración del entorno de Tomcat
<a name="create-custom-setup-config-env"></a>

El primer recurso `template` utiliza el archivo de plantilla `tomcat_env_config.erb` para crear un archivo de configuración del entorno de Tomcat que se utiliza para definir las variables de entorno, por ejemplo `JAVA_HOME`. El nombre de archivo predeterminado es el argumento del recurso `template`. `tomcat::container_config` utiliza un atributo `path` para anular el valor predeterminado y el nombre del archivo de configuración `/etc/sysconfig/tomcat6` (Amazon Linux) o `/etc/default/tomcat6` (Ubuntu). El recurso `template` también especifica el propietario, el grupo y la configuración de modo del archivo, e indica a Chef que no cree archivos de backup.

Si examina el código fuente, verá que existen tres versiones de `tomcat_env_config.erb`, cada una en un subdirectorio diferente del directorio `templates`. Los directorios `ubuntu` y `amazon` contienen las plantillas para sus respectivos sistemas operativos. La carpeta `default` contiene una plantilla ficticia con una única línea de comentario, que se utiliza solo si se intenta ejecutar esta receta en una instancia con un sistema operativo no admitido. La receta `tomcat::container_config` no precisa especificar qué `tomcat_env_config.erb` utilizar. Chef elige automáticamente el directorio adecuado para el sistema operativo de la instancia basándose en las reglas descritas en [Especificidad de archivos](http://docs.chef.io/templates.html#file-specificity).

Los archivos `tomcat_env_config.erb` de este ejemplo se componen, en gran parte, de comentarios. Para establecer otras variables de entorno, tan solo quite el comentario de las líneas correspondientes y proporcione sus valores de preferencia.

**nota**  
Cualquier opción de configuración que pueda cambiar debe definirse como un atributo, en lugar de estar codificada en la plantilla. De esta forma, no es necesario volver a escribir la plantilla para cambiar una opción de configuración, basta con anular el atributo.

La plantilla de Amazon Linux establece una variable de entorno únicamente, tal y como se muestra en el siguiente fragmento.

```
...
# 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"
...
```

Se puede utilizar JAVA\$1OPTS para especificar opciones de Java, por ejemplo, la ruta de la biblioteca. Si se usan los valores de atributo predeterminados, la plantilla no establece opciones de Java para Amazon Linux. Puede definir sus opciones de Java anulando el atributo `['tomcat']['java_opts']`, por ejemplo, usando atributos de JSON personalizado. Para ver un ejemplo, consulta [Creación de una pila](create-custom-stack.md#create-custom-stack-stack).

La plantilla de Ubuntu establece varias variables de entorno, como se muestra en el siguiente fragmento de la plantilla.

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

Si se usan los valores de atributo predeterminados, la plantilla establece las variables de entorno de Ubuntu de la siguiente manera:
+ `TOMCAT6_USER` y `TOMCAT6_GROUP`, que representan el usuario y grupo de Tomcat, están establecidos en `tomcat6`.

  Si establece ['tomcat'] ['base\$1version'] en `tomcat7`, los nombres de las variables se resuelven como `TOMCAT7_USER` y `TOMCAT7_GROUP`, y ambos se establecen en `tomcat7`.
+ `JAVA_OPTS` se establece en `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`:
  + Al establecer `-Djava.awt.headless` en `true` se informa al motor de gráficos que la instancia no tiene encabezado y no tiene una consola, para abordar así el comportamiento defectuoso de determinadas aplicaciones gráficas.
  + `-Xmx128m` garantiza que JVM tenga suficientes recursos de memoria, 128 MB en este ejemplo.
  + `-XX:+UseConcMarkSweepGC` especifica la recopilación simultánea de elementos no utilizados, lo que ayuda a limitar las pausas causadas por la recopilación.

    Para obtener más información, consulte: [Mejoras del recolector Concurrent Mark Sweep](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html).
+ Si la versión de Tomcat es inferior a la 7, la plantilla no establece `LC_ALL` para abordar un error de Ubuntu.

**nota**  
Con los atributos predeterminados, algunas de estas variables de entorno se establecen sencillamente en sus valores predeterminados. No obstante, establecer de forma explícita las variables de entorno en atributos significa que puede definir atributos de JSON personalizado para anular los atributos predeterminados y proporcionar los valores personalizados. Para obtener más información acerca de la anulación de atributos, consulte [Anulación de atributos](workingcookbook-attributes.md).

Para ver los archivos de plantilla completos, consulte el [código fuente](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

### Archivo de configuración server.xml
<a name="create-custom-setup-config-server"></a>

El segundo `template` recurso se utiliza `server.xml.erb` para crear el [archivo `system.xml` de configuración](http://tomcat.apache.org/tomcat-7.0-doc/config/), que configura el contenedor. servlet/JSP `server.xml.erb`no contiene ninguna configuración específica del sistema operativo, por lo que se encuentra en el `template` subdirectorio del directorio. `default`

La plantilla utiliza la configuración estándar, pero puede crear un archivo `system.xml` para Tomcat 6 o Tomcat 7. Por ejemplo, el siguiente código de la sección del servidor de la plantilla configura los agentes de escucha adecuados para la versión especificada.

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

La plantilla utiliza atributos en lugar de configuración codificada, de manera que puede cambiar fácilmente la configuración con atributos de JSON personalizado. Por ejemplo:

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

Para obtener más información, consulte el [código fuente](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

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

La receta `tomcat::apache_tomcat_bind` habilita el servidor Apache para que actúe como front-end de Tomcat, recibiendo las solicitudes entrantes y enviándolas a Tomcat para devolver después las respuestas al cliente. En este ejemplo se utiliza [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) como proxy/gateway de 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
```

Para habilitar `mod_proxy`, debe habilitar el módulo `proxy` y un módulo basado en protocolo. Dispone de dos opciones para el módulo de protocolo: 
+ HTTP: `proxy_http`
+ [ JServ Protocolo Apache (AJP](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html)): `proxy_ajp`

  AJP es un protocolo interno de Tomcat.

Ambos [recursos execute](https://docs.chef.io/chef/resources.html#execute) de la receta ejecutan el comando `a2enmod`, que habilita el módulo especificado para crear los symlinks requeridos:
+ El primer recurso `execute` habilita el módulo `proxy`.
+ El segundo recurso `execute` habilita el módulo de protocolo, que está establecido en `proxy_http` de forma predeterminada.

  Si prefiere utilizar AJP personalizado, puede definir JSON personalizado para anular el atributo `apache_tomcat_bind_mod` y establecerlo en `proxy_ajp`. 

La `apache2::service` receta es una receta integrada en OpsWorks Stacks que define el servicio Apache. Para obtener más información, consulta la [receta](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb) en el repositorio de OpsWorks Stacks GitHub . 

El recurso `template` utiliza `apache_tomcat_bind.conf.erb` para crear un archivo de configuración denominado `tomcat_bind.conf` de forma predeterminada. Coloca el archivo en el directorio `['apache']['dir']/.conf.d`. El atributo `['apache']['dir']` se define en el archivo de atributos `apache2` integrado y se establece de forma predeterminada en `/etc/httpd` (Amazon Linux) o `/etc/apache2` (Ubuntu). Si el recurso `template` crea o cambia el archivo de configuración, el comando `notifies` programa un reinicio del servicio de 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 -%>
```

La plantilla usa las [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse)directivas [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass)y para configurar el puerto que se usa para pasar el tráfico entre Apache y Tomcat. Dado que ambos servidores están en la misma instancia, pueden utilizar una dirección URL de localhost y ambos están establecidos de forma predeterminada en `http://localhost:8080`.