DEV Community: ecordero

Configurando AWS Batch

ecordero — Fri, 14 Jul 2023 05:03:06 +0000

En este tutorial se creará un sencillo ejemplo del uso de AWS Batch. Nuestra aplicación consistirá en tomar un frame (imagen) desde un video procesado. En este caso usaremos Batch sobre Fargate, crearemos una imagen docker que se encargará de compilar la aplicación y AWS Batch se encargará de tener el ambiente de ejecución listo y realizar el job.

Tomaremos como ejemplo este código sencillo en Python:

import boto3
import cv2
import os
import logging

# Configuración de logging
logging.basicConfig(level=logging.INFO)

# Variables de entorno
INPUT_URL = os.getenv('INPUT_URL')
OUTPUT_BUCKET = os.getenv('OUTPUT_BUCKET')

s3_client = boto3.client('s3')

def download_video(input_url):
    logging.info('Descargando video...')
    cap = cv2.VideoCapture(input_url)
    if not cap.isOpened():
        logging.error('No se pudo abrir el video.')
        return None
    return cap

def process_video(cap):
    logging.info('Procesando video...')
    # Aquí debes incluir tu propio código de procesamiento de video.
    # Por ahora, simplemente leemos el primer frame del video.
    ret, frame = cap.read()
    if not ret:
        logging.error('No se pudo leer el video.')
        return None
    # Guardamos el frame como una imagen JPEG.
    cv2.imwrite('/tmp/frame.jpg', frame)
    return '/tmp/frame.jpg'

def upload_to_s3(file_path, bucket_name):
    logging.info('Subiendo archivo a S3...')
    with open(file_path, 'rb') as data:
        s3_client.upload_fileobj(data, bucket_name, os.path.basename(file_path))

def main():
    cap = download_video(INPUT_URL)
    if cap is None:
        return
    output_file = process_video(cap)
    if output_file is None:
        return
    upload_to_s3(output_file, OUTPUT_BUCKET)

if __name__ == '__main__':
    main()

Creamos el Dockerfile

FROM python:3.8

WORKDIR /app

COPY . .

RUN pip install boto3 opencv-python-headless

CMD ["python", "./script.py"]

Creamos la imagen con el comando Docker

docker build -t myimage .

Nos autenticamos con ECR, previamente habiendo configurado nuestro AWS profile para ejecución de comandos por AWS cli y habiendo creado el repositorio ECR en la consola.

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

Tageamos la imagen creada y hacemos push sobre ECR

docker tag videoprocess:latest [your-id-account].dkr.ecr.us-east-1.amazonaws.com/repo_videoprocess:latest

docker push [your-id-account].dkr.ecr.us-east-1.amazonaws.com/repo_videoprocess:latest

Y obtenemos lo siguiente:

Antes de configurar AWS Batch explicaré como se relacionan ciertos conceptos que posteriormente configuraremos:

Jobs: Un trabajo es la unidad de trabajo, como un script o una aplicación, que se envía a AWS Batch para que se ejecute en un entorno de cálculo. Cada trabajo se define con una definición de trabajo y se envía a una cola de trabajo.
Job definitions: Una definición de trabajo es una serie de parámetros que AWS Batch utiliza para ejecutar un trabajo. Esta definición especifica la imagen de Docker a utilizar, el número de vCPUs y la cantidad de memoria, entre otros parámetros. En esencia, la definición del trabajo es una "plantilla" que se utiliza para ejecutar uno o varios trabajos. Por lo tanto, un trabajo se basa en una definición de trabajo.
Job queues: Una cola de trabajo es un lugar donde se envían los trabajos para ser ejecutados. Cada cola de trabajo se asocia con uno o más entornos de cálculo y tiene una prioridad asignada. AWS Batch utiliza estas prioridades para determinar el orden en el que se deben ejecutar los trabajos. Por lo tanto, un trabajo es enviado a una cola de trabajo, y desde allí AWS Batch lo asigna a un entorno de cálculo.
Compute environments: Un entorno de cálculo es un conjunto de recursos de cálculo, como instancias de EC2 o AWS Fargate, que se utilizan para ejecutar trabajos. Los trabajos en una cola de trabajo se ejecutan en uno de los entornos de cálculo asociados con la cola de trabajo. Cada entorno de cálculo define el tipo de recursos que se deben utilizar (CPU, memoria, etc.) y otras configuraciones, como la VPC en la que se deben ejecutar los trabajos.

