Uso de AWS Copilot para crear una infraestructura de Amazon ECS con AWS AppMesh

Amanda Quinto, Sr. Arquitecto de soluciones, sector público

Introducción

El despliegue de aplicaciones, la gestión de ecosistemas de microservicios, la creación y el monitoreo de orquestadores de contenedores son aspectos que los profesionales de TI deben analizar a la hora de crear entornos de infraestructura desacoplados en la nube. Existen varias herramientas que pueden ayudar a resolver estos desafíos, pero implementarlas (incluso con la infraestructura como código) acaba generando más complejidad, lo que hace que las plantillas y los scripts sean cada vez más extensos y acoplados.

En este blog explicaremos cómo utilizar las herramientas de AWS para facilitar la implementación y el monitoreo de microservicios, reducir la complejidad utilizando AWS Copilot como opción de infraestructura como código, Amazon Elastic Container Service (Amazon ECS) como orquestador de contenedores y gestionar la observabilidad y el tráfico con AWS App Mesh y AWS X-Ray.

Comprender los conceptos

Antes de entrar en la solución técnica, comprendamos los conceptos en los que se basan las tecnologías utilizadas.

Infraestructura como código

La creación de servicios y soluciones de infraestructura mediante código es la práctica conocida como IaC (Infrastructure as a Code), que introdujo la estandarización, las pruebas, la automatización y la escalabilidad del entorno de infraestructura, al tiempo que mantuvo el dinamismo necesario para los entornos de nube. Esta base de código debe mantenerse, al igual que cualquier código fuente de sistemas y software, en una herramienta de control de versiones de código como AWS CodeCommit o Github, que genere auditabilidad de este contenido. Y todo esto permite crear plantillas que definan los estándares aplicados a todo el entorno, garantizando que todas las versiones de los servidores sean iguales y que la configuración de seguridad se mantenga entre los servicios.

Malla de servicio

Service Mesh es una capa de infraestructura dedicada que proporciona una forma uniforme de conectar, proteger y monitorear la intercomunicación entre microservicios. Pero para entender el concepto de malla de servicios y por qué se ha vuelto tan importante, primero es necesario basarse en los microservicios. Esto se debe a que el desacoplamiento de las aplicaciones aportó soluciones como la agilidad en la creación de nuevas funciones, el aislamiento de los problemas y el escalado individual de las aplicaciones. Sin embargo, este nuevo patrón arquitectónico también trajo nuevos problemas. Un vasto ecosistema de microservicios presenta desafíos de los que las aplicaciones monolíticas estarían exentas. La comunicación entre microservicios, la capacidad de gestionar rutas, la gestión de cortacircuitos y el control de los cambios de estado de las aplicaciones son algunas de las nuevas complejidades creadas con este estándar de desarrollo de software.

Para gestionar una operación de microservicio escalable, es necesario contar con una capa desacoplada para abordar las complejidades enumeradas. En este escenario, surgió el concepto de Service Mesh, que es una capa de infraestructura dedicada que proporciona una forma uniforme de conectar, proteger y monitorear la intercomunicación entre microservicios.

Servicios utilizados

Amazon ECS

Amazon Elastic Container Service (Amazon ECS) es un servicio de administración de contenedores rápido y altamente escalable. Puede usarlo para lanzar, detener y administrar los contenedores de un clúster.

AWS Copilot

AWS Copilot es una CLI desarrollada por AWS para acelerar la implementación de aplicaciones en Amazon ECS o AWS App Runner mediante las mejores prácticas arquitectónicas recomendadas por AWS Well Architected Framework para crear el entorno.

AWS App Mesh

El AWS App Mesh es una malla de servicios que proporciona redes para que las aplicaciones faciliten la comunicación de los servicios entre sí y entre varios tipos de infraestructura informática. App Mesh estandariza el modo de comunicación de sus servicios, ofrece una visibilidad de extremo a extremo y garantiza una alta disponibilidad para sus aplicaciones.

