tomcat::setup tomcat::install tomcat::service tomcat::container_config tomcat::apache_tomcat_bind

Receitas de instalação

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 ou por meio do Premium AWS Support.

As receitas de instalação são atribuídas ao evento do ciclo de vida 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 AWS OpsWorks executadas, o Stacks executa as receitas de implantação para implantar qualquer aplicativo na nova instância.

tomcat::setup

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 instala o pacote do servidor Tomcat.
A receita tomcat::service configura o serviço Tomcat.

A parte intermediária de tomcat::setup habilita e inicia o serviço Tomcat:

O service resource do Chef habilita o serviço Tomcat na inicialização.
O bash resource 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 (para Amazon Linux) ou 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_config cria arquivos de configuração.
A apache2 receita (que é uma abreviatura deapache2::default) é uma receita integrada do AWS OpsWorks Stacks que instala e configura um servidor Apache.
A receita tomcat::apache_tomcat_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.

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.

tomcat::install

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:

Cria uma lista de pacotes a serem instalados, dependendo do sistema operacional da instância.
Instala cada pacote na lista.

O package resource 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.
Usa um recurso link resource 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 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.

tomcat::service

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 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 AWS OpsWorks Stacks inicia uma execução do Chef para executar 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_config

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

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.

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

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_version'] 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.
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.

Para obter os arquivos de modelo completos, consulte o source code.

Arquivo de configuração Server.xml

O segundo recurso template usa server.xml.erb para criar o arquivo de configuração system.xml, que configura o contêiner servlet/JSP. server.xml.erb não contém configurações específicas do sistema operacional, logo, ele está no subdiretório default do diretório template.

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.

tomcat::apache_tomcat_bind

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_proxy 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
Apache JServ Protocol (AJP): proxy_ajp

AJP é um protocolo do Tomcat interno.

Os execute resources 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 AWS OpsWorks Stacks que define o serviço Apache. Para obter mais informações, consulte a receita no GitHub repositório AWS 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 ProxyPassReversediretivas ProxyPasse 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.

Atenção O Javascript está desativado ou não está disponível no seu navegador.

Para usar a documentação da AWS, o Javascript deve estar ativado. Consulte as páginas de Ajuda do navegador para obter instruções.

Convenções do documento

Arquivo de atributos

Receitas de configuração