DEV Community: Israel Oña Ordoñez 🚀

Everything as Code: La evolución de la infraestructura

Israel Oña Ordoñez 🚀 — Thu, 06 Feb 2025 23:55:26 +0000

📝 TL;DR

Everything as Code (EaC) es un enfoque donde todo elemento de la infraestructura, desde la configuración de la red hasta la configuración de la aplicación, se define y gestiona como código. Este enfoque permite mayor automatización, control y reproducibilidad en los entornos de TI. En este artículo aprenderás qué es EaC, sus beneficios y cómo implementarlo en tu organización.

🏗️ Todo como código

En los entornos de TI modernos, la infraestructura y la configuración de las aplicaciones se gestionan cada vez más como código. Este enfoque, conocido como Everything as Code (EaC), permite definir y gestionar todos los elementos de la infraestructura y la aplicación como código, lo que facilita la automatización, el control y la seguridad en los entornos de TI.

Existen varios tipos de "código" en el contexto de EaC:

Infrastructure as Code (IaC): Define y gestiona la infraestructura de TI como código para crear y gestionar recursos en la nube (Terraform).
Configuration as Code (CaC): Define y gestiona la configuración de la aplicación como código para instalar y configurar aplicaciones (Ansible).
Policy as Code (PaC): Define y gestiona las políticas de cumplimiento como código para validar y hacer cumplir las políticas de seguridad (OPA).
Security as Code (SaC): Define y gestiona la seguridad de la aplicación como código para identificar y corregir vulnerabilidades (Snyk).
GitOps: Define y gestiona la infraestructura y las aplicaciones a través de Git para automatizar despliegues y operaciones (Argo CD).

🔧 Ejemplo: Creando infraestructura con EaC

Objetivo: Crear una infraestructura en AWS utilizando:

Terraform: Definir la infraestructura como código.
Ansible: Configurar la instancia EC2 con Nginx.
OPA: Validar que los recursos cumplan con las políticas de seguridad.
Bash: Automatizar el proceso de creación y configuración.

Arquitectura del proceso:

El diagrama muestra el flujo de trabajo utilizando Everything as Code para crear una infraestructura en AWS. Cada herramienta cumple una función específica en el proceso:

Se inicializan los recursos de terraform para preparar el directorio de trabajo.
Se genera el plan de ejecución de terraform para crear los recursos en AWS.
Se ejecutan las validaciones de OPA para asegurar que los recursos cumplen con las políticas de seguridad.
Se aplica el plan de terraform para crear los recursos en AWS.
Se ejecuta el playbook de Ansible para configurar la instancia EC2 con Nginx.

Estructura del proyecto:

.
├── ansible
│   ├── ansible.cfg                   # Configuración de Ansible
│   ├── ec2-instance.yml              # Playbook principal
│   ├── hosts                         # Inventario
│   ├── roles
│   │   ├── nginx-setup               # Rol para configurar Nginx
│   │   │   ├── handlers
│   │   │   │   └── main.yml          # Manejador para reiniciar Nginx
│   │   │   └── tasks
│   │   │       └── main.yml          # Instalación y configuración de Nginx
│   │   └── web-index                 # Rol para configurar la página de inicio
│   │       ├── tasks
│   │       │   └── main.yml          # Copia la plantilla de la página de inicio
│   │       └── templates
│   │           └── index.html        # Página de inicio personalizada
│   ├── terraform_generated_key.pem   # Clave privada generada por Terraform
│   └── vars
│       └── ec2-instance.yml          # Variables para el playbook
├── opa
│   └── policy.rego                   # Políticas de validación con OPA
├── scripts
│   ├── apply_ansible.sh              # Ejecuta Ansible
│   ├── apply_terraform.sh            # Aplica Terraform
│   ├── pipeline.sh                   # Orquesta Terraform, OPA y Ansible
│   └── validate_opa.sh               # Valida con OPA
└── terraform
    ├── 01-vpc.tf                     # Creación de VPC y redes
    ├── 02-ec2.tf                     # Creación de EC2 con security group
    ├── outputs.tf                    # Salidas de Terraform
    ├── providers.tf                  # Configuración del proveedor AWS
    ├── variables.auto.tfvars         # Valores por defecto
    ├── variables.tf                  # Definición de variables
    └── versions.tf                   # Configuración de versiones

1. Definiendo la infraestructura con Terraform:

En el directorio terraform, se definen los recursos de AWS, en este caso:

Una VPC con una subred pública, un internet gateway y una route table.
Una instancia EC2 con un security group y una key pair.

Después de ejecutar scripts/apply_terraform.sh, los recursos se crearán en AWS y obtendrás la información de salida con el id de la instancia EC2, la dirección IP pública y la ruta de la clave privada generada.

2. Validando la infraestructura con OPA:

En el directorio opa, se definen las políticas de validación con OPA. Estas políticas se aplican a los recursos planificados por Terraform para asegurar que cumplan con las políticas de seguridad antes de ser creados en AWS. Las políticas definidas en policy.rego validan que:

En todos los recursos aplicables, el tag Name debe estar presente.
Las instancias EC2 no deben generar un costo superior a $0.05 USD por hora.
Los security groups no deben permitir todo el tráfico desde cualquier origen.

Después de ejecutar scripts/validate_opa.sh, OPA validará los recursos planificados por Terraform y mostrará los resultados de la validación. Si los recursos no cumplen con las políticas, OPA mostrará los errores.

Después de corregir los errores, OPA mostrará un resultado exitoso.

3. Configurando la instancia EC2 con Ansible:

En el directorio ansible, se definen los playbooks y roles de Ansible. El playbook ec2-instance.yml instala Nginx y copia una página de inicio personalizada. Después de ejecutar scripts/apply_ansible.sh, Ansible configurará la instancia EC2 con Nginx y la página de inicio personalizada.

Una vez finalizado el proceso, podrás acceder a la dirección IP pública de la instancia EC2 en tu navegador o con curl para ver la página de inicio personalizada.

4. Orquestando todo el proceso con un Bash script:

El script scripts/pipeline.sh orquesta todo el proceso anterior de creación de infraestructura en AWS utilizando Terraform, validación con OPA y configuración con Ansible. Al ejecutar este script, se ejecutarán las siguientes tareas:

Inicialización de Terraform.
Generación del plan de ejecución de Terraform.
Conversión del plan de Terraform en un formato compatible con OPA.
Validación de los recursos planificados con OPA.
Solicitud de confirmación para aplicar los cambios.
Aplicación del plan de Terraform.
Ejecución del playbook de Ansible para configurar la instancia EC2.

📂 Repositorio del proyecto

Para seguir el ejemplo y explorar el proyecto completo, puedes clonar el repositorio asociado.

Repositorio: https://github.com/israoo/eac-cloud-provisioning.git

Este repositorio contiene:

Código de Terraform para crear la infraestructura en AWS.
Políticas de validación con OPA.
Playbooks y roles de Ansible para configurar la instancia EC2.
Scripts de Bash para orquestar los procesos.
Instrucciones detalladas en el archivo README.md sobre cómo configurar y ejecutar el proyecto.

📈 Beneficios de Everything as Code

Adoptar el enfoque de Everything as Code en tu organización puede proporcionar una serie de beneficios significativos:

Automatización total: La infraestructura y las aplicaciones se pueden crear, configurar y gestionar de forma automática, reduciendo el tiempo y los errores manuales.
Consistencia y reproducibilidad: Los entornos de desarrollo, pruebas y producción se pueden replicar de forma consistente, lo que facilita la detección y corrección de problemas.
Seguridad y cumplimiento: Las políticas de seguridad y cumplimiento se pueden aplicar de forma consistente en toda la infraestructura y las aplicaciones, reduciendo los riesgos de seguridad.
Control de versiones y auditoría: Todo el código de infraestructura y configuración se puede controlar con un sistema de control de versiones, lo que permite auditar y revertir cambios si es necesario.
Colaboración y transparencia: Los equipos de desarrollo, operaciones y seguridad pueden colaborar de forma más eficaz al utilizar un enfoque común basado en código.
Escalabilidad y flexibilidad: La infraestructura y las aplicaciones se pueden escalar y adaptar fácilmente a medida que cambian los requisitos del negocio.
Integración con CI/CD: Se puede automatizar de punta a punta el proceso validación, aplicación y configuración de la infraestructura y las aplicaciones.

💡 EaC vs Enfoque tradicional

Aspecto	Enfoque tradicional	Everything as Code (EaC)
Provisionamiento	Manual a través de la consola de AWS o scripts aislados	Declarativo con Terraform o similares
Configuración	Manual a través de SSH o scripts aislados	Declarativo con Ansible u otras herramientas
Validación y seguridad	Manual y revisiones ad-hoc	Automatizada con OPA o similares
Escalabilidad	Manual y propenso a errores	Definida en código y fácilmente replicable
Auditoria y cambios	Difícil de rastrear y revertir	Control de versiones y auditoría con Git
Colaboración	Silos entre equipos de desarrollo y operaciones	Colaboración entre equipos con un enfoque común
Errores y problemas	Difícil de detectar y corregir	Detección temprana y corrección de errores

EaC no solo optimiza la creación y gestión de la infraestructura, sino que también mejora la colaboración entre equipos, la seguridad y la escalabilidad de los entornos de TI.

🔗 Referencias/Extras

🚀 ¿Qué sigue?

Ahora que conoces Everything as Code (EaC), el siguiente paso es aplicarlo en tus proyectos. Empieza definiendo tu infraestructura y configuración como código, automatizando cada etapa del proceso para lograr entornos más consistentes y seguros.

Si quieres llevar este enfoque aún más lejos, integra herramientas de CI/CD para automatizar despliegues. En este sentido, GitHub Actions es una excelente opción. Te invito a leer mi artículo sobre ¿Qué es CI/CD y cómo puede acelerar tus despliegues en minutos? para aprender más al respecto.

¡No dudes en compartir tus experiencias y desafíos al implementar EaC en tu organización!

EKS con Terraform: Todo lo necesario, desde la red hasta los nodos

Israel Oña Ordoñez 🚀 — Tue, 28 Jan 2025 04:59:03 +0000

📝 TL;DR

EKS (Elastic Kubernetes Service) es un servicio de AWS que permite desplegar clústeres de Kubernetes de forma sencilla. Con Terraform, puedes automatizar la creación de un clúster de EKS y todos los recursos necesarios. En este artículo, encontrarás un proyecto completo que despliega un clúster de EKS con Terraform, incluyendo la creación de una VPC, subredes, grupos de seguridad, roles de IAM y nodos.

🌟 Una solución práctica

Elastic Kubernetes Service (EKS) es una de las opciones de Kubernetes más populares en la nube. Sin embargo, configurar un clúster de EKS manualmente puede ser un proceso tedioso y propenso a errores, por lo que es recomendable automatizarlo. Una forma de hacerlo es utilizando Terraform, una herramienta de infraestructura como código que te permite definir y gestionar la infraestructura de tu aplicación de forma declarativa.

He creado un proyecto de Terraform que despliega un clúster de EKS, incluyendo la creación de una VPC, subredes, grupos de seguridad, roles de IAM y nodos. Este proyecto te permitirá desplegar un clúster de EKS con un solo comando, ahorrándote tiempo y esfuerzo, pero también te servirá como punto de partida para personalizar y extender la configuración según tus necesidades.

🏗️ Estructura del proyecto

El proyecto está organizado en varios archivos de Terraform, cada uno de los cuales se encarga de crear un conjunto específico de recursos. A continuación, se muestra la estructura del proyecto:

.
├── 1.01-vpc.tf
├── 1.02-private_subnets.tf
├── 1.03-public_subnets.tf
├── 1.04-elastic_ips.tf
├── 1.05-nat_gateway.tf
├── 1.06-internet_gateway.tf
├── 1.07-private_route_tables.tf
├── 1.08-public_route_table.tf
├── 1.09-private_routes.tf
├── 1.10-public_routes.tf
├── 1.11-private_route_table_association.tf
├── 1.12-public_route_table_association.tf
├── 1.13-security_groups.tf
├── 2.01-control_plane_iam_role.tf
├── 2.02-worker_node_iam_role.tf
├── 3.01-eks_cluster.tf
├── 3.02-launch_template.tf
├── 3.03-node_group.tf
├── 3.04-eks_access.tf
├── eks_user_data.sh
├── outputs.tf
├── providers.tf
├── variables.auto.tfvars
├── variables.tf
└── versions.tf