Descripción general de la solución

En este tutorial, demostraremos cómo crear un marco para orquestar sus microservicios en AWS mediante contenedores a través de Amazon ECS y monitorear y administrar las rutas mediante AWS App Mesh y AWS X-Ray, todo ello creado a través de la herramienta de IaC, AWS Copilot, que facilita el mantenimiento y las actualizaciones del entorno a través de su propia CLI.

Figura 1 — Diagrama de solución

Prerrequisitos

Paso a paso

Lanzamiento de la aplicación
Inicialización del entorno
Implementación de los servicios de aplicaciones
- Aplicación Mesh Gateway
- Servicio de cristal
- Servicio NodeJS
- Servicio de frontend
Probar la aplicación
- Acceso al balanceador de carga de red
- Acceder a la consola de App Mesh
- Observabilidad con rayos X
Desaprovisionamiento de recursos

1. Lanzamiento de la aplicación

Para este tutorial, necesitamos clonar el siguiente repositorio de AWS Samples y ejecutar los siguientes comandos en su terminal de escritorio/portátil:

git clone https://github.com/aws-samples/aws-appmesh-xray-with-copilot.git

cd appmeshcopilot
git clone https://github.com/aws-containers/ecsdemo-nodejs.git
git clone https://github.com/aws-containers/ecsdemo-crystal.git
git clone https://github.com/aws-containers/ecsdemo-frontend.git
rm -rf ecsdemo-frontend/copilot
export appName=ecsdemo-workshop
export envName=dev

copilot app init $appName

Con una configuración limpia, Copilot creará automáticamente la carpeta copilot y el archivo “.workspace”, pero en este ejemplo, la carpeta copilot ya está creada previamente con los archivos y las personalizaciones necesarios para su despliegue con App Mesh y X-Ray.

El comando “copilot app init” genera una pila de CloudFormation y prepara las funciones para que CloudFormation pueda crear recursos de aplicaciones (como S3, ECR, SNS, etc.).

2. Inicialización del entorno

En este ejemplo, Copilot ya creó el archivo de manifiesto de la aplicación, por lo que podemos continuar y crear el entorno con:

copilot env init --name $envName

Este comando solicitará las credenciales configuradas en la CLI de AWS (en este ejemplo utilizamos la predeterminada configurada en la configuración de la CLI de AWS) y la configuración del entorno (predeterminada o importada) y creará un archivo de manifiesto para ese entorno. También utilizará CloudFormation para crear los roles y un bucket de S3 para almacenar los artefactos necesarios.

¿Cuál es su credencial? Patrón
¿Desea utilizar la configuración predeterminada para un entorno nuevo? Sí, utilice el predeterminado (puede personalizar los recursos de la infraestructura o incluso importar una infraestructura existente para implementar la aplicación)
1. Una nueva VPC con 2 AZ,
2. 2 subredes públicas y 2 subredes privadas
3. Un nuevo clúster de ECS
4. Nuevas funciones de IAM para gestionar los servicios y las tareas de su entorno

Ahora podemos implementar el entorno para crear los recursos necesarios (VPC, subred, IGW, funciones, clúster de Amazon ECS). Usa el comando:

copilot env deploy --name $envName

Ahora estamos listos para implementar los componentes de la aplicación y la puerta de enlace.

3. Implementación de servicios de aplicaciones

3.1. Implementación de servicios de aplicaciones – App Mesh Gateway

Empecemos por implementar la aplicación Mesh Gateway. Será el punto de entrada a su Application Service Mesh. Todas las comunicaciones externas (fuera de la malla) deben enviarse mediante un balanceador de carga de red a Envoy Gateway que se ejecuta en Amazon ECS Fargate.

cd appmesh-gateway
copilot init -n ecsdemo-envoygw -t "Load Balanced Web Service"

Selecciona la opción “. /Dockerfile”.

