

As traduções são geradas por tradução automática. Em caso de conflito entre o conteúdo da tradução e da versão original em inglês, a versão em inglês prevalecerá.

# Receitas de instalação
<a name="create-custom-setup"></a>

**Importante**  
O AWS OpsWorks Stacks serviço chegou ao fim da vida útil em 26 de maio de 2024 e foi desativado para clientes novos e existentes. É altamente recomendável que os clientes migrem suas cargas de trabalho para outras soluções o mais rápido possível. Se você tiver dúvidas sobre migração, entre em contato com a AWS Support equipe no [AWS re:POST](https://repost.aws/) ou por meio do Premium [AWS Support](https://aws.amazon.com/support).

As receitas de instalação são atribuídas ao evento do [ciclo de vida](workingcookbook-events.md) de configuração da camada e executadas após a inicialização de uma instância. Elas realizam tarefas como instalar pacotes, criar arquivos de configuração e iniciar serviços. Depois que as receitas de configuração terminarem de ser OpsWorks executadas, o Stacks executa [as receitas](create-custom-deploy.md) de implantação para implantar qualquer aplicativo na nova instância.

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

A receita `tomcat::setup` deve ser atribuída a um evento do ciclo de vida de configuração de uma camada.

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

A receita `tomcat::setup` é mais uma metarreceita. Ela inclui um conjunto de receitas dependentes que processam a maioria dos detalhes de como instalar e configurar o Tomcat e os pacotes relacionados. A primeira parte do `tomcat::setup` executa as seguintes receitas, que serão abordadas posteriormente: 
+ A receita [tomcat::install](#create-custom-setup-install) instala o pacote do servidor Tomcat.
+ A receita [tomcat::service](#create-custom-setup-service) configura o serviço Tomcat.

A parte intermediária de `tomcat::setup` habilita e inicia o serviço Tomcat:
+ O [service resource](https://docs.chef.io/chef/resources.html#service) do Chef habilita o serviço Tomcat na inicialização.
+ O [bash resource](https://docs.chef.io/chef/resources.html#bash) do Chef executa um script Bash para iniciar o daemon autofs, necessário para instâncias com suporte do Amazon EBS. O recurso acaba notificando o recurso `service` para reiniciar o serviço Tomcat.

  Para obter mais informações, 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) ou [Autofs](https://help.ubuntu.com/community/Autofs) (para Ubuntu).

A parte final de `tomcat::setup` cria arquivos de configuração, além de instalar e configurar o servidor Apache front-end:
+ A receita [tomcat::container\$1config](#create-custom-setup-config) cria arquivos de configuração.
+ A `apache2` receita (que é uma abreviatura de`apache2::default`) é uma receita integrada do OpsWorks Stacks que instala e configura um servidor Apache.
+ A receita [tomcat::apache\$1tomcat\$1bind](#create-custom-setup-bind) configura o servidor Apache para funcionar como um front-end para o servidor Tomcat.

**nota**  
Muitas vezes, você pode economizar tempo e esforço usando receitas integradas para realizar algumas das tarefas obrigatórias. Esta receita usa a receita `apache2::default` integrada para instalar o Apache, em vez de implementá-lo do zero. Para obter outro exemplo de como usar receitas integradas, consulte [Receitas de implantação](create-custom-deploy.md).

As seções a seguir descrevem as receitas de instalação do livro de receitas Tomcat em mais detalhes. Para obter mais informações sobre as receitas `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>

A receita `tomcat::install ` instala o servidor Tomcat, o OpenJDK e uma biblioteca de conectores Java que processa a conexão com o 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'
```

A receita executa as seguintes tarefas:

1. Cria uma lista de pacotes a serem instalados, dependendo do sistema operacional da instância.

1. Instala cada pacote na lista.

   O [package resource](https://docs.chef.io/chef/resources.html#id146) do Chef usa o provedor apropriado (`yum` para Amazon Linux e `apt-get` para Ubuntu) a fim de processar a instalação. Os provedores de pacotes instalam o OpenJDK como uma dependência do Tomcat, mas a biblioteca de conectores MySQL deve ser instalada explicitamente.

1. Usa um recurso [link resource](https://docs.chef.io/chef/resources.html#link) do Chef para criar um symlink no diretório lib do servidor do Tomcat para o a biblioteca de conectores do MySQL no JDK.

   Usando os valores de atributo padrão, o diretório lib do Tomcat é `/usr/share/tomcat6/lib` e a biblioteca de conectores do MySQL (`mysql-connector-java.jar`) está em `/usr/share/java/`.

A receita `tomcat::remove_root_webapp` remove o aplicativo web ROOT (`/var/lib/tomcat6/webapps/ROOT` por padrão) para evitar alguns problemas de segurança.

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

A instrução `only_if` garante que a receita só remova o arquivo caso ele exista.

**nota**  
A versão do Tomcat é especificada pelo atributo `['tomcat']['base_version']`, definido como 6 no arquivo de atributos. Para instalar o Tomcat 7, você pode usar atributos JSON personalizados para substituir o atributo. Basta [editar as configurações da pilha](workingstacks-edit.md) e inserir o seguinte JSON na caixa **Custom Chef JSON** ou adicioná-la a qualquer JSON personalizado existente:  

```
{
  'tomcat' : {
    'base_version' : 7
  }
}
```
O atributo JSON personalizado substitui o atributo padrão e define a versão do Tomcat como 7. Para obter mais informações sobre como substituir esses atributos, consulte [Sobrepor atributos](workingcookbook-attributes.md).

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

A receita `tomcat::service` cria a definição de serviço do 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
```

A receita usa o [service resource](https://docs.chef.io/chef/resources.html#service) do Chef para especificar o nome do serviço do Tomcat (tomcat6, por padrão) e define o atributo `supports` para determinar como o Chef gerencia os comandos de reinicialização, recarregamento e status do serviço nos sistemas operacionais diferentes.
+ `true` indica que o Chef pode usar o script init ou outro provedor de serviços para executar o comando
+ `false` indica que o Chef deve tentar executar o comando por outros meios.

O `action` é definido como `:nothing`. Para cada evento do ciclo de vida, o OpsWorks Stacks inicia uma execução do [Chef para executar](https://docs.chef.io/chef_client_overview.html#the-chef-client-run) o conjunto apropriado de receitas. O livro de receitas do Tomcat segue um padrão comum de fazer uma receita criar a definição de serviço, mas não reiniciá-lo. Outras receitas na execução do Chef processam a reinicialização, normalmente incluindo um comando `notifies` nos recursos `template` usados para criar arquivos de configuração. Notificações são uma maneira prática de reiniciar um serviço porque elas só fazem isso caso a configuração tenha sido alterada. Além disso, caso uma execução do Chef tenha várias notificações de reinicialização para um serviço, o Chef reinicia o serviço uma vez, no máximo. Essa prática evita problemas que possam ocorrer durante a tentativa de reiniciar um serviço que não esteja totalmente operacional, que é uma fonte comum de erros do Tomcat.

 O serviço Tomcat deve ser definidos para qualquer execução do Chef que use notificações de reinicialização. Portanto, `tomcat::service` é incluído em vários receitas, para garantir que o serviço seja definido para cada execução do Chef. Não haverá penalidade se uma execução do Chef incluir várias instâncias de `tomcat::service` porque o Chef garante que uma receita seja executada somente uma vez por execução, independentemente de quantas vezes ele seja incluído.

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

A receita `tomcat::container_config` cria arquivos de configuração com base em arquivos de modelo do livro de receitas.

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

A receita chama primeiro `tomcat::service`, que define o serviço, se necessário. A maior parte da receita consiste em dois [template resources](https://docs.chef.io/chef/resources.html#template), cada um criando um arquivo de configuração com base em um dos arquivos de modelo do livro de receitas, define as propriedades do arquivo e notifica o Chef para reiniciar o serviço.

### Arquivo de configuração do ambiente do Tomcat
<a name="create-custom-setup-config-env"></a>

O primeiro recurso `template` usa o arquivo de modelo `tomcat_env_config.erb` para criar um arquivo de configuração do ambiente do Tomcat, usado para definir variáveis do ambiente, como `JAVA_HOME`. O nome do arquivo padrão é o argumento do recurso `template`. `tomcat::container_config` usa um atributo `path` para substituir o valor padrão e o nome do arquivo de configuração `/etc/sysconfig/tomcat6` (Amazon Linux) ou `/etc/default/tomcat6` (Ubuntu). O recurso `template` também especifica o proprietário, o grupo e as configurações de modo do arquivo e leva o Chef a não criar arquivos de backup.

Caso você observe o código-fonte, na verdade, há três versões de `tomcat_env_config.erb`, cada uma em um subdiretório diferente do diretório `templates`. Os diretórios `ubuntu` e `amazon` contêm os modelos para os respectivos sistemas operacionais. A pasta `default` contém um modelo fictício com uma única linha de comentário, usada apenas caso você tente executar essa receita em uma instância com um sistema operacional não compatível. A receita `tomcat::container_config` não precisa especificar qual `tomcat_env_config.erb` usar. O Chef escolhe automaticamente o diretório apropriado para o sistema operacional da instância com base em regras descritas em [File Specificity](http://docs.chef.io/templates.html#file-specificity).

Os arquivos `tomcat_env_config.erb` deste exemplo consistem em grande parte de comentários. Para definir variáveis de ambiente adicionais, basta excluir o comentário das linhas apropriadas e fornecer os valores preferidos.

**nota**  
Qualquer definição de configuração que possa mudar deve ser determinada como um atributo, em vez de codificada no modelo. Assim, você não precisa reescrever o modelo para alterar uma configuração, bastando substituir o atributo.

O modelo do Amazon Linux define apenas uma variável de ambiente, conforme mostrado no trecho a seguir.

```
...
# 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 pode ser usado para especificar opções de Java, como o caminho da biblioteca. Usando os valores de atributo padrão, o modelo não define opções de Java para o Amazon Linux. Você pode definir as próprias opções de Java substituindo o atributo `['tomcat']['java_opts']`, por exemplo, usando atributos JSON personalizados. Para ver um exemplo, consulte [Criar um stack](create-custom-stack.md#create-custom-stack-stack).

O modelo do Ubuntu define várias variáveis de ambiente, conforme mostrado no trecho do modelo a seguir.

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

Usando valores de atributo padrão, o modelo define as variáveis de ambiente do Ubuntu da seguinte forma:
+ `TOMCAT6_USER` e `TOMCAT6_GROUP`, que representam o usuário e o grupo do Tomcat, são definidos como `tomcat6`.

  Caso você defina ['tomcat'] ['base\$1version'] como `tomcat7`, os nomes de variável são resolvidos como `TOMCAT7_USER` e `TOMCAT7_GROUP`, e ambos são definidos como `tomcat7`.
+ `JAVA_OPTS` é definido como `-Djava.awt.headless=true -Xmx128m -XX:+UseConcMarkSweepGC`:
  + A definição de `-Djava.awt.headless` como `true` informa o mecanismo de gráficos que a instância é descentralizada e não tem um console, o que resolve o comportamento de determinadas aplicações gráficas.
  + `-Xmx128m` garante que o JVM tenha recursos de memória adequados, 128 MB para este exemplo.
  + `-XX:+UseConcMarkSweepGC` especifica a coleta de lixo de varredura de marca simultânea, o que ajuda a limitar pausas induzidas pela coleta de lixo.

    Para obter mais informações, consulte: [Concurrent Mark Sweep Collector Enhancements](http://docs.oracle.com/javase/6/docs/technotes/guides/vm/cms-6.html).
+ Caso a versão do Tomcat seja inferior à versão 7, o modelo cancela a definição de `LC_ALL`, que resolve um bug do Ubuntu.

**nota**  
Com os atributos padrão, algumas dessas variáveis de ambiente são simplesmente definidas como os valores padrão. No entanto, a definição explícita das variáveis de ambiente como atributos significa que você pode definir atributos JSON personalizados para substituir os atributos padrão e fornecer valores personalizados. Para obter mais informações sobre como substituir esses atributos, consulte [Sobrepor atributos](workingcookbook-attributes.md).

Para obter os arquivos de modelo completos, consulte o [source code](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

### Arquivo de configuração Server.xml
<a name="create-custom-setup-config-server"></a>

O segundo `template` recurso é usado `server.xml.erb` para criar o [arquivo `system.xml` de configuração](http://tomcat.apache.org/tomcat-7.0-doc/config/), que configura o servlet/JSP contêiner. `server.xml.erb`não contém configurações específicas do sistema operacional, portanto, está no `template` subdiretório do `default` diretório.

O modelo usa configurações padrão, mas pode criar um arquivo `system.xml` para o Tomcat 6 ou o Tomcat 7. Por exemplo, o código a seguir na seção do servidor do modelo configura as escutas corretamente para a versão 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 -%>
```

O modelo usa atributos em vez de configurações codificadas, de maneira que você possa alterar facilmente as configurações definindo atributos JSON personalizados. Por exemplo:

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

Para obter mais informações, consulte o [source code](https://github.com/amazonwebservices/opsworks-example-cookbooks/tree/master/tomcat).

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

A receita `tomcat::apache_tomcat_bind` permite que o servidor Apache funcione como o front-end do Tomcat, recebendo solicitações de entrada e as encaminhando para o Tomcat e retornando as respostas ao cliente. Este exemplo usa [mod\$1proxy](https://httpd.apache.org/docs/2.2/mod/mod_proxy.html) como o proxy/gateway do 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`, você deve habilitar o módulo `proxy` e um módulo com base em protocolo. Você tem duas opções para o módulo de protocolo: 
+ HTTP: `proxy_http`
+ [ JServ Protocolo Apache](http://tomcat.apache.org/connectors-doc/ajp/ajpv13a.html) (AJP): `proxy_ajp`

  AJP é um protocolo do Tomcat interno.

Os [execute resources](https://docs.chef.io/chef/resources.html#execute) da receita executam o comando `a2enmod`, que habilita o módulo especificado criando os symlinks obrigatórios:
+ O primeiro recurso `execute` habilita o módulo `proxy`.
+ O segundo recurso `execute` habilita o módulo de protocolo, definido como `proxy_http`, por padrão.

  Caso prefira usar AJP, você pode definir JSON personalizada para substituir o atributo `apache_tomcat_bind_mod` e defini-lo como `proxy_ajp`. 

A `apache2::service` receita é uma receita integrada do OpsWorks Stacks que define o serviço Apache. Para obter mais informações, consulte a [receita](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/apache2/recipes/service.rb) no GitHub repositório OpsWorks Stacks. 

O recurso `template` usa `apache_tomcat_bind.conf.erb` para criar um arquivo de configuração que, por padrão, é chamado `tomcat_bind.conf`. Ele salva o arquivo no diretório `['apache']['dir']/.conf.d`. O atributo `['apache']['dir']` é definido no arquivo de atributos `apache2` integrados, e é definido por padrão como `/etc/httpd` (Amazon Linux) ou `/etc/apache2` (Ubuntu). Caso o recurso `template` crie ou altere o arquivo de configuração, o comando `notifies` programa uma reinicialização do serviço do 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 -%>
```

O modelo usa as [ProxyPassReverse](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypassreverse)diretivas [ProxyPass](https://httpd.apache.org/docs/2.0/mod/mod_proxy.html#proxypass)e para configurar a porta usada para transmitir tráfego entre o Apache e o Tomcat. Como ambos os servidores estão na mesma instância, eles podem usar um URL localhost e são definidos por padrão como `http://localhost:8080`.