Prácticas recomendadas: administración e implementación de aplicaciones y libros de 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.

AWS OpsWorks Stacks despliega aplicaciones y libros de cocina en cada nueva instancia desde un repositorio remoto. Durante la vida de una instancia, a menudo hay que actualizar las aplicaciones o los libros de recetas de las instancias online de la pila para añadir características, solucionar errores, etc. Existen diversas formas de administrar las aplicaciones y los libros de recetas de una pila, pero el enfoque que elija debe cumplir los siguientes requisitos generales:

• Todas las instancias de la pila de producción deben tener el mismo código de aplicación y de libro de recetas personalizado, con excepciones limitadas como las pruebas A/B.

• La implementación de una actualización no debe interrumpir el buen funcionamiento del sitio, incluso si hay algún problema.

En esta sección se describen las prácticas recomendadas para administrar e implementar aplicaciones y libros de recetas personalizados.

Mantenimiento de la coherencia

En general, debe mantener un estrecho control sobre el código de la aplicación o del libro de recetas que se ejecuta en la pila de producción. Normalmente, todas las instancias deben ejecutar la versión aprobada actualmente del código. Se aplica alguna excepción al actualizar las aplicaciones o los libros de recetas, tal y como se describe más tarde, y en casos especiales como, por ejemplo, al realizar pruebas A/B.

El código de la aplicación y del libro de recetas se implementa desde un repositorio de origen específico en las instancias de la pila de las dos formas siguientes:

• Cuando inicias una instancia, AWS OpsWorks Stacks implementa automáticamente el código de la aplicación y el libro de cocina actuales en la instancia.

• Para las instancias online, debe implementar el código actual de la aplicación o del libro de recetas de forma manual o mediante la ejecución de un comando Deploy (para aplicaciones) o de un comando Update Custom Cookbooks (para libros de recetas).

Dado que existen dos mecanismos de implementación, es de vital importancia que administre su código fuente con cuidado para evitar que se ejecute un código diferente por error en otras instancias. Por ejemplo, si despliegas aplicaciones o libros de cocina desde una rama maestra de Git, AWS OpsWorks Stacks despliega lo que hay en esa rama en ese momento. Si actualiza el código en la ramificación maestra y, a continuación, inicia una nueva instancia, dicha instancia tendrá una versión más reciente del código que las instancias más antiguas. Es posible que la versión más reciente ni siquiera esté aprobada por producción.

Recomendación: archivos de Amazon S3

Para garantizar que todas las instancias dispongan de la versión del código aprobada, le recomendamos que implemente las aplicaciones y los libros de recetas desde un archivo Amazon Simple Storage Service (Amazon S3). De este modo se garantiza que el código es un elemento estático (un archivo .zip u otro fichero de archivo) que debe actualizarse de forma explícita. Además, Amazon S3 es muy fiable, por lo que es muy poco probable (o casi imposible) que no pueda obtener acceso al archivo. Para garantizar aún más la coherencia, realice un control de versiones explícito de cada fichero de archivo mediante el uso de una convención de nomenclatura o del control de versiones de Amazon S3, que proporciona un registro de auditoría y una forma sencilla de volver a la versión anterior.

Por ejemplo, podría crear una canalización de implementación utilizando una herramienta como Jenkins. Después de validar y probar el código que desea implementar, cree un fichero de archivo y cárguelo en Amazon S3. Todas las implementaciones de aplicaciones o actualizaciones de libros de recetas instalarán el código en dicho archivo de almacenamiento y todas las instancias tendrán el mismo código.

Recomendación: repositorios Git o Subversion

Si prefiere utilizar un repositorio Git o Subversion, no implemente desde la ramificación maestra. En su lugar, etiquete la versión aprobada y especifique que dicha versión es el origen de la aplicación o del libro de recetas.

Implementación del código en instancias online