Copilot hará la siguiente pregunta: “¿Desea implementar un entorno de prueba?” , dado que ya hemos creado un entorno (recursos de infraestructura) para la aplicación en nuestro escenario, no vamos a crear un entorno de prueba, respondiendo N. Vale la pena recordar que crear un entorno de prueba es una buena práctica. A continuación, ejecute el comando de despliegue del servicio:

copilot svc deploy --name ecsdemo-envoygw --env $envName

Tome nota de la dirección pública del balanceador de carga de red. Se utilizará para probar la aplicación.

Los recursos que creará el Copilot están relacionados con el tipo de servicio que elija. Para el servicio de gateway, seleccionamos el servicio web equilibrado de carga y, a continuación, personalizamos el manifest.yml para crear un NLB en lugar de un ALB estándar (puede consultar el archivo de manifiesto en la carpeta copilot/ecsdemo-envoygw).

Los parámetros que se pueden utilizar en el archivo de manifiesto de copilot, como las comprobaciones de estado, las variables de las tareas de Amazon ECS, etc., se pueden comprobar en CopilotDocs.

Ahora que tenemos la infraestructura y la pasarela listas, implementemos las otras capas (servicios) de la aplicación junto con los componentes de App Mesh (sidecars, nodos virtuales y servicios virtuales).

3.2. Implementación de servicios de aplicaciones – Crystal Service

App Mesh requiere dos elementos en cada tarea/contenedor que pertenece a Mesh:

un rol de IAM que tiene permiso para AppMesh:streamAggregatedResources, de modo que la tarea pueda enviar información al servicio App Mesh.
un proxy de mensajero (contenedor de sidecar) adjunto al contenedor con una variable que contiene el ARN de un nodo virtual creado en App Mesh.

Ambos componentes se añadirán mediante los complementos de Copilot (archivos de plantilla de Cloudformation en la carpeta Complementos). Implementemos nuestros servicios de aplicaciones con las configuraciones de App Mesh (nodos virtuales) necesarias:

cd ../ecsdemo-crystal
copilot init -n ecsdemo-crystal -t "Backend Service"

Selecciona la opción ”. /Dockerfile” y nuevamente responda “N” a la pregunta: “¿Desea implementar un entorno de prueba?”. Próxima:

copilot svc deploy --name ecsdemo-crystal --env $envName

3.3. Despliegue de los servicios de la aplicación – NodeJS Service

Realizaremos el mismo proceso que en el paso anterior, creando un nuevo servicio en ECS Fargate y automáticamente un nuevo nodo virtual y un servicio virtual en App Mesh (puede consultar cómo crear los componentes de App Mesh para cada servicio en la carpeta copilot/addons).

cd ../ecsdemo-nodejs
copilot init -n ecsdemo-nodejs -t "Backend Service"

Selecciona la opción “. /Dockerfile” y nuevamente responda “N” a la pregunta: “¿Desea implementar un entorno de prueba?”. Próxima:

copilot svc deploy --name ecsdemo-nodejs --env $envName

Nota: Este paso puede tardar varios minutos, ya que Copilot ejecutará la creación de una imagen de contenedor mediante Docker, cargará la imagen en el repositorio de Amazon ECR e implementará y probará la disponibilidad del servicio en Amazon ECS Fargate.

3.4. Implementación de los servicios de aplicaciones – FrontEnd Service

Realizaremos el mismo proceso que en el paso anterior, creando un nuevo servicio en Amazon ECS Fargate y automáticamente un nuevo nodo virtual y un servicio virtual en App Mesh (puede consultar cómo crear los componentes de App Mesh para cada servicio en la carpeta copilot/addons).

Cabe mencionar que, aunque este servicio es nuestra interfaz, lo estamos creando como un backend, ya que todo el tráfico externo a través del balanceador de carga será recibido primero por App Mesh Gateway y solo entonces se redirigirá a la interfaz.

cd ../ecsdemo-frontend
copilot init -n ecsdemo-frontend -t "Backend Service"

