Forem: Leonel Gareis

Docker para Jrs #2: Imágenes y Contenedores 🍰

Leonel Gareis — Thu, 02 Jan 2025 12:40:00 +0000

En el primer post te conté lo básico sobre Docker y por qué puede ser tu mejor amigo para contenerizar apps. Ahora vamos a dar un paso más y entender dos conceptos clave: imágenes y contenedores.

Spoiler: si los entendés bien, el resto será pan comido. 😉

¿Qué es una Imagen de Docker?

Las imágenes son como una receta: definen qué ingredientes (archivos, dependencias) y pasos (comandos) necesita tu app para correr.

Cada imagen es inmutable (una vez creada, no se modifica).
Se pueden construir usando un archivo llamado Dockerfile.

Ejemplo:
Si querés una app basada en Python, tu receta incluiría Python, librerías, y tu código.

¿Y qué es un Contenedor?

Un contenedor es la app lista y funcionando, creada a partir de una imagen. Es como seguir una receta y tener el plato servido. 🍝

Los contenedores son efímeros: viven mientras los necesitás.
Podés correr, pausar o eliminar contenedores sin afectar la imagen original.

Capas en las Imágenes: el truco de la magia 🎩

Cada imagen se construye en capas. Cada comando en un Dockerfile crea una nueva capa.
Esto hace que las imágenes sean eficientes:

Si actualizás algo, Docker reutiliza las capas que no cambiaron.
Resultado: builds más rápidos y menos espacio usado.

Comandos Básicos para Trabajar con Imágenes y Contenedores

Gestión de Imágenes

docker pull <imagen>: Bajate una imagen del registry (como Docker Hub).
docker images: Listá las imágenes locales.
docker rmi <id>: Eliminá una imagen que no necesitás.
docker tag <id_imagen> <nuevo_nombre>: Renombrá una imagen local.
docker save -o <archivo.tar> <imagen>: Guardá una imagen como archivo.
docker load -i <archivo.tar>: Cargá una imagen desde un archivo.

Gestión de Contenedores

docker run <imagen>: Crea y corre un contenedor.
docker stop <id>: Paramos un contenedor.
docker ps -a: Lista todos los contenedores (corriendo o no).
docker rm <id>: Eliminá un contenedor parado.
docker logs <id>: Mirá los logs de un contenedor.
docker exec -it <id> bash: Ingresá a un contenedor corriendo.

Ejemplo práctico:

docker pull nginx
docker run -d --name mi-nginx -p 8080:80 nginx

Con esto, ya tenés un servidor web corriendo en http://localhost:8080. 🚀

Bonus: Contenerizá tu Primera App en Go

Creamos una app simple que devuelve "¡Hola, Docker!" cuando accedemos a localhost:8080.

/mi-app
│── Dockerfile
│── main.go

main.go

package main

import (
    "fmt"
    "net/http"
)

func main() {
    http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
        fmt.Fprintln(w, "¡Hola, Docker!")
    })
    http.ListenAndServe(":8080", nil)
}

Dockerfile

# Imagen base
FROM golang:1.20

# Configuración del contenedor
WORKDIR /app
COPY . .

# Build de la app
RUN go build -o app .

# Comando que ejecuta el contenedor
CMD ["./app"]

Pasos para Correr la App

Navegá al directorio donde está tu app (mi-app).
Construí la imagen:

docker build -t mi-app .

Corré un contenedor basado en la imagen:

docker run -d -p 8080:8080 mi-app

Probalo en el navegador o con curl:

curl localhost:8080

Próximos Pasos

¡Ya entendiste cómo funcionan las imágenes y los contenedores en Docker! Ahora podés empezar a experimentar construyendo tus propias imágenes y lanzando aplicaciones contenerizadas. Pero acá no termina el viaje: en el próximo post vamos a hablar de algo igual de importante que los contenedores mismos, los volúmenes.