Entonces configuremos

Compute Environment:

a. Inicia sesión en la consola de AWS y abre la consola de AWS Batch.

b. En el panel de navegación, elige 'Compute environments', luego 'Create'.

c. En la página 'Create compute environment', proporciona los detalles del entorno de computación, como el nombre, el tipo de servicio (administrado o no administrado), y los detalles del tipo de instancia.

d. Especifica la VPC, las subredes y las políticas de seguridad que quieras que tenga tu Compute Environment.

e. Si se necesita, configura el límite de vCPU y el tipo de instancias a utilizar.

f. Elige 'Create' para crear el entorno de computación.

Job Definition:

a. En la consola de AWS Batch, elige 'Job definitions', luego 'Create'.

b. En la página 'Create job definition', proporciona los detalles de la definición del trabajo, como el nombre, la imagen de Docker a utilizar, los volúmenes a montar, la cantidad de vCPU y memoria que el trabajo necesita, y el comando a ejecutar.

c. Asegúrate de especificar cualquier otra configuración necesaria para tu trabajo, como variables de entorno, roles de IAM (mandatorio crear roles que permitan acceso a S3), etc.

d. Para nuestro caso usaremos 2 variables de entorno. El primero es el URL de nuestro video que subimos previamente a un S3 y el segundo el nombre del bucket donde guardaremos la imagen luego de haberse procesado nuestro código en batch.

INPUT_URL https://s3-awsbatch.s3.amazonaws.com/158980+(Original).mp4
OUTPUT_BUCKET s3-awsbatch

d. Elige 'Create' para crear la definición del trabajo.

Job Queue:

a. En la consola de AWS Batch, elige 'Job queues', luego 'Create'.

b. En la página 'Create job queue', proporciona los detalles de la cola de trabajo, como el nombre, la prioridad y los entornos de computación a los que los trabajos pueden ser enviados.

c. Elige 'Create' para crear la cola de trabajo.

Ejecutaremos el job desde AWS cli

aws batch submit-job --job-name batch-job --job-queue video-processing-queue --job-definition video-processing-definition

Resultado:

Nuestra imagen en S3

Podemos revisar tambien el resultado de los logs del job se pueden encontrar en la pestaña logging luego de ubicar nuestro job en la opción Jobs en el panel izquierdo de la consola

¡Felicidades! Has navegado con éxito a través del proceso de creación de una aplicación de procesamiento de video escalable utilizando AWS Batch y Docker. Comenzaste con la definición de tu propósito: procesar un video utilizando un script de Python. Luego, creaste una imagen Docker que contiene tu script y todas sus dependencias, garantizando así la portabilidad y la reproducibilidad de tu entorno de ejecución. Después de eso, configuraste AWS Batch con gran detalle, estableciendo una definición de trabajo, un entorno de computación y una cola de trabajos. Todo este proceso te permitió tener una solución robusta y flexible, capaz de manejar no sólo un solo trabajo, sino potencialmente miles de ellos simultáneamente.

Como reto podrías modificar el código y generar cientos de imágenes del contenido de tu video.

Terraform con AWS en Español - Parte 2

ecordero — Fri, 14 Jul 2023 04:25:21 +0000

Directo a la acción! Nuestra aplicación 3 tier se basará en esta arquitectura mostrada.

La estructura de nuestros archivos en terraform tendrá la siguiente forma:

- main.tf
- outputs.tf
- vpc/
  - main.tf
  - variables.tf
  - outputs.tf
- ec2_instances/
  - main.tf
  - variables.tf
  - outputs.tf
- rds/
  - main.tf
  - variables.tf
  - outputs.tf
- alb/
  - main.tf
  - variables.tf
  - outputs.tf

módulo principal:

main.tf