AWS OpsWorks Stacks no implementa automáticamente el código actualizado en las instancias en línea. Debe realizar dicha operación manualmente, cosa que plantea los siguientes retos:

• Implementar la actualización de forma eficaz sin comprometer la capacidad del sitio de gestionar las solicitudes de los clientes durante el proceso de implementación.

• Gestionar una implementación que no se ha ejecutado correctamente, ya sea debido a problemas con la aplicación o los libros de recetas implementadas o problemas con el propio proceso de implementación.

El enfoque más sencillo consiste en ejecutar un comando Deploy predeterminado (para las aplicaciones) o un comando Update Custom Cookbooks (para los libros de recetas), que implementa la actualización en cada instancia de forma simultánea. Este método es sencillo y rápido, pero no se pueden cometer errores. Si la implementación no se ejecuta correctamente o el código actualizado tiene algún problema, cada instancia de su pila de producción podría verse afectada, lo que podría interrumpir o desactivar su sitio hasta que pueda solucionar el problema o volver a la versión anterior.

Recomendación: utilice una estrategia de implementación sólida que permita a las instancias ejecutar la versión antigua del código para continuar gestionando las solicitudes hasta que haya comprobado que la implementación se ha realizado correctamente y pueda transferir de forma fiable todo el tráfico entrante a la nueva versión.

En las secciones siguientes se proporcionan dos ejemplos de estrategias de implementación sólidas y se abre un debate sobre cómo administrar una base de datos de backend durante la implementación. Brevemente, describen las actualizaciones de las aplicaciones, aunque puede utilizar estrategias similares para libros de recetas.

Temas

• Uso de una implementación continua
• Uso de pilas distintas
• Administración de una base de datos de backend

Uso de una implementación continua

Una implementación continua actualiza una aplicación en las instancias del servidor de aplicaciones online de una pila en varias fases. En cada fase se actualiza un subconjunto de instancias online y se verifica que la actualización se ha realizado correctamente antes de iniciar la siguiente fase. Si hay problemas, las instancias que todavía se están ejecutando en la versión antigua de la aplicación pueden seguir gestionando el tráfico entrante hasta que se resuelva el problema.

En el siguiente ejemplo se parte de la base de que se está utilizando la práctica recomendada de distribuir las instancias del servidor de aplicaciones de la pila entre varias zonas de disponibilidad.

Para realizar una implementación continua

1. En la página Deploy App, elija Advanced (Avanzado) y una única instancia del servidor de aplicaciones e implemente la aplicación en dicha instancia.

   Para ser prudente, puede eliminar la instancia del balanceador de carga antes implementar la aplicación. De este modo, se garantiza que los usuarios no se encuentren con la aplicación actualizada hasta que se haya verificado que funciona correctamente. Si utiliza Elastic Load Balancing, elimine la instancia del equilibrador de carga mediante la consola Elastic Load Balancing, la CLI o un SDK.

2. Compruebe que la aplicación actualizada funciona correctamente y que la instancia dispone de unas métricas de desempeño aceptables.

   Si ha eliminado la instancia de un equilibrador de carga Elastic Load Balancing, utilice la consola Elastic Load Balancing, la CLI o un SDK. Ahora, la versión actualizada de la aplicación gestiona las solicitudes de los usuarios.

3. Implemente la actualización en el resto de instancias de la zona de disponibilidad y verifique que funcionan correctamente y que disponen de métricas aceptables.

4. Repita el paso 3 para las otras zonas de disponibilidad de la pila, una zona cada vez. Si quiere ser muy prudente, repita los pasos 1 a 3.

nota

Si utiliza un equilibrador de carga de Elastic Load Balancing, puede utilizar su comprobación de estado para verificar que la implementación se ha realizado correctamente. Sin embargo, defina la ruta de ping hacia una aplicación que comprueba las dependencias y verifica que todo funciona correctamente, no hacia un archivo estático que simplemente confirma que el servidor de aplicaciones se está ejecutando.

Uso de pilas distintas

