Políticas y ajustes de implementación - AWS Elastic Beanstalk

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Políticas y ajustes de implementación

AWS Elastic Beanstalk dispone de varias opciones para definir cómo se procesarán las implementaciones, tales como las políticas de implementación (Todo a la vez, Continua, Continua con lote adicional, Inmutable y División de tráfico) y opciones que le permiten configurar el tamaño de los lotes y el comportamiento de las comprobaciones de estado durante las implementaciones. De forma predeterminada, su entorno utiliza implementaciones de tipo "todo a la vez". Si ha creado el entorno con la CLI de EB y es un entorno escalable (no especificó la opción --single), este utiliza implementaciones continuas.

Con implementaciones continuas, Elastic Beanstalk divide las instancias de Amazon EC2 del entorno en lotes e implementa la nueva versión de la aplicación en un lote cada vez. Deja el resto de las instancias en el entorno ejecutando la versión anterior de la aplicación. Durante la implementación continua, algunas instancias atienden solicitudes con la versión antigua de la aplicación, mientras que las instancias de los lotes completados atienden otras solicitudes con la nueva versión. Para obtener más información, consulte Funcionamiento de las implementaciones continuas.

Para mantener toda la capacidad durante las implementaciones, puede configurar el entorno para lanzar un nuevo lote de instancias antes de que alguna de estas instancias se quede fuera de servicio. Esta opción se conoce como implementación continua con un lote adicional. Cuando la implementación se completa, Elastic Beanstalk termina el lote adicional de instancias.

Las implementaciones inmutables ejecutan una actualización inmutable para lanzar un conjunto completo de instancias nuevas con la versión nueva de la aplicación en otro grupo de Auto Scaling, junto con las instancias que ejecutan la versión antigua. Las implementaciones inmutables pueden impedir que se produzcan los problemas causados por las implementaciones continuas realizadas parcialmente. Si las nuevas instancias no superan las comprobaciones de estado, Elastic Beanstalk las termina y deja las instancias originales tal y como estaban.

Las implementaciones de división de tráfico le permiten realizar pruebas de canary controlados como parte de la implementación de la aplicación. En una implementación de división de tráfico, Elastic Beanstalk lanza un conjunto completo de instancias nuevas al igual que durante una implementación inmutable. A continuación, reenvía un porcentaje especificado del tráfico de cliente entrante a la nueva versión de la aplicación durante un período de evaluación especificado. Si las nuevas instancias permanecen en buen estado, Elastic Beanstalk les reenvía todo el tráfico a ellas y termina las antiguas. Si las nuevas instancias no pasan las comprobaciones de estado, o si decide anular la implementación, Elastic Beanstalk devuelve el tráfico a las instancias antiguas y termina las nuevas. Nunca hay interrupción del servicio. Para obtener más información, consulte Funcionamiento de las implementaciones de división de tráfico.

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

Si la aplicación no supera todas las comprobaciones de estado, pero funciona correctamente con un nivel de corrección inferior, puede permitir que las instancias superen las comprobaciones de estado con un nivel de corrección inferior (por ejemplo, Warning) modificando la opción Healthy threshold (Umbral de buen estado). Si se producen errores en las implementaciones por no superar las comprobaciones de estado y necesita aplicar forzosamente la actualización con independencia del estado que tengan, establezca la opción Ignore health check (ignorar comprobación de buen estado).

Si especifica un tamaño de lote en las actualizaciones continuas, Elastic Beanstalk utilizará también ese valor para los reinicios continuos de las aplicaciones. Utilice los reinicios continuos cuando necesite reiniciar el servidor proxy y el servidor de aplicaciones que se ejecutan en las instancias del entorno sin tiempo de inactividad.

Configuración de la implementación de aplicaciones

En la consola de administración del entorno, habilite y configure implementaciones de versiones basadas en lotes. Para ello, edite Updates and Deployments (Actualizaciones e implementaciones) en la página Configuration (Configuración) del entorno.

