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á. # Extensão de uma camada **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). Algumas vezes, você precisa personalizar uma camada integrada além do que é possível lidar com a modificação de atributos do OpsWorks Stacks ou com a personalização de modelos. Por exemplo, suponha que você precisa criar symlinks, definir modos de arquivos ou de pastas, instalar pacotes adicionais,e assim por diante. Você deve estender as camadas personalizadas para fornecer mais do que a funcionalidade mínima. Neste caso, será necessário implementar um ou mais livros de receitas personalizados com receitas para lidar com as tarefas de personalização. Este tópico fornece alguns exemplos de como usar as receitas para estender uma camada. Se você ainda não conhece o Chef, primeiro deverá ler [Introdução a livros de receitas](cookbooks-101.md), que é um tutorial que apresenta as noções básicas de como implementar os livros de receitas para realizar uma variedade de tarefas comuns. Para obter um exemplo detalhado de como implementar uma camada personalizada, consulte [Criação de uma camada de servidor Tomcat personalizada](create-custom.md). **Topics** + [Uso de receitas para executar scripts](workingcookbook-extend-scripts.md) + [Uso de hooks de implantação do Chef](workingcookbook-extend-hooks.md) + [Execução de trabalhos cron em instâncias do Linux](workingcookbook-extend-cron.md) + [Instalação e configuração de pacotes em instâncias do Linux](workingcookbook-extend-package.md) # Uso de receitas para executar scripts **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). Se você já tiver um script que realize as tarefas de personalização necessárias, a abordagem mais simples para estender uma camada quase sempre será implementar uma receita simples para executar o script. Assim, você poderá atribuir a receita aos eventos de ciclo de vida adequados, normalmente a configuração ou a implantação, ou usar o comando de pilha`execute_recipes` para executar a receita manualmente. O exemplo a seguir executa um script de shell em instâncias Linux, mas você pode usar a mesma abordagem para outros tipos de script, incluindo PowerShell scripts do Windows. ``` cookbook_file "/tmp/lib-installer.sh" do source "lib-installer.sh" mode 0755 end execute "install my lib" do command "sh /tmp/lib-installer.sh" end ``` O recurso `cookbook_file` representa um arquivo que é armazenado em um subdiretório do diretório `files` de um livro de receitas e transfere o arquivo para um local especificado na instância. Este exemplo transfere um script de shell, `lib-installer.sh`, para o diretório `/tmp` da instância e define o modo de arquivo como `0755`. Para obter mais informações, consulte [cookbook\$1file](https://docs.chef.io/chef/resources.html#cookbook-file). O recurso `execute` representa um comando, como um comando de shell. Este exemplo executa `lib-installer.sh`. Para obter mais informações, consulte [execute](https://docs.chef.io/chef/resources.html#execute). Você também pode executar um script incorporando-o a uma receita. O exemplo a seguir executa um script bash, mas o Chef também oferece suporte a Csh, Perl, Python e Ruby. ``` script "install_something" do interpreter "bash" user "root" cwd "/tmp" code <<-EOH #insert bash script EOH end ``` O recurso `script` representa um script. O exemplo especifica um intérprete bash, define o usuário como `"root"` e define o diretório de trabalho como `/tmp`. Em seguida, ele executa o script bash no bloco `code`, o que pode incluir quantas linhas forem necessárias. Para obter mais informações, consulte [script](https://docs.chef.io/chef/resources.html#script). Para obter mais informações sobre como usar receitas para executar scripts, consulte [Exemplo 7: Execução de comandos e scripts](cookbooks-101-basics-commands.md). Para ver um exemplo de como executar um PowerShell script em uma instância do Windows, consulte[Executando um PowerShell script do Windows](cookbooks-101-opsworks-opsworks-powershell.md). # Uso de hooks de implantação do Chef **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). Você pode personalizar a implantação ao implementar uma receita personalizada para realizar as tarefas necessárias e atribuí-la ao evento Implantar da camada apropriada. Uma abordagem alternativa e algumas vezes mais simples, especialmente se não for necessário implementar um livro de receitas para outros fins, é usar hooks de implantação do Chef para executar o seu código de personalização. Além disso, o Implantar receitas personalizado é executado depois que a implantação tiver sido realizada pelas receitas integradas. Os hooks de implantação permitem que você interaja durante uma implantação, por exemplo, após o check-out do código do aplicativo do repositório, mas antes do reinício do Apache. O Chef implanta aplicativos em quatro estágios: + **Check-out**: faz download dos arquivos do repositório + **Migrar**: executa uma migração conforme necessário + **Symlink**: cria symlinks + **Reiniciar**: reinicia o aplicativo Os hooks de implantação do Chef oferecem uma maneira simples de personalizar uma implantação ao executarem opcionalmente um aplicativo Ruby fornecido pelo usuário após a conclusão de cada estágio. Para usar os hooks de implantação, implemente um ou mais aplicativos Ruby e coloque-os no diretório `/deploy` do seu aplicativo. (Se seu aplicativo não tiver um diretório `/deploy`, crie um no nível `APP_ROOT`). O aplicativo deve ter um dos seguintes nomes, que determina quando ele será executado. + `before_migrate.rb` é executado após a conclusão do estágio Check-out, mas antes de Migração. + `before_symlink.rb` é executado após a conclusão do estágio Migração, mas antes de Symlink. + `before_restart.rb` é executado após a conclusão do estágio Symlink, mas antes de Reinício. + `after_restart.rb` é executado após a conclusão do estágio Reinício. Os hooks de implantação do Chef podem acessar o objeto de nó usando a sintaxe padrão do nó, assim como acontece com as receitas. Os hooks de implantação também podem acessar os valores de qualquer [variável de ambiente de aplicativo](workingapps-creating.md#workingapps-creating-environment) especificada. No entanto, você deve usar `new_resource.environment["VARIABLE_NAME"] ` para acessar o valor da variável em vez de `ENV["VARIABLE_NAME"]`. # Execução de trabalhos cron em instâncias do Linux **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). Um trabalho cron do Linux direciona o daemon cron para executar um ou mais comandos em uma programação especificada. Por exemplo, suponha que sua pilha seja compatível com um aplicativo de comércio eletrônico PHP. Você pode configurar um trabalho cron para que o servidor envie um relatório de vendas em um horário especificado a cada semana. Para obter mais informações sobre cron, consulte [cron](http://en.wikipedia.org/wiki/Cron) na Wikipédia. Para obter mais informações sobre como executar um trabalho cron diretamente em uma instância ou computador baseado em Linux, consulte [O que são cron e crontab, e como usá-los?](https://kb.iu.edu/d/afiz) (em inglês), no site da base de dados de conhecimento da Universidade de Indiana. Embora você possa configurar manualmente os trabalhos `cron` em instâncias baseadas no Linux individuais ao conectar-se a eles com SSH e ao editar suas entradas `crontab`, uma das principais vantagens do OpsWorks Stacks é que você pode direcioná-lo para executar a tarefa em uma camada de instâncias inteira. O procedimento a seguir descreve como configurar um trabalho `cron` em instâncias de uma camada PHP App Server, mas você pode usar a mesma abordagem com qualquer camada. **Para configurar um trabalho `cron` nas instâncias de uma camada** 1. Implemente um livro de receitas com uma receita com um recurso `cron` que configure o trabalho. O exemplo supõe que a receita se chama `cronjob.rb`; os detalhes da implementação serão descritos mais tarde. Para obter mais informações sobre livros de receitas e receitas, consulte [Livros de receitas e receitas](workingcookbook.md). 1. Instale o livro de receitas em sua pilha. Para obter mais informações, consulte [Instalação de livros de receitas personalizados](workingcookbook-installingcustom-enable.md). 1. Faça com que o OpsWorks Stacks execute a receita automaticamente nas instâncias da camada, atribuindo-a aos seguintes eventos do ciclo de vida. Para obter mais informações, consulte [Execução automática de receitas](workingcookbook-assigningcustom.md). + **Configuração** — A atribuição `cronjob.rb` a esse evento faz com que o OpsWorks Stacks execute a receita em todas as novas instâncias. + **Implantar** — A atribuição `cronjob.rb` a esse evento faz com que o OpsWorks Stacks execute a receita em todas as instâncias on-line quando você implanta ou reimplanta um aplicativo na camada. Você também pode executar manualmente a receita em instâncias online usando o comando `Execute Recipes` da pilha. Para obter mais informações, consulte [Executa comandos de pilha](workingstacks-commands.md). A seguir, o exemplo de `cronjob.rb` configura um trabalho cron para executar um aplicativo PHP implementado pelo usuário uma vez por semana que coleta os dados de vendas do servidor e envia um relatório por e-mail. Para obter mais exemplos de como usar um recurso cron, consulte [cron](https://docs.chef.io/chef/resources.html#cron). ``` cron "job_name" do hour "1" minute "10" weekday "6" command "cd /srv/www/myapp/current && php .lib/mailing.php" end ``` O `cron` é um recurso do Chef que representa um trabalho `cron`. Quando o OpsWorks Stacks executa a receita em uma instância, o provedor associado trata dos detalhes da configuração do trabalho. + `job_name` é um nome definido pelo usuário para o trabalho `cron`, como `weekly report`. + `hour`/`minute`/`weekday` especificam quando os comandos devem ser executados. Este exemplo executa os comandos todos os sábados à 1:10h. + `command` especifica os comandos a serem executados. Este exemplo executa dois comandos. O primeiro navega até o diretório `/srv/www/myapp/current`. O segundo executa o aplicativo `mailing.php` implementado pelo usuário, que coleta os dados de vendas e envia o relatório. **nota** Por padrão, o comando `bundle` não funciona com trabalhos `cron`. O motivo é que o OpsWorks Stacks instala o bundler no diretório. `/usr/local/bin` Para usar `bundle` com um trabalho `cron`, você deve adicionar explicitamente o caminho `/usr/local/bin` ao trabalho cron. Além disso, como a variável de ambiente \$1PATH não pode se expandir no trabalho `cron`, uma melhor prática é adicionar explicitamente qualquer informação sobre caminho necessária ao trabalho sem depender da expansão da variável \$1PATH. Os exemplos a seguir mostram duas maneiras de usar `bundle` em um trabalho `cron`. ``` cron "my first task" do path "/usr/local/bin" minute "*/10" command "cd /srv/www/myapp/current && bundle exec my_command" end ``` ``` cron_env = {"PATH" => "/usr/local/bin"} cron "my second task" do environment cron_env minute "*/10" command "cd /srv/www/myapp/current && /usr/local/bin/bundle exec my_command" end ``` Se a sua pilha tiver vários servidores de aplicativos, a atribuição de `cronjob.rb` aos eventos de ciclo de vida da camada PHP App Server pode não ser uma abordagem ideal. Por exemplo, a receita é executada em todas as instâncias da camada e, portanto, você receberá vários relatórios. Uma abordagem melhor é usar uma camada personalizada para garantir que apenas um servidor envie um relatório. **Para executar uma receita em apenas uma das instâncias de uma camada** 1. Crie uma camada personalizada chamada, por exemplo, PHPAdmin e `cronjob.rb` atribua aos seus eventos de configuração e implantação. As camadas personalizadas não precisam necessariamente fazer muito. Nesse caso, PHPAdmin basta executar uma receita personalizada em suas instâncias. 1. Atribua uma das instâncias do PHP App Server AdminLayer a. Se uma instância pertencer a mais de uma camada, o OpsWorks Stacks executa as receitas integradas e personalizadas de cada camada. Como apenas uma instância pertence ao PHP App Server e às PHPAdmin camadas, `cronjob.rb` é executada somente nessa instância e você recebe apenas um relatório. # Instalação e configuração de pacotes em instâncias do Linux **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 camadas integradas dão suporte apenas a determinados pacotes. Para obter mais informações, consulte [Layers](workinglayers.md). Você pode instalar outros pacotes, como um servidor Redis, ao implementar as receitas personalizadas para lidar com as tarefas associadas de instalação, de configuração e de implantação. Em alguns casos, a melhor abordagem é estender uma camada integrada para que ela instale o pacote em suas instâncias junto com os pacotes padrão da camada. Por exemplo, se você tiver uma pilha que ofereça suporte a um aplicativo PHP e se quiser incluir um servidor Redis, poderá estender a camada PHP App Server para instalar e configurar um servidor Redis nas instâncias da camada além de um servidor de aplicativos PHP. Uma receita de instalação de pacote normalmente precisa executar tarefas como estas: + Crie um ou mais diretórios e defina seus modos. + Crie um arquivo de configuração desde um modelo. + Execute o instalador para instalar o pacote na instância. + Inicie um ou mais serviços. Para obter um exemplo de como instalar um servidor Tomcat, consulte [Criação de uma camada de servidor Tomcat personalizada](create-custom.md). O tópico descreve como configurar uma camada personalizada do Redis, mas você pode usar o mesmo código para instalar e configurar o camada em uma camada integrada. Para ver exemplos de como instalar outros pacotes, consulte os livros de receitas integrados, em [https://github.com/aws/opsworks-cookbooks](https://github.com/aws/opsworks-cookbooks).