Estrutura da receita

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.

Livro de receitas é basicamente um conjunto de receitas, que podem executar uma grande variedade de tarefas em uma instância. Para esclarecer como implementar receitas, é útil ver um exemplo simples. Esta é a receita de configuração para a camada HAProxy integrada. Basta se concentrar na estrutura geral a esta altura e não se preocupar muito com os detalhes; eles serão abordados nos exemplos subsequentes.

package 'haproxy' do
  action :install
end

if platform?('debian','ubuntu')
  template '/etc/default/haproxy' do
    source 'haproxy-default.erb'
    owner 'root'
    group 'root'
    mode 0644
  end
end

include_recipe 'haproxy::service'

service 'haproxy' do
  action [:enable, :start]
end

template '/etc/haproxy/haproxy.cfg' do
  source 'haproxy.cfg.erb'
  owner 'root'
  group 'root'
  mode 0644
  notifies :restart, "service[haproxy]"
end

nota

Para esse e outros exemplos de receitas e arquivos relacionados funcionais, consulte Receitas integradas do AWS OpsWorks Stacks.

O exemplo destaca os principais elementos de receita, descritos nas seções a seguir.

Recursos

As receitas consistem mais em um conjunto de recursos do Chef. Cada uma especifica um determinado aspecto do estado final da instância, como um pacote ou um serviço a ser iniciado. O exemplo tem quatro recursos:

• Um recurso package, que representa um pacote instalado, um servidor HAProxy neste exemplo.

• Um recurso service, que representa um serviço, o serviço HAProxy neste exemplo.

• Dois recursos template, que representam arquivos que devem ser criados com base em um modelo especificado, dois arquivos de configuração HAProxy para este exemplo.

Os recursos apresentam uma maneira declarativa de especificar o estado da instância. Nos bastidores, cada recurso tem um provedor associado que executa as tarefas necessárias, como a instalação de pacotes, a criação e a configuração de diretórios, a inicialização de serviços etc. Caso os detalhes da tarefa dependam do sistema operacional específico, o recurso tem vários provedores e usa o adequado para o sistema. Por exemplo, em um sistema Red Hat Linux, o provedor package usa yum para instalar os pacotes. Em um sistema Ubuntu Linux, o provedor package usa apt-get.

Você implementa um recurso como um bloco de código Ruby com o formato geral a seguir.

resource_type "resource_name" do
  attribute1 'value1'
  attribute2 'value2'
  ...
  action :action_name
  notifies : action 'resource'
end

Os elementos são:

Tipo de recurso

(Obrigatório) O exemplo inclui três tipos de recurso, package, servicee template.

Nome do recurso

(Obrigatório) O nome identifica o recurso específico e, às vezes, é usado como um valor padrão para um dos atributos. No exemplo, package representa um pacote de recursos chamado haproxy, e o primeiro recurso template representa um arquivo de configuração chamado /etc/default/haproxy.

Atributos

(Opcional) Os atributos especificam a configuração do recurso e variam de acordo com o tipo de recurso e como você deseja configurar o recurso.

• Os recursos template do exemplo definem explicitamente um conjunto de atributos que especificam a origem do arquivo criado, o proprietário, o grupo e o modo.

• Os recursos package e service do exemplo não definem explicitamente nenhum atributo.

  O nome do recurso costuma ser o valor padrão de um atributo obrigatório e, às vezes, é tudo o que basta. Por exemplo, o nome do recurso é o valor padrão do atributo do package do recurso package_name, o único atributo obrigatório.

Também existem alguns atributos especializadas chamados atributos de proteção, que especificam quando o provedor de recursos deve realizar uma ação. Por exemplo, o atributo only_if leva o provedor de recursos a só executar a ação caso uma condição especificada seja atendida. A receita HAProxy não usa atributos de proteção, mas eles são usados por vários exemplos a seguir.

Ações e notificações

(Opcional) Actions e notificações especificam quais tarefas o provedor deve realizar.

• action leva o provedor a executar uma ação especificada, como instalar ou criar.

  Cada recurso tem um conjunto de ações que dependem do recurso específico, um dos quais é a ação padrão. No exemplo, a ação do recurso package é install, que leva o provedor a instalar o pacote. Como o primeiro recurso template não tem elemento action, o provedor utiliza a ação create padrão.

• notifies leva outro provedor do recurso a realizar uma ação, mas somente caso o estado do recurso tenha sido alterado.

  notifies costuma ser usado com recursos como template e file para realizar tarefas como reiniciar um serviço após a modificação de um arquivo de configuração. Os recursos não têm notificações padrão. Caso você queira uma notificação, o recurso deve ter um elemento notifies explícito. Na receita HAProxy, o segundo recurso template notifica o recurso service haproxy para reiniciar o serviço HAProxy caso o arquivo de configuração associado tenha sido alterado.

Às vezes, os recursos dependem do sistema operacional.

• Alguns recursos só podem ser usados em sistemas Linux ou Windows.

  Por exemplo, package instala pacotes em sistemas Linux e windows_package instala pacotes em sistemas Windows.

• Alguns recursos podem ser usados com qualquer sistema operacional, mas têm atributos específicos de um determinado sistema.

  Por exemplo, o recurso file pode ser usado em sistemas Linux ou Windows, mas tem conjuntos de atributos separados para configurar permissões.

Para obter descrições dos recursos padrão, inclusive os atributos, as ações e as notificações disponíveis para cada recurso, consulte About Resources and Providers.

Controle de fluxo

Como receitas são aplicações do Ruby, você pode usar as estruturas de controle do Ruby para incorporar o controle de fluxo a uma receita. Por exemplo, você pode usar a lógica condicional do Ruby para que a receita se comporte de maneira diferente em sistemas diferentes. A receita HAProxy inclui um bloco if que usa um recurso template para criar um arquivo de configuração, mas somente caso a receita esteja em execução em um sistema Debian ou Ubuntu.

Outro cenário comum é usar um loop para executar um recurso várias vezes com configurações de atributo diferentes. Por exemplo, você pode criar um conjunto de diretórios usando um loop para executar um recurso directory várias vezes com nomes de diretórios diferentes.

nota

Caso você não esteja familiarizado com o Ruby, consulte Just Enough Ruby for Chef, que aborda o que você precisa saber para a maioria das receitas.

Receitas incluídas

include_recipe inclui outras receitas no código, o que permite modularizar as receitas e reutilizar o mesmo código em várias. Quando você executa a receita host, o Chef substitui cada elemento include_recipe pelo código da receita especificado antes de executar a receita host. Você identifica uma receita incluída usando a sintaxe cookbook_name::recipe_name do Chef, em que recipe_name omite a extensão .rb. O exemplo inclui uma receita, haproxy::service, que representa o serviço HAProxy.

nota

Caso use include_recipe em receitas em execução no Chef 11.10 e posterior para incluir uma receita de outro livro de receitas, você deve usar uma instrução depends para declarar a dependência no arquivo metadata.rb do livro de receitas. Para ter mais informações, consulte Implementação de receitas: Chef 11.10.