Vas a aprender cómo guardar y compartir datos entre tus contenedores, algo fundamental si querés que tus aplicaciones sean más que "efímeras". Desde un servidor web que mantiene sus logs hasta una base de datos que conserva información entre reinicios, los volúmenes son clave para llevar tus contenedores al próximo nivel. 🚀

Nos vemos en la próxima entrega: "Docker para Jrs #3: Guardá tus Datos con Volúmenes 📂". ¡A seguir aprendiendo! 🙌

Docker para Jrs #1: Introducción 🔥

Leonel Gareis — Sun, 04 Aug 2024 21:35:48 +0000

📦 Docker en pocas palabras

Docker es "una" herramienta que permite a los desarrolladores empaquetar sus aplicaciones y todas sus dependencias en un "contenedor". Este contenedor puede ejecutarse en cualquier entorno, garantizando que la aplicación funcione de la misma manera sin importar dónde se ejecute.

¿Por qué Docker es lo recomendado?
En el mundo del desarrollo, es común escuchar la frase "funciona en mi máquina, pero no en la tuya". Docker resuelve este problema al garantizar que tu aplicación y sus dependencias siempre se ejecuten de la misma manera. ¿Cómo lo hace? Empaquetando todo y ejecutandolo en un contenedor, que incluye:

El código de tu aplicación.
Las bibliotecas y dependencias necesarias.
Configuraciones del sistema.

Contenedores vs. Máquinas Virtuales 🖥️

Para entender mejor Docker, es útil compararlo con las máquinas virtuales (VMs).

Máquinas Virtuales

Simulan hardware completo: Cada VM incluye un sistema operativo completo.
Recursos: Cada VM necesita su propia cantidad de memoria y CPU asignada. Estos recursos son reservados se usen o no.
Aislamiento completo: Cada VM opera de manera totalmente independiente, lo que puede ser necesario para ciertos entornos de seguridad o aplicaciones que requieren un nivel alto de aislamiento.

Contenedores

Ligereza: Los contenedores comparten el kernel del sistema operativo anfitrión, lo que los hace mucho más ligeros.
Arranque rápido: Iniciar un contenedor toma segundos.
Eficiencia: Pueden ejecutarse múltiples contenedores en la misma máquina sin una sobrecarga significativa.
Aislamiento: Aunque los contenedores comparten el mismo kernel, siguen proporcionando un buen nivel de aislamiento para la mayoría de las aplicaciones.

Beneficios de Docker ⭐

Portabilidad: Los contenedores pueden ejecutarse en cualquier entorno que tenga Docker instalado.
Eficiencia: Al compartir el kernel del sistema operativo, los contenedores utilizan menos recursos que las máquinas virtuales.
Consistencia: El mismo contenedor se puede ejecutar en desarrollo, pruebas y producción, eliminando problemas de configuración entre entornos.
Aislamiento: Cada contenedor opera de manera independiente, lo que facilita la gestión de múltiples aplicaciones y sus dependencias.

¿Esto significa que los contenedores son mejores que las máquinas virtuales? No. Son herramientas desarrolladas con propósitos distintos. Habrá casos en los que las máquinas virtuales, sean una mejor solución que un contenedor.

Ejemplo práctico

En la documentación oficial de Docker podes encontrar los pasos para instalar la herramienta según el Sistema Operativo que estés usando.

Dicho esto, para ilustrar lo fácil que es comenzar con Docker, vamos a correr un contenedor simple que muestra un mensaje de "Hola Mundo".

Abris la terminal
Corres el comando docker run hello-world

Y así, sin vueltas, tenés tu primer contenedor corriendo con Docker. ¿Viste qué fácil?
Ahora seguramente la pregunta que se te viene es, ¿cómo hizo Docker esto?

En el medio pasaron algunas cosas que, para no enredarte, decidí graficar:

De esta imagen podemos desprender tres conceptos nuevos que me gustaría que te lleves:

Docker client: se trata de la interfaz que usamos para comunicarnos con docker. Esta puede ser una interfaz grafica (como Docker Desktop si estas usando Windows/MacOS) o una herramienta de CLI (terminal). Lo importante es que esa herramienta es la encargada de tomar nuestro pedido y enviárselo al "Docker Daemon"
Docker Daemon: el "demonio" de Docker es el cerebro detrás de todo. Expone una API que le permite recibir instrucciones del cliente. Este proceso se ejecuta en segundo plano y se encarga de cosas como: gestión de contenedores, gestión de imágenes, gestión de volúmenes, etc.
Registry: en la imagen vemos a Docker Hub como el lugar donde conseguimos las imágenes. Este sitio es un Registry pero no es el único que existe. Lo importante es que se trata de un lugar remoto donde almacenamos las imágenes de contenedores.

Conclusión 🎯

En esta primera parte del post, hemos explorado qué es Docker y por qué se ha convertido en una herramienta esencial para el desarrollo moderno. Hemos visto que Docker permite empaquetar aplicaciones en contenedores ligeros y portátiles, resolviendo problemas comunes de consistencia y portabilidad en el desarrollo de software.

También hemos comparado contenedores con máquinas virtuales, destacando sus diferencias clave en cuanto a ligereza, eficiencia, y uso de recursos. Los contenedores ofrecen una forma más ágil y eficiente de ejecutar aplicaciones, especialmente en entornos de desarrollo y producción donde la consistencia y la rapidez son cruciales.

Además, hemos desglosado los componentes principales de Docker: el Cliente, el Daemon, y los Registros. Cada uno de estos elementos desempeña un papel fundamental en el ecosistema de Docker, permitiendo a los desarrolladores crear, gestionar y desplegar aplicaciones de manera sencilla y efectiva.

En la próxima parte, vamos a sumergirnos en los conceptos básicos de Docker, como la creación y ejecución de contenedores, y cómo empezar a trabajar con imágenes de Docker. Prepárate para poner manos a la obra y empezar a contenerizar tus aplicaciones.

¡Nos vemos en la próxima! 👋

Despliega un servidor Nginx en AWS con Terraform

Leonel Gareis — Mon, 27 Nov 2023 18:36:56 +0000

Hoy vamos a aprender como podemos desplegar una instancia EC2 e instalar Nginx de forma rápida y sencilla con Terraform.

Desde el inicio: Que es Terraform? 🤔

Terraform es una herramienta que nos permite crear, modificar y versionar la infraestructura de nuestro proyecto de forma fácil a partir de manifiestos (archivos). A esto se le conoce como IaC (Infrastructure as Code)

Terraform no es la única herramienta para IaC, pero si me arriesgo a decir que es la más popular.

Terraform vs Manual ❗🟰

Características	Terraform	Configuración Manual
Sintaxis y Lenguaje	HCL (HashiCorp Configuration Lang.)	Interfaz gráfica o CLI proveedor
Declarativo vs. Imperativo	Declarativo	Imperativo
Gestión de Estado	Sí (Archivo de Estado)	No (Depende de documentación)
Escalabilidad	Escala bien con infraestructuras	Propenso a complejidad y errores
Control de Versiones	Sí (Archivo de Configuración)	No (Depende de documentación)
Gestión de Cambios	Planificación antes de aplicar	Riesgo de cambios no documentados
Reproducibilidad	Alta	Variable
Curva de Aprendizaje	Moderada	Baja (Interfaz gráfica)
Colaboración	Facilita la colaboración en equipos	Dificultad para compartir contextos
Flexibilidad y Abstracción	Permite abstracciones complejas	Limitado a la interfaz del proveedor
Automatización	Totalmente automatizable	Limitado a capacidades de proveedor

Que seria el "versionado"? 🤔

Al declarar toda la infraestructura en archivos, estos pueden estar versionados tranquilamente con Git.

Es conveniente hacer todo con Terraform? 🤔

Esto depende mucho de lo que estes haciendo. A veces, para proyectos muy chicos/personales es mas rápido utilizar la consola del proveedor.

Instalación 🖥️