Para configurar las implementaciones (consola)
  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. En el panel de navegación, elija Configuration (Configuración).

  4. En la categoría de configuración Rolling updates and deployments (Actualizaciones acumulativas e implementaciones), elija Edit (Editar).

  5. En la sección Application Deployments (Implementaciones de aplicación), elija Deployment policy (Política de implementación), la configuración por lotes y las opciones de comprobación de estado.

  6. Para guardar los cambios, elija Aplicar en la parte inferior de la página.

La sección Application Deployments (Implementaciones de aplicaciones) de la página Rolling updates and deployments (Actualizaciones e implementaciones continuas) contiene las siguientes opciones para las implementaciones de aplicaciones:

  • Deployment policy (Política de implementación). Seleccione una de las siguientes opciones de implementación:

    • All at once (Todo a la vez): implemente la nueva versión en todas las instancias a la vez. Todas las instancias del entorno se quedarán fuera de servicio durante un breve periodo de tiempo, mientras tiene lugar la implementación.

    • Rolling (Continua): implemente la nueva versión por lotes. Cada lote se queda fuera de servicio durante la fase de implementación, lo que reduce la capacidad del entorno en el número de instancias que tenga el lote.

    • Rolling with additional batch (Continua con un lote adicional): implemente la nueva versión por lotes, pero lance primero un nuevo lote de instancias para asegurarse de que cuenta con toda la capacidad durante el proceso de implementación.

    • Immutable (Inmutable): implemente la nueva versión en un nuevo grupo de instancias a través de una actualización inmutable.

    • Traffic splitting (División de tráfico): implemente la nueva versión en un nuevo grupo de instancias y divida temporalmente el tráfico de cliente entrante entre la versión de la aplicación existente y la nueva.

Para las políticas de implementación Rolling (Continua) y Rolling with additional batch (Continua con lote adicional) puede configurar:

  • Batch size (Tamaño del lote): el tamaño del conjunto de instancias que se deben implementar en cada lote.

    Elija Percentage (Porcentaje) para configurar un porcentaje del número total de instancias EC2 del grupo de Auto Scaling (hasta el 100%) o elija Fixed (Fijo) para configurar un número fijo de instancias (hasta el número máximo de instancias de la configuración de Auto Scaling de su entorno).

Para la política de implementación Traffic splitting (División de tráfico) puede configurar lo siguiente:

  • Traffic split (Dividir tráfico): el porcentaje inicial del tráfico de cliente entrante que Elastic Beanstalk pasa a instancias de entorno que ejecutan la nueva versión de la aplicación que está implementando.

  • Traffic splitting evaluation time (Tiempo de evaluación de división de tráfico): el período de tiempo, en minutos, que Elastic Beanstalk espera después de una implementación inicial en buen estado antes de proceder a cambiar todo el tráfico de cliente entrante a la nueva versión de la aplicación que está implementando.


        Página de configuración de implementación de aplicaciones Elastic Beanstalk

La sección Deployment preferences (Preferencias de implementación) contiene opciones relacionadas con las comprobaciones de estado.

  • Ignore health check (omitir comprobación de estado): impide que se revierta una implementación cuando un lote no es capaz de adquirir un estado correcto durante el periodo de tiempo especificado en Command timeout.

  • Healthy threshold (Umbral de buen estado): reduce el umbral en el que una instancia se considera que está en buen estado durante las implementaciones continuas, las actualizaciones continuas y las actualizaciones inmutables.

  • Command timeout (Tiempo de espera del comando): número de segundos que debe esperarse a que una instancia adquiera un estado correcto antes de cancelar la implementación o, si se ha establecido Ignore health check (Omitir la comprobación de estado), antes de continuar con el lote siguiente.


        Página de configuración de implementaciones de aplicaciones Elastic Beanstalk

Funcionamiento de las implementaciones continuas