Cada archivo tiene un nombre descriptivo que indica su función en el proyecto. Por ejemplo, 1.01-vpc.tf se encarga de crear la VPC, 1.02-private_subnets.tf crea las subredes privadas, 1.03-public_subnets.tf crea las subredes públicas, etc. Los archivos están numerados para indicar el orden en que deberían ser aplicados aunque Terraform se encarga de gestionar las dependencias entre los recursos.

⚙️ Recursos creados

1. VPC

El primer archivo, 1.01-vpc.tf, crea una VPC con una CIDR 10.0.0.0/16, habilita el DNS hostnames que permite a los nodos de EKS tener nombres de dominio de AWS y habilita el DNS support que permite a los nodos de EKS resolver nombres de dominio de AWS.

2. Subredes privadas y públicas

Los archivos 1.02-private_subnets.tf y 1.03-public_subnets.tf crean las subredes privadas y públicas respectivamente.

Para poder comunicarse con internet, las subredes privadas utilizan NAT Gateways 1.05-nat_gateway.tf que requieren una IP pública 1.04-elastic_ips.tf.

Las subredes públicas utilizan un Internet Gateway 1.06-internet_gateway.tf para permitir el tráfico de entrada y salida a internet.

Para habilitar la comunicación entre las subredes y el internet, se crean las tablas de rutas 1.07-private_route_tables.tf, 1.08-public_route_table.tf, las rutas 1.09-private_routes.tf, 1.10-public_routes.tf y se asocian las tablas de rutas a las subredes 1.11-private_route_table_association.tf, 1.12-public_route_table_association.tf.

3. Grupos de seguridad

El archivo 1.13-security_groups.tf crea los grupos de seguridad necesarios para el clúster de EKS.

Se crea un grupo de seguridad para el control plane de EKS que permite el tráfico de entrada desde el internet en el puerto 443 y el tráfico de salida a internet en todos los puertos.

Se crea un grupo de seguridad para los nodos de EKS que permite el tráfico de entrada desde el control plane en el puerto 10250 y el tráfico de salida a internet en todos los puertos.

4. Roles de IAM

El archivo 2.01-control_plane_iam_role.tf crea un rol de IAM para el control plane de EKS que permite a EKS administrar recursos en tu cuenta de AWS.

El archivo 2.02-worker_node_iam_role.tf crea un rol de IAM para los nodos de EKS que permite a los nodos de EKS acceder a los repositorios de imágenes de Amazon ECR, al control plane de EKS, a los servicios de SSM y CloudWatch.

5. Clúster de EKS

El archivo 3.01-eks_cluster.tf crea el clúster de EKS con la versión 1.31 de Kubernetes.

6. Nodos de EKS

El archivo 3.02-launch_template.tf crea un launch template para los nodos de EKS que utiliza una imagen de Amazon Linux 2023 y un script de usuario eks_user_data.sh que instala los componentes necesarios para que los nodos se unan al clúster de EKS.

El archivo 3.03-node_group.tf crea un node group para los nodos de EKS que utiliza el launch template creado anteriormente.

7. Acceso a EKS

El archivo 3.04-eks_access.tf configura un IAM access entry en el clúster de EKS para permitir el acceso a un usuario de IAM (cloud_user) con permisos de administrador.

🔧 Configuración

El proyecto utiliza un archivo de variables variables.auto.tfvars para definir los valores de las variables de Terraform. A continuación, se muestra un ejemplo de cómo se definen las variables en el archivo variables.auto.tfvars:

aws_user = "cloud_user" # Nombre del usuario de AWS que se utilizará para acceder al clúster de EKS como administrador

eks = {
  cluster_name    = "eks-cluster" # Nombre del clúster de EKS
  cluster_version = "1.31"        # Versión de Kubernetes
  worker_nodes = {
    node_group_name = "eks-managed-node-group" # Nombre del node group
    ebs_volume = {
      size = 20    # Tamaño del volumen EBS en GB
      type = "gp3" # Tipo del volumen EBS
    }
    instance_type              = "t3a.medium" # Tipo de instancia de los nodos
    desired_capacity           = 2            # Número de nodos deseados
    min_size                   = 1            # Número mínimo de nodos
    max_size                   = 3            # Número máximo de nodos
    max_unavailable_percentage = 50           # Porcentaje máximo de nodos no disponibles durante una actualización
  }
}

tags = { # Etiquetas para todos los recursos creados
  environment = "Prod"
  service     = "demo"
}

vpc = { # Configuración de la VPC
  cidr_block = "10.0.0.0/16"
  private_subnet_1 = {
    cidr_block        = "10.0.1.0/24"
    availability_zone = "us-east-1a"
  }
  private_subnet_2 = {
    cidr_block        = "10.0.2.0/24"
    availability_zone = "us-east-1b"
  }
  private_subnet_3 = {
    cidr_block        = "10.0.3.0/24"
    availability_zone = "us-east-1c"
  }
  public_subnet_1 = {
    cidr_block        = "10.0.4.0/24"
    availability_zone = "us-east-1a"
  }
  public_subnet_2 = {
    cidr_block        = "10.0.5.0/24"
    availability_zone = "us-east-1b"
  }
  public_subnet_3 = {
    cidr_block        = "10.0.6.0/24"
    availability_zone = "us-east-1c"
  }
}

En esta configuración, se usan 3 subredes privadas y 3 subredes públicas en 3 zonas de disponibilidad de la región us-east-1. Se crean 2 nodos de EKS con un volumen EBS de 20 GB, tipo gp3, instancia t3a.medium, y se configura el node group para tener entre 1 y 3 nodos con un máximo del 50% de nodos no disponibles durante una actualización.

🛠️ Despliegue

Para desplegar el proyecto, sigue estos pasos:

Clona el repositorio:

git clone https://github.com/israoo/eks-cluster-setup.git
cd eks-cluster-setup

Inicializa Terraform:
```
terraform init
```

Planifica los recursos a crear:

terraform plan -out=eks-cluster-setup.tfplan

Aplica los cambios:

terraform apply eks-cluster-setup.tfplan

Accede al clúster de EKS:

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

Verifica que los nodos de EKS se han unido al clúster:
```
kubectl get nodes
```

¡Listo! Ahora tienes un clúster de EKS desplegado con Terraform.

📂 Repositorio del proyecto

Para obtener el código completo del proyecto, visita el repositorio en GitHub:

Repositorio: https://github.com/israoo/eks-cluster-setup

Este repositorio contiene:

Archivos de Terraform para desplegar un clúster de EKS.
Documentación sobre los recursos creados y su configuración.
Configuraciones personalizables para adaptar el clúster a tus necesidades.
Instrucciones detalladas en el archivo README.md sobre cómo usar el proyecto.

🎯 Recomendaciones adicionales

Seguridad:
- Restringe el acceso al clúster mediante una VPN o rangos de IP específicos.
- Configura un ACL en las subredes para controlar el tráfico de red.
- Habilita el cifrado de datos en el control plane y en los nodos de EKS con una clave KMS.
- Deshabilita el access entry configurado con el archivo 3.04-eks_access.tf y crea roles de IAM específicos para los usuarios que necesiten acceso al clúster.
Tráfico de red:
- Configura un api gateway para gestionar las peticiones HTTP.
- Configura un WAF para proteger tu aplicación de ataques.

Dentro del cluster de EKS puedes configurar diferentes servicios para mejorar la escalabilidad, resiliencia, observabilidad y seguridad de las aplicaciones desplegadas en el clúster.

🔗 Referencias/Extras

🚀 ¿Qué sigue?

Con un clúster de EKS completamente funcional, puedes comenzar a desplegar tus aplicaciones en Kubernetes. Puedes utilizar Helm o Kustomize para gestionar los manifiestos de tus aplicaciones. Si quieres aprender más sobre Helm y Kustomize, te invito a leer mi artículo sobre Helm vs Kustomize.

¡Espero que este proyecto te sea útil y si tienes dudas o sugerencias, no dudes en compartirlas en los comentarios!

Crea imágenes Docker ligeras y seguras

Israel Oña Ordoñez 🚀 — Sun, 26 Jan 2025 04:13:19 +0000

📝 TL;DR

Optimizar tus imágenes Docker es esencial para mejorar los tiempos de construcción y despliegue, reducir costos y mejorar la seguridad. Este artículo muestra cómo usar multi-stage builds, elegir imágenes ligeras y aplicar buenas prácticas para crear imágenes Docker más eficientes.

🤔 ¿Por qué optimizar imágenes Docker?

En la contenerización, el tamaño y la seguridad de las imágenes Docker tienen un impacto significativo en el rendimiento, la eficiencia y la seguridad de las aplicaciones. Las imágenes grandes aumentan los tiempos de construcción, despliegue y consumo de recursos, mientras que las vulnerabilidades en las imágenes pueden exponer tu aplicación a riesgos de seguridad.

Optimizar tus imágenes Docker te permite:

Mejorar los tiempos de construcción y despliegue: Imágenes más pequeñas se construyen y despliegan más rápido.
Reducir costos de almacenamiento y transferencia: Imágenes más ligeras ocupan menos espacio y se transfieren más rápido.
Mejorar la seguridad: Reducir vulnerabilidades y riesgos de seguridad en tus imágenes.

⚙️ Principales estrategias de optimización

1. Multi-stage builds

Las multi-stage builds te permiten dividir la construcción de tu imagen en múltiples etapas, lo que te permite compilar y empaquetar tu aplicación en una etapa y copiar solo los artefactos necesarios a una imagen final más pequeña.

Beneficios:

Imágenes más pequeñas: La imagen final, basada en una imagen más ligera, solo contiene los artefactos necesarios.
Reduce la superficie de ataque: Las etapas de construcción no se incluyen en la imagen final.

2. Elegir imágenes base ligeras

Usar imágenes base ligeras y especializadas, como Alpine Linux, Slim o Buster, en lugar de imágenes genéricas como Ubuntu o Debian, puede reducir significativamente el tamaño de tus imágenes.

Beneficios:

Imágenes más pequeñas: Las imágenes base ligeras tienen un tamaño reducido.
Menos vulnerabilidades: Menos paquetes y dependencias significan menos vulnerabilidades potenciales.

3. Usar un usuario no-root

Ejecutar contenedores con un usuario no-root (sin privilegios) mejora la seguridad de tus aplicaciones, ya que limita los daños potenciales en caso de una vulnerabilidad o ataque.

Beneficios:

Mejora la seguridad: Limita los daños potenciales en caso de una vulnerabilidad o ataque.
Cumplimiento de estándares de seguridad: Algunas regulaciones y estándares de seguridad requieren ejecutar aplicaciones con usuarios no-root.

4. Excluir archivos innecesarios

Usar .dockerignore para excluir archivos y directorios innecesarios de tus imágenes Docker puede reducir significativamente el tamaño de tus imágenes y mejorar los tiempos de construcción.

Beneficios:

Imágenes más pequeñas: Menos archivos y directorios innecesarios.
Mejora los tiempos de construcción: Menos archivos a copiar y procesar.

5. Optimizar capas de imagen

Reducir el número de capas de imagen y combinar instrucciones en una sola capa puede mejorar el rendimiento y la eficiencia de tus imágenes Docker.

Beneficios:

Mejora el rendimiento: Menos capas significa menos operaciones de lectura/escritura.
Reduce el tamaño de la imagen: Menos capas y posibilidad de eliminar archivos temporales en la misma capa donde se crean.

6. Escaneo de vulnerabilidades

Utilizar herramientas de escaneo de vulnerabilidades, como Trivy, te permite identificar y corregir vulnerabilidades en tus imágenes Docker antes de desplegarlas en producción.

Beneficios:

Mejora la seguridad: Identifica y corrige vulnerabilidades antes de desplegar tus imágenes.
Protege tu aplicación: Reduce el riesgo de ataques y brechas de seguridad.

