Intro
- Crear una AWS VPC para nuestros recursos usando Terrafom
- Crear un cluster de AWS EKS con Fargate usando Terraform
- Actualizar CoreDNS para que pueda correr en Fargate
- Crear un registry para nuestras imagenes de las aplicaciones frontend y backend en AWS ECR
- Publicar nuestras imagenes en nuestro registry de ECR
- Desplegar nuestros pods (Frontend y Backend) con sus respectivos secrets
- Crear servicios para nuestros pods
- Mejorar la estabilidad de nuestros pods con Pod Disruption Budget
- Crear un IAM OIDC provieder usando Terraform
- Desplegar un AWS Load Balancer controller (que creara un ALB por cada ingress que tengamos) en nuestro cluster usando Terraform
- Crear un ingress para nuestros pods (frontend y backend)
- Adjuntar dominios a nuestro ALB
- Secure Ingress con SSL/TLS
- Habilitar Fargate Loggin para logear a CloudWatch
Y vamos a automatizar todos estos pasos con GitHub Actions.
Pre requisitos
Crear un repositorio en GitHub
Lo primero es crear el repositorio de GitHub para poder automatizar el proceso de provisioning con Terraform. Para eso debemos crear un repositorio.
Para eso ejecutaremos los siguiente comandos:
ldamore@Desktop:~ $ mkdir aws-eks-fargateldamore@Desktop:~ $ cd aws-eks-fargateldamore@Desktop/aws-eks-fargate:~ $ echo "# aws-eks-fargate" >> README.mdldamore@Desktop/aws-eks-fargate:~ $ git initldamore@Desktop/aws-eks-fargate:~ $ git add README.mdldamore@Desktop/aws-eks-fargate:~ $ git commit -m "first commit"ldamore@Desktop/aws-eks-fargate:~ $ git branch -M mainldamore@Desktop/aws-eks-fargate:~ $ git remote add origin [your-origin]ldamore@Desktop/aws-eks-fargate:~ $ git push -u origin mainCrear un Terraform Provider
Para comenzar a usar terraform primero necesitamos declarar un aws terraform provider. Para eso crearemos una carpeta llamada terraform y un archivo dentro de ella llamado 0-provider.tf con el siguiente codigo.
Dentro de terraform/0-provider.tf
provider "aws" { region = "us-east-1" access_key = var.aws_access_key secret_key = var.aws_secret_key}
terraform { required_providers { aws = { source = "hashicorp/aws" version = "~> 4.0" } }
backend "s3" { bucket = "ldamore-terraform-state" // Put your bucket name key = "terraform.tfstate" region = "us-east-1" encrypt = true }}
variable "aws_access_key" { type = string}
variable "aws_secret_key" { type = string}
variable "cluster_name" { type = string default = "demo"}
variable "cluster_version" { type = string default = "1.22"}Este archivo iniciara nuestro provider de terraform y guardara el estado de los recursos que vamos creando en un bucket de S3 en nuestro AWS. Recuerde tener un access key y un secret key con los roles necesarios para crear recursos.
Debemos crear una carpeta en la raiz del proyecto llamada .github y dentro de ella otra carpeta llamada workflows. En la carpeta workflows crearemos un archivo provisioning.yml con el siguiente codigo dentro. Este archivo se ejecutara cada vez pusheemos y que cambiemos algo dentro de la carpeta terraform.
Dentro de .github/workflows/provisioning.yml
on: push: branches: - main paths: - terraform/*
jobs: provisioning-staging: runs-on: ubuntu-latest env: AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }} steps: - name: Checkout repository uses: actions/checkout@v2 - name: Setup Terraform uses: hashicorp/setup-terraform@v2 - name: Apply terraform run: | cd ${GITHUB_WORKSPACE}/terraform terraform init -backend-config "access_key=${AWS_ACCESS_KEY_ID}" -backend-config "secret_key=${AWS_SECRET_ACCESS_KEY}" terraform plan -var="aws_access_key=${AWS_ACCESS_KEY_ID}" -var="aws_secret_key=${AWS_SECRET_ACCESS_KEY}" -out="terraform.tfplan" terraform apply -auto-approve terraform.tfplanEl proposito de este job es aplicar los archivos terraform para crear los recursos necesarios en aws.
Para que este archivo se ejecute correctamente debemos agregar nuestro AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY como secrets en nuestro repositorio.
Una vez configurado los secrets podemos commitear y pushear nuestro codigo. Esto activara por primera vez el pipeline y iniciara el terraform provider y creara el archivo con nuestro estado de terraform en el bucket.
Bucket
Crear una AWS VPC para nuestros componentes usando Terraform
Dentro de esta seccion crearemos algunos recursos de networking como:
- VPC
- Subnets (Publics & Privates)
- Internet Gateway
- NAT Gateway
- Route Tables
VPC
Ahora es momento de crear una VPC (Virtual Private Cloud) para nuestros componentes.
Para eso dentro de la carpeta terraform debemos crear el siguiente archivo 1-vpc.tf y dentro:
resource "aws_vpc" "main" { cidr_block = "10.0.0.0/16"
tags = { Name = "main" }}Internet Gateway
Luego un Internet Gateway, este sera usado para proveer acceso a internet directo a las Subnets publicas y acceso a internet indirecto a las Subnets privadas usando un NAT Gateway.
Crearemos un archivo terraform/2-igw.tf con**:**
resource "aws_internet_gateway" "igw" { vpc_id = aws_vpc.main.id
tags = { Name = "igw" }}Subnets
Ahora debemos crear nuestras subnets, 2 publicas y 2 privadas.
Crear el archivo terraform/3-subnets.tf con el siguiente codigo:
resource "aws_subnet" "private-us-east-1a" { vpc_id = aws_vpc.main.id cidr_block = "10.0.0.0/19" availability_zone = "us-east-1a"
tags = { "Name" = "private-us-east-1a" "kubernetes.io/role/internal-elb" = "1" "kubernetes.io/cluster/${var.cluster_name}" = "owned" }}
resource "aws_subnet" "private-us-east-1b" { vpc_id = aws_vpc.main.id cidr_block = "10.0.32.0/19" availability_zone = "us-east-1b"
tags = { "Name" = "private-us-east-1b" "kubernetes.io/role/internal-elb" = "1" "kubernetes.io/cluster/${var.cluster_name}" = "owned" }}
resource "aws_subnet" "public-us-east-1a" { vpc_id = aws_vpc.main.id cidr_block = "10.0.64.0/19" availability_zone = "us-east-1a" map_public_ip_on_launch = true
tags = { "Name" = "public-us-east-1a" "kubernetes.io/role/elb" = "1" "kubernetes.io/cluster/${var.cluster_name}" = "owned" }}
resource "aws_subnet" "public-us-east-1b" { vpc_id = aws_vpc.main.id cidr_block = "10.0.96.0/19" availability_zone = "us-east-1b" map_public_ip_on_launch = true
tags = { "Name" = "public-us-east-1b" "kubernetes.io/role/elb" = "1" "kubernetes.io/cluster/${var.cluster_name}" = "owned" }}Se necesitan al menos dos subnets publicas y dos subnets privadas porque los load balancer que crearemos necesitan al menos 2 subredes.
El Internal-elb tag es usado por EKS para seleccionar las subnets privada y crearles private load balancer y el elb tag para crear public load balancers. Ademas necesitamos un cluster tag con un valor de owned or shared.
NAT
Para el NAT Gateway crearemos una ip elastica para no ocuparnos de alocarlo en una ip especifica (que podria estar en uso) y luego el NAT Gateway en si especificando sobre que Internet Gateway y que public subnet depende.
Crear archivo terraform/4-nat.tf con:
resource "aws_eip" "nat" { vpc = true
tags = { Name = "nat" }}
resource "aws_nat_gateway" "nat" { allocation_id = aws_eip.nat.id subnet_id = aws_subnet.public-us-east-1a.id
tags = { Name = "nat" }
depends_on = [aws_internet_gateway.igw]}Route Tables
Por ultimo antes de empezar a crear nuestro EKS Cluster debemos crear Route Tables.
Crearemos el archivo terraform/5-routes.tf con el codigo:
resource "aws_route_table" "private" { vpc_id = aws_vpc.main.id
route { cidr_block = "0.0.0.0/0" nat_gateway_id = aws_nat_gateway.nat.id }
tags = { Name = "private" }}
resource "aws_route_table" "public" { vpc_id = aws_vpc.main.id
route { cidr_block = "0.0.0.0/0" gateway_id = aws_internet_gateway.igw.id }
tags = { Name = "public" }}
resource "aws_route_table_association" "private-us-east-1a" { subnet_id = aws_subnet.private-us-east-1a.id route_table_id = aws_route_table.private.id}
resource "aws_route_table_association" "private-us-east-1b" { subnet_id = aws_subnet.private-us-east-1b.id route_table_id = aws_route_table.private.id}
resource "aws_route_table_association" "public-us-east-1a" { subnet_id = aws_subnet.public-us-east-1a.id route_table_id = aws_route_table.public.id}
resource "aws_route_table_association" "public-us-east-1b" { subnet_id = aws_subnet.public-us-east-1b.id route_table_id = aws_route_table.public.id}La primera es una tabla de ruta privada con ruta default al NAT Gateway. La segunda es una tabla de ruta publica con ruta default al Internet Gateway. Finalmente, debemos asociar las subnets creadas anteriormente a estas route tables.
Luego de crear estos archivos para el networking, pusheamos para que se active el pipeline y terraform cree la VPC por nosotros.
Create a AWS EKS with Fargate using Terraform
El siguiente paso es crear el cluster de Kubernetes en EKS con nodos gestionados por Fargate. Para eso debemos crear el EKS control plane sin nodos (luego fargate los creara por nosotros).
El control plane consiste en nodos que corren Kubernetes software como etcd o la Kubernetes API server.
Lo primero de todo es crear un IAM role para EKS. Este rol se usara para poder crear el cluster. Recordemos que ante cada creacion de recurso necesitamos tener ciertos permisos para crearlos. Para eso creamos un archivo terraform/6-eks.tf con esto:
resource "aws_iam_role" "eks-cluster" { name = "eks-cluster-${var.cluster_name}"
assume_role_policy = <<POLICY{ "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Principal": { "Service": "eks.amazonaws.com" }, "Action": "sts:AssumeRole" } ]}POLICY}Despues tenemos que adjuntarle la AmazonEKSClusterPolicy a este rol.
Dentro de 6-eks.tf
resource "aws_iam_role_policy_attachment" "amazon-eks-cluster-policy" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSClusterPolicy" role = aws_iam_role.eks-cluster.name}Y, por supuesto, el propio EKS control plane. Debemos usar el rol creado para crear el cluster.
Además, hay que especificar al cluster las dos subnets privadas y las dos públicas. AWS Fargate solo puede usar subnets privadas con NAT Gateway para deployar nuestros pods. Las subnets públicas se pueden usar para que los load balancers que expongan la aplicación a Internet.
Creamos 6terraform/6-eks.tf con
resource "aws_eks_cluster" "cluster" { name = var.cluster_name version = var.cluster_version role_arn = aws_iam_role.eks-cluster.arn
vpc_config {
endpoint_private_access = false endpoint_public_access = true public_access_cidrs = ["0.0.0.0/0"]
subnet_ids = [ aws_subnet.private-us-east-1a.id, aws_subnet.private-us-east-1b.id, aws_subnet.public-us-east-1a.id, aws_subnet.public-us-east-1b.id ] }
depends_on = [aws_iam_role_policy_attachment.amazon-eks-cluster-policy]}Una vez pusheado y creado el cluster deberiamos poder verlo en nuestro EKS.
Y desde nuestra consola de comandos podemos conectarnos al cluster y ejecutar comandos de kubernetes. Para eso debemos correr
ldamore@Desktop/aws-eks-fargate:~ aws configure //para configurar el aws-cli con nuestra cuentaldamore@Desktop/aws-eks-fargate:~ aws eks update-kubeconfig --name demo --region us-east-1 //para darle acceso de nuestro cluster a kubectlldamore@Desktop/aws-eks-fargate:~ kubectl get pods -A // para listar los pods creados hasta le momentoSi todo fue correcto, podemos listar todos los pods de nuestro cluster (que por ahora son 2 de CoreDNS que necesita nuestro cluster de Kubernetes para funcionar)
Si podemos observar, los pods estan en status Pending, eso lo solucionaremos en el siguiente paso.
Actualizar CoreDNS
Para que Fargate pueda crear nodos para los pods de CoreDNS debemos hacer lo siguiente.
Primero debemos crear un perfil de Fargate. Un Fargate profile, configurado en un cluster de EKS, permite crear nodos de manera automatica, para los pods de un namespace de cluster.
Necesitamos crear un único rol de IAM que se pueda compartir entre todos los perfiles de Fargate. Al igual que EKS, Fargate necesita permisos para activar los nodos y conectarlos al EKS control plane.
Para eso crearemos el archivo 7-kube-system-profile.tf con lo siguiente:
resource "aws_iam_role" "eks-fargate-profile" { name = "eks-fargate-profile"
assume_role_policy = jsonencode({ Statement = [{ Action = "sts:AssumeRole" Effect = "Allow" Principal = { Service = "eks-fargate-pods.amazonaws.com" } }] Version = "2012-10-17" })}Luego tenemos que adjuntar la IAM policy llamada AmazonEKSFargatePodExecutionRolePolicy.
resource "aws_iam_role_policy_attachment" "eks-fargate-profile" { policy_arn = "arn:aws:iam::aws:policy/AmazonEKSFargatePodExecutionRolePolicy" role = aws_iam_role.eks-fargate-profile.name}Y por ultimo el Fargate profile con el rol
resource "aws_eks_fargate_profile" "kube-system" { cluster_name = aws_eks_cluster.cluster.name fargate_profile_name = "kube-system" pod_execution_role_arn = aws_iam_role.eks-fargate-profile.arn
# These subnets must have the following resource tag: # kubernetes.io/cluster/<CLUSTER_NAME>. subnet_ids = [ aws_subnet.private-us-east-1a.id, aws_subnet.private-us-east-1b.id ]
selector { namespace = "kube-system" }}Ahora, si obtenemos los pods nuevamente, esperariamos que CoreDNS ya este con los pods corriendo y con nodos asignados. Pero lo más probable es que, si el equipo de EKS no lo soluciona en versiones posteriores, esos pods de coreDNS seguirán en estado pendiente, ya que no tienen nodos asignados.
Podemos intentar describir el pod para obtener algún tipo de error de Kubernetes (kubectl describe pod). Deberíamos ver algo como: no hay nodos disponibles. Si te scrolleamos hacia arriba, veremos la razón. Estos pods vienen con la anotacion compute-type: ec2 que evita que Fargate cree los nodos para dichos pods. La solución es simple, simplemente hay que eliminar la anotación.
Para eliminar debemos correr el siguiente comando
kubectl patch deployment coredns \-n kube-system \--type json \-p='[{"op": "remove", "path": "/spec/template/metadata/annotations/eks.amazonaws.com~1compute-type"}]'Una vez eliminada la anotacion, AWS Fargate proveera un par de nodos para que puedan correr los pods.
Luego de unos minutos si volvemos a correr kubectl get pods -A podremos ver que no estos pods estan status ready.