Este es el archivo principal de Terraform. Aquí definimos todos los módulos que necesitamos (VPC, EC2, RDS, ALB) y cómo interactúan entre ellos, es decir, pasamos las salidas de un módulo (como las IDs de las subredes de la VPC) como variables de entrada para otro módulo.

module "network" {
  source = "./vpc"
}

module "ec2_instances" {
  source = "./ec2_instances"
  ami = "ami-0c94855ba95c574c8" 
  vpc_id = module.network.vpc_id
  public_subnet_id = module.network.public_subnets[0]
  private_subnet_id = module.network.private_subnets[0]
}

module "rds" {
  source = "./rds"
  db_name = "mydb"
  db_username = "username"
  db_password = "password"
  vpc_id = module.network.vpc_id
  db_subnet_group = module.network.private_subnets
}

module "alb" {
  source = "./alb"
  subnets = module.network.public_subnets
  vpc_id = module.network.vpc_id
}

módulos secundarios:

VPC

vpc/main.tf

Este archivo contiene la definición del módulo de la VPC. Incluye la definición de la VPC, las subredes públicas y privadas, el gateway NAT y los grupos de seguridad necesarios.

module "vpc" {
  source = "terraform-aws-modules/vpc/aws"
  name = "my-vpc"
  cidr = var.vpc_cidr

  azs             = var.azs
  private_subnets = var.private_subnets_cidrs
  public_subnets  = var.public_subnets_cidrs

  enable_nat_gateway = true
  single_nat_gateway = true
  enable_dns_hostnames = true

  tags = {
    "Name" = "main"
    "Environment" = "Test"
  }
}

output "vpc_id" {
  description = "The ID of the VPC"
  value       = module.vpc.vpc_id
}

output "public_subnets" {
  description = "List of IDs of public subnets"
  value       = module.vpc.public_subnets
}

output "private_subnets" {
  description = "List of IDs of private subnets"
  value       = module.vpc.private_subnets
}

vpc/variables.tf

En este archivo se declaran las variables que necesita el módulo de la VPC, como los CIDR de la VPC y las subredes, y las zonas de disponibilidad que se van a utilizar.

variable "vpc_cidr" {
  description = "CIDR block for the VPC"
  default     = "10.0.0.0/16"
}

variable "azs" {
  description = "List of Availability Zones to be used"
  default     = ["us-east-1a", "us-east-1b"]
}

variable "private_subnets_cidrs" {
  description = "List of CIDR blocks for private subnets"
  default     = ["10.0.1.0/24", "10.0.2.0/24"]
}

variable "public_subnets_cidrs" {
  description = "List of CIDR blocks for public subnets"
  default     = ["10.0.3.0/24", "10.0.4.0/24"]
}

vpc/outputs.tf

Este archivo contiene las salidas que nos interesan del módulo VPC, como la ID de la VPC y las IDs de las subredes.

output "vpc_id" {
  description = "The ID of the VPC"
  value       = module.vpc.vpc_id
}

output "public_subnets" {
  description = "List of IDs of public subnets"
  value       = module.vpc.public_subnets
}

output "private_subnets" {
  description = "List of IDs of private subnets"
  value       = module.vpc.private_subnets
}

output "web_sg_id" {
  description = "The ID of the security group for the web server"
  value       = aws_security_group.web_sg.id
}

output "app_sg_id" {
  description = "The ID of the security group for the application server"
  value       = aws_security_group.app_sg.id
}

output "rds_sg_id" {
  description = "The ID of the security group for the RDS instance"
  value       = aws_security_group.rds_sg.id
}

output "alb_sg_id" {
  description = "The ID of the security group for the ALB"
  value       = aws_security_group.alb_sg.id
}

output "vpc_cidr_block" {
  description = "The CIDR block of the VPC"
  value       = module.vpc.vpc_cidr_block
}

EC2

ec2_instances/main.tf

Este archivo define las instancias EC2 que vamos a utilizar para nuestros servidores web y de aplicaciones, incluyendo los grupos de seguridad asociados.