Cuando se procesa un lote, Elastic Beanstalk desconecta todas las instancias del lote del balanceador de carga, implementa la nueva versión de la aplicación y vuelve a conectar las instancias. Si habilita el vaciado de conexiones, Elastic Beanstalk vacía las conexiones existentes de las instancias EC2 de cada lote antes de comenzar la implementación.

Cuando las instancias de un lote vuelven a conectarse con el balanceador de carga, Elastic Load Balancing espera hasta que superan un número mínimo de comprobaciones de estado de Elastic Load Balanceador (el valor de Healthy check count threshold (Umbral de comprobación de buen estado)) y después reanuda el tráfico dirigido a ellas. Si no se ha configurado health check URL, esto puede producirse con mucha rapidez, ya que una instancia superará la comprobación de estado tan pronto como pueda aceptar una conexión TCP. Si se ha configurado una URL de comprobación de estado, el balanceador de carga no direcciona el tráfico a las instancias cargadas hasta que devuelven el código de estado 200 OK en respuesta a una solicitud HTTP GET enviada a la URL de comprobación de estado.

Elastic Beanstalk espera hasta que todas las instancias de un lote tienen un estado correcto antes de pasar al siguiente. Con los informes de estado básicos, el estado de la instancia depende del estado de comprobación de estado de Elastic Load Balancing. Cuando todas las instancias de un lote superan suficientes comprobaciones de estado como para que Elastic Load Balancing considere que tiene un estado correcto, el lote se ha completado. Si están habilitados los informes de estado avanzados, Elastic Beanstalk tiene en cuenta otros factores, como el resultado de las solicitudes entrantes. Con los informes de estado avanzados, todas las instancias deben superan 12 comprobaciones de estado consecutivas con el estado OK en un plazo de dos minutos en el caso de los entornos de servidor web y 18 comprobaciones en un plazo de tres minutos en el caso de los entornos de trabajo.

Si un lote de instancias no adopta un estado correcto durante el tiempo de espera del comando, la implementación no se realiza correctamente. Después de un error en la implementación, compruebe el estado de las instancias de su entorno para obtener información sobre la causa del error. A continuación, realice otra implementación con una versión correcta o corregida de la aplicación que desea restaurar.

Si se produce un error en la implementación después de que uno o varios lotes se han completado correctamente, los lotes completados ejecutarán la nueva versión de la aplicación, mientras que los lotes pendientes seguirán ejecutando la versión antigua. Puede identificar la versión que se ejecuta en las instancias del entorno en la página de estado de la consola. En esta página, se muestra el ID de la implementación de la última implementación que se ejecutó en cada instancia del entorno. Si termina las instancias de una implementación con errores, Elastic Beanstalk las reemplazará por instancias con la versión de la aplicación que se utilizó en la última implementación correcta.

Funcionamiento de las implementaciones de división de tráfico

Las implementaciones de división de tráfico le permiten realizar pruebas de canary controlados. Dirija un poco de tráfico de cliente entrante a la nueva versión de la aplicación para verificar el estado de la aplicación antes de confirmar la nueva versión y dirigir todo el tráfico a ella.

Durante una implementación de división de tráfico, Elastic Beanstalk crea un nuevo conjunto de instancias en un grupo temporal de Auto Scaling independiente. A continuación, Elastic Beanstalk indica al balanceador de carga que dirija un determinado porcentaje del tráfico entrante de su entorno a las nuevas instancias. A continuación, durante un período de tiempo configurado, Elastic Beanstalk realiza un seguimiento del estado del nuevo conjunto de instancias. Si todo está bien, Elastic Beanstalk desplaza el tráfico restante a las nuevas instancias y las asocia al grupo Auto Scaling original del entorno, reemplazando las instancias antiguas. A continuación, Elastic Beanstalk limpia: finaliza las instancias antiguas y elimina el grupo temporal Auto Scaling.

nota