🚀 Resultados de la optimización

Al aplicar estas estrategias de optimización, puedes obtener los siguientes resultados:

Imágenes más pequeñas: Reducción significativa del tamaño de las imágenes Docker, en este caso, de 1.12 GB a 159 MB.
Mejora de los tiempos de construcción: Reducción en los tiempos de construcción, en este caso, 60% más rápido.
Mejora de la seguridad: Reducción de vulnerabilidades y riesgos de seguridad en las imágenes, en este caso, 0 vulnerabilidades.
Mejora de la eficiencia: Reducción de costos de transferencia, en este caso, 85% menos de datos transferidos.
Cumplimiento de estándares de seguridad: Ejecución de contenedores con un usuario no-root para mejorar la seguridad.

📂 Repositorio del proyecto

Para ver un ejemplo práctico de cómo aplicar estas estrategias de optimización, puedes clonar o explorar el repositorio asociado.

Repositorio: https://github.com/israoo/docker-image-optimization

Este repositorio contiene:

Un ejemplo de Dockerfile con las mejores prácticas de optimización.
Un archivo .dockerignore para excluir archivos innecesarios.
Un script para escanear vulnerabilidades en la imagen Docker con Trivy.
Instrucciones detalladas en el archivo README.md sobre cómo construir, optimizar y escanear la imagen Docker paso a paso.

🔗 Referencias/Extras

🚀 ¿Qué sigue?

Prueba estas técnicas en tus proyectos y comparte los resultados. ¿Conoces otras estrategias para optimizar imágenes Docker? ¡Déjalas en los comentarios!

Helm vs Kustomize: ¿Cuál es mejor para gestionar manifiestos en Kubernetes?

Israel Oña Ordoñez 🚀 — Mon, 20 Jan 2025 15:37:41 +0000

📝 TL;DR

Helm y Kustomize son herramientas esenciales para gestionar manifiestos en Kubernetes. Helm es ideal para empaquetar y compartir configuraciones reutilizables, mientras que Kustomize sobresale en la personalización y simplicidad. Este artículo te ayudará a decidir cuál usar en tu próximo proyecto.

🌟 El reto de gestionar manifiestos en Kubernetes

Gestionar despliegues en Kubernetes puede ser un desafío, especialmente cuando se trata de mantener y personalizar múltiples manifiestos YAML. Helm y Kustomize son dos herramientas populares que facilitan la gestión de configuraciones y despliegues en Kubernetes.

🌍 Visión general

Helm

Helm es un gestor de paquetes para Kubernetes que permite empaquetar, compartir y desplegar aplicaciones.

Características principales
- Usa plantillas Go para generar manifiestos YAML.
- Soporte para repositorios públicos y privados.
- Gestión de versiones y actualizaciones.
Ventajas
- Facilita la reutilización de configuraciones.
- Permite compartir y distribuir aplicaciones.
- Amplia comunidad y soporte.
Desventajas
- Curva de aprendizaje para manejar plantillas.
- Complejidad en personalizaciones avanzadas.

Para usar helm, se debe instalar el cliente de helm en tu máquina local. Para instalar helm, puedes seguir las instrucciones en la documentación oficial de Helm.

Los comandos básicos de helm son:

helm create <nombre>: Crea un nuevo chart.
helm install <nombre> <ruta>: Instala un chart.
helm upgrade <nombre> <ruta>: Actualiza un chart.
helm uninstall <nombre>: Desinstala un chart.
helm list: Lista los charts instalados.
helm rollback <nombre> <versión>: Revierte a una versión anterior.
helm template <nombre> <ruta>: Genera los manifiestos YAML.
helm package <ruta>: Empaqueta un chart en un archivo .tgz.
helm repo add <nombre> <url>: Añade un repositorio.
helm repo update: Actualiza los repositorios.
helm lint <ruta>: Verifica la sintaxis del chart.

Kustomize

Kustomize es una herramienta nativa de Kubernetes que permite personalizar y gestionar manifiestos YAML sin plantillas.

Características principales
- Usa overlays o patches para modificar manifiestos.
- Integración nativa con kubectl.
- No requiere plantillas adicionales.
Ventajas
- Simplifica la personalización de manifiestos.
- Fácil integración con flujos de CI/CD.
- Soporte nativo en Kubernetes.
Desventajas
- No incluye gestión de versiones ni repositorios centralizados.
- Limitado en la reutilización de configuraciones.

Para usar kustomize, se debe instalar el cliente de kubectl en tu máquina local. Para instalar kubectl, puedes seguir las instrucciones en la documentación oficial de Kubernetes.

Los comandos básicos de kustomize son:

kubectl apply -k <ruta>: Aplica los manifiestos personalizados.
kubectl diff -k <ruta>: Muestra las diferencias antes de aplicar.
kubectl kustomize <ruta>: Genera los manifiestos personalizados.
kubectl delete -k <ruta>: Elimina los recursos creados.
kubectl get -k <ruta>: Muestra los recursos creados.
kubectl describe -k <ruta>: Muestra detalles de los recursos creados.

💡 Comparación

Característica	Helm	Kustomize
Propósito	Empaquetar y compartir configuraciones	Personalizar y gestionar manifiestos
Reutilización	Alta, mediante charts reutilizables	Baja, requiere configuraciones específicas
Simplicidad	Complejo para personalizaciones avanzadas	Sencillo y directo en YAML
Gestión de versiones	Incluye historial y rollback	No incluye, depende de `git` o `kubectl`
Comunidad	Amplia y activa	Limitada, pero integrada en Kubernetes
Flexibilidad	Menos flexible en personalizaciones	Más flexible y modular

🤔 ¿Cuál elegir?

La elección entre Helm y Kustomize depende de tus necesidades y preferencias. Aquí algunas consideraciones:

Usa Helm si:
- Necesitas empaquetar y compartir configuraciones.
- Deseas gestionar versiones y actualizaciones.
- Prefieres plantillas Go para generar manifiestos.
Usa Kustomize si:
- Buscas personalizar manifiestos sin plantillas.
- Quieres una integración nativa con kubectl.
- Prefieres simplicidad y flexibilidad en YAML.