data "aws_ami" "ubuntu" {
  most_recent = true
  filter {
    name   = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }
  filter {
    name   = "virtualization-type"
    values = ["hvm"]
  }
  owners = ["099720109477"] # Canonical
}

resource "aws_instance" "web" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "t2.micro"
  subnet_id              = var.public_subnet_id
  vpc_security_group_ids = [aws_security_group.web_sg.id]

  tags = {
    Name = "Web Server"
  }
}

resource "aws_instance" "app" {
  ami                    = data.aws_ami.ubuntu.id
  instance_type          = "t2.micro"
  subnet_id              = var.private_subnet_id
  vpc_security_group_ids = [aws_security_group.app_sg.id]

  tags = {
    Name = "App Server"
  }
}

resource "aws_security_group" "web_sg" {
  name        = "web_sg"
  description = "Allow inbound traffic from ALB and outbound to App"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [var.alb_cidr]
  }

  egress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [var.app_cidr]
  }
}

resource "aws_security_group" "app_sg" {
  name        = "app_sg"
  description = "Allow inbound traffic from Web and outbound to RDS"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = [var.web_cidr]
  }

  egress {
    from_port   = 3306
    to_port     = 3306
    protocol    = "tcp"
    cidr_blocks = [var.rds_cidr]
  }
}

output "web_sg_id" {
  description = "Security Group ID for Web Server"
  value       = aws_security_group.web_sg.id
}

output "app_sg_id" {
  description = "Security Group ID for App Server"
  value       = aws_security_group.app_sg.id
}

ec2_instances/variables.tf

Este archivo declara las variables necesarias para crear las instancias EC2 y los grupos de seguridad.

variable "vpc_id" {
  description = "The ID of the VPC to use"
}

variable "public_subnet_id" {
  description = "The ID of the public subnet to use"
}

variable "private_subnet_id" {
  description = "The ID of the private subnet to use"
}

variable "alb_cidr" {
  description = "CIDR block for ALB"
  default     = "0.0.0.0/0"
}

variable "app_cidr" {
  description = "CIDR block for App Server"
  default     = "0.0.0.0/0"
}

variable "web_cidr" {
  description = "CIDR block for Web Server"
  default     = "0.0.0.0/0"
}

variable "rds_cidr" {
  description = "CIDR block for RDS"
  default     = "0.0.0.0/0"
}

ec2_instances/outputs.tf

Este archivo contiene las salidas del módulo EC2 que necesitamos, como las IDs de los grupos de seguridad de las instancias EC2.

output "web_sg_id" {
  description = "Security Group ID for Web Server"
  value       = aws_security_group.web_sg.id
}

output "app_sg_id" {
  description = "Security Group ID for App Server"
  value       = aws_security_group.app_sg.id
}

RDS

rds/main.tf

Este archivo define la base de datos RDS que vamos a utilizar, incluyendo la configuración de almacenamiento y el grupo de seguridad asociado.

resource "aws_db_instance" "default" {
  name            = var.db_name
  username        = var.db_username
  password        = var.db_password
  engine          = "mysql"
  engine_version  = "5.7"
  instance_class  = "db.t2.micro"
  allocated_storage = 20
  vpc_security_group_ids = [var.app_sg_id]
  db_subnet_group_name = var.db_subnet_group

  tags = {
    Name = "MyDBInstance"
  }
}

rds/variables.tf

Este archivo declara las variables que necesitamos para crear la instancia de RDS y su grupo de seguridad.


variable "db_name" {
  description = "The database name"
}

variable "db_username" {
  description = "Username for the master DB user"
}

variable "db_password" {
  description = "Password for the master DB user"
}

variable "vpc_id" {
  description = "The ID of the VPC to use"
}

variable "db_subnet_group" {
  description = "A list of subnet IDs to associate with the RDS instance"
}

variable "app_sg_id" {
  description = "Security Group ID for App Server"
}

ALB

alb/main.tf

Este archivo define el balanceador de carga de aplicación (ALB) que vamos a utilizar, incluyendo la configuración de escucha y el grupo de seguridad asociado.

