Recetas de implementación

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.

Las recetas de implementación se asignan al evento Deploy del ciclo de vida de la capa. Suele ocurrir en todas las instancias de la pila cada vez que despliegas una aplicación, aunque, si lo deseas, puedes restringir el evento solo a instancias específicas. AWS OpsWorks Stacks también ejecuta las recetas de implementación en instancias nuevas, una vez completadas las recetas de configuración. El objetivo principal de las recetas de implementación es implementar el código y los archivos relacionados de un repositorio en las instancias de la capa del servidor de aplicaciones. Sin embargo, a menudo se ejecutan también en otras capas. Esto permite que las instancias de esas capas, por ejemplo, actualicen su configuración para adaptarse a la nueva aplicación implementada. Cuando implemente una receta de implementación, tenga en cuenta que un evento Deploy no supone necesariamente que las aplicaciones se implementen en la instancia. Podría simplemente ser una notificación para que las aplicaciones se implementen en otras instancias de la pila, para permitir que la instancia haga las actualizaciones que sean necesarias. La receta debe ser capaz de responder de forma adecuada, lo que podría significar no hacer nada.

AWS OpsWorks Stacks implementa automáticamente las aplicaciones de los tipos de aplicaciones estándar en las correspondientes capas del servidor de aplicaciones integradas. Para implementar una capa personalizada, debe implementar las recetas de implementación personalizadas que descargan los archivos de la aplicación de un repositorio en la ubicación adecuada de la instancia. No obstante, a menudo podrá limitar la cantidad de código que debe escribir utilizando el libro de recetas de implementación integrado para controlar algunos aspectos de la implementación. Por ejemplo, si almacena los archivos en uno de los repositorios compatibles, el libro de recetas integrado puede controlar los detalles de la descarga de los archivos del repositorio en las instancias de la capa.

La receta tomcat::deploy debe asignarse al evento Deploy del ciclo de vida.

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

La receta tomcat::deploy utiliza el libro de recetas de implementación integrado para aspectos de implementación que no son específicos de la aplicación. La receta deploy (que es la forma abreviada de la receta integrada deploy::default) es una receta integrada que administra los detalles de configuración de los usuarios, los grupos, etc., en función de los datos de los atributos deploy.

La receta utiliza dos definiciones de Chef integradas, opsworks_deploy_dir y opworks_deploy, para instalar la aplicación.

La definición opsworks_deploy_dir configura la estructura de directorios en función de los datos del JSON de implementación de la aplicación. Las definiciones son básicamente una cómoda forma de empaquetar las definiciones de los recursos y se encuentran en el directorio definitions de un libro de recetas. Las recetas pueden utilizar definiciones de forma similar a los recursos, pero la definición por sí misma no tiene un proveedor asociado, solo los recursos incluidos en ella. Puede definir variables en la receta, que se pasan a las definiciones de los recursos subyacentes. La receta tomcat::deploy establece las variables user, group y path según los datos del JSON de implementación. Se pasan al recurso de directorios de la definición, que administra los directorios.

nota

El usuario y el grupo de su aplicación implementada vienen determinados por los atributos [:opsworks][:deploy_user][:user] y [:opsworks][:deploy_user][:group], que se definen en el archivo de atributos deploy.rb del libro de recetas de implementación integrado. El valor predeterminado de [:opsworks][:deploy_user][:user] es deploy. El valor predeterminado de [:opsworks][:deploy_user][:group] depende del sistema operativo de la instancia:

• Para las instancias de Ubuntu, el grupo predeterminado es www-data.

• Para las instancias de Amazon Linux que pertenecen a una capa del servidor de aplicaciones de Rails que usa Nginx y Unicorn, el grupo predeterminado es nginx.

• Para todas las demás instancias de Amazon Linux, el grupo predeterminado es apache.

Puede cambiar cualquier valor utilizando JSON personalizado o un archivo de atributos personalizados para anular el atributo correspondiente. Para obtener más información, consulte Anulación de atributos.

La otra definición, opsworks_deploy, administra los detalles de la comprobación de código y los archivos relacionados de la aplicación del repositorio y los implementa en la instancia, en función de los datos de los atributos deploy. Puede utilizar esta definición con cualquier tipo de aplicación; los detalles de implementación como, por ejemplo, los nombres de directorio, se especifican en la consola o a través de la API, y se incluyen en los atributos deploy. No obstante, opsworks_deploy funciona únicamente con los cuatro tipos de repositorio admitidos: Git, Subversion, S3 y HTTP. Debe implementar este código manualmente si desea utilizar otro tipo de repositorio.

Puede instalar los archivos de una aplicación en el directorio webapps de Tomcat. Una práctica habitual es copiar los archivos directamente en webapps. Sin embargo, la implementación de AWS OpsWorks Stack está diseñada para conservar hasta cinco versiones de una aplicación en una instancia, por lo que puedes volver a una versión anterior si es necesario. AWS OpsWorks Por lo tanto, Stacks hace lo siguiente:

1. Implementa las aplicaciones en un directorio distinto cuyo nombre contiene una marca temporal, como /srv/www/my_1st_jsp/releases/20130731141527.

2. Crea un symlink llamado current, como /srv/www/my_1st_jsp/current, en este directorio único.

3. Si no existe, crea un symlink desde el directorio webapps en el symlink current creado en el paso 2.

Si necesita volver a una versión anterior, modifique el symlink current para que apunte a un directorio distinto que contenga la marca temporal adecuada, por ejemplo, cambiando el destino del enlace de /srv/www/my_1st_jsp/current.

La sección central de tomcat::deploy configura el 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
  ...

La primera receta crea dos variables, current_dir y webapp_dir para representar los directorios current y webapp, respectivamente. A continuación, utiliza un recurso link para vincular webapp_dir con current_dir. La deploy::default receta de AWS OpsWorks Stacks crea algunos directorios auxiliares que no son necesarios para este ejemplo, por lo que la parte central del extracto los elimina.

La parte final de tomcat::deploy reinicia el servicio de Tomcat, si es necesario.

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

La receta ejecuta en primer lugar tomcat::service para garantizar que el servicio se defina para esta ejecución de Chef. Después, utiliza un recurso execute para notificar al servicio el reinicio, pero solo si ['tomcat']['auto_deploy'] se establece en 'true'. De lo contrario, Tomcat permanece a la escucha de posibles cambios en su directorio webapps, lo que hace innecesario reiniciar un servicio de Tomcat explícito .

nota

El recurso execute no ejecuta nada realmente sustancial; /bin/true es un script de shell ficticio que simplemente devuelve un código de éxito. Se utiliza aquí como una forma cómoda de generar una notificación de reinicio. Como se ha mencionado anteriormente, la utilización de las notificaciones garantiza que los servicios no se reinicien con demasiada frecuencia.

Por último, tomcat::deploy ejecuta tomcat::context, que actualiza el archivo de configuración de contexto de la aplicación web si ha cambiado la base de datos de back-end.