Receitas de instalação

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 parte intermediária de tomcat::setup habilita e inicia o serviço Tomcat:

A parte final de tomcat::setup cria arquivos de configuração, além de instalar e configurar o servidor Apache front-end:

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:

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.

{
  'tomcat' : {
    'base_version' : 7
  }
}

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.

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.

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 obter 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:

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:

Os execute resources da receita executam o comando a2enmod, que habilita o módulo especificado criando os symlinks obrigatórios:

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.