resource "aws_alb" "example" {
  name               = "example-alb"
  subnets            = var.subnets
  security_groups    = [aws_security_group.alb_sg.id]

  tags = {
    Name = "example-alb"
  }
}

resource "aws_alb_target_group" "example" {
  name     = "example"
  port     = 80
  protocol = "HTTP"
  vpc_id   = var.vpc_id
}

resource "aws_alb_listener" "front_end" {
  load_balancer_arn = aws_alb.example.arn
  port              = "80"
  protocol          = "HTTP"

  default_action {
    type             = "forward"
    target_group_arn = aws_alb_target_group.example.arn
  }
}

resource "aws_security_group" "alb_sg" {
  name        = "alb_sg"
  description = "Allow inbound traffic from the internet"
  vpc_id      = var.vpc_id

  ingress {
    from_port   = 80
    to_port     = 80
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }
}

alb/variables.tf

Este archivo declara las variables que necesitamos para crear el ALB y su grupo de seguridad.

variable "subnets" {
  description = "A list of subnet IDs to associate with the ALB"
}

variable "vpc_id" {
  description = "The ID of the VPC to use"
}

¡Genial, casi hemos terminado! Ahora que ya tienes todos los archivos listos, es hora de poner en marcha tu infraestructura. En la terminal, navega hasta el directorio donde se encuentran tus archivos de Terraform. Primero, inicializa tu directorio de trabajo con terraform init. Luego, es recomendable comprobar qué cambios se aplicarán con terraform plan. Si todo está bien, es momento de desplegar tu infraestructura con terraform apply. Este comando te pedirá confirmación, solo escribe 'yes' y Terraform se encargará del resto. Ahora tienes tu arquitectura de 3 niveles funcionando en AWS. Con Terraform, realmente es así de fácil. Recuerda, siempre que hagas cambios en tu código, puedes repetir estos pasos para actualizar tu infraestructura. Y si alguna vez necesitas deshacerte de todo, terraform destroy limpiará todo por ti.

AWS Batch vs AWS Lambda en Español

ecordero — Fri, 14 Jul 2023 00:29:17 +0000

En temas de computo AWS ofrece una variedad de servicios con distintas funcionalidades para satisfacer distintas necesidades. Una discusión interesante resulta al comparar AWS batch y AWS Lambda por estar orientados a jobs de procesamiento dentro de sus bondades. En esta oportunidad haremos un análisis comparativo de estos 2 servicios.

AWS Lambda

AWS Lambda permite ejecutar código en respuesta a eventos usando varios lenguajes de programación, escalando automáticamente la capacidad según la carga de trabajo y cobrando en función del tiempo de ejecución y memoria utilizada.

AWS Batch

AWS Batch es un servicio para ejecutar trabajos en lotes en la nube, definidos en contenedores de Docker. Maneja la asignación de recursos y se factura en base a los recursos utilizados durante la ejecución de los trabajos.

Modelo de Programación:

AWS Lambda ejecuta funciones individuales en respuesta a eventos, y puede ser invocada mediante eventos generados por otros servicios de AWS. Por ejemplo, una función de Lambda podría activarse cada vez que se carga un archivo en un bucket de S3.

AWS Batch permite ejecutar trabajos en lotes, procesos más largos y complejos. Los trabajos en lotes se definen en contenedores de Docker, lo que proporciona flexibilidad. Por ejemplo, podrías procesar gran cantidad de datos almacenados en Amazon S3 usando una aplicación Docker.

Granularidad:

AWS Lambda es ideal para ejecutar código pequeño en respuesta a eventos específicos, permitiendo alto grado de escalabilidad y rendimiento. Puede ser usada para crear una API serverless que procese solicitudes HTTP individuales.

AWS Batch está diseñado para procesar grandes volúmenes de datos en trabajos en lote, que pueden ser más largos y requerir más recursos.

Escalabilidad:

AWS Lambda escala automáticamente según la demanda, maneja cargas de trabajo variables y picos de tráfico sin necesidad de administrar la infraestructura.

AWS Batch permite ejecutar múltiples trabajos en paralelo y escalar automáticamente la capacidad según la demanda. Adicionalmente se puede definir políticas de escalado para controlar cómo se asignan y liberan los recursos de procesamiento en función de la carga de trabajo y los recursos disponibles.

