Hola, soy Miguel y hoy les traigo un nuevo post.
Índice
Motivación
Docker es una herramienta fantástica para encapsular e implementar aplicaciones de una manera fácil y escalable.
De hecho, algo que me encuentro haciendo muy a menudo es empaquetar bibliotecas de Python en imágenes de Docker que luego puede usar como plantillas para mis proyectos.
En esta publicación, ilustraré cómo registrar sus imágenes de Docker en un registro de contenedores y cómo implementar los contenedores en AWS usando Fargate, un motor de cómputo sin servidor diseñado para ejecutar aplicaciones en contenedores.
Además, usaremos Cloud Formation para implementar nuestra pila de manera programática. ¡Empecemos!
Registre sus imágenes en un registro de contenedores
Los registros de contenedores son para las imágenes de Docker lo que los repositorios de código son para codificar.
En un registro, usted crea repositorios de imágenes para enviar y registrar sus imágenes locales, puede almacenar diferentes versiones de la misma imagen y otros usuarios pueden extraer y actualizar la imagen si tienen acceso al repositorio.
Ahora, supongamos que ha desarrollado localmente una imagen que desea implementar en la nube. Para hacerlo, necesitaríamos almacenar nuestra imagen local en un registro de contenedor desde el cual se puede extraer e implementar.
En este artículo, usaré una imagen bastante simple que inicia una web Python-Dash aplicación en el puerto 80
.
Usaremos el ECR
(Elastic Container Registry) para registrar nuestras imágenes. ECR
es un servicio de AWS
, bastante similar a DockerHub
, para almacenar imágenes de Docker
.
Lo primero que tenemos que hacer es crear un repositorio en ECR
, podemos usar la AWS CLI
de la siguiente manera:
aws ecr create-repository \ --repository-name dash-app \ --image-scan-configuration scanOnPush = true \ --region eu -central-1
Debería poder ver el repositorio en la consola de administración de AWS
.
Para enviar imágenes locales a nuestro repositorio ECR
, debemos autenticar nuestra CLI
de Docker
local en AWS
:
aws ecr get-login-password --region region | docker login --username AWS --password-stdin acccount_id.dkr.ecr.region.amazonaws.com
Simplemente reemplace el aws_account_id
y region
adecuadamente. Deberías ver el mensaje Login Succeeded
en la terminal, lo que significa que nuestra CLI
de Docker
local está autenticada para interactuar con la ECR
.
Empujemos ahora nuestra imagen local a nuestro nuevo repositorio. Para ello debemos etiquetar nuestra imagen para que apunte al repositorio ECR
:
docker tag image_id account_id.dkr.ecr.eu-central-1.amazonaws.com/dash-app:latest
Ahora solo tenemos que empujarlo al ECR
:
docker push account_id.dkr.ecr.eu-central-1.amazonaws.com/dash-app:latest
Debería ver la imagen enviada en la consola de AWS
:
Con eso llegamos al final de la sección, resumamos:
(i) Hemos creado un repositorio de imágenes llamado dash-app
en ECR
.
(ii) Hemos autorizado nuestra CLI
de Docker
local para conectarse a AWS
.
(iii) Hemos han enviado una imagen al repositorio. En la siguiente sección, cubriremos cómo implementar esta imagen en AWS
.
Implemente contenedores Docker
en AWS
Dejando a un lado Kubernetes
, AWS
ofrece varias opciones para implementar aplicaciones en contenedores:
- Implementar contenedores en
EC2
, generalmente dentro de un grupo de instancias de escalado automático. En este escenario, somos responsables de parchear, asegurar, monitorear y escalar las instanciasEC2
. - Implementación de contenedores en
AWS Fargate
. Dado queFargate
no tiene servidor, no hay instanciasEC2
para administrar o aprovisionar.Fargate
gestiona la ejecución de nuestras tareas proporcionando la potencia informática adecuada (una tarea en este contexto se refiere a un grupo de contenedores que funcionan juntos como una aplicación).
En esta sección, nos centraremos en la segunda opción, que ilustra cómo implementar nuestra aplicación web en AWS Fargate
.
Además, asignaremos todos los recursos necesarios con AWS Cloud Formation
.
Cloud Formation
es un servicio de AWS
para aprovisionar e implementar recursos de manera programática, una técnica que generalmente se conoce como infraestructura como código o IaC
.
En IaC
, en lugar de asignar recursos manualmente a través de la consola de administración, definimos nuestra pila en un archivo JSON
o YAML
.
Luego, el archivo se envía a Cloud Formation
, que implementa automáticamente todos los recursos especificados en él. Esto tiene dos ventajas principales:
(i) facilita la automatización del aprovisionamiento y la implementación de recursos.
(ii) los archivos ayudan como documentación de nuestra infraestructura en la nube.
Aunque definir nuestra pila en un archivo JSON / YAML
requiere pasar por una curva de aprendizaje y olvidarse de la consola de administración de AWS
y sus asistentes realmente fáciles de usar, definitivamente vale la pena a largo plazo.
A medida que su infraestructura crezca, mantener toda la pila como código será increíblemente útil para escalar de manera productiva.
Ahora, enumeremos los recursos que necesitamos para ejecutar nuestra aplicación:
- Tarea: Describe el grupo de contenedores
Docker
que dan forma a nuestra aplicación. En nuestro ejemplo, simplemente tenemos una imagen. - Servicio ECS: Se encarga de ejecutar y mantener la cantidad deseada de instancias de una tarea. Por ejemplo, si una tarea falla o se detiene, el servicio
ECS
puede lanzar automáticamente una nueva instancia para mantener la cantidad deseada de tareas en servicio. - Fargate: Un motor informático sin servidor para contenedores. Con
Fargate
no es necesario reservar y administrar servidores. Proporciona automáticamente potencia informática para ejecutar nuestras tareas. - Recursos de red: también necesitamos una
VPC
, una subred pública conectada a una puerta de enlace de Internet a través de una tabla de enrutamiento (no olvide que estamos implementando una aplicación web a la que se debe poder acceder desde Internet) y un grupo de seguridad para ejecutar nuestros contenedores de forma segura. No necesita configurar esos recursos si ya tiene una configuración de red en su lugar, aunque los incluyo en elscript Cloud Formation
.
Ahora, sin más preámbulos, saltemos a la pila
.
Expliquémoslos en detalle:
VPC-FARGATE
: Esta es laVPC
. Es importante habilitar el soporte deDNS
y los nombres de host deDNS
para llegar alECR
y extraer las imágenes.INT-GATEWAY
: Esta es una puerta de enlace de Internet, es necesaria para exponer la subred a Internet.ATTACH-IG
: Esto conecta la puerta de enlace de Internet a laVPC
.ROUTE-TABLE
: Esta es una tabla de enrutamiento, a la que agregaremos las reglas para exponer la subred a la puerta de enlace de Internet.ROUTE
: Esto agrega una regla a la tabla de enrutamiento descrita anteriormente. Reenvía el tráfico a la puerta de enlace de Internet.SUBNETFARGATE
: Esta es la subred para alojar nuestros servicios. Definimos la zona de disponibilidad y laVPC
a la que pertenece.SUBNETROUTE
: Esto asocia la tabla de enrutamiento a la subred.SGFARGATE
: Este es el grupo de seguridad que se aplicará a nuestros servicios. Permite el tráfico en lospuertos 443
y80
a través de los protocolosHTTPS
yHTTP
.FARGATECLUSTER
: Define el clúster deFargate
para alojar nuestros servicios.ECSTASK
: Determina las tareas a ejecutar. Incluye la lista de imágenes deDocker
que realizan la tarea. Para cada contenedor, registra la asignación de puertos, los comandos de inicio y las opciones de registro. Las imágenes se extraen del repositorioECR
configurado anteriormente.SERVICE
: Define elServicio ECS
que lanzará y mantendrá nuestras tareas. Si ya tiene una configuración de red y no necesita crear una nueva subred y grupo de seguridad, solo haga referencia a esos recursos existentes en elNetworkConfiguration
sección delServicio ECS
.
Una vez que su archivo esté listo, cárguelo en Cloud Formation
para crear su pila:
Siga los pasos de la consola de administración para iniciar la pila. Una vez finalizado, Cloud Formation
comenzará a aprovisionar los servicios automáticamente. Puedes seguir su progreso en la pestaña de eventos:
Y lo que es más importante, cuando esté listo, puede acceder a su aplicación web en la dirección IP pública
asignada a la tarea en ejecución.
Si sigue las mejores prácticas, no está creando recursos con su cuenta raíz de AWS
. En su lugar, debería utilizar un usuario que no sea root.
Sin embargo, debe tener en cuenta que para transferir un rol a un servicio, AWS
requiere que el usuario que crea el servicio tenga permisos de "Transferir rol"
.
En nuestro ejemplo, necesitamos que nuestro usuario pase el rol ecsTaskExecutionRole
al TaskDefinition
service, y por lo tanto debemos otorgar permisos al usuario para hacerlo.
Esto es algo que debe hacerse desde la cuenta raíz en IAM
o desde cualquier cuenta con privilegios de IAM
. Simplemente agregue la política a continuación y adjúntela al usuario que asignará todos los recursos.
{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": "iam:PassRole", "Resource": "arn:aws:iam::account_id:role/ecsTaskExecutionRole" } ] }
Hemos cubierto mucho en este artículo. Hemos visto cómo crear un repositorio ECR
y cómo enviarle imágenes de Docker
.
También hemos tenido una breve introducción a CloudFormation
e IaC
. Me gustaría reafirmar la importancia de especificar su infraestructura y apilar como código.
A medida que su infraestructura crece, tener la pila definida en archivos JSON
o YAML
facilitará la automatización de implementaciones, escalar de manera productiva y proporcionará cierta documentación sobre su infraestructura.
Finalmente, usamos AWS Fargate
para implementar contenedores de Docker
sin servidor, lo que nos ahorró la carga de aprovisionar y administrar servidores.
Espero que encuentre útil este artículo, gracias por leer.
Añadir comentario