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 implantação
<a name="create-custom-deploy"></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 implantação são atribuídas ao evento do [ciclo de vida](workingcookbook-events.md) 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. 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.

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](https://github.com/aws/opsworks-cookbooks/tree/release-chef-11.4/deploy) 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 definição `opsworks_deploy_dir` configura a estrutura do diretório, com base em dados do JSON de implantação da aplicação. 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. A receita `tomcat::deploy` define variáveis `user`, `group` e `path` com base em dados do JSON de implantação. Eles são passados para o [directory resource](https://docs.chef.io/chef/resources.html#directory) da definição, que gerencia os diretórios. 

**nota**  
O usuário e o grupo da aplicação implantado são determinados pelos atributos `[:opsworks][:deploy_user][:user]` e `[:opsworks][:deploy_user][:group]`, definidos no [arquivo de atributos `deploy.rb` do livro de receitas de implantação integrado](https://github.com/aws/opsworks-cookbooks/blob/release-chef-11.4/deploy/attributes/deploy.rb). O valor padrão de `[:opsworks][:deploy_user][:user]` é `deploy`. O valor padrão de `[:opsworks][:deploy_user][:group]` depende do sistema operacional da instância:  
Para instâncias do Ubuntu, o grupo padrão é `www-data`.
Para instâncias do Amazon Linux membros de uma camada do Rails App Server que use Nginx e Unicorn, o grupo padrão é `nginx`.
Para todas as outras instâncias do Amazon Linux, o grupo padrão é `apache`.
Você pode alterar a definição usando um JSON personalizado ou um arquivo de atributos personalizado para substituir o atributo apropriado. Para obter mais informações, consulte [Sobrepor atributos](workingcookbook-attributes.md).

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 aplicação; detalhes da implantação, como os nomes de diretório especificados no console ou por meio da API e colocar os atributos `deploy`. No entanto, `opsworks_deploy` só funciona para os quatro [tipos de repositório compatíveis](workingcookbook-installingcustom-repo.md): 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 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. OpsWorks Portanto, o Stacks faz o seguinte:

1. Implanta aplicativos em um diretório distinto cujo nome contém um time stamp, como `/srv/www/my_1st_jsp/releases/20130731141527`.

1. Cria um symlink chamado `current`, como `/srv/www/my_1st_jsp/current`, para esse diretório exclusivo.

1. Caso ele ainda não exista, cria um symlink com base no diretório `webapps` para o symlink `current` criado na Etapa 2.

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 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](https://docs.chef.io/chef/resources.html#execute) 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. 

**nota**  
O recurso `execute` não executa realmente nada substantivo; `/bin/true` é um script do shell fictício que simplesmente retorna um código de êxito. Ele é usado aqui apenas como uma maneira cômoda para gerar uma notificação de reinicialização. Conforme mencionado anteriormente, o uso de notificações garante que os serviços não sejam reiniciados com muita frequência.

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.