Si no tenes Terraform instalado, te sugiero que entres aca y sigas la guía.

Creando nuestra infraestructura ☁️

Empecemos creando nuestro archivo main.tf con el siguiente contenido (voy a ir explicando para que es cada bloque):

provider "aws" {
    region = "us-east-1"
}

El archivo main.tf es el archivo de configuración principal. Acá vamos a definir todo lo que queremos crear.

El bloque provider le permite saber a Terraform con que proveedor de la nube vamos a trabajar. Existen varios proveedores (podes ver la lista completa en este link)

Cada proveedor establece que valores deberemos indicar en este bloque. Hay cosas que son obligatorias, y otras que son opcionales.

Autenticación 🔐

Si, es necesario que Terraform se identifique con el proveedor para crear los recursos solicitados. Como logramos esto?

Para el caso de AWS existen 3 formas principales (en la doc hay mas):

Colocar los valores directamente en el bloque del proveedor (no recomiendo esta forma):

    provider "aws" {
        region = "us-east-1"
        access_key = "clave-de-acceso"
        secret_key = "clave-secreta"
    }

Usando variables de entorno (AWS_ACCESS_KEY_ID y AWS_SECRET_ACCESS_KEY y opcionalmente AWS_SESSION_TOKEN)
Configurando el archivo de credenciales. Podes hacerlo con la herramienta de awscli y la instrucción aws configure. Terraform buscara el archivo donde, según la documentación, deberían estar. Pero podemos indicarle nosotros mismos donde buscar con lo siguiente:
```
    provider "aws" {
        shared_config_files = ["/tf_user/.aws/conf"]
        shared_credentials_files = ["/tf_user/.aws/creds"]
        profile = "mi-perfil-para-test"
    }
```

En mi caso, yo tengo las credenciales como variables de entorno así que no voy a colocar parámetros extras en el bloque del proveedor.

Creamos una VPC ☁️

Lo primero que vamos a crear es una VPC.

Si estas viendo Terraform, es porque algo de conocimiento tenés sobre AWS y ciertos recursos como VPC, EC2, etc. Si no es el caso, tranquilo/a que repasamos algunos conceptos clave para que entiendas 😃

Una VPC nos permite crear una red virtual privada para aislar recursos de forma lógica en la nube. Con esto podremos lanzar y gestionar recursos como instancias EC2, bases de datos en RDS, etc.

Escribamos esto en nuestro main.tf y analicemos que es:

resource "aws_vpc" "my-vpc" {
  cidr_block = "10.0.0.0/16"

  tags = {
    Name = "aws-nginx-server-with-terraform"
    Environment = "test"
    Terraform = true
  }
}

En Terraform debemos crear un bloque de resource por cada recurso que deseemos. Se define así:

resource "tipo_de_recurso" "nombre_del_recurso" {
    atributo = valor
}

Donde:

tipo_de_recurso: indica el tipo de recurso que estamos creando (esto se define en la documentación del proveedor). Por ejemplo: aws_instance, aws_vpc, aws_eks_cluster, etc.
nombre_del_recurso: nombre que le damos a ese recurso para usarlo en los siguientes bloques en caso de ser necesario (spoiler)

Los Tags

El atributo tags es algo que se encuentra presente en casi todos los recursos que podemos crear. Yo normalmente agrego estas 3 etiquetas:

El nombre del proyecto para el que estoy creando la infra. Es mejor si es el nombre del repositorio donde estas por almacenar los manifiestos.
El ambiente para el que esta siendo desplegado (dev, stg, prd).
El tag de Terraform = true para saber que ese recurso esta siendo gestionado por esa herramienta y comunicarle así a mi equipo (o a mi yo del futuro) que evite modificarlo manualmente.

Creamos un Internet Gateway 🌐

Este recurso es fundamental en la infraestructura de red de AWS, ya que proporciona una conexión entre una red privada en la nube y la red publica de internet.