Selecciona la opción ”. /Dockerfile” y nuevamente responda “N” a la pregunta: “¿Desea implementar un entorno de prueba?”. Próxima:

copilot svc deploy --name ecsdemo-frontend --env $envName

4. Probar la aplicación

4.1. Acceso al balanceador de carga de red

Verifique su aplicación dirigiendo su navegador a la URL del balanceador de carga de red indicada en la sesión “Implementación de servicios de aplicaciones: App Mesh Gateway”. Si no te has dado cuenta, puedes comprobar la dirección del balanceador de carga de red con el comando “sh copilot svc show —name ecsdemo-envoygw” y buscar la URL o, si tienes jq instalado, utilizar el comando “sh copilot svc show —name ecsdemo-envoygw —json | jq .routes [] .url”.

En la pantalla del navegador (Chrome o Firefox), pulsa F12 para acceder a las herramientas para desarrolladores, selecciona la pestaña “Red” y verás una lista de llamadas.

En Chrome, haz clic en el botón rojo de la izquierda para detener los registros de la red y, en la lista de registros, selecciona cualquier registro cuyo nombre coincida con el del balanceador de carga de red.

Figura 2: Herramientas para desarrolladores en Chrome

En Firefox, selecciona cualquier registro cuyo campo “Archivo” sea “/” (si la lista de registros está “desapareciendo”, haz clic en el icono con forma de engranaje de la parte derecha y activa la opción “Conservar registros”).

Figura 3 — Herramientas para desarrolladores en Firefox

Tenga en cuenta que el encabezado de respuesta contiene “server:envoy”. Esto significa que tu solicitud externa se envió a través de un proxy (App Mesh) mediante Envoy y ahora puedes controlar tus rutas y reglas para cada servicio.

4.2. Acceso a la consola de AWS App Mesh

Consulte los nodos virtuales, que representan cada uno de nuestros recursos o puntos finales (servicios de ECS, implementaciones de EKS o instancias de Amazon EC2), los nombres de host y los oyentes.

Figura 4 — Nodos virtuales de App Mesh

Compruebe que la interfaz del nodo virtual tenga 2 servicios de backend (Crystal y nodejs). Dado que nuestra interfaz envía tráfico saliente a estos dos elementos, decimos que la interfaz del nodo virtual tiene 2 servicios de backend (tenga en cuenta que la referencia es a los servicios y no a los nodos).

Figura 5: Nodo virtual App Mesh FrontEnd

Consulte los servicios virtuales. Los servicios virtuales representan una abstracción de cada servicio real representado por un nodo virtual o un enrutador virtual (más detalles a continuación) que tenemos en nuestra malla/aplicación. Cuando un servicio depende de otro, utilizan el nombre del servicio virtual para la comunicación y ese tráfico se envía al nodo virtual o al enrutador virtual que proporciona ese servicio de aplicación.

Figura 6 — Servicios virtuales de App Mesh

Compruebe la puerta de enlace virtual. La puerta de enlace virtual se utiliza para permitir la comunicación desde el exterior hacia el interior de la malla, como el acceso de los usuarios o los recursos que no forman parte de la malla. En nuestro escenario, creamos un balanceador de carga de red para recibir clientes externos y luego enviarlo a la puerta de enlace virtual (puerta de enlace en malla), que a su vez tiene una única ruta que envía al router frontal.

Figura 7 — Aplicación Mesh Virtual Gateway

Compruebe el router virtual y sus rutas. El enrutador virtual se usa para administrar rutas para diferentes nodos virtuales, especificando rutas (rutas), pesos, tiempos de espera, reintentos, entre otros. Por ejemplo, en nuestro escenario podemos usar el enrutador virtual (en lugar de enviar tráfico directamente a un nodo virtual) para redirigir diferentes versiones de nuestra interfaz, cada versión es un nodo virtual. Esta función es especialmente útil cuando implementamos estrategias de despliegue canarias o azul/verdes para ciertos servicios de aplicaciones.

