Implementación de aplicaciones en entornos Elastic Beanstalk

Puede utilizar la consola de AWS Elastic Beanstalk con el objetivo de cargar un paquete de código fuente actualizado e implementarlo en el entorno de Elastic Beanstalk o para volver a implementar una versión que se cargó anteriormente.

Cada implementación se identifica a través de un ID de implementación Los ID de implementación empiezan a partir de 1 y van a aumentando en una unidad con cada implementación y cada cambio de configuración de la instancia. Si habilita los informes de estado avanzados, Elastic Beanstalk muestra el ID de implementación en la consola de estado y en la CLI de EB cuando notifica el estado de la instancia. El ID de implementación le ayuda a determinar el estado del entorno cuando se produce un error en una actualización continua.

Elastic Beanstalk proporciona varias políticas y configuraciones de implementación. Para obtener información detallada sobre la configuración de una política y opciones adicionales, consulte Políticas y ajustes de implementación. En la tabla siguiente se enumeran las políticas y los tipos de entornos que las admiten.

Políticas de implementación admitidas
Política de implementación	Entornos con balanceo de carga	Entornos de una sola instancia	Entornos de Windows Server heredados†
Todo a la vez	Sí	Sí	Sí
Continua	Sí	No	Sí
Continua con un lote adicional	Sí	No	No
Inmutable	Sí	Sí	No
División de tráfico	Sí (Balanceador de carga de aplicaciones).	No	No

†En esta tabla, un entorno Windows Server heredado es un entorno basado en una configuración de plataforma de Windows Server que utiliza una versión de IIS anterior a la IIS 8.5.

aviso

Algunas políticas reemplazan todas las instancias durante la implementación o actualización. Esto provoca la pérdida de todos los saldos de ráfagas de Amazon EC2 acumulados. Sucede en los siguientes casos:

• Actualizaciones de plataforma administradas con reemplazo de instancias habilitado

• Actualizaciones inmutables

• Implementaciones con actualizaciones inmutables o división de tráfico habilitada

Elección de una política de implementación

Elegir la política de implementación adecuada para su aplicación es un balance de algunas consideraciones, y depende de sus necesidades particulares. La página Políticas y ajustes de implementación tiene más información sobre cada política y una descripción detallada del funcionamiento de algunas de ellas.

En la lista siguiente se proporciona información resumida sobre las diferentes políticas de implementación y se agregan consideraciones relacionadas.

• Todo a la vez: el método de implementación más rápido. Adecuado si puede aceptar una breve pérdida de servicio y si las implementaciones rápidas son importantes para usted. Con este método, Elastic Beanstalk implementa la nueva versión de la aplicación en cada instancia. A continuación, es posible que el proxy web o el servidor de aplicaciones necesite reiniciar. Como resultado, es posible que la aplicación no esté disponible para los usuarios (o tenga poca disponibilidad) durante un corto período de tiempo.

• Continua: evita el tiempo de inactividad y minimiza la disponibilidad reducida, a un costo de más tiempo de implementación. Adecuado si usted no puede aceptar cualquier período de servicio perdido por completo. Con este método, la aplicación se implementa en el entorno una serie de instancias a la vez. La mayor parte del ancho de banda se conserva durante toda la implementación.

• Continua con lote adicional: evita cualquier disponibilidad reducida, a un costo de un tiempo de implementación aún mayor en comparación con el método Continua. Adecuado si debe mantener el mismo ancho de banda durante toda la implementación. Con este método, Elastic Beanstalk inicia un lote adicional de instancias y, a continuación, realiza una implementación sucesiva. El inicio del lote adicional lleva tiempo y garantiza que se conserve el mismo ancho de banda durante toda la implementación.

• Inmutable: método de implementación más lento, que garantiza que la nueva versión de la aplicación siempre se implementa en instancias nuevas, en lugar de actualizar instancias existentes. También tiene la ventaja adicional de una restauración rápida y segura en caso de que falle la implementación. Con este método, Elastic Beanstalk realiza una actualización inmutable para implementar la aplicación. En una actualización inmutable, se lanza un segundo grupo de Auto Scaling en el entorno y la nueva versión administra el tráfico junto con la versión antigua hasta que las nuevas instancias superan las comprobaciones de estado.