Flexibilidad del Entorno de Ejecución:

AWS Lambda proporciona entornos de ejecución predefinidos para varios lenguajes de programación y permite personalización del entorno mediante capas y variables de entorno.

AWS Batch utiliza contenedores de Docker personalizados con todas las bibliotecas, herramientas y configuraciones necesarias para definir el entorno de ejecución de los trabajos en lotes, brindando mayor flexibilidad y personalización.

Tiempo de Ejecución:

AWS Lambda está diseñada para ejecuciones rápidas y en tiempo real, ideal para cargas de trabajo que requieren una respuesta rápida.

AWS Batch está diseñado para trabajos que no requieren una respuesta inmediata y que pueden llevar más tiempo, pudiendo ser incluso dias.

Orquestación:

AWS Lambda se integra fácilmente con otros servicios de AWS utilizando eventos y reglas de disparo. Puede ser usado con AWS Step Functions para construir flujos de trabajo más complejos.

AWS Batch proporciona una API para el envío y control de trabajos en lotes y puede ser utilizado con herramientas de orquestación como AWS Batch Operations y AWS Data Pipeline.

Costo:

AWS Lambda se factura en función del tiempo de ejecución y la memoria utilizada por cada invocación de función.

AWS Batch se factura por la cantidad de recursos utilizados durante la ejecución de trabajos, ya sea EC2, Fargate o EKS.

Resumen:

Características	AWS Lambda	AWS Batch
Modelo de programación	Ejecuta funciones individuales en respuesta a eventos.	Ejecuta trabajos en lotes más largos y complejos.
Granularidad	Ideal para ejecutar código pequeño en respuesta a eventos.	Diseñado para procesar grandes volúmenes de datos en trabajos en lote.
Escalabilidad	Escala automáticamente según la demanda.	Permite ejecutar múltiples trabajos en paralelo y escala automáticamente.
Flexibilidad del entorno	Proporciona entornos predefinidos y permite personalización.	Utiliza contenedores de Docker para mayor flexibilidad.
Tiempo de ejecución	Diseñado para ejecuciones rápidas y en tiempo real.	Trabajos que pueden ejecutarse durante períodos más largos.
Orquestación	Se integra fácilmente con otros servicios de AWS.	Proporciona una API para el control de trabajos en lotes.
Costo	Se factura en función del tiempo de ejecución y memoria usada.	Se factura en función de los recursos utilizados durante la ejecución.

Conclusiones:

Tanto AWS Lambda como AWS Batch ofrecen soluciones potentes y flexibles para diferentes necesidades de procesamiento en la nube. Lambda es ideal para tareas más cortas, basadas en eventos y que requieren ejecuciones rápidas, como el procesamiento de eventos en tiempo real. Sin embargo, Batch es más adecuado para trabajos más largos y complejos que requieren mayor cantidad de recursos, como el procesamiento de grandes volúmenes de datos. Ambos servicios brindan escalabilidad automática, pero difieren en costos, modelos de programación y la flexibilidad del entorno de ejecución. Elegir entre Lambda y Batch dependerá en última instancia de los requisitos específicos del proyecto.

Terraform con AWS en Español - Parte 1

ecordero — Sat, 18 Feb 2023 01:56:06 +0000

¡Bienvenidos a este tutorial de Terraform en Español! ¿Quieres construir tu propia infraestructura en minutos? ¿O simplemente quieres hacer las cosas más rápido, mejor y más eficientemente? Entonces, Terraform es el camino a seguir. Con Terraform, puedes construir, actualizar y destruir recursos en la nube de una manera fácil, rápida y escalable.
Veremos en esta serie de capítulos desde el nivel básico hasta intermedio de terraform y de manera práctica aplicado sobre la nube de AWS.

¿Qué es IaC?