Figura 8 — Aplicación y rutas del enrutador virtual Mesh

4.3. Observabilidad con rayos X

Abra el servicio Amazon CloudWatch mediante la consola de administración de AWS y, en la sección Rastreos X-Ray del menú de la izquierda, seleccione “Mapa de servicios”.

Explore nuestro mapa de aplicaciones, el tiempo de respuesta por servicio, las métricas y el seguimiento de cada nivel.

Figura 9 — Mapa del servicio de rayos X

En el mapa de servicios de X-Ray, es posible verificar gráficamente el mapa de comunicación entre los servicios, el tiempo promedio en cada componente y el número de llamadas por minuto.

Figura 10 — Tiempo de respuesta a los rayos X por nodo

En el menú de la izquierda, aún en la sección “Rastros de X-Ray”, seleccione «Rastros». De esta forma, es posible tener una vista de la lista de cada una de las llamadas a la aplicación y del tiempo total transcurrido (desde la entrada hasta la salida de una solicitud). Un ejemplo sería ver la ruta y el tiempo de respuesta que recibió un usuario al interactuar con la aplicación.

Figura 11 — Lista de rastreo de rayos X (seguimiento por llamada)

Al hacer clic en un ID de la lista de rastreo, es posible detallar cada una de las llamadas internas para ese cliente/acceso específico, mostrando toda la ruta recorrida por la aplicación. Esta visualización se puede utilizar principalmente en escenarios de resolución de problemas para identificar errores que afectan a grupos específicos de usuarios.

Figura 12 — Rastreo detallado de una llamada en rayos X

5. Desaprovisionamiento de recursos

Con la CLI de AWS Copilot es posible, de forma sencilla, eliminar todos los recursos creados con unos pocos comandos. AWS Copilot eliminará todos los scripts y recursos de CloudFormations creados.

copilot svc delete -n ecsdemo-frontend --yes
copilot svc delete -n ecsdemo-crystal --yes
copilot svc delete -n ecsdemo-nodejs --yes
copilot svc delete -n ecsdemo-envoygw --yes
copilot app delete -n $appName --yes

Conclusión

En este blog, vimos la construcción de un marco sólido para soportar cargas de trabajo en contenedores mediante un orquestador, que incluía la observabilidad y la gestión de rutas. Estas herramientas pueden facilitar las pruebas a/b, se despliegan con un enfoque canario o azul/verde, y todas ellas utilizan la infraestructura como código, aprovisionan todos los recursos sin necesidad de adaptaciones ni scripts adicionales, lo que facilita enormemente la vida diaria del equipo de desarrollo.

Próximos pasos

Como pasos siguientes, puedes implementar un FrontendV2 (según el repositorio de Github) para explorar la configuración de rutas y las comprobaciones de estado de App Mesh.

Además, explore Copilot Pipelines, que utiliza los servicios AWS CodeBuild y AWS CodePipeline, para simplificar la implementación de una canalización de CI/CD.

Este artículo fue traducido del Blog de AWS en Portugués.

Acerca de los autores

Joao Melo es un arquitecto de soluciones que presta servicios a clientes empresariales con un enfoque en el mercado financiero. Con más de 10 años de experiencia, João comenzó su carrera como desarrollador de Java y .NET, y más tarde se especializó en infraestructura como ingeniero de sistemas en Cisco Systems. Graduado en la FEI, es un entusiasta de los contenedores, DeFi y los sistemas de pago y un apasionado del cine y los juegos.

Amanda Quinto es una arquitecta de soluciones de AWS en el equipo del sector público que se centra en organizaciones sin fines de lucro. Amanda ha trabajado en varios proyectos ayudando a los equipos de desarrollo y soporte a diseñar sistemas resilientes y escalables. Graduada en FATEC-SP, es una entusiasta de Devops, el aprendizaje automático y una apasionada de Kombis.

Blog de Amazon Web Services (AWS)