Otro método para administrar aplicaciones es utilizar una pila distinta para cada fase del ciclo de vida de la aplicación. A las pilas distintas a veces se las denomina entornos. Esta organización permite realizar el desarrollo y las pruebas en pilas que no son accesibles al público. Cuando esté listo para implementar una actualización, cambie el tráfico del usuario de la pila que aloja la versión actual de la aplicación a la pila que aloja la versión actualizada.

Temas

• Uso de pilas de desarrollo, de ensayo y de producción
• Uso de una estrategia de implementación azul-verde

Uso de pilas de desarrollo, de ensayo y de producción

El enfoque más común utiliza las siguientes pilas.

Pila de desarrollo

Utilice una pila de desarrollo para tareas como la implementación de funciones nuevas o para solucionar errores. Una pila de desarrollo es básicamente un prototipo de pila de producción, con las mismas capas, aplicaciones, recursos, etc. que se incluyen en la pila de producción. Dado que la pila de desarrollo normalmente no tiene que gestionar la misma carga que la pila de producción, puede utilizar menos instancias o más pequeñas.

Las pilas de desarrollo no están expuestas al público. Puede controlar el acceso a las mismas de la siguiente manera:

• Restrinja el acceso a la red mediante la configuración de reglas de entrada del grupo de seguridad del servidor de aplicaciones o del balanceador de carga para aceptar solicitudes entrantes solo desde rangos de direcciones o de direcciones IP específicas.

  Por ejemplo, limite el acceso HTTP, HTTPS y SSH a direcciones de su rango de direcciones de la empresa.

• Controla el acceso a la funcionalidad de administración de pilas de AWS OpsWorks Stacks mediante la página de permisos de la pila.

  Por ejemplo, conceda un nivel de permisos Manage al equipo de desarrollo y permisos Show a todos los demás empleados.

Pila de ensayo

Utilice una pila de ensayo para probar y finalizar los candidatos para una pila de producción actualizada. Cuando haya completado el desarrollo, cree una pila de ensayo mediante la clonación de la pila de desarrollo. A continuación, ejecute el conjunto de pruebas en la pila de ensayo e implemente las actualizaciones en dicha pila para solucionar los problemas que surjan.

Las pilas de ensayo tampoco están expuestas al público. El acceso a la red y la pila se controla de la misma forma que para la pila de desarrollo. Ten en cuenta que cuando clonas una pila de desarrollo para crear una pila provisional, puedes clonar los permisos otorgados por la administración de permisos de AWS OpsWorks Stack. Sin embargo, la clonación no afecta a los permisos concedidos por las políticas de IAM de los usuarios. Se debe utilizar la consola de IAM, la CLI o un SDK para modificar dichos permisos. Para obtener más información, consulte Administración de permisos de usuario.

Pila de producción

La pila de producción es la pila expuesta al público que es compatible con la aplicación actual. Cuando la pila de ensayo supera las pruebas, pasa a producción y se elimina la antigua pila de producción. Para ver un ejemplo práctico, consulte Uso de una estrategia de implementación azul-verde.

nota

En lugar de usar la consola de AWS OpsWorks Stacks para crear pilas manualmente, crea una AWS CloudFormation plantilla para cada pila. Este enfoque tiene las siguientes ventajas:

• Velocidad y comodidad: al lanzar la plantilla, AWS CloudFormation crea la pila automáticamente, incluidas todas las instancias necesarias.

• Coherencia: almacene la plantilla para cada pila en el repositorio de origen para garantizar que los desarrolladores utilizan la misma pila para el mismo fin.

Uso de una estrategia de implementación azul-verde

Una estrategia azul-verde es una forma común de utilizar pilas distintas de forma eficaz para implementar una actualización de la aplicación en la producción.

• El entorno de color azul es la pila de producción, que aloja la aplicación actual.

• El entorno de color verde es la pila de ensayo, que aloja la aplicación actualizada.

