Estructura de las recetas

importante

El AWS OpsWorks Stacks servicio llegó al final de su vida útil el 26 de mayo de 2024 y se ha desactivado tanto para los clientes nuevos como para los existentes. Recomendamos encarecidamente a los clientes que migren sus cargas de trabajo a otras soluciones lo antes posible. Si tienes preguntas sobre la migración, ponte en contacto con el AWS Support equipo en AWS Re:post o a través de Premium AWS Support.

Un libro de recetas es principalmente un conjunto de recetas que puede realizar una amplia variedad de tareas en una instancia. Para ver claramente cómo se implementan las recetas, utilizaremos un ejemplo sencillo. Esta es la receta de configuración de la capa HAProxy integrada. En este punto, solo tiene que fijarse en la estructura general; no se preocupe demasiado por los detalles, los trataremos en ejemplos posteriores.

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 este y otros ejemplos de cómo trabajar con recetas y archivos relacionados, consulte las recetas integradas de AWS OpsWorks Stacks.

En el ejemplo siguiente se resaltan los principales elementos de las recetas, que se describen en las secciones posteriores.

Recursos

Las recetas son principalmente un conjunto de recursos de Chef. Cada uno especifica un aspecto determinado del estado final de la instancia, como un paquete que debe instalarse o un servicio que debe iniciarse. El ejemplo tiene cuatro recursos:

• Un recurso package que representa un paquete instalado; en este ejemplo, un servidor HAProxy.

• Un recurso service que representa un servicio; en este ejemplo el servicio HAProxy.

• Dos recursos template que representan archivos que deben crearse a partir de una plantilla especificada; en este ejemplo, dos archivos de configuración HAProxy.

Los recursos permiten especificar el estado de la instancia de una forma declarativa. En segundo plano, cada recurso tiene asociado un proveedor que se encarga de realizar las tareas necesarias, como, por ejemplo, instalar paquetes, crear y configurar directorios, iniciar servicios, etc. Si los detalles de la tarea dependen de un sistema operativo determinado, el recurso dispone de varios proveedores y utiliza el más adecuado para el sistema. Por ejemplo, en un sistema Red Hat Linux, el proveedor de package utiliza yum para instalar paquetes. En un sistema Ubuntu Linux, el proveedor de package utiliza apt-get.

Puede implementar un recurso como un bloque de código Ruby con el formato general siguiente.

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

Los elementos son:

Tipo de recurso

(Obligatorio) El ejemplo incluye tres tipos de recursos, package, service y template.

Nombre del recurso

(Obligatorio) El nombre identifica el recurso en concreto y a veces se utiliza como valor predeterminado de uno de los atributos. En el ejemplo, package representa un recurso de paquete denominado haproxy y el primer recurso template representa un archivo de configuración denominado /etc/default/haproxy.

Atributos

(Opcional) Los atributos sirven para especificar la configuración del recurso y varían en función del tipo de recurso y de cómo desea configurarlo.

• Los recursos template del ejemplo definen explícitamente un conjunto de atributos que especifican el origen, el propietario, el grupo y el modo del archivo creado.

• Los recursos package y service del ejemplo no definen explícitamente ningún atributo.

  Normalmente, el nombre del recurso es el valor predeterminado de un atributo obligatorio y a veces es todo lo que se necesita. Por ejemplo, el nombre del recurso es el valor predeterminado del atributo package del recurso package_name, que es el único atributo obligatorio.

Existen también algunos atributos especializados denominados atributos de guardia, que especifican cuándo tiene que intervenir el proveedor del recurso. Por ejemplo, el atributo only_if indica al proveedor de recursos que solo tiene que intervenir si se cumple una condición especificada. La receta HAProxy no utiliza atributos de guardia, aunque sí se utilizan en varios de los ejemplos siguientes.

Acciones y notificaciones

(Opcional) Las acciones y las notificaciones sirven para especificar qué tareas debe llevar a cabo el proveedor.

• action indica al proveedor que debe ejecutar una acción concreta, como, por ejemplo, instalar o crear.

  Cada recurso tiene un conjunto de acciones que dependen del recurso concreto, entre las que figura la acción predeterminada. En el ejemplo, la acción del recurso package es install, que indica al proveedor que instale el paquete. El primer recurso template no tiene ningún elemento action, por lo que el proveedor ejecuta la acción create de forma predeterminada.

• notifies indica al proveedor de otro recurso que ejecute una acción, aunque solo si ha cambiado el estado del recurso.

  notifies se suele utilizar con recursos como template o file para ejecutar tareas como reiniciar un servicio después de modificar un archivo de configuración. Los recursos no tienen notificaciones predeterminadas. Si quiere una notificación, el recurso debe tener un elemento notifies explícito. En la receta HAProxy, el segundo recurso template indica al recurso service haproxy que debe reiniciar el servicio HAProxy si el archivo de configuración asociado cambia.

En ocasiones, los recursos dependen del sistema operativo.

• Algunos recursos pueden utilizarse únicamente en sistemas Linux o Windows.

  Por ejemplo, package instala paquetes en sistemas Linux y windows_package instala paquetes en sistemas Windows.

• Algunos recursos se pueden utilizar con cualquier sistema operativo, pero tienen atributos específicos de un sistema determinado.

  Por ejemplo, el recurso file puede utilizarse en sistemas Linux o Windows, pero tiene conjuntos de atributos diferentes para configurar los permisos.

Par obtener descripciones de recursos estándar, como los atributos, acciones y notificaciones disponibles para cada recurso, consulte la sección de información sobre recursos y proveedores.

Control del flujo

Dado que las recetas son aplicaciones Ruby, puede utilizar las estructuras de control de Ruby para incorporar un control de flujo en la receta. Por ejemplo, puede utilizar la lógica condicional de Ruby para que la receta se comporte de forma distinta según el sistema. La receta HAProxy contiene un bloque if que utiliza un recurso template para crear un archivo de configuración, pero solo si la receta se ejecuta en un sistema Debian o Ubuntu.

Otro escenario habitual suele producirse cuando se usa un bucle para ejecutar un recurso varias veces con diferentes valores de atributo. Por ejemplo, puede crear un conjunto de directorios utilizando un bucle para ejecutar un recurso directory varias veces con nombres de directorio diferentes.

nota

Si no conoce Ruby, consulte la página de Ruby, que abarca todo lo que necesita saber sobre la mayoría de las recetas.

Recetas incluidas

include_recipe incluye otras recetas en el código, lo que le permite modularizar las recetas y volver a utilizar el mismo código en varias recetas. Cuando ejecuta la receta host, Chef sustituye cada elemento include_recipe por el código de la receta especificada antes de ejecutar la receta host. Las recetas incluidas se identifican con la sintaxis cookbook_name::recipe_name de Chef estándar, donde recipe_name omite la extensión .rb. El ejemplo incluye una receta, haproxy::service, que representa el servicio HAProxy.

nota

Si utiliza include_recipe en recetas que se ejecutan en Chef 11.10 y más tarde incluye una receta de otro libro de recetas, debe utilizar una declaración depends para declarar la dependencia en el archivo metadata.rb del libro de recetas. Para obtener más información, consulte Implementación de recetas: Chef 11.10.