📂 Repositorio del proyecto

Para explorar los ejemplos de Helm y Kustomize, puedes clonar o explorar el repositorio asociado.

Repositorio: https://github.com/israoo/helm-vs-kustomize

Este repositorio contiene:

Ejemplos de configuraciones en Helm y Kustomize.
Scripts para probar y comparar ambas herramientas.
Instrucciones detalladas en el archivo README.md sobre cómo usar el repositorio.

🔗 Referencias/Extras

🚀 ¿Qué sigue?

¿Prefieres Helm o Kustomize para gestionar tus despliegues? ¡Comparte tu experiencia y cuéntanos qué herramienta prefieres en los comentarios!

5 errores comunes en Kubernetes y cómo solucionarlos rápidamente

Israel Oña Ordoñez 🚀 — Mon, 13 Jan 2025 15:57:04 +0000

📝 TL;DR

Desplegar aplicaciones en Kubernetes puede ser complicado al inicio debido a errores como imágenes no disponibles, configuraciones YAML incorrectas o recursos insuficientes. Aquí descubrirás los 5 errores más comunes al trabajar con Kubernetes y aprenderás a solucionarlos de manera rápida y efectiva.

🌟 El desafío de evitar errores en Kubernetes

Trabajar con Kubernetes, especialmente al inicio, puede ser una experiencia desafiante. Muchas veces, pequeños errores de configuración pueden causar grandes problemas al desplegar pods. Este artículo aborda 5 de los errores más comunes que podrías enfrentar y ofrece soluciones rápidas para ayudarte a dominar Kubernetes sin frustraciones.

🔥 Errores comunes y soluciones

1. Imagen de contenedor no disponible

Indicador

El pod entra en estado ErrImagePull o ImagePullBackOff.

Causa más común

La imagen no existe o no es accesible desde el registro.
Errores en el nombre, etiqueta o versión de la imagen.

Solución

Verifica que la imagen exista y sea accesible:
```
docker pull registry.example.com/image:tag
```

Verifica el nombre y la etiqueta de la imagen en el archivo YAML del pod.

spec:
  containers:
    - name: my-container
      image: registry.example.com/image:tag

Si es un registro privado, configura las credenciales:

kubectl create secret docker-registry my-registry-secret \
  --docker-server=registry.example.com \
  --docker-username=my-user \
  --docker-password=my-password

Agrega las credenciales al archivo YAML del pod:

spec:
  imagePullSecrets:
    - name: my-registry-secret
  containers:
    - name: my-container
      image: registry.example.com/image:tag

2. Etiquetas y selectores incorrectos

Indicador

Un Service no puede encontrar los pods.

Causa más común

Las etiquetas de los pods no coinciden con los selectores del Service.

Solución

Verifica que las etiquetas de los pods coincidan con los selectores del Service.

Etiquetas del pod:
```
metadata:
  labels:
    app: my-app
```
Selectores del Service:
```
spec:
  selector:
    matchLabels:
      app: my-app
```
Inspecciona el estado del recurso:
```
kubectl describe service my-service
```

3. Recursos insuficientes

Indicador

El pod permanece en estado Pending o CrashLoopBackOff.

Causa más común

No hay suficientes recursos (CPU, memoria) disponibles en el clúster.
Los límites de recursos son demasiado bajos.

Solución

Verifica los eventos del pod para encontrar la causa:
```
kubectl describe pod my-pod
```

Aumenta los recursos en el archivo YAML del pod:

spec:
  containers:
    - name: my-container
      resources:
        requests:
          memory: "64Mi"
          cpu: "250m"
        limits:
          memory: "128Mi"
          cpu: "500m"

Confirma que haya nodos disponibles en el clúster:
```
kubectl get nodes
```

4. Configuración YAML incorrecta

Indicador

El pod no se crea debido a errores de sintaxis en el archivo YAML.

Causa más común

Errores de sintaxis, sangría o formato en el archivo YAML.

Solución

Verifica la sintaxis del archivo YAML antes de aplicarlo:
```
kubectl apply -f my-pod.yaml --dry-run=client
```
Usa herramientas de validación de YAML para encontrar errores:
```
yamllint my-pod.yaml
```
Instalar yamllint https://yamllint.readthedocs.io/en/stable/quickstart.html#installing-yamllint
Usa kubectl explain para entender la estructura de los recursos:
```
kubectl explain pod.spec
```

5. Variables de entorno incorrectas

Indicador

El pod falla con errores relacionados con variables de entorno incorrectas o faltantes.

Causa más común

Variables de entorno no definidas o con valores incorrectos.

Solución

Verifica que las variables de entorno estén definidas en el archivo YAML del pod:

spec:
  containers:
    - name: my-container
      env:
        - name: MY_VAR
          value: my-value

Si usas ConfigMaps o Secrets, asegúrate de que estén montados correctamente:

spec:
  containers:
    - name: my-container
      envFrom:
        - configMapRef:
            name: my-configmap
        - secretRef:
            name: my-secret

📂 Repositorio del proyecto

Para practicar y aprender más sobre estos errores comunes, puedes clonar o explorar el repositorio asociado.

Repositorio: https://github.com/israoo/k8s-common-errors

Este repositorio contiene:

Ejemplos de manifiestos YAML con errores comunes.
Scripts de ayuda para verificar y solucionar los errores.
Instrucciones detalladas en el archivo README.md sobre cómo usar el repositorio.

🔗 Referencias/Extras

🚀 ¿Qué sigue?

¿Quieres aprender más sobre solución de problemas en Kubernetes? Comenta tus dudas o comparte problemas que te gustaría resolver en futuros artículos.

Domina Bash con ejemplos prácticos de Git

Israel Oña Ordoñez 🚀 — Wed, 08 Jan 2025 03:12:30 +0000

📝 TL;DR

Bash es un lenguaje de scripting utilizado en sistemas tipo Unix para automatizar tareas. Aprende a usarlo mientras automatizas operaciones de Git con un script que te permitirá realizar commits, push, cambiar de ramas y más, ahorrando tiempo y esfuerzo en tu flujo de trabajo diario.