La IaC o Infraestructura como Código (Infrastructure as Code) es una metodología que se utiliza para gestionar la infraestructura de forma automatizada a través de código. En lugar de configurar manualmente servidores, redes, almacenamiento y otros componentes de infraestructura, los desarrolladores y operadores utilizan herramientas de IaC para escribir y gestionar código que define su infraestructura.
La IaC permite automatizar la gestión de infraestructura, reducir errores y aumentar la escalabilidad y la consistencia en la gestión de recursos. Los desarrolladores y operadores pueden trabajar en equipo y versionar sus cambios, lo que facilita el seguimiento y la implementación de cambios en la infraestructura.

¿Qué es Terraform?

Terraform es una herramienta de IaC de código abierto desarrollada por HashiCorp. Se utiliza para crear, cambiar y versionar la infraestructura de forma segura y eficiente. Terraform se centra en la declaratividad, lo que significa que los usuarios describen la infraestructura deseada y Terraform se encarga de determinar la mejor manera de crearla.
Terraform admite una amplia variedad de proveedores de servicios en la nube, como AWS, Azure, Google Cloud, y otros proveedores, lo que permite crear infraestructura en diferentes proveedores de servicios. Además, Terraform es compatible con múltiples sistemas operativos y lenguajes de programación, lo que permite una integración más sencilla en diferentes flujos de trabajo.

Casos de uso de Terraform

Terraform se puede utilizar en una amplia variedad de casos de uso, entre los que se incluyen:

Creación de infraestructura de red: Terraform se puede utilizar para crear y gestionar redes en AWS, como VPCs, subredes, grupos de seguridad y equilibradores de carga.
Implementación de aplicaciones: Terraform se puede utilizar para automatizar la implementación de aplicaciones en AWS, incluyendo la creación de instancias de EC2, el aprovisionamiento de recursos de almacenamiento y la configuración de políticas de escalado automático.
Gestión de bases de datos: Terraform se puede utilizar para crear y gestionar bases de datos en AWS, incluyendo la configuración de instancias de bases de datos relacionales, como RDS, y bases de datos NoSQL, como DynamoDB.
Creación de entornos de pruebas y desarrollo: Terraform se puede utilizar para crear y gestionar entornos de pruebas y desarrollo en AWS, lo que permite a los desarrolladores trabajar en entornos aislados y seguros.
Creación de pipelines de entrega continua: Terraform se puede utilizar para crear pipelines de entrega continua en AWS, lo que permite la implementación automatizada y continua de cambios en la infraestructura y la aplicación en un entorno seguro y controlado.

¿Cómo instalar Terraform en Linux?

Para instalar Terraform en Linux, sigue los siguientes pasos:

Abre una terminal de línea de comandos en Linux.

Actualiza los paquetes de Linux con el siguiente comando:

sudo yum update -y

Descarga la última versión de Terraform para Linux en la página de descargas de Terraform. Puedes usar el siguiente comando para descargar la versión 1.3.9:

wget https://releases.hashicorp.com/terraform/1.3.9/terraform_1.3.9_linux_386.zip

Descomprime el archivo ZIP que acabas de descargar con el siguiente comando:

unzip terraform_1.1.4_linux_amd64.zip

Mueve el archivo binario de Terraform a un directorio que esté en tu PATH de usuario, como /usr/local/bin, con el siguiente comando:

sudo mv terraform /usr/local/bin/

Verifica que Terraform esté instalado y funcionando correctamente ejecutando el siguiente comando:

terraform version

Este comando debería mostrar la versión de Terraform que acabas de instalar.

Para realizar la instalación en otro Sistema Operativo, por favor revisar el siguiente enlace: https://developer.hashicorp.com/terraform/downloads

Estructura de archivos básica para un proyecto en Terraform

Algo que considero importante y que brinda mejor visión sobre el uso y configuración de Terraform es la estructura de archivos, a continuación se comparte un ejemplo y explicación de cada uno de ellos.

├── main.tf
├── providers.tf
├── variables.tf
├── outputs.tf
├── modules/
│   ├── networking/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── ...
│   ├── instances/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── ...
│   └── ...
├── environments/
│   ├── dev/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── ...
│   ├── staging/
│   │   ├── main.tf
│   │   ├── variables.tf
│   │   ├── outputs.tf
│   │   └── ...
│   └── prod/
│       ├── main.tf
│       ├── variables.tf
│       ├── outputs.tf
│       └── ...
└── README.md