La capacidad del entorno no cambia durante una implementación de división del tráfico. Elastic Beanstalk inicia el mismo número de instancias en el grupo temporal de Auto Scaling que en el grupo Auto Scaling original en el momento en que se inicia la implementación. A continuación, mantiene un número constante de instancias en ambos grupos Auto Scaling durante la duración de la implementación. Tenga en cuenta este hecho al configurar el tiempo de evaluación de división de tráfico del entorno.

Deshacer la implementación a la versión anterior de la aplicación es rápido y no afecta el servicio al tráfico del cliente. Si las nuevas instancias no pasan las comprobaciones de estado, o si decide anular la implementación, Elastic Beanstalk devuelve el tráfico a las instancias antiguas y termina las nuevas. Puede anular cualquier implementación mediante la página de descripción general del entorno de la consola de Elastic Beanstalk y eligiendo Abort current operation (Anular operación actual) en Enviroment actions (Acciones de entorno). También puede llamar a la API AbortEnvironmentUpdate o al comando equivalente de la AWS CLI.

Las implementaciones de división del tráfico requieren un balanceador de carga de aplicaciones. Elastic Beanstalk utiliza este tipo de balanceador de carga de forma predeterminada al crear su entorno mediante la consola de Elastic Beanstalk o la CLI de EB.

Espacios de nombres de opciones de implementación

Puede utilizar las opciones de configuración del espacio de nombres aws:elasticbeanstalk:command para configurar sus implementaciones. Si elige la política de división de tráfico, hay opciones adicionales disponibles para esta política en el espacio de nombres aws:elasticbeanstalk:trafficsplitting.

Utilice la opción DeploymentPolicy para establecer el tipo de implementación. Se admiten los siguientes valores:

  • AllAtOnce: deshabilita las implementaciones continuas e implementa siempre todas las instancias a la vez.

  • Rolling: habilita las implementaciones continuas estándar.

  • RollingWithAdditionalBatch: lanza un lote adicional de instancias, antes de comenzar la implementación, para mantener la capacidad completa.

  • Immutable: realiza una actualización inmutable de cada implementación.

  • TrafficSplitting: realiza implementaciones de división de tráfico para probar con canary las implementaciones de aplicaciones.

Cuando habilite las implementaciones continuas, defina las opciones BatchSize y BatchSizeType para configurar el tamaño de cada lote. Por ejemplo, para implementar el 25 % de todas las instancias en cada lote, especifique las siguientes opciones y valores.

ejemplo .ebextensions/rolling-updates.config
option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Rolling BatchSizeType: Percentage BatchSize: 25

Para realizar la implementación en cinco instancias en cada lote, independientemente del número de instancias en ejecución, y para crear un lote adicional de cinco instancias que ejecuten la versión nueva antes de dejar ninguna instancia fuera de servicio, especifique las siguientes opciones y valores.

ejemplo .ebextensions/rolling-additionalbatch.config
option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: RollingWithAdditionalBatch BatchSizeType: Fixed BatchSize: 5

Para ejecutar una actualización inmutable de cada implementación con el umbral de comprobación de estado Warning (Advetencia) y continuar con la implementación incluso si las instancias de un lote no superan las comprobaciones de estado durante un periodo de espera de 15 minutos, especifique las siguientes opciones y valores.

ejemplo .ebextensions/immutable-ignorehealth.config
option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: Immutable HealthCheckSuccessThreshold: Warning IgnoreHealthCheck: true Timeout: "900"

Para realizar implementaciones de división de tráfico, reenviando el 15 por ciento del tráfico de cliente a la nueva versión de la aplicación y evaluando el estado durante 10 minutos, especifique las opciones y valores siguientes.

ejemplo .ebextensions/traffic-splitting.config
option_settings: aws:elasticbeanstalk:command: DeploymentPolicy: TrafficSplitting aws:elasticbeanstalk:trafficsplitting: NewVersionPercent: "15" EvaluationTime: "10"

La CLI de EB y la consola de Elastic Beanstalk aplican los valores recomendados a las opciones anteriores. Debe eliminar estos ajustes si desea usar archivos de configuración para configurarlos. Para obtener más información, consulte Valores recomendados.