🤔 ¿Por qué aprender Bash?

Bash es un lenguaje de scripting utilizado en sistemas tipo Unix para automatizar tareas. Su capacidad para ejecutar comandos del sistema y manipular archivos de forma sencilla lo convierte en una herramienta esencial para optimizar operaciones diarias.

Como caso práctico aprenderás a automatizar operaciones rutinarias de Git con Bash, como realizar commits, push, cambiar de ramas y más, mostrando cómo puedes ahorrar tiempo y esfuerzo en tu flujo de trabajo diario.

🔑 Conceptos básicos de Bash

Shebang (#!/bin/bash): Indica que el archivo debe ser ejecutado con Bash.

Variables: Almacenan valores y se acceden con $.

VARIABLE="Hello World"
echo $VARIABLE

Funciones: Bloques de código reutilizables.

function greeting() {
  echo "Hi!"
}

greeting

Condicionales (if, else): Ejecutan comandos basados en condiciones.

if [ "$USER" == "root" ]; then
  echo "You are root"
else
  echo "You are not root"
fi

Bucles (for, while): Repiten comandos hasta que se cumpla una condición.

for i in {1..5}; do
  echo "Number: $i"
done

while [ $i -le 5 ]; do
  echo "Number: $i"
  ((i++))
done

⚙️ Git Helper Script

Script: git-helper.sh

#!/bin/bash

show_menu() {
  echo "==================================="
  echo "          Git Helper Script        "
  echo "==================================="
  echo "1) Perform git pull"
  echo "2) Create a new branch"
  echo "3) Switch to an existing branch"
  echo "4) Add files and commit"
  echo "5) Show repository status (git status)"
  echo "6) Push to the current branch"
  echo "7) Show commit history (git log)"
  echo "8) Exit"
  echo "==================================="
}

git_pull() {
  echo "Performing git pull..."
  git pull
}

create_branch() {
  read -p "Enter the name of the new branch: " branch_name
  if git branch --list | grep -q "$branch_name"; then
    echo "Error: The branch '$branch_name' already exists."
    return
  fi

  echo "Creating and switching to branch $branch_name..."
  git checkout -b "$branch_name"
}

switch_branch() {
  branches=$(git branch)
  if [ -z "$branches" ]; then
    echo "No branches available in this repository."
    return
  fi

  echo "Available branches:"
  echo "$branches"

  read -p "Enter the name of the branch you want to switch to: " branch_name
  if ! git branch --list | grep -q "$branch_name"; then
    echo "Error: The branch '$branch_name' does not exist."
    return
  fi

  echo "Switching to branch $branch_name..."
  git checkout "$branch_name"
}

git_commit() {
  while true; do
    git status

    read -p "Which files do you want to add? (use . for all or 'exit' to cancel): " files
    if [[ "$files" == "exit" ]]; then
      echo "Operation canceled."
      return
    fi

    git add "$files"

    read -p "Enter the commit message: " commit_message
    git commit -m "$commit_message"
    echo "Commit completed."
    break
  done
}

git_status() {
  echo "Showing repository status..."
  git status
}

git_push() {
  echo "Pushing to branch $branch..."
  git push origin "$branch"
}

git_log() {
  echo "Recent commit history:"
  git log --oneline --graph --decorate -10
}

check_git_repo() {
  if [ ! -d .git ]; then
    echo "Error: This does not appear to be a Git repository."
    exit 1
  fi
}

main() {
  check_git_repo

  while true; do
    show_menu
    read -p "Select an option: " choice
    case $choice in
      1) git_pull ;;
      2) create_branch ;;
      3) switch_branch ;;
      4) git_commit ;;
      5) git_status ;;
      6) git_push ;;
      7) git_log ;;
      8) echo "Exiting..."; exit 0 ;;
      *)
        echo "Invalid option. Please try again."
        continue
        ;;
    esac
    break
  done
}

main

Resultado:

Ejecución:

Guarda el script como git-helper.sh y hazlo ejecutable:
```
chmod +x git-helper.sh
```
(Opcional) Colócalo en un directorio que esté en tu PATH (por ejemplo, /usr/local/bin) para usarlo globalmente:
```
mv git-helper.sh /usr/local/bin/git-helper
```
Ejecútalo:
```
git-helper
```

🛠️ Paso a paso

Paso 1: Crear un menú principal

El primer paso es crear un menú principal con las opciones disponibles.

show_menu() {
  echo "==================================="
  echo "          Git Helper Script        "
  echo "==================================="
  echo "1) Perform git pull"
  echo "2) Create a new branch"
  echo "3) Switch to an existing branch"
  echo "4) Add files and commit"
  echo "5) Show repository status (git status)"
  echo "6) Push to the current branch"
  echo "7) Show commit history (git log)"
  echo "8) Exit"
  echo "==================================="
}

Explicación:

Utilizamos echo para mostrar mensajes en la consola.
El menú se muestra con las opciones disponibles.

Paso 2: Validar si es un repositorio Git

Antes de realizar cualquier operación de Git, es importante verificar si el directorio actual es un repositorio Git.

check_git_repo() {
  if [ ! -d .git ]; then
    echo "Error: This does not appear to be a Git repository."
    exit 1
  fi
}

Explicación:

Verificamos con -d .git si existe un directorio .git en el directorio actual.
Si no es un repositorio Git, mostramos un mensaje de error y salimos del script con exit 1 (código de error).

Paso 3: Crear funciones para las operaciones de Git

Cada función realiza una operación específica de Git. A continuación, se muestran algunas de las funciones disponibles:

Crear una nueva rama

create_branch() {
  read -p "Enter the name of the new branch: " branch_name
  if git branch --list | grep -q "$branch_name"; then
    echo "Error: The branch '$branch_name' already exists."
  fi

  echo "Creating and switching to branch $branch_name..."
  git checkout -b "$branch_name"
}

Explicación:

Con read -p leemos la entrada del usuario para el nombre de la nueva rama y almacenamos el valor en branch_name.
Usamos git branch --list para listar las ramas existentes y grep -q para buscar si la rama almacenada en branch_name existe en la lista.
- Si la rama ya existe, mostramos un mensaje de error y salimos de la función.
Si la rama no existe, creamos y cambiamos a la nueva rama con git checkout -b.