resource "aws_internet_gateway" "internet-gw" {
  vpc_id = aws_vpc.dev-vpc.id
  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Fijate en el siguiente detalle: No estamos escribiendo el id del VPC porque no lo tenemos ya que no existe. Así que le estamos pidiendo a Terraform que lo defina por nosotros cuando cree ese recurso.
Siempre que tengamos que referirnos a un recurso que va a ser creado en el mismo manifiesto, lo vamos a hacer de esta forma: tipo_de_recurso.nombre_del_recurso.atributo

Creamos el Route Table 📄

El Route Table nos permite definir como se dirige el trafico entre las subredes de la VPC y, en particular, como se enruta el trafico desde y hacia internet mediante el Internet Gateway.

resource "aws_route_table" "route-table" {
  vpc_id = aws_vpc.my-vpc.id
  route {
    cidr_block = "0.0.0.0/0"
    gateway_id = aws_internet_gateway.internet-gw.id
  }

  route {
    ipv6_cidr_block = "::/0"
    gateway_id = aws_internet_gateway.internet-gw.id
  }

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Este bloque de configuración está estableciendo reglas para decirle a AWS cómo manejar el tráfico dentro de una VPC, permitiendo que las cosas en esa VPC se comuniquen con el Internet y viceversa. La tabla de rutas es como un mapa que dice a las instancias de la VPC hacia dónde enviar o recibir datos.

Creamos una subnet en la VPC 🌐

Una subnet es una porción de una red IP mas grande. En AWS, una subnet esta asociada a una VPC y se usa para organizar y segmentar los recursos de red.

resource "aws_subnet" "subnet-1a" {
  vpc_id            = aws_vpc.my-vpc.id
  cidr_block        = "10.0.1.0/24"
  availability_zone = "us-east-1a"

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Creamos la asociación entre la subnet y la route table 🌐

resource "aws_route_table_association" "association-1a" {
  subnet_id      = aws_subnet.subnet-1a.id
  route_table_id = aws_route_table.route-table.id
}

Este bloque nos va a permitir establecer una relación entre la subred que creamos mas arriba y la tabla de enrutamiento también creada con anterioridad. Esto significa, básicamente, que la subred va a usar esas reglas de enrutamiento.

Creamos un security group 🔓

Los "security group" son como un firewall. Estos permiten definir que conexiones entrantes y salientes se aceptan, y cuales no.

resource "aws_security_group" "security-group" {
  name        = "sg-internet"
  description = "Allow ingress and egress connection to the internet"
  vpc_id      = aws_vpc.my-vpc.id

  ingress {
    description = "Allow HTTPS connection"
    from_port   = 443
    to_port     = 443
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

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

  ingress {
    description = "Allow SSH connection"
    from_port   = 22
    to_port     = 22
    protocol    = "tcp"
    cidr_blocks = ["0.0.0.0/0"]
  }

  egress {
    from_port   = 0
    to_port     = 0
    protocol    = "-1"
    cidr_blocks = ["0.0.0.0/0"]
  }

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Este bloque nos permite definir las reglas necesarias para permitir las conexiones hacia los puertos 80 (HTTP), 443 (HTTPS) y 22 (SSH) desde cualquier IP. Si, se que no es seguro permitir conexiones desde cualquier lado por SSH, pero es solo para el ejemplo.

Creamos una network interface 🌐

Las "network interfaces" (interfaces de red) son un componente clave para permitir la conexión de instancias EC2 a la red.

resource "aws_network_interface" "network-interface" {
  subnet_id       = aws_subnet.subnet-1a.id
  private_ips     = ["10.0.1.50"]
  security_groups = [aws_security_group.security-group.id]

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Este recurso nos permite configurar también la IP privada que asignaremos a la interfaz.

Creamos una elastic IP 🌐

En AWS, una elastic IP es una dirección IP publica estática que sera asociada a una instancia EC2. Lo que la diferencia de las IPs publicas tradicionales que son asignadas dinámicamente a nuestras instancias EC2, es que las IPs otorgadas por este recurso persisten aun cuando las instancias son reiniciadas o detenidas. Increíble, no?

resource "aws_eip" "eip" {
  domain                    = "vpc"
  network_interface         = aws_network_interface.network-interface.id
  associate_with_private_ip = "10.0.1.50"

  depends_on = [aws_internet_gateway.internet-gw]

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Algo interesante de este bloque es el depends_on que nos permite decirle a Terraform que debe crear primero de forma explícita. En nuestro caso, este atributo asegura que la Elastic IP se cree después de que el Internet Gateway asociado esté disponible.

Finalmente: creamos el servidor 🖥️

Las instancias EC2 (Elastic Cloud Computing) son básicamente maquinas virtuales con recursos de computo limitados según el tipo de instancia elegida. Como es una maquina virtual, debemos seleccionar el sistema operativo que correrá en la misma. Es lo que en AWS se conocen como AMI (Amazon Machine Image).
Tenemos AMI's para Windows, Linux y MacOS.
Para este tutoria, voy a usar una imagen de Ubuntu Server 20.04 aunque vos podes usar el que quieras.

El recurso necesita que le indiquemos el ID de la AMI. Como lo obtenemos? Existen dos formas: buscar en la consola de AWS, o definir un bloque de data para que haga la búsqueda por nosotros.

Si vamos por la consola, al darle "Crear instancia" podremos seleccionar el tipo de AMI y copiar el ID. También podes usar esta guía de AWS.

El bloque `data`

Este bloque se usa para obtener y utilizar información existente antes de la creación o modificación de los recursos.

data "aws_ami" "ubuntu-ami" {
  most_recent = true 
  filter {
    name = "name"
    values = ["ubuntu/images/hvm-ssd/ubuntu-focal-20.04-amd64-server-*"]
  }

  filter {
    name = "virtualization-type"
    values = ["hvm"]
  } 
}

Es importante que si vamos a usar esta opción, aceptemos los términos y condiciones de AWS Marketplace. Si no lo hacemos, obtendremos un error como este:

creating EC2 Instance: OptInRequired: In order to use this AWS Marketplace product you need to accept terms and subscribe. To do so please visit https://<URL>

Por último, creamos la instancia de EC2

resource "aws_instance" "nginx-server" {
  ami           = data.aws_ami.ubuntu-ami.id
  instance_type = "t2.micro"

  network_interface {
    device_index         = 0
    network_interface_id = aws_network_interface.network-interface.id
  }

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

Si no usaste data, podes hacerlo de esta forma:

resource "aws_instance" "nginx-server" {
  ami           = "ami-0fc5d935ebf8bc3bc"
  instance_type = "t2.micro"

  network_interface {
    device_index         = 0
    network_interface_id = aws_network_interface.network-interface.id
  }

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = "test",
    Terraform = true
  }
}

En este bloque estamos definiendo: el tipo de instancia, la AMI que debe usar, la interfaz de red (que creamos mas arriba) y los tags de siempre.

Que nos falta? 🤔
Esto nos creara una instancia con un sistema operativo y nada mas. Que pasa con Nginx? Debemos instalarlo a mano a través de SSH? 🤔
Por suerte no. Si has trabajado con la consola, te acordaras de un input llamado "user data". Este input nos permitía definir un script de bash (en su mayoría) que seria ejecutado cuando la instancia de EC2 sea creada.
Para agregar un user_data en el bloque, tenemos dos formas:

Forma 1️⃣:

  ...
  user_data=<<EOF
#!/bin/bash
sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx
EOF
  ...

Forma 2️⃣ (mi favorita)

Creamos un archivo llamado init.sh (o como prefieras) y definimos el script ahi:

#!/bin/bash
sudo apt update
sudo apt install nginx -y
sudo systemctl start nginx
sudo systemctl enable nginx

Ahora, en el main.tf definimos el user_data de la siguiente forma:

  ...
  user_data = file('init.sh')
  ...

El archivo de init.sh debe estar al mismo nivel que el archivo main.tf

Despliegue 🚀

Ahora que tenemos toda la infraestructura definida, solo nos resta decirle a Terraform que aplique lo solicitado.

El primer comando que vamos a ejecutar donde se encuentra el main.tf es: terraform init. Este comando incializará los archivos de estado y descargara los archivos necesarios para interactuar con el proveedor (AWS en nuestro caso).

Al ejecutarlo, notaremos que se han creado algunas cosas en el directorio donde estamos:

.terraform.lock.hcl: este archivo registra la version del proveedor que vamos a usar para el despliegue.
.terraform: este directorio contiene varios directorios, pero en resumen, acá se guarda el binario del proveedor.

Si no estamos seguro de que es lo que va a hacer Terraform, este nos provee de un comando para la visualización del plan de ejecución. Simplemente debemos ejecutar terraform plan.

Si estamos seguros, podemos ejecutar terraform apply para aplicar el plan. Este comando primero nos mostrara todo lo que va a hacer (misma salida que el terraform plan), y nos pedirá que ingresemos una palabra para confirmar los cambios.

Mientras el plan se ejecuta, notaremos cambios en nuestro directorio. Se ha creado un archivo llamado terraform.tfstate. Este es MUY importante para Terraform ya que con el rastrea y gestiona el estado de los recursos que fueron creados por la herramienta.

Cuidado! En este terraform.tfstate, Terraform muestra secretos y cosas sensibles en texto plano. Así que si estas recuperando secretos de Secrets Manager para inyectarlos en los recursos que estes creando/modificando, tené por seguro que van a aparecer ahi sin protección alguna.

Abordaremos cuestiones de seguridad y buenas practicas en otro post.

Revisamos la consola de AWS

Para saber que todo fue bien, entramos a la consola y nos vamos al apartado de EC2

Ya tenemos una instancia creada!
Copiemos la IP y vayamos al navegador para corroborar que todo funciona:

Destruir lo creado

Para borrar todos los recursos creados y evitar un costo extra en nuestra factura de AWS, apliquemos terraform destroy

Extras (lo que no vimos)

Existen mas cosas de Terraform que no cubrimos en este mini tutorial.

Bloque output

Este bloque se utiliza para declarar valores que deben ser mostrados después de que Terraform haya aplicado los cambios. Puede ser información útil, identificadores, direcciones IP, o cualquier otro dato que deseemos exponer después de que la infraestructura ha sido creada o modificada.

En nuestro caso podriamos agregar el siguiente bloque para obtener la IP pública y evitar acceder a la consola

output "public_ip_nginx_server" {
  value = aws_instance.nginx-server.public_ip
}

Archivos

Si bien el main.tf es el mas importante, existen otros archivos que podemos definir para mantener el main lo mas limpio posible:

variables.tf : acá definimos variables que pueden ser usadas para parametrizar la configuracion de los recursos. Por ejemplo: el environment y el tipo de instancia

# variables.tf
variable "instance_type" {
    type = string
    default = "t2.micro"
}

variable "environment" {
    type = string
    default = "test"
}

# main.tf
resource "aws_instance" "nginx-server" {
  ami           = "ami-0fc5d935ebf8bc3bc"
  instance_type = var.instance_type # <-- esto cambió

  network_interface {
    device_index         = 0
    network_interface_id = aws_network_interface.network-interface.id
}

  user_data = file("init.sh")

  tags = {
    Name        = "aws-nginx-server-with-terraform",
    Environment = var.environment, # <-- esto cambió
    Terraform = true
  }
}

outputs.tf: Acá definimos todas las salidas que necesitamos

output "public_ip_nginx_server" {
  value = aws_instance.nginx-server.public_ip
}

terraform.tfvars: Este archivo se usa para asignar valores a las variables definidas en variables.tf. Por ejemplo, podemos darle un valor de la variable aws_region (si la tuvieramos definida)
```
    aws_region = "us-east-1"
```
backend.tf: Este archivo se usa para definir un backend remoto, es decir, el lugar donde se va a almacenar el terraform.tfstate, pero esto mejor dejémoslo para otro post.

Hasta acá el post de hoy! Espero realmente que te haya gustado.
Todo comentario o sugerencia es mas que bienvenido.

Te dejo el link al repositorio por si queres dar un vistazo mas general, forkearlo (spanglish++) o revisar mis otros repositorios.

No te olvides de seguirme en redes (Twitter: LeoGareis)

Hasta la próxima coder!

Bases de datos: Vistas

Leonel Gareis — Mon, 24 May 2021 00:46:42 +0000

Photo by luis gomes from Pexels

En algun momento de nuestras vidas como desarrolladores, nos hemos topado con SQL.

Hemos hecho consultas agradables:

SELECT * FROM users
WHERE age > 18;

Otras mas complejas

SELECT * FROM users
INNER JOIN posts
ON (posts.user_id = users.id)
WHERE users.age > 18;

Y mas complejas aun

SELECT * FROM employees
INNER JOIN departments
ON (departments.id = employees.dep_id)
WHERE salary > (
    SELECT AVG(salary) FROM employees
);

Y en algun momento te habras preguntado: ¿Hay una forma mas sencilla que estar copiando y ejecutando la misma sentencia SQL una y otra vez?

Bueno, esto ya esta respondido en el titulo 😁

Introduccion a Vistas

Las vistas son tablas virtuales creadas a partir de una consulta almacenada.
Este mecanismo de SQL nos permite definir, una unica vez, una consulta (query) y usarla tantas veces como deseemos.

Como crear una vista

Esto depende del motor de bases de datos usado.
Yo uso PostgreSQL, pero vos podes usar el que quieras (solo vas a tener que buscar la sintaxis)

CREATE VIEW <nombre_de_la_vista> AS
    <SENTENCIA_sql>

Como usar una vista

Dado que se crea una tabla virtual, podemos consultarla como tal a traves del select.

SELECT * FROM <nombre_de_la_vista>

Veamos un ejemplo

Mi tabla users tiene los siguiente campos:

id
username
email
password
age

Necesito obtener el username y el email de aquellos usuarios cuya edad sea mayor a 18.

Antes, hubieramos realizado una consulta SQL normal de toda la vida.

SELECT username, email FROM users
WHERE age > 18;

Pero ahora que sabemos vistas, las cosas se ponen mas interesantes

CREATE VIEW users_legal_age AS 
    SELECT username, email FROM users
    WHERE age > 18;

SELECT * FROM users_legal_age

Lo interesante de las vistas es que, dado que son tablas, podemos seguir lanzando distintas consultas sin necesidad de modificar la query original.

Si yo quisiera en este momento obtener, ademas de los usuarios mayores de edad, aquellos cuyo username contiene la cadena 'admin', solo tendria que hacer esto:

SELECT * FROM users_legal_age
WHERE username LIKE '%admin%'

Y nuestra query original se mantiene intacta.

Recomendacion para operaciones con mas tablas

Si tenemos la siguiente vista

CREATE VIEW view_posts_users AS
    SELECT * FROM users
    INNER JOIN posts
    ON (posts.user_id = users.id)
    WHERE users.age > 18;

Debemos de tener cuidado con los campos que tienen el mismo nombre.

Si users y posts tienen campos cuyos nombres son iguales, debemos de asignarle un alias a esos campos para evitar conflictos.

¿Cuando debo usar vistas?

Lo recomendado es que lo uses cuando tenes una query compleja y que requiere ser usada mas de una vez.

Aca tiene sentido crear una:

CREATE VIEW view_admin_users_legal_age AS
    SELECT first_name, last_name
    FROM users
    WHERE age > 18 AND username LIKE '%admin%';

Aca no:

CREATE VIEW view_list_users AS
    SELECT * FROM users;

Esto solo fue una introduccion, lo demas, lo dejo a tu imaginacion para que sigas practicando y probando 💪