DEV Community: Jose Yapur

Picturesocial - Cómo añadir integración continua y entrega continua a mi aplicación

Jose Yapur — Mon, 08 May 2023 16:35:02 +0000

Episodio escrito por: Ricardo Ceci y Jose Yapur

Si es la primera vez que llegas a escuchar o leer sobre Picturesocial es una serie de contenido en la que aprendemos de cero el proceso de desarrollo, integración, despliegue y mantenimiento de una red social ficticia creada para aprender sobre tecnología con ayuda de especialistas de Nube, Seguridad, Software y DevOps, puedes encontrar todos los episodios de la serie en https://bit.ly/m/picturesocial

En la temporada anterior de Picturesocial aprendimos sobre el proceso de construcción de nuestra aplicación desde cero, sin embargo, hoy día nos enfrentamos a los retos de llevar una aplicación a producción y que debemos planificar desde el inicio. Sabemos tambien, que los escenarios ideales, en la mayoría de los casos, son propios de la academia y no de la vida real. Picturesocial nació como un proyecto que estaba “listo” para ir a producción, porque “¿Qué es lo peor que puede pasar?”

La ingenuidad, el exceso de fe o el elevado amor personal de desarrolladores senior 😆, nos llevó a donde estamos el día de hoy, con una red social en donde los pases a producción tardan días, se hacen muchos cambios al mismo tiempo por cada pase y es muy difícil detectar dónde están los problemas y por ende también a resolverlos.

En el mundo ideal queremos que Picturesocial tenga procesos libres de mamíferos (tal cual como suena 😅), en donde los desarrolladores solo hagan push a sus repositorios, los flujos de aprobación entren en vigor y una vez que se haga merge al repositorio principal entonces todo lo demás que aprendimos en la temporada anterior lo hagan los seres binarios perfectos (las máquinas)

Completamente conscientes de nuestras deficiencias para resolverlo solos, es que decidimos llamar a personas brillantes de las comunidades de AWS en todo América Latina, para que nos rescaten. En esta primera entrega hemos invitado a Ricardo Cecci, quien es AWS Community Builder y miembro del AWS UG de Buenos Aires, quien nos ayudará a resolver este problema y con quien estoy co-escribiendo este artículo.

Los retos por los que pasa Picturesocial son comunes en muchos proyectos, es usualmente al momento de pasar a producción, cuando observamos a ciencia cierta que los pases tardan días, porque dependen de muchas personas y necesitan que se hagan de forma ordenada (no se puede hacer un despliegue y luego una compilación, o si? 🥶), este proceso de días, afecta directamente el time to market y a la vez ocasiona esa sensación de que nuestro corazón se va a detener o el mundo va a explotar si omitimos un paso en el proceso que ya está en ejecución.

Un flujo de Integración Continua / Despliegue Continuo (CI/CD en inglés), nos va a permitir que nuestro proyecto pase por un circuito controlado automatizado de despliegue, donde, por ejemplo cada cambio en la rama master o main de nuestro repositorio haga que se muevan ciertas piezas automáticamente y nuestro código termine en producción si todos los chequeos pasaron, o no termine en producción si algo falló en el medio. En este circuito nosotros podremos definir todos los controles que queremos que ocurran y cómo va a ser ese despliegue a producción.

En AWS existen las siguientes herramientas que nos pueden ayudar en el proceso:

AWS Codepipeline, con quien coordinaremos todo el proceso de salida a producción
AWS CodeBuild, con esta herramienta haremos el build de nuestra imágen y la subiremos al repositorio de ECR.
Por lo general también se utiliza AWS CodeDeploy, pero en este caso como estamos utilizando EKS no va a ser necesario utilizarlo.

Recuerdo cuando desplegabamos código manualmente, era como un rito, había que dejar de hacer todo, nos conectabamos servidor por servidor, e íbamos haciendo un pull en cada uno de los servidores, procurando no olvidarnos de ninguno, y que todas las librerías y dependencias estén actualizados en todos, que en ninguno nos hayamos olvidado de algún paso y cuando pasaba que nos olvidábamos (porque somos humanos) o algún servidor quedaba trabado en mitad del proceso, saltaban las alarmas y había que atacar servidor por servidor.

Si había que hacer migraciones o modificaciones en las bases de datos que requerían hacer un lanzamiento similar a un blue/green, había que armar una regla específica en el load balancer para que rutee cierta parte del tráfico manualmente y podamos probar y luego manualmente rutear todo el tráfico, si bien había herramientas para hacerlo más fácil, no dejaba de ser manual.

Una vez que implementamos el circuito de CI/CD, todo fue más fácil, podemos manejar salidas a producción con un click o tocando un botón y estaremos tranquilos de que si algo falla, podremos volver atrás o en el mejor de los casos se volverá automáticamente para atrás sin nuestra intervención y se nos avisará.

En este caso, vamos a usar toda esa experiencia para implementar un proceso de CI/CD en el despliegue del servicio Pictures.

Crearemos una solución que haga lo siguiente:

Detectar nuevos push a nuestro repositorio de código (Github/CodeCommit), en la branch principal. Suele llamarse ‘main’.
A partir de allí un pipeline de AWS CodePipeline escuchará el cambio.
A través de AWS CodeBuild construiremos la imagen de Docker y la subiremos a Elastic Container Registry (ECR)
Luego haremos que nuestro cluster de EKS tome la nueva imagen y así nuestro servicio estará desplegado a producción.

Y lo más divertido es que todo se producirá automáticamente sin intervención nuestra, salvo la de crear la automatización en primer lugar 😃

Lo primero que te recomendamos aquí es armarte de paciencia, dado que esto es algo que harás una sola vez, e iteraras algunas otras sobre la mejora de la implementación, si no cambias tus procesos no tendrás que prácticamente tocarlo una vez que lo tengas pulido y solo tendrás que ocuparte de hacer commits y push a las diferentes ramas que tu pipeline este escuchando.

Los Servicios de AWS que vamos a utilizar son:

AWS CodePipeLine.
AWS CodeBuild
Amazon EKS

Hemos preparado una branch con todo lo que necesitas para ejecutar este episodio

git clone https://github.com/aws-samples/picture-social-sample.git -b cicd

Primero hemos agregado un archivo Dockerfile dentro de la carpeta de nuestro servicio pictures.

Contenido del archivo:

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /app
# Copy everything
COPY . ./
# Restore as distinct layers
RUN dotnet restore
# Build and publish a release
RUN dotnet publish -c Release -o out
# Build runtime image
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build-env /app/out .
EXPOSE 5075
ENV ASPNETCORE_URLS=http://+:5075
ENTRYPOINT ["dotnet", "pictures.dll"]

Una vez que hemos hecho esto, vamos a armar el pipeline, nuestro pipeline en este caso va a tener 2 pasos:

Paso 1:
Pull del Repositorio
Paso 2:
Armado de la imágen con CodeBuild, Publicación en ECR y en EKS
Al final del episodio el Pipeline debería de quedar así:

Primero desde la barra de búsqueda de nuestra Consola de administración Buscamos CodePipeline

Presionamos: Create pipeline

Ingresamos el nombre que queramos darle, en este caso PicturesService-CICD, y creamos un rol, pongamos un nombre que podamos recordar porque este rol más tarde lo modificaremos y le agregaremos unos permisos adicionales y presionamos Next

En Source Provider, en este caso vamos a elegir Github Versión 2, que es donde tenemos alojado nuestro repositorio:
Nota: En este caso te recomendamos que crees tu propio repositorio y lo conectes a tu cuenta, así puedes probar el pipeline sin problemas.

Luego nos pedirá conectarnos a github con nuestras credenciales, o bien si ya nos hemos conectado con anterioridad, para elegir una cuenta existente.

En el paso siguiente elegimos el repositorio desde el cual vamos a tomar el código y el branch (la rama) que queremos monitorear.

Presionamos Next y nos pedira en el siguiente paso elegir el Build Provider, en este caso vamos a elegir AWS CodeBuild

Luego de elegir CodeBuild, seleccionamos: Crear nuevo proyecto (Create new project)

Se nos abrirá una ventana y pasamos a completar lo que nos solicita:
Ponemos un nombre

Environment:

Elegimos Managed Image (estas imágenes son administradas por AWS CodeBuild y no tendremos que preocuparnos por la gestión de seguridad y actualización del OS de esas imágenes)
AmazonLinux 2 como sistema operativo
Runtime: Standard
Image: En este caso la última versión vigente la momento de escribir este articulo es la 4.0
Environment type: Linux
Muy importante: Dado que con este entorno vamos a crear nuevas imágenes de docker, debemos asegurarnos de que la casilla Privileged, esté activada.
Creamos un service role nuevo (Anotar el nombre)
Desplegamos donde dice Additional Configuration para poder crear algumas variables de entorno que vamos a utilizar en el próximo paso:

Creamos las siguientes variables:

AWS_DEFAULT_REGION : us-east-1
IMAGE_REPO_NAME: nombre de la imagen que estamos generando (en nuestro caso pictures)
AWS_ACCOUNT_ID : Nuestro número de cuenta de AWS
AWS_CLUSTER_NAME : nombre de nuestro cluster de EKS (en nuestro caso picturesocial-823)

El próximo paso es indicarle a CodeBuild dónde van a estar las instrucciones de “Build de nuestro proyecto”, existen 2 opciones:

Con un archivo buildspec.yml en la carpeta raíz del repositorio (al mismo nivel que el Dockerfile)
Escribiendo las instrucciones de construcción en el proyecto. Vamos a elegir esta opcion y presionamos Switch to editor

En el repositorio les hemos dejado el archivo Buildspec-example.yml que es el que usaremos para completar el código.

¿Qué estamos haciendo aqui?
Declaramos la versión que vamos a usar y el listado de fases:

version: 0.2
phases:

Primero declaramos las Fases
Fase 1: Pre-Build
En esta fase lo que estamos haciendo es

iniciando sesión en ECR
Descargando y configurando kubectl para que se conecte con nuestro cluster de EKS
Creamos una variable de entorno que utilizaremos luego como el tag que identificara la imágen imagen.

pre_build:
 commands:
 - echo Logging in to Amazon ECR...
 - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
 - curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.25.6/2023-01-30/bin/linux/amd64/kubectl
 - chmod +x ./kubectl
 - mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
 - echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
 - source ~/.bashrc
 - aws eks --region $AWS_DEFAULT_REGION update-kubeconfig --name $AWS_CLUSTER_NAME
 - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)

Luego viene la fase de Build:

Escribimos un mensaje en la consola para reconocer que comenzó la generación de las imágenes
Cambiamos de directorio y nos movemos a la carpeta Pictures, donde se encuentra el Dockerfile
Hacemos el build de la imágen tal como aprendimos en el episodio 1
Aplicamos un tag a nuestra imágen para luego subirla a ECR

build: commands: - echo Build started on `date` - echo Building the Docker image... - cd pictures - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG . - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG

Una vez que tenemos la imagen armada, vamos ahora si a enviarla a ECR y luego a EKS

Enviamos un mensaje a la consola para registrar el momento en el que se terminó de hacer el build de la imágen y avisamos que vamos a subir la imágen a ECR
Subimos la imágen a ECR
En el repositorio que les dejamos en el archivo manifest.yml hemos cambiado el nombre de la imágen a ECR_IMAGE_PLACEHOLDER, en este paso lo que estamos haciendo es reemplazar ese placeholder por le nombre real de la imágen genreada durante la fase de Build.
Luego hacemos un kubectl apply -f del archivo manifest.yml y con esto ya tendremos nuestra imágen publicada.

post_build:
 commands:
 - echo Build completed on `date`
 - echo Pushing the Docker image...
 - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG
 - echo Replacing in manifest with the image name
 - sed -i "s/ECR_IMAGE_PLACEHOLDER/${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com\/${IMAGE_REPO_NAME}:${IMAGE_TAG}/g" manifest.yml
 - kubectl apply -f manifest.yml

El archivo final debera quedarnos así:


version: 0.2

phases:
  pre_build:
    commands:
      - echo Logging in to Amazon ECR...
      - aws ecr get-login-password --region $AWS_DEFAULT_REGION | docker login --username AWS --password-stdin $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com
      - curl -o kubectl https://s3.us-west-2.amazonaws.com/amazon-eks/1.25.6/2023-01-30/bin/linux/amd64/kubectl
      - chmod +x ./kubectl
      - mkdir -p $HOME/bin && cp ./kubectl $HOME/bin/kubectl && export PATH=$PATH:$HOME/bin
      - echo 'export PATH=$PATH:$HOME/bin' >> ~/.bashrc
      - source ~/.bashrc
      - aws eks --region $AWS_DEFAULT_REGION update-kubeconfig --name $AWS_CLUSTER_NAME
      - IMAGE_TAG=$(echo $CODEBUILD_RESOLVED_SOURCE_VERSION | cut -c 1-7)
  build:
    commands:
      - echo Build started on `date`
      - echo Building the Docker image...
      - cd pictures
      - docker build -t $IMAGE_REPO_NAME:$IMAGE_TAG .
      - docker tag $IMAGE_REPO_NAME:$IMAGE_TAG $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG      
  post_build:
    commands:
      - echo Build completed on `date`
      - echo Pushing the Docker image...
      - docker push $AWS_ACCOUNT_ID.dkr.ecr.$AWS_DEFAULT_REGION.amazonaws.com/$IMAGE_REPO_NAME:$IMAGE_TAG_V2
      - echo Replacing in manifest with the image name
      - sed -i "s/ECR_IMAGE_PLACEHOLDER/${AWS_ACCOUNT_ID}.dkr.ecr.${AWS_DEFAULT_REGION}.amazonaws.com\/${IMAGE_REPO_NAME}:${IMAGE_TAG}/g" manifest.yml
      - kubectl apply -f manifest.yml

Reemplazamos el contenido del editor por el del archivo:

Luego seleccionamos continue to CodePipeline

De vuelta en CodePipeline presionamos: Next y saltamos el paso de Deploy Stage dado que ya lo hemos hecho en el paso anterior.

Nos pedirá confirmar todo y luego de confirmar nuestro pipeline ya estará creado.

Enhorabuena!

Esto no termina aqui, seguramente nuestra pipeline falle porque CodeBuild no tiene permisos para poder publicar en ECR, ni en EKS

Vamos a darle los permisos que necesita:

Vamos a modificar el Rol creado cuando estabamos creando el proyecto en CodeBuild y vamos a darle los permisos que necesitamos, para esto nos vamos a IAM: https://us-east-1.console.aws.amazon.com/iamv2/home?region=us-east-1
Ya en IAM nos vamos a Roles
Allí buscamos el rol que creamos en el momento de crear el proyecto de CodeBuild

Vamos a agregar permisos creando una nueva Policy

Nos vamos a la solapa JSON y pegamos el siguiente contenido:

Reemplazar donde dice ACCOUNT-ID por tu número de cuenta, y CLUSTER NAME por el nombre del cluster de EKS

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "VisualEditor0",
            "Effect": "Allow",
            "Action": [
                "ecr:CompleteLayerUpload",
                "eks:DescribeCluster",
                "ecr:UploadLayerPart",
                "ecr:InitiateLayerUpload",
                "ecr:BatchCheckLayerAvailability",
                "ecr:PutImage"
            ],
            "Resource": [
                "arn:aws:ecr:us-east-1:[ACCOUNT-ID]:repository/pictures",
                "arn:aws:eks:us-east-1:[ACCOUNT-ID]:cluster/[CLUSTER-NAME]"
            ]
        },
        {
        "Sid": "VisualEditor1",
        "Effect": "Allow",
        "Action": "ecr:GetAuthorizationToken",
        "Resource": "*"
        }
    ]
}

En nuestro caso quedaría asi:

Presionamos Siguiente, Ingresamos un nombre a nuestra policy

Luego presionamos Create policy y nuestra política estará creada.

Luego agregamos los permisos a nuestro rol:

Así debería quedar:

Copiemos el ARN de nuestro rol ya que lo vamos a utilizar para el próximo paso

Ahora lo que nos queda hacer, es darle permiso a CodeBuild en nuestro cluster de EKS para que pueda ejecutar el comando apply, para esto hay que a través de un Role Based Access Control darle permiso:
Desde nuestra consola ejecutamos el siguiente comando:

kubectl edit cm aws-auth -n kube-system

Luego dentro de mapRoles agregamos una nueva entrada:

Aqui reemplazamos el ARN por el que copiamos anteriormente, notese que quitamos el path /service-role/ del nombre del ARN

- groups:
 - system:masters
 rolearn: arn:aws:iam::XXXXXXXX:role/PicturesBuildServiceRole 
 username: CodeBuild Role to Access EKS

Ahora si, podemos volver a nuestro pipeline, y lo tenemos listo para trabajar, presionemos “Release change”

Y veremos cómo ahora si se completa el trabajo:

Ahora:

Realiza algún cambio mínimo en el código y verás como cada vez que se haga un push a la rama que hayas configurado, automáticamente se desplegará en el Cluster.

Si llegaste hasta acá, hoy aprendiste cómo usar algunas de las capacidades de CI/CD que tienes disponibles en AWS y cómo es que puedes aplicarlas a tus proyectos contenerizados. En el siguiente episodio aprenderemos cómo agregar observabilidad a Picturesocial y por qué deberíamos hacerlo. Nos vemos en el siguiente episodio!

Sobre los autores

José Yapur es Senior Developer Advocate en AWS con experiencia en Arquitectura de Software y pasión por el desarrollo especialmente en .NET y PHP. Trabajó como Arquitecto de Soluciones por varios años, ayudando a empresas y personas en LATAM.
Ricardo Ceci es CTO @ Halsbrook y Fundador de .VNS | Software Agency, es un desarrollador apasionado por arquitecturas en la nube y desarrollo con nuevas tecnologías.

Picturesocial - Cómo es la arquitectura de una aplicación

Jose Yapur — Fri, 30 Dec 2022 21:39:23 +0000

Crear Picturesocial ha sido todo un viaje, cuando comenzamos me propuse crear una red social de cero, con el solo propósito de que aprendamos juntos el proceso de llevar una solución contenerizada a Amazon Web Services.

Algo que tal vez no dejé claro es que yo aprendí de AWS creando esta serie, comencé hace poco más de 1 año y solo sabía mi nombre y mi edad. Pero hoy me siento orgulloso de todo lo que hemos logrado y aprendido juntos.

Acá les dejo los enlaces con todo el contenido de la primera temporada.

Estos 10 episodios marcan el fin de nuestra primera temporada que se ha enfocado en el descubrimiento. La siguiente temporada estará pensada en la vida real, esa que no suele ser color de rosa, donde las cosas pueden fallar, podemos tener algunos problemas de disponibilidad, seguridad o gastar más de lo que creíamos, casi todo puede prevenirse y nos vamos a enfocar en crear una mejor experiencia para todos y todas. Por eso me pareció que debíamos cerrar la temporada pensando en arquitectura, a manera de resumen de todo lo que hemos hecho hasta ahora y de pensar en el futuro. He invitado a Gustavo Fandiño quien es arquitecto de soluciones en AWS para que nos guíe en entender cuáles son los retos y el futuro de Picturesocial para el siguiente año.

Lo primero que hicimos fue entender la arquitectura as-is y los servicios que hemos explorado en los diferentes episodios de la serie.

Para luego revisar la primera fase de lo que será nuestra nueva arquitectura, donde iremos agregando Entrega e Integración continua así como el offloading de cómputo de nuestro clúster de Kubernetes hacia componentes Serverless.

Este post no tiene mucho detalle porque creo que lo más valioso es la conversación del video así que espero sus comentarios y sugerencias. Todo lo que me escriban será tomado en cuenta para la siguiente temporada.

¿Nos leemos el próximo año?

Picturesocial - Cómo desplegar un cluster de Kubernetes en AWS usando Terraform

Jose Yapur — Tue, 07 Jun 2022 15:31:28 +0000

En nuestro último post descubrimos sobre Kubernetes y por qué lo estamos usando en Picturesocial. En este post vamos a aprender sobre infraestructura cómo código, y específicamente sobre cómo desplegar un Amazon Elastic Kubernetes Service usando Terraform.

He trabajado en proyectos de TI por varios años y algo recurrente, en mi experiencia, ha sido cómo los desarrolladores trabajan junto con los Sysadmins, especialmente cuando la aplicación fuerza cambios en la infraestructura y en la forma en la que las cosas son hechas tradicionalmente, ¿La aplicación tiene que adaptarse a la infraestructura o la infraestructura debe adaptarse a la aplicación?, ¿Qué pasa si los cambios en infraestructura representan problemas para hacer rollback a versiones anteriores de la aplicación de forma sencilla?

En el pasado, diseñamos aplicaciones sabiendo que en la mayoría de los casos la infraestructura era estática, que teníamos que lidiar con las limitaciones como algo axiomático e inamovible. A medida que avanzamos en nuestro camino a la computación en la nube, ese paradigma comenzó a romperse con la posibilidad de tener teóricamente todo el poder de computo que necesitábamos al alcance de nuestras manos y casi de forma inmediata. Ese cambio ayudó a crear un nuevo set de soluciones diseñadas para esas nuevas capacidades, una de ellas fue Infraestructura como Código (IaC)

Pero, ¿Qué es infraestructura como código?

Cuando estaba en el colegio me gustaba escribir historias de Calabozos y Dragones, donde el personaje principal tenía que tomar decisiones irreversibles que eran seleccionadas por el lector, y dependiendo de la elección podrías ir a través una serie de aventuras que podían ser potencialmente largas y complejas o simplemente hacían que la historia termine en ese momento. Así es como suceden las cosas con la infraestructura, comienzas con algunos supuestos que te obligan a elegir el tamaño de tu infra, dimensionamiento de redes, uso de balanceadores, etc. La mayoría de cambios que hagas sobre la infraestructura base son potencialmente irreversibles a menos que conozcas exactamente lo que pasó desde el inicio y cada acción que se realizó. Esto significa que mantener versionamiento de la infraestructura y su configuración en conjunto con la aplicación puede ser posible pero se vuelve bastante difícil, y es ahí donde la Infraestructura como Código entra a la acción.

La Infraestructura como Código te permite definir tu infraestructura y configuración de manera similar a como los desarrolladores de software definen sus aplicaciones y está compuesto por archivos de configuración. Estos archivos de configuración son interpretados y transformados en infraestructura en tu ambiente de nube pública o híbrida. IaC te permite mantener versionamiento de cada cambio, así como hacer rollback hacia versiones anteriores, incluso puedes crear pruebas para entender qué representan esos cambios antes de aplicarlos.

Para Picturesocial decidí usar Hashicorp Terraform, para nuestras definiciones de IaC, debido a que es una herramienta que vengo usando por años y me siento seguro de poder escalar mi arquitectura e infraestructura sin gastar mucho tiempo aprendiendo una nueva herramienta. Sin embargo, hay otras excelentes herramientas en el mercado como AWS Cloud Development Toolkit, AWS CloudFormation, Pulumi, Ansible, Chef, Puppet, entre otras. Estas herramientas también pueden ayudarte, la mejor opción es la que te haga sentir más cómodo y productivo.

¿Qué es Hashicorp Terraform?

Terraform es una herramienta de IaC creada por Hashicorp que te ayuda a definir una infraestructura completa de una forma en la que puedes versionarla y reutilizarla. Usa Hashicorp Configuration Language (HCL) para su estructura. Todos los archivos de configuración de Terraform deben ser guardados con la extensión .tf

Algunas definiciones básicas a tener en cuenta son:

Providers: Aquí es donde le dices a Terraform que estás usando un proveedor de nube específico [providers (https://registry.terraform.io/browse/providers)], por ejemplo, si quieres desplegar tu infraestructura a AWS, necesitas definir un proveedor como en el ejemplo a continuación. Tener en cuenta que especificar la versión del proveedor es opcional, si no la especificas usará la última disponible como versión por defecto.

terraform {
  required_providers {
    aws = {
      source  = "hashicorp/aws"
      version = ">= 3.20.0"
    }
  }
}

Resources: Acá es donde defines la infraestructura. Puedes definir los recursos como piezas de infraestructura tipo: instancias, redes, storage, etc. Un recurso necesita dos parametros declarativos: 1/ el tipo de recurso y 2/ el id del recurso. Por ejemplo, abajo estamos definiendo una instancia de AWS con un AMI específico y tipo de instancia t2.micro.

resource "aws_instance" "web" {
  ami           = "ami-a1b2c3d4"
  instance_type = "t2.micro"
}

Variables:
- Input: Estas son las variables que usas para solicitar información de los usuarios o runtime antes de aplicar algún cambio. Este tipo de variables son parámetros que debes ingresar en el Terraform CLI [CLI (https://www.terraform.io/cli)]

variable "project_code" {
  type = string
}

variable "availability_zone" {
  type    = list(string)
  default = ["us-east-1a"]
}

* Output: Estas son variables que retornarán información de la ejecución. Por ejemplo, nombre del repositorio, id del cluster, etc.

output "ec2_ip" {  value = aws_instance.server.private_ip}

* Locals: Estas son variables que estableces en tu código y pueden ser referenciadas en cualquier parte del proyecto. El ejemplo a continuación creará una etiqueta común para todos los recursos que creemos y concatenará los valores de las variables project_code y environment


locals {
  project_code = "pso"
  environment        = "dev"
}
common_tags = {
  project_name = "pe-${local.project_code}-${local.environment}01"
}

Modules: Usamos los módulos para agrupar diferentes recursos que son utilizados de forma conjunta en una arquitectura, de esa forma en vez de tener una plantilla de Terraform de 30 paginas y 2 volúmenes, podemos estandarizar escenarios como un solo objeto. Por ejemplo: Cada Amazon EKS Cluster necesita una VPC con 6 subnets, 2 Elastic Load Balancers, 2 Worker Groups con al menos 3 instancias de EC2 cada grupo, etc. En vez de crear todos los recursos por cluster, podemos crear un módulo y reutilizarlo para simplificar las creaciones futuras.

module "aws-vpc" {
  source = "./mods/aws-vpc"
  base_cidr_block = "11.0.0.0/16"
}

Me gusta pensar en Terraform como una herramienta de IaC de 4 pasos (inclusive si tenemos más opciones), vamos a usar 4 comandos básicos que aplicarán a todos nuestros proyectos, esos pasos necesitan ser ejecutados en el siguiente orden:

terraform init Usa este comando para inicializar tu proyecto de Terraform, solo debes ejecutar este comando una vez por proyecto.
terraform plan Este comando se usa para probar qué es lo que se creará, actualizará o eliminará en tu ambiente de nube y antes de ejecutar cualquier cambio.
terraform apply Este comando ejecuta terraform plan como paso 1 y luego en base a tu confirmación, ejecuta los cambios finales en tu ambiente de nube.
terraform destroy Cuando ya no necesitas tu ambiente de nube, puedes destruirlo por completo. Esto es súper útil para ambientes de certificación que solo son usados cuando sale un nuevo release, por ejemplo.

Ahora que entendemos algunos conceptos básicos de IaC y Terraform ¡Vamos a desplegar un Cluster de Amazon EKS desde el inicio!

Pre-requisitos

Una cuenta de AWS, si no tienes puedes pedir una aquí: https://aws.amazon.com/free/
Si estás usando Microsoft Windows te sugiero trabajar usando WSL2: https://docs.microsoft.com/en-us/windows/wsl/install
Si no tienes Git, desde acá puedes instalarlo: https://github.com/git-guides/install-git
Instala la línea de comandos de Terraform https://learn.hashicorp.com/tutorials/terraform/install-cli
Necesitarás el AWS CLI v2 https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
Si esta es tu primera vez trabajando con AWS CLI o necesitas un refresh de como setear tus credenciales en el terminal te sugiero seguir este paso a paso: https://aws.amazon.com/es/getting-started/guides/setup-environment/. Si no quieres instalar todo desde cero, en este mismo link podrás seguir los pasos para configurar Amazon Cloud9 que es un entorno de desarrollo virtual, que incluye casi todo el toolset que necesitas para este paso a paso.

Paso a Paso

En este paso a paso vamos a crear un Cluster de Amazon EKS en la región us-east-1 usando 3 zonas de disponibilidad, nuestra propia VPC, un worker group con 3 instancias t2.small y security rules para prevenir acceso no restringido a nuestro worker group. He creado este repositorio en Github https://github.com/aws-samples/picture-social-sample con todo el código necesario para seguir este paso a paso. Asegúrate de seleccionar la branch “ep3”.
In this walkthrough we are going to create an Amazon EKS Cluster on the us-east-1 region using 3 availability zones, our own VPC, a worker group with 3 t2.small instances and security rules to prevent unrestricted access to our worker group.
I created a repository on Github https://github.com/aws-samples/picture-social-sample with all the code needed to follow this walkthrough, make sure you select branch “ep3”.

Primero, vamos a clonar nuestro repositorio base para tener todos los archivos de terraform que necesitaremos para crear nuestro cluster.

git clone https://github.com/aws-samples/picture-social-sample --branch ep3

Una vez clonado, vayamos al directorio creado. Aseguremonos de siempre estar dentro de este directorio por el resto de esta guía, de esa forma todo se ejecutará sin problemas.

cd picture-social-sample

Ahora que estamos en el directorio correcto y hemos clonado la branch, vamos a iniciar con el archivo config.tf. Este archivo contiene toda la configuración básica de nuestro proyecto de Terraform, como: región por defecto de AWS, nombre del cluster, variables para generar valores aleatorios, etc. Podemos referencias cualquiera de estos valores en el proyecto.

variable "region" {
  default     = "us-east-1"
  description = "Region of AWS"
}

provider "aws" {
  region = var.region
}

data "aws_availability_zones" "available" {}

locals {
  cluster_name = "picturesocial-${random_integer.suffix.result}"
}

resource "random_integer" "suffix" {
  min = 100
  max = 999
}

El archivo vpc.tf es donde configuramos nuestra red y zonas de disponibilidad. Si quieres aprender más sobre VPC, puedes dar una mirada a este link: https://docs.aws.amazon.com/vpc/latest/userguide/vpc-getting-started.html

module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "3.2.0"

  name                 = "picturesocial-vpc"
  cidr                 = "10.0.0.0/16"
  azs                  = data.aws_availability_zones.available.names
  private_subnets      = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets       = ["10.0.4.0/24", "10.0.5.0/24", "10.0.6.0/24"]
  enable_nat_gateway   = true
  single_nat_gateway   = true
  enable_dns_hostnames = true

  tags = {
    "kubernetes.io/cluster/${local.cluster_name}" = "shared"
  }

  public_subnet_tags = {
    "kubernetes.io/cluster/${local.cluster_name}" = "shared"
    "kubernetes.io/role/elb"                      = "1"
  }

  private_subnet_tags = {
    "kubernetes.io/cluster/${local.cluster_name}" = "shared"
    "kubernetes.io/role/internal-elb"             = "1"
  }
}

Ahora que hemos configurado nuestra VPC, vamos a crear los Security Groups. Estos serán los que tienen a cargo la autorización o denegación del tráfico a las instancias de EC2 de nuestro Amazon EKS. Para este caso habilitaremos el trafico al puerto 22 de entrada desde algunos segmentos de red llamados cidr_blocks

resource "aws_security_group" "worker_group_mgmt_one" {
  name_prefix = "worker_group_mgmt_one"
  vpc_id      = module.vpc.vpc_id

  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"

    cidr_blocks = [
      "10.0.0.0/8",
    ]
  }
}

resource "aws_security_group" "worker_group_mgmt_two" {
  name_prefix = "worker_group_mgmt_two"
  vpc_id      = module.vpc.vpc_id

  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"

    cidr_blocks = [
      "192.168.0.0/16",
    ]
  }
}

resource "aws_security_group" "all_worker_mgmt" {
  name_prefix = "all_worker_management"
  vpc_id      = module.vpc.vpc_id

  ingress {
    from_port = 22
    to_port   = 22
    protocol  = "tcp"

    cidr_blocks = [
      "10.0.0.0/8",
      "172.16.0.0/12",
      "192.168.0.0/16",
    ]
  }
}

El archivo eks-cluster.tf es donde se une todo lo que creamos en los pasos anteriores, usa un módulo público de AWS que podemos reutilizar para simplificar la creación de nuestro cluster. Vamos a establecer el nombre del cluster referenciando las variables que creamos en el config.tf, seleccionamos la versión de Kubernetes y referenciamos la VPC y subnets definidas en el archivo vpc.tf

module "eks" {
  source          = "terraform-aws-modules/eks/aws"
  version         = "17.24.0"
  cluster_name    = local.cluster_name
  cluster_version = "1.20"
  subnets         = module.vpc.private_subnets

  vpc_id = module.vpc.vpc_id

  workers_group_defaults = {
    root_volume_type = "gp2"
  }

  worker_groups = [
    {
      name                          = "group-1"
      instance_type                 = "t2.small"
      additional_security_group_ids = [aws_security_group.worker_group_mgmt_one.id]
      asg_desired_capacity          = 3
    },
  ]
}

data "aws_eks_cluster" "cluster" {
  name = module.eks.cluster_id
}

data "aws_eks_cluster_auth" "cluster" {
  name = module.eks.cluster_id
}

Y finalmente vamos a revisar los outputs luego que se entregarán al finalizar la ejecución del proyecto de Terraform en el archivo outputs.tf Este archivo producirá el archivo Config de Kubernetes o kubeconfig, esto es neceario para que Kubectl o el Kubernetes REST API sepa quien eres, si tienes acceso y si puede confiar en ti. Y además es una de las piezas más importantes para obtener acceso al cluster de Amazon EKS.

output "cluster_id" {
  value       = module.eks.cluster_id
}

output "cluster_endpoint" {
  value       = module.eks.cluster_endpoint
}

output "cluster_security_group_id" {
  value       = module.eks.cluster_security_group_id
}

output "kubectl_config" {
  value       = module.eks.kubeconfig
}

output "config_map_aws_auth" {
  value       = module.eks.config_map_aws_auth
}

output "region" {
  value       = var.region
}

output "cluster_name" {
  value       = local.cluster_name
}

Ahora asegurémonos que tenemos terraform correctamente instalado, vamos a ejecutar el comando a continuación en el terminal que prefieras. Si todo está bien deberías recibir la versión de Terraform instalada, necesitas al menos la versión 1.1.7.

terraform —version

Ahora vamos a inicializar nuestro proyecto al ejecutar el siguiente comando:

terraform init

El comando anterior descargará todos los módulos públicos y archivos que necesita el proveedor de Terraform para AWS. Si recibes el siguiente mensaje en la línea de comandos “Terraform has been successfully initialized!" entonces estamos listos para continuar. Si recibes algún error, revisa el mensaje de error donde te dirán la línea y archivo que tienen problemas, no te preocupes el error suele ser un error en nombre de variable o que te falta una comilla :)
Ahora vamos a probar nuestra configuración:

terraform plan

El comando plan retornará un resumen de todas las cosas que se agregarán, cambiarán o destruirán. Esto nos dará una buena idea de cómo funcionará todo antes de ejecutar cambios.

Terraform used the selected providers to generate the following execution plan. Resource
actions are indicated with the following symbols:
  + create
 <= read (data resources)

Terraform will perform the following actions:

  # data.aws_eks_cluster.cluster will be read during apply
  # (config refers to values not yet known)
 <= data "aws_eks_cluster" "cluster"  {
      + arn                       = (known after apply)
      + certificate_authority     = (known after apply)
      + created_at                = (known after apply)
      + enabled_cluster_log_types = (known after apply)
      + endpoint                  = (known after apply)
      + id                        = (known after apply)
      + identity                  = (known after apply)
      + kubernetes_network_config = (known after apply)
      + name                      = (known after apply)
      + platform_version          = (known after apply)
      + role_arn                  = (known after apply)
      + status                    = (known after apply)
      + tags                      = (known after apply)
      + version                   = (known after apply)
      + vpc_config                = (known after apply)
    }

  #,
 .
 .
 .
*Plan: 50 to add, 0 to change, 0 to destroy.
*
Changes to Outputs:
  + cluster_endpoint          = (known after apply)
  + cluster_id                = (known after apply)
  + cluster_name              = (known after apply)
  + cluster_security_group_id = (known after apply)
  + config_map_aws_auth       = [
      + {
          + binary_data = null
          + data        = (known after apply)
          + id          = (known after apply)
          + metadata    = [
              + {
                  + annotations      = null
                  + generate_name    = null
                  + generation       = (known after apply)
                  + labels           = {
                      + "app.kubernetes.io/managed-by" = "Terraform"
                      + "terraform.io/module"          = "terraform-aws-modules.eks.aws"
                    }
                  + name             = "aws-auth"
                  + namespace        = "kube-system"
                  + resource_version = (known after apply)
                  + uid              = (known after apply)
                },
            ]
        },
    ]
  + kubectl_config            = (known after apply)
  + region                    = "us-east-1"

───────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take
exactly these actions if you run "terraform apply"

Ahora que estamos seguros, vamos a ejecutar los cambios en AWS. Para ello ejecutaremos el comando a continuación. Deberás escribir explícitamente “yes” para confirmar que estás de acuerdo con los cambios antes de ejecutarlos.

terraform apply

Este proceso tardará alrededor de 15 a 20 minutos, pero dependiendo de tu propia configuración puede ser significativamente más o menos tiempo. Ten en cuenta que tu terminal necesita ser accesible y estar conectada a internet mientras el comando se ejecuta y finaliza la ejecución. Es un bueno momento para hacerte un buen café y ver videos de gatos cantando.
Una vez que el comando termine de ejecutarse, deberás recibir el siguiente mensaje:

Apply complete! Resources: 50 added, 0 changed, 0 destroyed.

Vamos a extraer todos los outputs que configuramos en el archivo outputs.tf, esos outputs además, son parte del mensaje que sale abajo de Apply complete! Todo esto será usado para construir el kubeconfig. Para extraer esos valores usaremos el comando a continuación:

aws eks --region $(terraform output --raw region) update-kubeconfig --name $(terraform output --raw cluster_name)

¡Estamos Listos! Ahora confirmemos que el cluster ha sido creado correctamente ejecutando el siguiente comando:

aws eks list-clusters

Si todo funcionó como lo esperábamos entonces deberías tener un output similar a este:

{"clusters": ["picturesocial-129"]}

Si tienes experiencia con Kubernetes y tienes una carga de trabajo que quieras probar, sientete libre de comenzar a jugar. Pero, si no tienes experiencia en cómo desplegar aplicaciones en Kubernetes te sugiero que elimines toda la infraestructura y la re-despliegues en el siguiente episodio, de esa forma evitas cargos innecesarios en tu cuenta por recursos que no usarás. Puedes borrar todo ejecutando el siguiente comando:

terraform destroy

Wow! Realmente, este fue un artículo largo pero lo hicimos! Puedes reutilizar esta plantilla para crear tus propios clusters o incluso para crear tus propios módulos en el futuro.

En el siguiente post aprenderemos a desplegar una aplicación a Kubernetes y creo que es una de las partes más satisfactorias de la serie porque es cuando vemos la aplicación finalmente ejecutandose y aprovechando las ventajas de Kubernetes como self-healing, auto escalamiento, balanceo de carga, etc.

Espero que aprendieras leyendo este post, nos vemos en el siguiente!

Picturesocial – ¿Qué es Kubernetes y por qué debería importarme?

Jose Yapur — Tue, 10 May 2022 16:09:56 +0000

En el post anterior, aprendimos sobre Containers y los pasos necesarios para contenerizar una aplicación. Sin embargo, crear un container sin pensar dónde desplegarlo es como tener tu casa dentro de una caja flotando en el medio del mar. Por más que suene tentador o escalofriante, definitivamente necesitarás electricidad, agua, gas, recolección de desechos, comida y tal vez un poco de interacción humana, si quieres llevar una vida sana y productiva. En este artículo vamos a aprender sobre Kubernetes, una de las piezas más importantes en la arquitectura de Picturesocial.

Picturesocial tendrá varias APIs que queremos que sean mantenidas, desplegadas y desarrolladas de forma independiente, es por eso que decidimos usar una arquitectura de containers. Hablar de este tipo de arquitecturas no es tan complejo como suena. Simplemente significa que estás usando containers y un orquestador de containers. Un orquestador de containers es el que está a cargo de manejar todos los containers, réplicas, redes, almacenamiento y en general la infraestructura necesaria. El orquestador de contenedores más popular es Kubernetes gracias a su comunidad activa, soporte y ecosistema de integración.

Kubernetes, o k8s para los amigos, es un orquestador de código abierto con un ecosistema amplio y de rápido crecimiento. Te ayuda a administrar el escalamiento y failover de tus containers, además te podría ayudar con:
• Balanceo de Carga y Descubrimiento de Servicios: te permite balancear el trafico de red entre los containers y la infraestructura, así como a descubrir nuevas réplicas de containers o containers que fueron removidos.
• Despliegue y rollback automático: puedes elegir cómo desplegar tus containers, cómo manejar actualizaciones y cómo prevenir caídas debido a updates, fallos en la infraestructura o errores en el contenedor.
• Bin packing Automático: Kubernetes usará, optimizará se adaptará al poder de cómputo disponible basado en los límites que tu establezcas.
• Autocuración: si un container falla, Kubernetes lo reiniciará hasta que funcione o lo eliminará y creará uno nuevo.

Desplegar y mantener tu propio clúster de Kubernetes desde cero no es algo trivial y requiere un conocimiento profundo de cómo funciona Kubernetes, Linux, Virtualización, Redes, Seguridad y un abanico de otras tecnologías. Es por eso que Amazon Web Services tiene Amazon Elastic Kubernetes Engine (Amazon EKS), una solución de Kubernetes administrada por AWS que te ayuda a reducir la complejidad de la preparación de infraestructura y el setup de Kubernetes. Además, te ayuda a tener un entorno de Kubernetes más seguro con actualizaciones de seguridad aplicadas de forma automática a tu cluster.
El manifiesto o El YAML

Puedes comunicarte nativamente con un clúster de Kubernetes de dos formas: Kubectl (Kube Control) y llamando una API REST. Ambos métodos usan un cuerpo de petición común en formato YAML (Yet Another Markup Language), a este YAML lo llamamos el Manifiesto y contiene instrucciones detalladas sobre:
• Lo que estamos desplegando.
• Cómo lo estamos desplegando.
• Qué estamos exponiendo.
• Cómo lo estamos exponiendo.
El siguiente, es un ejemplo de YAML que usaremos como plantilla para varias aplicaciones contenerizadas. Revisaremos los conceptos básicos de este YAML en este blog post.

#########################
# POD Definition
#########################
apiVersion: apps/v1
kind: Deployment
metadata:
  name: deploymentName
  labels:
    app: applicationName
spec:
  replicas: 1
  selector:
    matchLabels:
      app: applicationName
  template:
    metadata:
      labels:
        app: applicationName
    spec:
      containers:
      - name: applicationName
        image: [aws account id].dkr.ecr.[aws region].amazonaws.com/imageName
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"
---
#########################
# Service Definition
#########################
kind: Service
apiVersion: v1
metadata:
  name: service-name
spec:
  selector:
    app: applicationName
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer

Label

Todo lo que esté dentro de Kubernetes necesita un Label, de esa forma identificas todos los recursos en el clúster y además es la forma en la que le dices a Kubernetes dónde mirar cada vez que ejecutas comandos Kubectl o peticiones al API REST.

template:
    metadata:
      labels:
        app: applicationName

Pods

Un pod es el objecto más pequeño en Kubernetes y es el lugar donde los containers viven. Un pod puede tener más de un container pero se recomienda una relación de un container por pod para evitar acoplamiento y puntos únicos de fallo. Algunas consideraciones importantes son:
• Los pods son efímeros, eso significa que si el container dentro de un pod falla entonces el resultado más probable es que Kubernetes reiniciará o eliminará el pod y creará uno nuevo. Cuando despliegas nuevas versiones del container, también se crean pods nuevos. Por lo que no debemos nunca asumir el pod como algo estático.
• Una imagen de container debe ser especificada. Siempre se define como el nombre del repositorio y el nombre de la imagen, por ejemplo: [aws account id].dkr.ecr.[aws region].amazonaws.com/imageName
• Es una buena práctica establecer límites de recursos. Tenemos dos tipos de control:
o Requests: este límite es la garantía de computo del pod. Es como cuando pides una pizza y tienes 30 minutos de garantía, eso no significa que la pizza no puede llegar antes, es solo un indicador para saber cuantos pedidos puede manejar un solo repartidor. Es lo mismo con Requests, especifica la garantía mínima de cómputo en un cluster. Si tus nodos tiene capacidad ociosa, lo más probable es que el pod obtenga más de lo garantizado.
o Limits: este es un límite estático para cualquier pod. Si tu especificas un Limit, incluso si tuvieras capacidad ociosa de cómputo, ese pod no consumirá más de lo que estableciste. Usando el mismo ejemplo del repartidor de pizza, es como decirle que bajo ninguna circunstancia puede entregar más de 3 pizzas al mismo tiempo.
• Las unidades que usamos comúnmente en Kubernetes son:
o Mebibytes (MiB) expresados como Mi: para convertir de MiB a MB, multiplica MiB x 1.049
o Milicores (mc) expresados como m: 1 CPU Core es representado como 1000 milicores. Por ejemplo, 250m es 1/4 de un CPU Core.

containers:
      - name: applicationName
        image: [aws account id].dkr.ecr.[aws region].amazonaws.com/imageName
        resources:
          requests:
            memory: "256Mi"
            cpu: "250m"
          limits:
            memory: "512Mi"
            cpu: "500m"

ReplicaSet

Los pods están destinadas a replicarse basado en diferentes métricas como CPU o consumo de memoria. También podemos establecer valores estáticos como en el ejemplo a continuación donde configuramos una sola réplica. Al conjunto de réplicas de un pod lo llamamos ReplicaSet.

spec:
  replicas: 1
  selector:
    matchLabels:
      app: applicationName

Services

Los pods no deben llamarse directamente, recuerda que son efímeros, lo que también significa que cada vez que actualizas o se crean nuevos, tanto los nombres como las IP varían. Los Services vienen a resolver ese problema directamente y ofrecer un punto único para llamar a una o multiples pods del mismo ReplicaSet. Vamos a enfocarnos en dos tipos de Service:
• LoadBalancer: Este tipo de Service es usado cuando necesitas exponer un ReplicaSet fuera del clúster de Kubernetes, ya sea de forma pública al internet o privada dentro de una red local. En el caso de Amazon EKS, deberías tomar en cuenta dos cosas:
o Los nombres de Service deben siempre empezar con una letra y contener un guion (“-”) como separador. Por ejemplo: picturesocial-pictures
o Los LoadBalancer privados deben siempre tener una anotación que especifique que será publicado en una red local únicamente.

kind: Service
apiVersion: v1
metadata:
  name: service-name
  annotations:
    service.beta.kubernetes.io/aws-load-balancer-scheme: "internal"
spec:
  selector:
    app: applicationName
  ports:
  - port: 80
    targetPort: 80
  type: LoadBalancer

• ClusterIP: Este tipo de Service es usado cuando necesitas exponer un réplica set para consumidores dentro del clúster de Kubernetes. Este es el enfoque más común debido a que los pods están más seguros si se mantienen dentro de los límites del clúster, de esta forma puedes agregar capas de seguridad para consumirlos como: ingress controller, mutual authentication, API Gateways, etc. Explicaremos un poco más de estos conceptos en futuros blog posts.

kind: Service
apiVersion: v1
metadata:
  name: service-Name
spec:
  selector:
    app: applicationName
  ports:
  - targetPort: 80
    port: 80
  type: ClusterIP

Los Services siempre detectan cambios en el backend, de esta forma si un pod se cae o es reemplazado por uno nuevo, el Service detendrá el tráfico hacia ese pod y lo redireccionará a los pods que estén trabajando sin problemas. Es por eso que enfatizo que la comunicación síncrona entre pods debe hacerse siempre usando Services y no llamando pods de forma directa, incluso si tu API está contenida en solo un pod.

Namespace

Kubernetes fue concebido como un orquestador de containers multi-tenant. Eso significa que fue diseñado como una solución capaz de gestionar múltiples aplicaciones y ambientes al mismo tiempo. Ahí es donde los Namespaces vienen a la acción. Los Namespaces trabajan como un separador de recursos lógico dentro de Kubernetes, puedes agrupar recursos (pods, services, etc.) en un Namespace específico y establecerle permisos. Por ejemplo, podrías decir que los pods en el Namespace A no pueden llamar a los pods del Namespace B.

Mi sugerencia es que agrupes los recursos de un dominio de negocio en un namespace, de esa forma será más fácil encontrar los recursos que necesitas mientras que habilitas a equipos mantener dominios de negocio de forma independiente.

¿Para qué tipo de aplicaciones debería usar Kubernetes?

Usar Kubernetes para todo es cómo manejar un auto de Formula 1 para ir al supermercado. No me malinterpretes, definitivamente lo haría, pero al mismo tiempo no tiene sentido, ¿En qué cajuela pondría mis 3 pallets de café para la semana?

Para determinar si usar o no Kubernetes yo suelo usar los siguientes criterios, esta no es una ciencia exacta y podría no adaptarse a tu escenario, pero me ha ayudado mucho en el pasado.
• Tienes una arquitectura contenerizada con al menos 10 servicios ejecutándose y escalando de forma independiente y en la misma infraestructura.
• Tus servicios tienen dependencias que viven en un ambiente restringido a una red local y necesitas políticas de tráfico y autenticación para invocar a esas dependencias.
• Estás trabajando con diferentes equipos manteniendo y desarrollando diferentes componentes de la misma aplicación, de forma independiente.
• Necesitas control sobre el cómputo, redes, políticas de redes, estrategia de despliegue y versionamiento del orquestador.
• Necesitas una solución que se expanda de on-premises a la nube usando herramientas y procesos consistentes que trabajen bajo una estrategia de despliegue unificada.
Si dos o más de esos criterios son verdaderos entonces Kubernetes es una buena opción.

Yo sé que ha sido demasiada información para un solo blog post, pero también sé que, a pesar de sentirse abrumador, el propósito de este artículo es que juntos entendamos cómo funciona Kubernetes y familiarizarnos con los términos importantes. A medida que avancemos en la creación de Picturesocial veremos como estos conceptos son aplicados en los paso a paso.
En el siguiente blog post aprenderemos cómo crear un clúster de Amazon EKS usando Terraform. Si te gustó este artículo te sugiero que mires el video de este segundo episodio en Youtube: https://www.youtube.com/watch?v=VHCnyiWVBR4&feature=emb_title

PictureSocial - Cómo contenerizar una aplicación en menos de 15 minutos

Jose Yapur — Fri, 22 Apr 2022 15:41:52 +0000

Hablar de contenedores o containers en arquitectura de software es hablar de un hot topic. Algunos de nosotros hemos trabajado en esos conceptos por años mientras que otros recién están empezando. De todas formas, me gustaría ser quien te guíe en tu proceso de aprendizaje en containers. Juntos, en esta serie, construiremos Picturesocial, una nueva red social para compartir fotos que nacerá con una arquitectura basada en containers. Mientras la construimos tomaremos decisiones de arquitectura y exploraremos algunos retos y soluciones.

Pero, ¿Qué es un container?
Imagina la sala de tus sueños, con una pintura del color que te gusta, un sofá súper cómodo para leer o pasar el rato, una mesa de centro para poner la tasa de dos litros de café y ese libro de pinturas famosas de que nunca abriste pero se ve muy cool. Finalmente sientes que es el espacio perfecto, solo para darte cuenta que tienes que mudarte a otro lugar y comenzar todo el proceso desde cero.

Ahora imagina que estás diseñando exactamente la misma sala pero dentro de uno de esos containers de metal que llevan los barcos de carga. Esa sala ira contigo a donde sea que vayas, puede estar en un barco en el medio del mar, en un avión o en un camión cruzando el país.
Un container es exactamente eso, tu aplicación, runtime y sistema de archivos, todo empaquetado (como tu sala en un container de barco) para ejecutarse en cualquier lugar que soporte containers. A mi particularmente me gustan los container porque me dan la flexibilidad y libertad de correr mis aplicaciones donde quiera, cuando quiera y saber que funcionarán sin hacer cambios.

Cuando trabajas sobre aplicaciones contenerizadas lo más probable es que tus dependencias como base de datos o manejador de colas, no estén dentro de containers sino como servicios externos, al menos en los ambientes productivos, por eso es súper importante que tengas un lugar donde poner la información de configuración de tu aplicación como cadenas conexión, zonas horarias y otros que puedas necesitar; de esa forma si pasas de un ambiente a otro como de Desarrollo a QA y luego a Producción solo necesitas apuntar a la configuración correcta y evitas errores como el mío, donde desplegué una nueva versión de un sitio web completo de alta concurrencia y en producción con la configuración de desarrollo, apuntando a una base de datos local donde todos los clientes tenían el nombre de mis gatos.

Para iniciar vamos a aprender sobre algunos conceptos básicos de Docker container que nos ayudarán en nuestra ruta de aprendizaje.

Image: Esta es una de las piezas fundamentales de un Container, es donde una aplicación y su estado viven. La imagen de un container está compuesta por la compilación de tu aplicación junto con un Dockerfile usando el demonio de Docker, que viene al instalar Docker en tu ambiente de desarrollo. Siempre pienso en la Imagen como un archivo ISO[1 (https://es.wikipedia.org/wiki/Imagen_ISO)], de esos que usaba para capturar el estado de mi sistema operativo con archivos, configuraciones y aplicaciones instaladas, y que podía ser utilizada en casi cualquier otra computadora. Comparado con un ISO, una imagen de container solo tiene una pequeña parte del sistema operativo, algunas librerías que yo indique, el runtime y mi aplicación, por lo que termina siendo mucho más liviana y con menos requerimientos de computo al no tener que cargar un sistema operativo completo.
Container: Cuando una Imagen se ejecuta pasa a llamarse un Container.
Engine: Tu container necesita ejecutarse en algún lado donde Docker esté instalado. La forma que usa Docker para comunicarse con el Hardware donde está instalado es por medio de APIs, esas APIs son el Engine. Con el Engine, tu container obtiene acceso a los recursos de hardware como CPU, almacenamiento y redes.
Registry: Es el lugar donde almacenas tus Imagenes de Container. El registry puede ser público o privado. Un registry no solo almacena la última (latest) imagen, sino también usa tags y metadata como 1/ cuándo fue subida tu imagen, 2/ quién sube la imagen y 3/ cuándo la imagen es usada. Es por eso que no podemos hablar de containers sin un registry, incluso cuando trabajamos localmente, nuestra computadora es el registry.

Ahora que tenemos un poco de contexto vamos a dar un vistazo al Dockerfile. Para mi, el Dockerfile es lo que solía hacer cuando estaba iniciando mi carrera como practicante, algunos de nosotros estuvimos a cargo de “Escribir el Manual de Instalación”, si, ese manual que nadie realmente leía y que cuando era necesario nunca servía y que sin embargo el principal problema de ellos siempre ha sido que fue escrito por humanos para humanos, sin embargo, un Dockerfile es un manual creado por humanos para máquinas, por lo que debe ser escrito de forma muy precisa y resuelve la mayoría de problemas de interpretación.

FROM mcr.microsoft.com/dotnet/sdk:6.0 AS build-env
WORKDIR /app
COPY . ./
RUN dotnet restore
RUN dotnet publish -c Release -o out
FROM mcr.microsoft.com/dotnet/aspnet:6.0
WORKDIR /app
COPY --from=build-env /app/out .
EXPOSE 5111
ENV ASPNETCORE_URLS=http://+:5111
ENTRYPOINT ["dotnet", "HelloWorld.dll"]

Todos los Dockerfile necesitan un FROM y está usualmente ubicado en la primera línea. Es usado para especificar la imagen base que estás usando para crear tu propia imagen, por ejemplo, imagina que quieres crear una Imagen que necesita escribir un archivo en Ubuntu 20.04, entonces necesitarías un FROM similar a este:

FROM ubuntu:20.04

Del ejemplo de arriba podemos deducir cierta información básica sobre tagging. 1/ Ubuntu es el nombre de la imagen, tenemos disponibles millones de imágenes en Docker Hub , que en su mayaría son públicas y podemos usar para crear nuestras aplicaciones derivadas o usarlas tal cual. 2/ 20.04 es la versión de Ubuntu, luego de los dos puntos (“:”) siempre se indica el tag de la imagen, puedes usar tagging para especificar versiones de un app, ambientes, lenguajes, o lo que quieras . Si revisamos la pagina de la imagen de Ubuntu en Docker Hub podremos ver los diferentes tags disponibles y sus descripciones. https://hub.docker.com/_/ubuntu?tab=description

Algunos otros comandos importantes de Docker son:

RUN: usado para ejecutar múltiples comandos bash para preparar un container. Puedes usar RUN múltiples veces en tu Dockerfile. Por ejemplo el siguiente comando creará un directorio demo en el container.

RUN mkdir demo

CMD: usado para ejecutar comandos bash que solo pueden ser usados una vez, si tienes más de un CMD solo se ejecutará el último. CMD se utiliza para proveer valores por defecto a tu container. Por ejemplo, el siguiente comando creará un archivo llamado config e la carpeta .conf con el texto Hello World.

CMD ["echo", "Hello World"]

Si quieres conocer más sobre los comandos de Dockerfile, este link https://docs.docker.com/engine/reference/builder será de mucha ayuda. Además si quieres ver ejemplos de Dockerfile para varios lenguajes de programación y runtimes, puedes revisar este link https://docs.docker.com/samples/. Cuando creas tus propios Dockerfile es como cuando escribes un cuaderno de recetas, puedes reusarlo para aplicaciones similares cambiando pocas cosas , en mi caso usaré el mismo template de Dockerfile para todas las APIs .NET 6 que expondré en Picturesocial.

Ahora que tenemos un poco de contexto sobre containers, quiero contarles sobre Amazon Elastic Container Registry o Amazon ECR para los amigos. Puedes usar ECR para almacenar tus imágenes de container ya sea de forma pública o privada, la ventaja es que el acceso a tus imágenes es manejado por AWS Identity and Access Management (IAM) y es nativo de Docker, por lo que los comandos que ejecutas localmente con el Docker CLI son los mismos que ejecutarías para hacer operaciones ECR, como docker login o docker push

Pre-requisitos:

Una cuenta de AWS, si no tienes puedes pedir una aquí: https://aws.amazon.com/free/
Si estás usando Microsoft Windows te sugiero trabajar usando WSL2: https://docs.microsoft.com/en-us/windows/wsl/install
Si no tienes Git, desde acá puedes instalarlo: https://github.com/git-guides/install-git
Si no tienes Docker instalado, acá las instrucciones https://docs.docker.com/engine/install/
Acá los pasos para instalar AWS CLI https://docs.aws.amazon.com/cli/latest/userguide/getting-started-install.html
Si esta es tu primera vez trabajando con AWS CLI o necesitas un refresh de como setear tus credenciales en el terminal te sugiero seguir este paso a paso: https://aws.amazon.com/es/getting-started/guides/setup-environment/. Si no quieres instalar todo desde cero, en este mismo link podrás seguir los pasos para configurar Amazon Cloud9 que es un entorno de desarrollo virtual, que incluye casi todo el toolset que necesitas para este paso a paso.

Paso a paso:

En esta oportunidad vamos a aprender sobre cómo contenerizar una API desarrollada en .NET 6 que retorna el texto pasado como parámetro en la URL, este template de API será usado para todas las API’s de Picturesocial. Vamos a contenerizar todo para mantener consistencia entre el ambiente de desarrollo local y los ambientes en nube.

He creado un repositorio de Github https://github.com/aws-samples/picture-social-sample con todo el código necesario para seguir este paso a paso, asegúrate de seleccionar la branch “ep1”.

Primero, vamos a clonar nuestro repo base, así tendremos todos los archivos de esta API así como también el Dockerfile que usaremos para crear la imagen de container.

git clone https://github.com/aws-samples/picture-social-sample --branch ep1

Una vez clonado, vayamos al directorio creado. Aseguremonos de siempre estar dentro de este directorio por el resto de esta guía, de esa forma todo se ejecutará sin problemas.

cd picture-social-sample/HelloWorld

Ahora, antes de iniciar con los siguientes pasos, vamos a revisar si Docker está instalado correctamente y funcionando, probemos el siguiente comando y deberíamos recibir que tenemos al menos la versión 20.10.

docker --help

Si abres el Dockerfile, que está dentro de nuestra carpeta, encontrarás exactamente la misma estructura que el que compartí en este artículo. No tengas miedo, cambia cosas y juega con el, la mejor forma de aprender siempre es experimentando por nuestra cuenta, equivocándonos y descubriendo cómo arreglarlo. Acá te doy algunas sugerencias de qué cosas probar.
- Añade una línea que imprima Hello World en el proceso de build de nuestra imagen de container. RUN echo “Hello World”
- Cambia el WORKDIR de app a api, asegúrate de cambiar todas las referencias a app en las lineas 2, 11 y 12 del Dockerfile.
Ahora vamos a construir la imagen de container. Usaremos el comando docker build que será el responsable de crear la imagen, para ello usamos el parámetro -t para especificar el nombre de la imagen, tal como aprendimos antes, la estructura del nombre es nombreDeImagen:nombreDeTag si no especificamos un nombreDeTag se creará uno por defecto con el nombre latest. Finalmente especificamos el path donde nuestro Dockerfile está localizado, si seguimos en la carpeta HelloWorld, entonces nuestro path será un punto (.) debido a que se encuentra en el mismo directorio.

docker build -t helloworld:latest .

Algo que aprendí mientras escribía este artículo es que si estás usando una Apple MacBook con Apple Silicon, el comando cambia un poco, de esta forma indicamos que construiremos la imagen para ejecutarse en linux/amd64.

docker buildx build —platform=linux/amd64 -t helloworld:latest .

Ahora vamos a ejecutar esta imagen y convertirla en un Container, para ello usaremos el comando docker run , por medio del parametro -d diremos que este container puede ejecutarse en segundo plano y con el parametro -p le diremos el puerto del container y el puerto que expondremos. Tal como podemos ver en nuestro Dockerfile, el container está usando el puerto 51111 y estamos mapeando el mismo puerto en el siguiente comando:

docker run -d -p 5111:5111 helloworld:latest

Después de ejecutar este comando podremos abrir el navegador y escribir http://localhost:5111/api/HelloWorld/johndoe (http://localhost:5111/api/HelloWorld/jhondoe) y si todo salió bien deberíamos recibir de respuesta un “Hello johndoe”, puedes cambiar el valor de la url a cualquier valor y probar que el API contenerizada devuelva el mensaje. Ahora que estamos obteniendo los valores esperados vamos a seguir con los pasos necesarios para subir la imagen a nuestro container registry privado, nuestro propio repositorio de ECR llamado “helloworld”. Para eso ejecutamos el siguiente comando de AWS CLI, donde creamos el respositorio y por medio del parametro —repository-name indicamos el nombre “helloworld”

aws ecr create-repository --repository-name helloworld

Ahora descubramos cual es el nombre de dominio calificado (FQDN) de nuestro registry, de forma que en los siguientes pasos podamos renombrar nuestras imagenes con el nombre completo, esa es la forma que usa Docker para identificar imagenes locales o remotas. Para este proyecto usaremos la región us-east-1 y asumiremos que nuestro AWS Account Id es 111122223333 por lo que el nombre debería quedar así:

[aws account id].dkr.ecr.[aws region].amazonaws.com
#for example for account id: 111122223333 on region: us-east-1
111122223333.dkr.ecr.us-east-1.amazonaws.com

Ya tenemos el nombre de nuestro registry, ahora vamos a iniciar sesión en el CLI de Docker, recuerda reemplazar el AWS Account Id y la región, tal como lo hicimos en el paso anterior. Cuando iniciamos sesión en Docker le estamos dando acceso a nuestro ambiente local para hacer push de imágenes de containers a un repositorio remoto como ECR.

aws ecr get-login-password --region us-east-1 | docker login --username AWS --password-stdin [aws account id].dkr.ecr.[aws region].amazonaws.com

Ahora ya estamos listos para hacer push de nuestra imagen, pero primero tenemos que cambiarle el nombre de forma que incluya el FQDN, caso contrario no la podremos subir a nuestro repositorio remoto, esto sucede porque Docker no reconoce a donde pertenece sin que se lo digas explícitamente. Al ejecutar este comando obtendrás un id de digest, eso significa que hiciste bien.

docker tag helloworld:latest [aws account id].dkr.ecr.[aws region].amazonaws.com/helloworld:latest
docker push [aws account id].dkr.ecr.[aws region].amazonaws.com/helloworld:latest

Si seguiste los pasos hasta acá, significa que ¡Lo lograste! Felicitaciones, contenerizaste tu primera aplicación. Tambien puedes ver el video para tener más detalles, en este Link.

El siguiente post estará enfocado en aprender acerca de Kubernetes, intentaré responder a la pregunta: ¿Qué es Kubernetes y por qué debería importarme?