Cambiar a una rama existente

switch_branch() {
  branches=$(git branch)
  if [ -z "$branches" ]; then
    echo "No branches available in this repository."
    return
  fi

  echo "Available branches:"
  echo "$branches"

  read -p "Enter the name of the branch you want to switch to: " branch_name
  if ! git branch --list | grep -q "$branch_name"; then
    echo "Error: The branch '$branch_name' does not exist."
    return
  fi

  echo "Switching to branch $branch_name..."
  git checkout "$branch_name"
}

Explicación:

Almacena las ramas existentes en la variable branches.
Con -z verificamos si la variable branches está vacía.
- Si no hay ramas disponibles, mostramos un mensaje y salimos de la función.
Mostramos las ramas disponibles y leemos la entrada del usuario para la rama a la que desea cambiar.
Usamos git branch --list y grep -q para verificar si la rama existe.
- Si la rama no existe, mostramos un mensaje de error y salimos de la función.
Cambiamos a la rama seleccionada con git checkout.

📂 Repositorio del proyecto

Para seguir este ejemplo de automatización de operaciones de Git con Bash, puedes clonar o explorar el repositorio asociado.

Repositorio: https://github.com/israoo/git-helper-bash

Este repositorio contiene:

Script git-helper.sh con las funciones para automatizar operaciones de Git.
Instrucciones detalladas en el archivo README.md sobre cómo configurar y ejecutar el script paso a paso.

🔗 Referencias/Extras

🚀 ¿Qué sigue?

¿Ya estás usando git tags o submódulos? Agrega estas funcionalidades a tu script para mejorar aún más tu flujo de trabajo con Git. ¡Coméntalo y comparte tus ideas!

¿Qué es CI/CD y cómo puede acelerar tus despliegues en minutos?

Israel Oña Ordoñez 🚀 — Fri, 03 Jan 2025 04:04:47 +0000

📝 TL;DR

CI/CD (integración continua y despliegue continuo) automatiza el proceso de integración del código, pruebas y despliegue. Gracias a CI/CD reduces errores humanos, aumentas la velocidad de entrega y aseguras una mayor calidad del software. En este artículo verás qué es, cómo funciona y un ejemplo para llevar a cabo.

🤔 ¿Qué es CI/CD?

CI/CD se refiere a Integración Continua (CI) y Despliegue Continuo (CD). Es un elemento imprescindible en las prácticas de DevOps que permite acelerar el ciclo de vida de desarrollo del software.

Integración Continua (CI): En el momento en que un programador sube un commit al repositorio central, se combina este código nuevo para probar sus cambios, si alguna prueba falla se obtiene una alerta temprana.
Despliegue Continuo (CD): Automatiza el proceso de despliegue de una aplicación en un entorno de pruebas o producción de forma rápida.

🔧 Ejemplo: Pipeline con GitHub Actions

Objetivo: Configurar un pipeline de CI/CD que:

Construya y pruebe tu aplicación automáticamente.
Despliegue los archivos estáticos en GitHub Pages.

Flujo del pipeline:

Archivo YAML: .github/workflows/cicd.yml

name: CI/CD demo

on:
  push:
    branches:
      - master

jobs:
  build:
    runs-on: ubuntu-24.04
    permissions:
      id-token: write

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Configure Node.js
        uses: actions/setup-node@v4
        with:
          node-version: "18"

      - name: Install dependencies
        run: npm install

      - name: Run tests
        run: npm test

      - name: Build
        run: npm run build

      - name: Upload static files as artifact
        uses: actions/upload-pages-artifact@v3
        with:
          name: github-pages
          path: ./dist

  deploy:
    runs-on: ubuntu-24.04
    needs: build
    environment:
      name: github-pages
      url: ${{ steps.deployment.outputs.page_url }}
    permissions:
      id-token: write
      pages: write
    steps:
      - name: Deploy to GitHub Pages
        id: deployment
        uses: actions/deploy-pages@v4
        with:
          artifact_name: github-pages

Ejecución del pipeline:

Explicación:

Build:
- Checkout: Descarga el código del repositorio.
- Configure Node.js: Configura Node.js v18.
- Install dependencies: Instala dependencias con npm install.
- Run tests: Corre los tests con npm test.
- Build: Genera los archivos estáticos con npm run build.
- Upload static files as artifact: Sube los archivos generados en ./dist como artefacto estático.
Deploy:
- Deploy to GitHub Pages: Utiliza los artefactos generados para desplegar automáticamente en GitHub Pages.

📂 Repositorio del proyecto

Para seguir este ejemplo de CI/CD con GitHub Actions, puedes clonar o explorar el repositorio asociado.

Repositorio: https://github.com/israoo/basic-ci-cd-github-actions

Este repositorio contiene:

Código fuente de la aplicación de ejemplo.
Archivo de configuración del pipeline (cicd.yml).
Instrucciones detalladas en el archivo README.md sobre cómo configurar y ejecutar el pipeline paso a paso.

📈 Beneficios clave del CI/CD

Despliegues más rápidos y frecuentes: Reduces el tiempo entre desarrollo y entrega.
Detección temprana de errores: Las pruebas automáticas alertan sobre problemas antes de llegar a producción.
Reducción de errores manuales: Todo el proceso está automatizado.
Mayor confianza y calidad: Cada cambio pasa por pruebas antes de ser desplegado.

En pocas palabras: Menos dolores de cabeza y más despliegues.

💡 Comparación: CI/CD vs. Flujos de trabajo tradicionales

Aspecto	Flujo tradicional	CI/CD
Integración de código	Manual y ocasional	Continua y automática
Pruebas	Ejecutadas manualmente	Automatizadas en cada cambio
Despliegue	Proceso manual y propenso a errores	Automatizado y confiable
Frecuencia de entregas	Poco frecuente (semanas/meses)	Frecuente (diario o incluso por hora)

🔗 Referencias/Extras

🚀 ¿Qué sigue?

¿Te gustaría ver un pipeline CI/CD más avanzado o con despliegue a otra plataforma? ¡Dímelo en los comentarios!