Editor Top
|
|
Si bien los contenedores han revolucionado cómo los equipos de desarrollo empaquetan e implementan aplicaciones, estos equipos han tenido que monitorear cuidadosamente las comunicaciones y construir herramientas personalizadas para mitigar los riesgos de implementación, lo que ralentiza la velocidad de envío. A escala, los equipos de desarrollo gastan ciclos valiosos construyendo y manteniendo herramientas de implementación indiferenciadas en lugar de innovar para su negocio.
A partir de hoy, puede usar la capacidad de implementación azul/verde incorporada en Amazon Elastic Container Service (Amazon ECS) para que sus implementaciones de aplicaciones sean más seguras y consistentes. Esta nueva capacidad elimina la necesidad de crear herramientas de implementación personalizadas al tiempo que le brinda la confianza para enviar actualizaciones de software con mayor frecuencia con capacidad de reversión.
Así es como puede habilitar la capacidad de implementación azul/verde incorporada en la consola ECS de Amazon.
Usted crea un nuevo entorno de aplicación «verde», mientras que su entorno «azul» existente continúa sirviendo tráfico en vivo. Después de monitorear y probar el entorno verde a fondo, enruta el tráfico vivo de azul a verde. Con esta capacidad, Amazon ECS ahora proporciona una funcionalidad incorporada que hace que las implementaciones de aplicaciones contenedores sean más seguras y confiables.
A continuación se muestra un diagrama que ilustra cómo funciona la implementación azul/verde al cambiar el tráfico de aplicaciones desde el entorno azul hasta el entorno verde. Puede obtener más información en la página de flujo de trabajo de implementaciones de Amazon ECS Blue/Green Service.
Amazon ECS orquesta todo este flujo de trabajo mientras proporciona ganchos de eventos para validar nuevas versiones utilizando el tráfico sintético antes de enrutar el tráfico de producción. Puede validar nuevas versiones de software en entornos de producción antes de exponerlos a los usuarios finales y revertir de manera casi instantánea si surgen problemas. Debido a que esta funcionalidad está construida directamente en Amazon ECS, puede agregar estas salvaguardas simplemente actualizando su configuración sin construir ninguna herramienta personalizada.
Empezando
Permítanme guiarlo a través de una demostración que muestra cómo configurar y usar implementaciones azules/verdes para un servicio ECS. Antes de eso, hay algunos pasos de configuración que necesito completar, incluida la configuración de los roles de gestión de identidad y acceso de AWS (IAM), que puede encontrar en los recursos requeridos para la página de documentación de implementaciones azules/verdes de Amazon ECS.
Para esta demostración, quiero implementar una nueva versión de mi aplicación utilizando la estrategia azul/verde para minimizar el riesgo. Primero, necesito configurar mi servicio ECS para usar implementaciones azules/verdes. Puedo hacer esto a través de la consola ECS, la interfaz de línea de comandos de AWS (AWS CLI) o usando la infraestructura como código.
Usando la consola de Amazon ECS, creo un nuevo servicio y lo configuro como de costumbre:
En la sección Opciones de implementación, elijo ECS como el Tipo de controlador de implementaciónentonces Azul/verde como el Estrategia de implementación. Hora de hornear es el tiempo después de que el tráfico de producción se ha cambiado a verde, cuando hay una reversión instantánea a azul disponible. Cuando el tiempo de horneado expira, se eliminan las tareas azules.
También presentamos ganchos de ciclo de vida de implementación. Estos son mecanismos basados en eventos que puede usar para aumentar el flujo de trabajo de implementación. Puedo seleccionar qué función AWS Lambda me gustaría usar como un gancho de ciclo de vida de implementación. La función Lambda puede realizar la lógica comercial requerida, pero debe devolver un estado de gancho.
Amazon ECS admite los siguientes ganchos del ciclo de vida durante las implementaciones azules/verdes. Puede obtener más información sobre cada etapa en la página de las etapas del ciclo de vida de implementación.
- Previamente escalar
- Publicar escala
- Cambio de tráfico de producción
- Probar el cambio de tráfico
- Cambio de tráfico de postproducción
- Post de prueba de tráfico de pruebas
Para mi aplicación, quiero probar cuando el cambio de tráfico de prueba está completo y el Servicio Verde maneja todo el tráfico de pruebas. Dado que no hay tráfico de usuario final, una reversión en esta etapa no tendrá impacto en los usuarios. Esto hace Post de prueba de tráfico de pruebas Adecuado para mi caso de uso, ya que puedo probarlo primero con mi función Lambda.
Cambiar el contexto por un momento, centrémonos en la función Lambda que utilizo para validar la implementación antes de permitir que continúe. En mi función Lambda como un gancho de ciclo de vida de implementación, puedo realizar cualquier lógica comercial, como pruebas sintéticas, llamar a otra API o consultar métricas.
Dentro de la función lambda, debo devolver un hookStatus. A hookStatus puede ser SUCCEEDEDque moverá el proceso al siguiente paso. Si el estado es FAILEDvuelve al despliegue azul. Si es IN_PROGRESSentonces Amazon ECS repleta la función Lambda en 30 segundos.
En el siguiente ejemplo, configuré mi validación con una función Lambda que realiza la carga de archivos como parte de un conjunto de pruebas para mi aplicación.
import json
import urllib3
import logging
import base64
import os
# Configure logging
logger = logging.getLogger()
logger.setLevel(logging.DEBUG)
# Initialize HTTP client
http = urllib3.PoolManager()
def lambda_handler(event, context):
"""
Validation hook that tests the green environment with file upload
"""
logger.info(f"Event: {json.dumps(event)}")
logger.info(f"Context: {context}")
try:
# In a real scenario, you would construct the test endpoint URL
test_endpoint = os.getenv("APP_URL")
# Create a test file for upload
test_file_content = "This is a test file for deployment validation"
test_file_data = test_file_content.encode('utf-8')
# Prepare multipart form data for file upload
fields = {
'file': ('test.txt', test_file_data, 'text/plain'),
'description': 'Deployment validation test file'
}
# Send POST request with file upload to /process endpoint
response = http.request(
'POST',
test_endpoint,
fields=fields,
timeout=30
)
logger.info(f"POST /process response status: {response.status}")
# Check if response has OK status code (200-299 range)
if 200 <= response.status < 300:
logger.info("File upload test passed - received OK status code")
return {
"hookStatus": "SUCCEEDED"
}
else:
logger.error(f"File upload test failed - status code: {response.status}")
return {
"hookStatus": "FAILED"
}
except Exception as error:
logger.error(f"File upload test failed: {str(error)}")
return {
"hookStatus": "FAILED"
}Cuando la implementación alcanza la etapa del ciclo de vida asociado con el gancho, Amazon ECS invoca automáticamente mi función Lambda con contexto de implementación. Mi función de validación puede ejecutar pruebas integrales contra la revisión verde: verificar la salud de la aplicación, ejecutar pruebas de integración o validar las métricas de rendimiento. La función luego se indica a ECS si procede o aborta la implementación.
Mientras elegí la estrategia de implementación azul/verde, también necesito configurar los equilibradores de carga y/o el servicio de Amazon ECS Connect. En el Equilibrio de carga Sección, selecciono mi Balancador de carga de la aplicación.
En el Oyente Sección, uso un oyente existente en el puerto 80 y selecciono dos Grupos objetivo.
Feliz con esta configuración, creo el servicio y espero a que ECS aprovisione mi nuevo servicio.
Prueba de implementaciones azules/verdes
Ahora, es hora de probar mis implementaciones azules/verdes. Para esta prueba, Amazon ECS activará mi función Lambda después de que se complete el cambio de tráfico de prueba. Mi función lambda volverá FAILED En este caso, mientras realiza la carga de archivos en mi aplicación, pero mi aplicación no tiene esta capacidad.
Actualizo mi servicio y comprobo Forzar nuevo despliegueConocer la capacidad de implementación azul/verde retrocedirá si detecta una falla. Selecciono esta opción porque no he modificado la definición de la tarea, pero aún así necesito activar una nueva implementación.
En esta etapa, tengo entornos azules y verdes en funcionamiento, con la revisión verde que maneja todo el tráfico de pruebas. Mientras tanto, según los registros de Amazon CloudWatch de mi función Lambda, también veo que los ganchos de ciclo de vida de implementación funcionan como se esperaba y emite la siguiente carga útil:
[INFO] 2025-07-10T13:15:39.018Z 67d9b03e-12da-4fab-920d-9887d264308e Event:
{
"executionDetails": {
"testTrafficWeights": {},
"productionTrafficWeights": {},
"serviceArn": "arn:aws:ecs:us-west-2:123:service/EcsBlueGreenCluster/nginxBGservice",
"targetServiceRevisionArn": "arn:aws:ecs:us-west-2:123:service-revision/EcsBlueGreenCluster/nginxBGservice/9386398427419951854"
},
"executionId": "a635edb5-a66b-4f44-bf3f-fcee4b3641a5",
"lifecycleStage": "POST_TEST_TRAFFIC_SHIFT",
"resourceArn": "arn:aws:ecs:us-west-2:123:service-deployment/EcsBlueGreenCluster/nginxBGservice/TFX5sH9q9XDboDTOv0rIt"
}Como se esperaba, mi función AWS Lambda regresa FAILED como hookStatus porque no pudo realizar la prueba.
[ERROR] 2025-07-10T13:18:43.392Z 67d9b03e-12da-4fab-920d-9887d264308e File upload test failed: HTTPConnectionPool(host="xyz.us-west-2.elb.amazonaws.com", port=80): Max retries exceeded with url: / (Caused by ConnectTimeoutError(, 'Connection to xyz.us-west-2.elb.amazonaws.com timed out. (connect timeout=30)')) Debido a que la validación no se completó con éxito, Amazon ECS intenta regresar a la versión azul, que es la versión anterior de implementación de trabajo. Puedo monitorear este proceso a través de eventos ECS en el Eventos Sección, que proporciona una visibilidad detallada del progreso de la implementación.
Amazon ECS reviene con éxito la implementación a la versión de trabajo anterior. La reversión ocurre casi instantáneamente porque la revisión azul sigue funcionando y está lista para recibir el tráfico de producción. No existe un impacto en el usuario final durante este proceso, ya que el tráfico de producción nunca cambió a la nueva versión de aplicación: los EC simplemente retrocedieron el tráfico de prueba a la versión estable original. Esto elimina el tiempo de inactividad de despliegue típico asociado con las implementaciones de laminación tradicionales.
También puedo ver el estado de reversión en el Última implementación sección.
A lo largo de mis pruebas, observé que la estrategia de implementación azul/verde proporciona un comportamiento consistente y predecible. Además, los ganchos del ciclo de vida de implementación proporcionan más flexibilidad para controlar el comportamiento de la implementación. Cada revisión del servicio mantiene una configuración inmutable, incluida la definición de tarea, la configuración del equilibrador de carga y la configuración de Service Connect. Esto significa que las reversiones restauran exactamente el mismo entorno que anteriormente se estaba ejecutando.
Cosas adicionales que saber
Aquí hay un par de cosas a tener en cuenta:
- Fijación de precios – La capacidad de implementación azul/verde se incluye con Amazon ECS sin cargo adicional. Paga solo por los recursos de cómputo utilizados durante el proceso de implementación.
- Disponibilidad – Esta capacidad está disponible en todas las regiones comerciales de AWS.
Comience con implementaciones azules/verdes actualizando su configuración de servicio de Amazon ECS en la consola ECS de Amazon.
¡Feliz despliegue!
– Donnie