Para aterrizar mejor el ejemplo anterior, supongamos que queremos crear una infraestructura en AWS con Terraform que incluya un VPC, una subred pública y una instancia EC2. Entonces los archivos anteriores podrian explicarse así:

main.tf: Este es el archivo principal donde se define la mayoría de los recursos. En este archivo, se crearía el VPC, la subred pública y la instancia EC2.
variables.tf: Este archivo se utiliza para definir las variables que se utilizarán en el archivo main.tf. En este caso, definiríamos variables como el CIDR block para el VPC, el nombre de la subred pública, el tipo de instancia EC2, etc.
outputs.tf: Este archivo se utiliza para definir las salidas que se mostrarán después de que Terraform haya aplicado los cambios. Por ejemplo, podríamos definir una salida que muestre la dirección IP pública de la instancia EC2.
providers.tf: Este archivo se utiliza para especificar el proveedor de servicios cloud que se está utilizando. En este caso, especificaríamos el proveedor de AWS.

El directorio modules/ contiene módulos reutilizables para cada componente del sistema. Por ejemplo, hay un módulo de networking y un módulo de instancias de EC2. Cada módulo tiene su propio archivo main.tf, variables.tf, y outputs.tf para definir los recursos específicos del módulo.

El directorio environments/ contiene archivos específicos de cada ambiente, como dev, staging y prod. Cada ambiente tiene sus propios archivos main.tf, variables.tf, y outputs.tf para definir los recursos específicos de ese ambiente.

Finalmente, hay un archivo README.md para documentar el proyecto.

Esta estructura de archivos separa claramente los recursos en módulos reutilizables y ambientes específicos, lo que facilita la organización del código y la administración de los diferentes ambientes.

Terraform Workflow y principales comandos

El flujo de trabajo de Terraform generalmente sigue los siguientes pasos:

Definir la configuración de infraestructura en archivos de configuración .tf.
Inicializar el directorio de trabajo de Terraform con el comando terraform init.
Crear un plan de ejecución para la infraestructura con el comando terraform plan.
Revisar y aprobar el plan de ejecución si está de acuerdo con los cambios propuestos.
Aplicar los cambios propuestos con el comando terraform apply.
Verificar la infraestructura creada y el estado actual de la misma con el comando terraform show.
Modificar la configuración de infraestructura en los archivos .tf y volver a partir del paso 3 si se requieren cambios.

A continuación, describimos los comandos más utilizados en Terraform:

terraform init: Este comando inicializa el directorio de trabajo de Terraform y descarga las dependencias necesarias, como los proveedores y módulos. Se recomienda ejecutar este comando siempre que se inicie un nuevo proyecto o cuando se realicen cambios en los proveedores o módulos.
terraform plan: Este comando muestra un plan de ejecución que describe los cambios que se van a realizar en la infraestructura. Este plan incluye la creación, modificación o eliminación de recursos. También muestra un resumen de los cambios y un resumen de los costos estimados.
terraform apply: Este comando aplica los cambios descritos en el plan de ejecución generado por el comando terraform plan. Este comando también solicita una confirmación antes de aplicar los cambios.
terraform destroy: Este comando elimina todos los recursos creados por Terraform. Este comando también solicita una confirmación antes de eliminar los recursos.
terraform show: Este comando muestra el estado actual de la infraestructura en formato legible por humanos. Este comando también se puede utilizar para verificar si los recursos se han creado correctamente.
terraform validate: Este comando verifica la sintaxis de los archivos .tf y comprueba si la configuración es válida.
terraform state: Este comando se utiliza para gestionar el estado de la infraestructura. Este comando se puede utilizar para ver, actualizar o eliminar recursos del estado.

Estos son algunos de los comandos más utilizados en Terraform, pero hay muchos otros comandos y opciones que se pueden utilizar según sea necesario.

Con esto terminamos el primer capítulo.
En el segundo capítulo trabajaremos el stack de una aplicación multi-tier en AWS.