• División de tráfico: método de implementación de pruebas de canary. Adecuado si desea probar el estado de la nueva versión de la aplicación utilizando una parte del tráfico entrante, mientras mantiene el resto del tráfico servido por la versión anterior de la aplicación.

En la tabla siguiente se comparan las propiedades de los métodos de implementación.

Métodos de implementación
Método	Repercusión de la implementación con errores	Tiempo de implementación	Sin inactividad	Sin cambios de DNS	Proceso de restauración	El código se implementa en
Todo a la vez	Tiempo de inactividad.		No	Sí	Nueva implementación manual	Instancias existentes
Continua	Un lote fuera de servicio y los lotes implementados correctamente antes del error ejecutan la nueva versión de la aplicación.	†	Sí	Sí	Nueva implementación manual	Instancias existentes
Continua con un lote adicional	Mínima si se produce un error en el primer lote; de lo contrario, similar a Rolling (Continua).	†	Sí	Sí	Nueva implementación manual	Instancias nuevas y existentes
Inmutable	Mínima		Sí	Sí	Terminar nuevas instancias	Instancias nuevas
División de tráfico	Porcentaje de tráfico del cliente dirigido a la nueva versión afectada temporalmente	††	Sí	Sí	Redireccionar tráfico y finalizar nuevas instancias	Instancias nuevas
Azul/verde	Mínima		Sí	No	Intercambio de URL	Instancias nuevas

† Varía en función del tamaño del lote.

††Varía en función de la configuración de la opción de tiempo de evaluación.

Implementación de una nueva versión de la aplicación

Puede realizar las implementaciones desde el panel del entorno.

Para implementar una nueva versión de aplicación en un entorno de Elastic Beanstalk

1. Abra la consola de Elastic Beanstalk y, en la lista Regions (Regiones), seleccione su Región de AWS.

2. En el panel de navegación, elija Environments (Entornos) y, a continuación, elija el nombre del entorno en la lista.

   nota

   Si tiene muchos entornos, utilice la barra de búsqueda para filtrar la lista de entornos.

3. Elija Upload and Deploy (Cargar e implementar).

4. Utilice el formulario en pantalla para cargar el paquete de código fuente de la aplicación.

5. Elija Implementar.

Nueva implementación de una versión anterior

También puede implementar una versión de la aplicación cargada anteriormente en cualquiera de los entornos desde la página de versiones de la aplicación.

Para implementar una versión de la aplicación existente en un entorno existente

1. Abra la consola de Elastic Beanstalk y, en la lista Regions (Regiones), seleccione su Región de AWS.

2. En el panel de navegación, elija Applications (Aplicaciones) y, a continuación, elija el nombre de la aplicación de la lista.

   nota

   Si tiene muchas aplicaciones, utilice la barra de búsqueda para filtrar la lista de aplicaciones.

3. En el panel de navegación, busque el nombre de la aplicación y elija Application versions (Versiones de la aplicación).

4. Seleccione la versión de la aplicación que desee implementar.

5. Elija Actions (Acciones) y a continuación seleccione Deploy (Implementar).

6. Seleccione un entorno y elija Deploy (Implementar).

Otras formas de implementar la aplicación

Si realiza implementaciones con frecuencia, considere la posibilidad de utilizar la interfaz de línea de comandos de Elastic Beanstalk (CLI de EB) para administrar los entornos. La CLI de EB crea un repositorio junto con su código fuente. También puede crear un paquete fuente, cargarlo en Elastic Beanstalk e implementarlo con un solo comando.

En el caso de las implementaciones que dependen de los cambios de configuración de recursos o de una versión nueva que no se puede ejecutar junto con la versión antigua, puede lanzar un entorno nuevo con la versión nueva y realizar un intercambio de CNAME en una implementación "blue/green" (azul/verde).