Cuando esté listo para implementar la aplicación actualizada en la producción, cambie el tráfico del usuario de la pila azul a la pila verde, que pasa a ser la pila de producción nueva. A continuación, retire la pila azul antigua.

En el siguiente ejemplo se describe cómo realizar una implementación azul-verde con pilas de AWS OpsWorks Stacks junto con Route 53 y un grupo de equilibradores de carga de Elastic Load Balancing. Antes de realizar el cambio, debe asegurarse de lo siguiente:

• La actualización de la aplicación en la pila verde ha superado las pruebas y está lista para la producción.

• La pila verde es idéntica a la pila azul salvo que incluye la aplicación actualizada y no está expuesta al público.

  Ambas pilas tienen los mismos permisos, el mismo número y tipo de instancia en cada capa, la misma configuración basada en tiempo y en carga, etc.

• Todas las instancias de funcionamiento ininterrumpido de la pila verde y todas las instancias basadas en tiempo programadas están online.

• Dispone de un conjunto de equilibradores de carga de Elastic Load Balancing que se puede adjuntar de forma dinámica a una capa en cada pila y se puede precalentar para gestionar el volumen del tráfico esperado.

• Ha utilizado la característica de enrutamiento ponderado Route 53 para crear un conjunto de registros en una zona alojada que incluye los equilibradores de carga agrupados.

• Ha asignado un peso diferente de cero al balanceador de carga que se adjunta a la capa del servidor de aplicaciones de la pila azul y un peso igual a cero para los balanceadores de carga sin usar. Esto garantiza que el balanceador de carga de la pila azul gestione todo el tráfico entrante.

Para cambiar a los usuarios a la pila verde

1. Adjunte uno de los balanceadores de carga sin usar del grupo a la capa del servidor de aplicaciones de la pila verde. En algunos casos como, por ejemplo, cuando se espera tráfico flash o si no puede configurar una prueba de carga para aumentar el tráfico gradualmente, precaliente el balanceador de carga para gestionar el tráfico esperado.

2. Después de que todas las instancias de la pila verde hayan superado la comprobación de estado de Elastic Load Balancing, cambie los pesos en el conjunto de registros de Route 53 para que el equilibrador de carga de la pila verde tenga un peso distinto de cero y que el equilibrador de carga de la pila azul tenga un peso reducido proporcionalmente. Le recomendamos que empiece haciendo que la pila verde gestione un pequeño porcentaje de solicitudes, quizás un 5 %, y que la pila azul gestione el resto. Ahora dispone de dos pilas de producción: la pila verde gestiona algunas de las solicitudes entrantes y la pila azul gestiona el resto.

3. Monitorice las métricas de desempeño de la pila verde. Si son aceptables, aumente el peso de la pila verde de forma que gestione alrededor del 10 % del tráfico entrante.

4. Repita el paso 3 hasta que la pila verde gestione aproximadamente la mitad del tráfico entrante. Si hubiera algún problema, ya habría surgido a estas alturas, de modo que si la pila verde tiene un desempeño razonable, puede completar el proceso reduciendo el peso de la pila azul a cero. La pila verde es ahora la nueva pila azul y gestiona todo el tráfico entrante.

5. Suelte el balanceador de carga de la capa del servidor de aplicaciones de la pila azul antigua y devuélvalo al grupo.

6. Aunque la pila azul antigua ya no gestiona las solicitudes de los usuarios, le recomendamos conservarla durante un tiempo en caso de que surjan problemas con la pila azul nueva. En ese caso, podrá anular la actualización revirtiendo el procedimiento para dirigir el tráfico entrante de nuevo a la pila azul antigua. Cuando esté seguro de que la pila azul nueva funciona de forma correcta, apague la pila azul antigua.

Administración de una base de datos de backend

Si tu aplicación depende de una base de datos interna, tendrás que hacer la transición de la aplicación anterior a la nueva. AWS OpsWorks Stacks admite las siguientes opciones de bases de datos.

