Receitas de implantação

As receitas de implantação são atribuídas ao evento do ciclo de vida de implantação da camada. Normalmente, ocorre em todas as instâncias da pilha sempre que você implanta um aplicativo, embora você possa, opcionalmente, restringir o evento somente a instâncias especificadas. AWS OpsWorks O Stacks também executa as receitas de implantação em novas instâncias, após a conclusão das receitas de configuração. A finalidade principal das receitas de implantação é implantar código e arquivos relacionados de um repositório nas instâncias da camada do servidor de aplicações. No entanto, você normalmente executa receitas de implantação em outras camadas também. Isso permite que as instâncias dessas camadas, por exemplo, atualizem a configuração para acomodar a aplicação recém-implantada. Quando você implementar uma receita de implantação, lembre-se de que um evento de implantação não necessariamente significa que aplicações estejam sendo implantadas na instância. Pode ser simplesmente uma notificação de que aplicações estão sendo implantadas em outras instâncias na pilha para permitir que a instância faça eventuais atualizações necessárias. A receita deve ser capaz de responder adequadamente, o que pode significar não fazer nada.

AWS OpsWorks O Stacks implanta automaticamente aplicativos dos tipos de aplicativos padrão nas camadas correspondentes do servidor de aplicativos incorporado. Para implantar aplicações em uma camada personalizada, você deve implementar receitas de implantação personalizadas que fazem download dos arquivos da aplicação de um repositório no local apropriado na instância. No entanto, você normalmente pode limitar a quantidade de código que deve gravar usando deploy cookbook integrada para lidar com alguns aspectos da implantação. Por exemplo, caso você armazene os arquivos em um dos repositórios compatíveis, o livro de receitas integrado pode processar os detalhes do download dos arquivos do repositório para as instâncias da camada.

A receita tomcat::deploy deve ser atribuída ao evento do ciclo de vida de implementação.

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

A receita tomcat::deploy usa o livro de receitas de implantação integrado em aspectos da implantação que não sejam específicos da aplicação. A receita deploy (abreviada para a receita deploy::default integrada) é uma receita integrada que processa os detalhes da configuração de usuários, grupos etc., com base em dados dos atributos deploy.

A receita usa duas definições do Chef integradas opsworks_deploy_dir e opworks_deploy para instalar a aplicação.

A opsworks_deploy_dir definição configura a estrutura de diretórios, com base nos dados da implantação do aplicativoJSON. As definições são basicamente uma maneira prática de empacotar definições de recurso e estão localizadas no diretório definitions de um livro de receitas. As receitas podem usar definições como os recursos, mas a definição propriamente dita não tem um provedor associado, apenas os recursos incluídos na definição. Você pode definir variáveis na receita, que são passadas para as definições de recurso subjacentes. Os conjuntos user de tomcat::deploy group receitas e path variáveis com base nos dados da implantaçãoJSON. Eles são passados para o directory resource da definição, que gerencia os diretórios.

A outra definição, opsworks_deploy, processa os detalhes de verificação do código da aplicação e dos arquivos relacionados do repositório e os implanta na instância, com base em dados dos atributos deploy. Você pode usar essa definição para qualquer tipo de aplicativo; detalhes de implantação, como os nomes dos diretórios, são especificados no console ou por meio do API e inseridos nos deploy atributos. No entanto, opsworks_deploy funciona somente para os quatro tipos de repositórios compatíveis: Git, Subversion, S3 e. HTTP Você deve implementar esse código sozinho caso queira usar um tipo de repositório diferente.

Você instala os arquivos de uma aplicação no diretório webapps do Tomcat. Uma prática comum é copiar os arquivos diretamente para webapps. No entanto, a implantação do AWS OpsWorks Stacks foi projetada para reter até cinco versões de um aplicativo em uma instância, para que você possa reverter para uma versão anterior, se necessário. AWS OpsWorks Portanto, o Stacks faz o seguinte:

Caso você precise reverter para uma versão anterior, modifique o symlink current a fim de apontar para um diretório distinto que contenha o carimbo de data e hora apropriado, por exemplo, alterando o link de destino de /srv/www/my_1st_jsp/current.

A seção intermediária de tomcat::deploy configura o symlink.

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

A receita cria primeiramente duas variáveis, current_dir e webapp_dir, para representar os diretórios current e webapp, respectivamente. Em seguida, ele usa um recurso link para vincular webapp_dir a current_dir. A deploy::default receita do AWS OpsWorks Stacks cria alguns diretórios stub que não são necessários para este exemplo, então a parte central do trecho os remove.

A parte final de tomcat::deploy reinicia o serviço do Tomcat, se necessário.

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

A receita executa primeiramente tomcat::service a fim de garantir que o serviço seja definido para essa execução do Chef. Ela acaba usando um execute resource a fim de notificar o serviço para reiniciar, mas somente se ['tomcat']['auto_deploy'] for definido como 'true'. Do contrário, o Tomcat escuta alterações no diretório webapps, que torna uma reinicialização do serviço do Tomcat explícito desnecessário.

Por fim, tomcat::deploy executa tomcat::context, que atualiza o arquivo de configuração do contexto da aplicação da web caso você tenha alterado o banco de dados back-end.