Capa Amazon RDS

Con una capa Amazon Relational Database Service (Amazon RDS), se crea la instancia de base de datos de RDS de forma independiente y luego se registra con la pila. Solo puede registrar una instancia de base de datos de RDS con una sola pila cada vez, pero puede cambiar una instancia de base de datos de RDS de una pila a otra.

AWS OpsWorks Stacks instala un archivo con los datos de conexión en tus servidores de aplicaciones en un formato que tu aplicación pueda usar fácilmente. AWS OpsWorks Stacks también agrega la información de conexión a la base de datos a los atributos de configuración e implementación de la pila, a los que se puede acceder mediante recetas. También puede usar JSON para proporcionar los datos de conexión a las aplicaciones. Para obtener más información, consulte Conexión a una base de datos.

La actualización de una aplicación que depende de una base de datos plantea dos retos básicos:

• Garantizar que cada transacción se registre correctamente durante la transición y, al mismo tiempo, evitar que se den condiciones de carrera entre las versiones nueva y antigua de la aplicación.

• Realizar la transición de forma que afecte lo más mínimo al desempeño del sitio y se minimice o elimine el tiempo de inactividad.

Al utilizar las estrategias de implementación descritas en este tema, no puede simplemente separar la base de datos de la aplicación antigua y reconectarla con la nueva. Ambas versiones de la aplicación se ejecutan en paralelo durante la transición y deben obtener acceso a los mismos datos. A continuación se describen dos enfoques para administrar la transición, los cuales presentan tanto ventajas como retos.

Enfoque 1: Que ambas aplicaciones se conecten a la misma base de datos

Ventajas

• No existe tiempo de inactividad durante la transición.

  Una aplicación deja de obtener acceso a la base de datos de manera gradual mientras que la otra toma el control de manera gradual.

• No tiene que sincronizar datos entre dos bases de datos.

Retos

• Ambas aplicaciones obtienen acceso a la misma base de datos, por lo que debe administrar el acceso para evitar la pérdida o la corrupción de datos.

• Si necesita migrar a un nuevo esquema de base de datos, la versión antigua de la aplicación debe poder utilizar el nuevo esquema.

Si utiliza pilas independientes, este enfoque es probablemente más adecuado para Amazon RDS, ya que la instancia no está conectada de forma permanente a una pila determinada y las aplicaciones que se ejecutan en pilas distintas pueden obtener acceso a ella. Sin embargo, no puede registrar una instancia de base de datos de RDS con más de una pila cada vez, por lo que debe proporcionar los datos de conexión a ambas aplicaciones, por ejemplo, mediante el uso de JSON. Para obtener más información, consulte Uso de una receta personalizada.

Si utiliza una actualización continua, las versiones nueva y antigua de la aplicación se alojan en la misma pila, de modo que puede utilizar una capa Amazon RDS o MySQL.

Enfoque 2: Proporcionar a cada versión de la aplicación su propia base de datos

Ventajas

• Cada versión tiene su propia base de datos, por lo que los esquemas no tienen que ser compatibles.

Retos

• Sincronizar los datos entre dos bases de datos durante la transición sin perder o corromper los datos.

• Garantizar que el proceso de sincronización no genere tiempos de inactividad significativos o degrade el desempeño del sitio de forma notable.

Si utiliza pilas diferentes, cada una tiene su propia base de datos. Si utiliza una implementación continua, puede adjuntar dos bases de datos a la pila, una para cada aplicación. Si las aplicaciones antigua y actualizada no son compatibles con los esquemas de bases de datos, este enfoque es mejor.

Recomendación: en general, le recomendamos que utilice una capa Amazon RDS como base de datos de backend de una aplicación porque es más flexible y se puede utilizar para cualquier escenario de transición. Para obtener más información acerca de cómo gestionar transiciones, consulte la Guía del usuario de Amazon RDS.