En este artículo, exploraremos las mejores prácticas para implementar IaC con Pulumi, con ejemplos prácticos en GCP, AWS y DigitalOcean, estrategias avanzadas para Kubernetes y consideraciones clave en Disaster Recovery Planning (DRP).

1. ¿Por qué Pulumi para IaC?

Pulumi ofrece ventajas únicas frente a alternativas como Terraform o CloudFormation:

✅ Lenguajes familiares (Python, TypeScript, Go) en lugar de DSLs propietarios.
✅ Soporte multi-cloud (AWS, GCP, Azure, DigitalOcean, Kubernetes).
✅ Estado de infraestructura gestionado (Pulumi Service, S3, etc.).
✅ Integración con CI/CD nativa.
✅ Reutilización de código mediante componentes y librerías.

Ejemplo: Desplegando un cluster Kubernetes en DigitalOcean con Pulumi (Python)

import pulumi
import pulumi_digitalocean as do
# Crear un cluster Kubernetes en DigitalOcean
cluster = do.KubernetesCluster(
    "saas-cluster",
    region="nyc1",
    version="1.25.4-do.0",
    node_pool={
        "name": "default-pool",
        "size": "s-2vcpu-4gb",
        "node_count": 3,
    }
)
# Exportar el kubeconfig
pulumi.export("kubeconfig", cluster.kube_configs[0].raw_config)

Este código despliega un cluster gestionado en DigitalOcean con tres nodos, listo para integrarse en un pipeline de CI/CD.

2. Mejores Prácticas para IaC con Pulumi

🔹 Modularización y Reutilización

Evitar scripts monolíticos. En su lugar, estructurar el código en componentes reutilizables:

# Ejemplo: Módulo para un bucket S3 con políticas de acceso
class SecureBucket(pulumi.ComponentResource):
    def __init__(self, name, **kwargs):
        super().__init__("custom:SecureBucket", name, **kwargs)
        
        self.bucket = aws.s3.Bucket(name)
        aws.s3.BucketPolicy(
            f"{name}-policy",
            bucket=self.bucket.id,
            policy=json.dumps({
                "Version": "2012-10-17",
                "Statement": [{
                    "Effect": "Deny",
                    "Principal": "*",
                    "Action": "s3:*",
                    "Resource": [self.bucket.arn, f"{self.bucket.arn}/*"],
                    "Condition": {"Bool": {"aws:SecureTransport": False}}
                }]
            })
        )
# Uso del módulo
bucket = SecureBucket("prod-data-lake")

🔹 Gestión de Estado (State Management)

Pulumi guarda el estado de la infraestructura. Opciones recomendadas:

• Pulumi Service (gratis para proyectos pequeños).

• Amazon S3 / Google Cloud Storage (para mayor control).

# Inicializar un proyecto con backend en S3
pulumi login s3://my-pulumi-state-bucket

🔹 CI/CD Integrado

Ejemplo con GitHub Actions:

name: Deploy Infrastructure
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - uses: pulumi/actions@v3
        with:
          command: up
          stack-name: prod
        env:
          PULUMI_ACCESS_TOKEN: ${{ secrets.PULUMI_ACCESS_TOKEN }}

3. Kubernetes con Pulumi: Gestión Eficiente

Pulumi permite gestionar Kubernetes de forma declarativa sin necesidad de kubectl manual.

Ejemplo: Despliegue de una App en Kubernetes

import pulumi_kubernetes as k8s
# Crear un Namespace
app_ns = k8s.core.v1.Namespace("app-ns")
# Desplegar una aplicación
app = k8s.apps.v1.Deployment(
    "app-deployment",
    metadata={"namespace": app_ns.metadata["name"]},
    spec={
        "replicas": 3,
        "selector": {"match_labels": {"app": "my-saas"}},
        "template": {
            "metadata": {"labels": {"app": "my-saas"}},
            "spec": {
                "containers": [{
                    "name": "app",
                    "image": "my-registry/my-saas-app:latest",
                    "ports": [{"container_port": 8080}]
                }]
            }
        }
    }
)
# Exponer el servicio
service = k8s.core.v1.Service(
    "app-service",
    metadata={"namespace": app_ns.metadata["name"]},
    spec={
        "selector": {"app": "my-saas"},
        "ports": [{"port": 80, "target_port": 8080}],
        "type": "LoadBalancer"
    }
)
pulumi.export("service_url", service.status["load_balancer"]["ingress"][0]["hostname"])

4. Disaster Recovery Planning (DRP) con Pulumi

Un buen DRP define RTO (Recovery Time Objective) y RPO (Recovery Point Objective).

Visualización de RTO/RPO

(Imagen conceptual: Tabla comparando estrategias de backup y replicación)

Ejemplo: Configuración de DRP en AWS

import pulumi_aws as aws
# Replicación de buckets S3 entre regiones
primary_bucket = aws.s3.Bucket("primary-bucket", acl="private")
replica_bucket = aws.s3.Bucket("replica-bucket", acl="private")
aws.s3.BucketReplication(
    "replication",
    bucket=primary_bucket.id,
    role=replication_role.arn,
    rules=[{
        "status": "Enabled",
        "destination": {
            "bucket": replica_bucket.arn,
            "storage_class": "STANDARD"
        }
    }]
)

5. Conclusión

Pulumi es una herramienta poderosa para automatizar infraestructura cloud con código real, mejorando la productividad de equipos DevOps y startups SaaS.

🔹 Mejores prácticas clave:

• Modularizar el código IaC.

• Gestionar el estado de forma segura.

• Integrar con CI/CD.

• Planificar Disaster Recovery (RTO/RPO).

¿Listo para probar Pulumi? Comienza con su documentación oficial.

📢 ¿Quieres más detalles sobre algún tema? ¡Contactame!

#DevOps #InfrastructureAsCode #Pulumi #Kubernetes #CloudComputing #SaaS #DisasterRecovery

En el mundo del desarrollo de software, la implementación de una pipeline de CI/CD robusta y eficiente es fundamental para mantener la agilidad y calidad del producto. Como desarrollador, me he enfrentado al reto de automatizar el despliegue de artefactos Java en múltiples entornos. En este artículo, compartiré mi experiencia implementando pipelines con Google Cloud Build, scripts Bash y el repositorio de artefactos Archiva para gestionar despliegues en máquinas virtuales.

El problema inicial

Antes de implementar nuestra solución automatizada, nos enfrentábamos a varios desafíos:

• Despliegues manuales propensos a errores
• Falta de consistencia entre entornos
• Tiempos de entrega prolongados
• Dificultad para rastrear qué versión estaba desplegada en cada entorno
• Complejidad para gestionar dependencias y artefactos Java

Necesitábamos una solución que pudiera gestionar el ciclo completo: desde la compilación del código fuente hasta el despliegue en nuestras máquinas virtuales, manteniendo un registro central de los artefactos generados.

Componentes de la solución

Google Cloud Build

Elegimos Cloud Build como el motor principal de nuestra pipeline de CI/CD por varias razones:

• Integración nativa con Google Cloud Platform
• Escalabilidad automática según las necesidades
• Facilidad para definir pasos de construcción mediante archivos YAML
• Capacidad para utilizar imágenes Docker personalizadas
• API robusta para la integración con otros servicios

SonarQube

Implementamos SonarQube como parte esencial de nuestra pipeline para garantizar la calidad del código:

• Análisis estático para detectar bugs y vulnerabilidades
• Medición de cobertura de pruebas
• Evaluación continua de la deuda técnica
• Verificación del cumplimiento de estándares de codificación
• Integración perfecta con el flujo de CI/CD

Apache Archiva

Para la gestión de artefactos, implementamos Apache Archiva, un repositorio de artefactos que nos permitió:

• Almacenar y versionar nuestros JAR, WAR y otros artefactos Java
• Gestionar dependencias de manera centralizada
• Establecer políticas de retención de artefactos
• Controlar el acceso a los diferentes repositorios
• Rastrear metadatos de los artefactos

Scripts Bash

El pegamento que unía todo nuestro sistema eran los scripts Bash, que nos proporcionaron:

• Flexibilidad para adaptarnos a casos específicos
• Capacidad para interactuar con APIs y servicios externos
• Manejo de errores y reintentos personalizados
• Despliegue en máquinas virtuales mediante SSH

Arquitectura de la pipeline

Nuestra pipeline de CI/CD sigue este proceso:

1. Trigger: Un push a una rama específica o la creación de una tag desencadena la pipeline
2. Build: Cloud Build compila el código Java utilizando Maven o Gradle
3. Test: Se ejecutan pruebas unitarias e integración
4. Análisis de calidad: SonarQube realiza un análisis estático y evaluación de calidad del código
5. Empaquetado: Se generan los artefactos (JAR, WAR)
6. Publicación: Los artefactos se suben a Apache Archiva
7. Despliegue: Scripts Bash se conectan por SSH a las VMs y despliegan los artefactos

Implementación estratégica

La implementación de nuestra pipeline requirió un enfoque meticuloso para integrar correctamente todos los componentes. La configuración de Cloud Build con los pasos adecuados fue fundamental, así como la integración de SonarQube para garantizar que solo el código que cumpliera con los estándares de calidad pudiera pasar a producción.

Desarrollamos scripts personalizados para manejar la comunicación entre los diferentes sistemas y establecimos puertas de calidad (quality gates) en cada etapa del proceso. El diseño modular nos permitió tener un sistema fácilmente adaptable a diferentes proyectos y entornos.

La integración entre SonarQube, Archiva y nuestros scripts de despliegue fue uno de los aspectos más desafiantes, pero también uno de los más gratificantes una vez implementado correctamente. Cada componente tenía un papel bien definido en la cadena de CI/CD, lo que permitía identificar rápidamente cualquier problema y solucionarlo sin afectar al resto del sistema.

Configuración de SonarQube

La integración de SonarQube fue crucial para mantener la calidad del código:

1. Establecimos Quality Gates con umbrales estrictos:
   • Cobertura de código mínima del 80%
   • Cero vulnerabilidades críticas
   • Menos de 5% de código duplicado
2. Configuramos reglas personalizadas según los estándares de nuestra organización
3. Implementamos webhooks para notificar al equipo sobre problemas detectados
4. Integramos los resultados del análisis como un paso bloqueante en nuestra pipeline

Configuración de Archiva

Para Archiva, creamos un repositorio interno y configuramos las políticas de seguridad:

1. Creamos usuarios específicos para despliegue con permisos limitados
2. Configuramos la retención de snapshots y releases
3. Establecimos políticas de proxy para dependencias externas
4. Configuramos índices para búsquedas eficientes

Lecciones aprendidas

Durante la implementación de esta solución, aprendí varias lecciones valiosas:

Calidad como prioridad

La integración de SonarQube desde el principio nos ahorró innumerables horas de depuración y problemas en producción:

• El análisis continuo permite detectar problemas temprano en el ciclo de desarrollo
• Los desarrolladores mejoraron sus prácticas al recibir retroalimentación inmediata
• La visualización de métricas de calidad motivó al equipo a mejorar constantemente

Gestión de secretos

Implementamos un sistema robusto para la gestión de credenciales:

• Secretos almacenados en Secret Manager de GCP
• Variables de entorno seguras en Cloud Build
• Cuentas de servicio con privilegios mínimos

Tolerancia a fallos

Los despliegues a veces fallaban por problemas de red o recursos. Mejoramos la resiliencia con:

• Reintentos automáticos con backoff exponencial
• Validaciones de estado tras el despliegue
• Capacidad de rollback automático

Paralelización

Para reducir los tiempos de despliegue en entornos con muchas VMs, implementamos:

• Despliegues paralelos con control de concurrencia
• Caché de artefactos entre pasos de la pipeline
• Optimización de la compilación con compilación incremental

Resultados

La implementación de esta pipeline nos proporcionó beneficios significativos:

• Reducción del tiempo de despliegue: de 45 minutos a menos de 5 minutos
• Eliminación de errores humanos: gracias a la automatización completa
• Mejora en la calidad del código: las métricas de SonarQube mostraron una reducción del 40% en la deuda técnica
• Mayor trazabilidad: registro completo de qué versión está en cada entorno
• Mejora de la colaboración: el equipo puede concentrarse en desarrollo en lugar de operaciones
• Escalabilidad: añadir nuevos entornos o servidores es trivial

Conclusión

La combinación de Cloud Build, SonarQube, scripts Bash y Apache Archiva nos ha permitido crear una solución robusta para el despliegue de aplicaciones Java. Si bien he compartido algunos aspectos de nuestra implementación, las soluciones específicas para cada organización requieren un análisis detallado de su infraestructura, procesos y necesidades particulares.

Esta arquitectura nos permitió no solo automatizar despliegues, sino también elevar significativamente la calidad del software entregado, reduciendo incidentes en producción y acelerando el ciclo de desarrollo.

Para equipos que enfrentan retos similares, recomiendo un enfoque incremental y personalizado. Cada organización tiene necesidades únicas que deben ser cuidadosamente analizadas para implementar la solución óptima.

¿Necesitas implementar una solución similar en tu organización? En webmago.dev ofrecemos consultoría especializada en la implementación de pipelines de CI/CD para entornos Java. Contáctanos para explorar cómo podemos ayudarte a optimizar tus procesos de desarrollo y despliegue.

🔹 El Problema: Procesamiento Seguro de Archivos

Un cliente necesitaba un sistema donde:

1. Al subir un archivo cifrado y comprimido a un bucket de Cloud Storage, se validara su autenticidad mediante una firma compartida entre emisor y receptor.

2. Si el archivo era válido, se descomprimía y se verificaba la integridad de los archivos internos usando SHA-256.

3. Solo los archivos que pasaran todas las validaciones serían procesados.

⚡ La Solución: Automatización con Cloud Functions

1️⃣ Trigger por Eventos de Cloud Storage

Configuré una Cloud Function activada por eventos de Cloud Storage (google.storage.object.finalize), lo que permite ejecutar código cada vez que se sube un archivo.

Validación de Firma Compartida

El archivo ZIP incluía un archivo .signature con una firma generada mediante un secreto compartido. Usé HMAC-SHA256 para asegurar que el archivo no fuera alterado.

import hmac
import hashlib
def validate_signature(secret_key, file_content, received_signature):
    generated_signature = hmac.new(secret_key.encode(), file_content, hashlib.sha256).hexdigest()
    return hmac.compare_digest(generated_signature, received_signature)

3️⃣ Descompresión y Validación SHA-256

Una vez validada la firma, el sistema descomprimía el archivo y verificaba cada archivo interno contra un hash predefinido.

import zipfile
import hashlib
def check_file_hash(file_path, expected_hash):
    with open(file_path, "rb") as f:
        file_data = f.read()
        computed_hash = hashlib.sha256(file_data).hexdigest()
        return computed_hash == expected_hash

4️⃣ Notificación y Manejo de Errores

Si alguna validación fallaba, el sistema enviaba una alerta por Pub/Sub o Correo Electrónico para notificar al administrador.

📊 Resultados

✅ Procesamiento automatizado y seguro sin intervención manual o humana.
✅ Reducción de errores por archivos corruptos o no autorizados.
✅ Escalabilidad gracias a Cloud Functions (pago por uso).

🚀 ¿Necesitas una Solución Similar?

Si buscas automatizar procesos en la nube con GCP, AWS o Azure, puedo ayudarte a diseñar e implementar una solución robusta y segura.

📩 ¡Contáctame y hablemos de tu proyecto!

Usando código en Typescript trabaje en un PoC para vincular 3 Droplets y balancear sus cargas, para ello hice uso de Pulumi para generar la arquitectura en donde un balanceador de carga recibirá las peticiones y las dirigirá hacia los droplets, a su vez un firewall evitara accesos a puertos no solicitados.

En un post previo hable de Pulumi con Digital Ocean, con el que trabaje en un PoC y Kubernetes. Para este PoC me base en este código  al cual le hice algunas adecuaciones para instalar docker y ejecutar el contenedor de Simple Web y validar el balanceo a través de los 3 Droplets creados.

En la primer creación del Load Balancer, el verificador de salud lo habia definido para revisar el protocolo TCP en el puerto 80, esto genero un fallo general debido al uso del contenedor con python, por lo que procedí a ajustarlo para revisar el protocolo HTTP en el codigo de Typescript en lugar de hacerlo en el panel administrativo de Digital Ocean obteniendo así el estado de salud satisfactorio.

Cabe señalar que existen algunos glitches que Pulumi deberá resolver como en el caso de actualizar el Userdata de los Droplets se generan errores en el recurso del Firewall y Load Balancer.

Les dejo a continuación unas capturas del PoC.

Pulumi Stack

DO VPC creado

DO DROPLETS creados

DO LB creado

DO FW creado

Puedes usar una gran variedad de software para llevarlo a cabo, lo que implica en algunos casos aprender un nuevo lenguaje, algo que Pulumi ha tomado en cuenta para su rápida adopción, por lo que si sabes Typescript, Go, Python, Javascript o .Net reducirás enormemente la curvatura de aprendizaje.

Había escuchado de Pulumi hace un año, hace unas semanas tome dos webinars  y las dudas que tenia sobre su uso, escenarios me animo a probarlo con una promo que obtuve en Digital Ocean por lo que inicie con la creación de un cluster Kuberntes usando Typescript. Pulumi te ofrece una version gratuita si únicamente tú usas el entorno.

La ventaja de esto que puedes ir haciéndolo poco a poco y esta es la lista ordenada de lo que fui administrando con mi código.

1. Creación del Cluster Kubernetes.
2. Creación de algunos namespaces, ex: staging, website
3. Creación de un primer Deployment con nginx en el namespace de staging.
4. Creación de un ClusterIP Service para el Deployment creado en el punto 3.
5. Una gran pausa para instalar Istio (muy complicado y tomaría mas horas) o nginx como Ingress
6. Después de decidirme en el punto 5 por nginx, procedí a crear el código para instalarlo como Ingress, con su namespace usando el Helm v3 Chart; esto me genero un LoadBalancer en Digital Ocean a su vez asignándome la IP Publica.
7. Creación de un Service Ingress para dirigir el tráfico del ingress-nginx creado en el punto 6 hacia el ClusterIP creado en el punto 4, puedes verlo en do.webmago.dev (puede no estar disponible en el futuro).

Ejecucion Paso 1 Pulumi

Revision Dashboard Digital Ocean

Dashboard Pulumi paso 1

Cabe señalar que para mantener mi entorno aislado y no interferir con mis configuraciones de mi equipo trabaje desde un contenedor de docker.

Tengo que aclarar que tuve algunos glitches con Pulumi al aplicar/actualizar cambios y al parecer es un comportamiento algo raro que tiene Digital Ocean, por lo que recibía errores y tenia que volver a ejecutar la actualización de cambios.

En mi experiencia, puedo decir que Pulumi reduce considerablemente su curvatura de aprendizaje y adopción permitiéndote administrar tu Infraestructura como Código con los lenguajes antes mencionados.

Para los clusters Kubernetes me auxilio de “Monitoring” (antes Stackdriver) en GCP o CloudWatch en AWS, o incluso Prometheus con Grafana.

Lo que hace de Weavescope un software Open Source tan peculiar no solo es ver métricas, sino pausar, detener, reiniciar un contenedor o acceder a la terminal del mismo para hacer algunas operaciones tal como si fuera una terminal remota.

Esta versatilidad de Weavescope me permite visualizar y hacer operaciones cuando solo cuento con un dispositivo móvil como una tableta o un iPad.

Weavescope ofrece varias alternativas de ser instalado, en mi caso donde uso VPS con docker-compose opte por esta version con algunos ajustes que no se mencionan en la version oficial, tal es el caso de la autenticacion, ya que de no contar con esto cualquiera que conozca la dirección de mi instalacion podria hacer un mal uso como detener o crear contenedores y vulnerar mi sistema.

Weaveworks la compañia creadora de Weavescope ofrece diferentes soluciones de automatizacion CI-CD, monitoreo y registros, una de las herramientas mas novedosas GitOps basado en Kubernetes.

No olvides contactarme si requieres asistencia en tus proyectos.

A continuacion dejo una serie de capturas de una de mis instalaciones de Weavescope.

Filtrando los recursos por contenedor

En la ficha del contenedor se observan varios botones para efectuar operaciones tales como adjuntar, acceder a la terminal, refrescar, pausar, detener el contenedor.

Esta version grafica es un atajo a la instruccion “docker exec -it dbadmin bash”

• Red/Black
• Blue/Green
• Rollout
• Canary

Me he inclinado por usar el segundo de la lista, el deploy Blue/Green, el cual te permite lanzar una nueva versión e ir redirigiendo tráfico de forma gradual a la nueva versión.

Existe una gran variedad de plugins en Codefresh uno de ellos, hacer un Deploy en tu entorno Kubernetes con Blue/Green, incluso hay un plugin y Howto para hacer un Canary Deployment.

Una de las ventajas de este plugin es que en caso de existir algun timeout, o error en el despliegue de la nueva version, la version actual no se ve afectada debido a que la nueva version es eliminada del clúster.

En caso de ser exitoso el despliegue el plugin en automatico inicia el proceso de redireccion del trafico hacia la  nueva version de forma gradual.

La integracion de este plugin en mis pipelines me ha permitido hacer despliegues sin caídas en entornos de producción de alto tráfico.

Code analysis made easy with the Codefresh’s @SonarQube integration — view the analysis report after every build ? https://t.co/lg3VW2hFZO#DevOps #codeanalysis #testing @urlichsanais pic.twitter.com/SkWJab3mKD

— Codefresh (@codefresh) December 2, 2020

Así que me dí a la tarea de integrar el escaneo de código de uno de los proyectos asignados para confirmar la integración sugerida.

El documento en inglés de Codefresh puedes encontrarlo en Continuous Code Analysis with SonarQube and Codefresh, lo revise y por supuesto que tiene algunos detalles por resolver, en este artículo describí que implemente SonarQube para escanear el código de los proyectos que me son asignados y que había implementado un Script en Bash para hacer el escaneo, algo manual por supuesto, por lo que hacer esto en el pipeline dejaría sin efecto a mi Bash Script, algo que ansiaba hacer en el corto plazo.

Por lo que describiré aquí cómo fue que lo implemente.

Creando el proyecto en SonarQube.

Si aún no has instalado SonarQube, te recuerdo que puedes hacerlo usando Docker, mas información en Install the Server.

1. Para evitar “conflictos” y evitar “mirones” genere un nuevo Grupo y le asigne permisos únicamente para que el Administrador o Usuario indicado pueda ver este proyecto.
2. Genere el proyecto siguiendo el asistente de SonarQube y le asigne un Token para que desde Codefresh pueda usarlo.

Creando Proyecto en Sonarqube

Proyecto Creado SonarQube

Integrando el Plugin al Pipeline del proyecto en Codefresh.

Este fue uno de los pasos de mayor atención, ya que mis pipelines toman las configuraciones de un repositorio adicional, por  lo que tuve que adicionar un Plugin solo para copiar el archivo sonar-project.properties en la raíz del proyecto.

Integración Plugin Pipeline Codefresh

La hora de la verdad, ejecutando el pipeline manualmente.

Aquí es donde veremos si realmente funciona la teoría, claro que la ejecución final tuvo como antecesores varias pruebas para darnos cuenta que debido a la configuración que tomamos por separado no obtenía la propiedad sonar.projectKey necesaria para identificar al proyecto en nuestro SonarQube.

En la imagen podemos ver la ejecución exitosa de nuestro pipeline, en el log del paso QUALITY podemos ver el ID de la Tarea (Task) la cual es AXY_dPYDfvCgCTUgh8X4 y debe coincidir con la tarea en el “fondo” (background) en nuestro escritorio, sección de tareas de SonarQube.

Ejecución Pipeline SonarQube Codefresh

Comprando en la cola de SonarQube la tarea de escaneo.

Como lo anticipe en mi retuit, mencionando que usaban SonarCloud y que si exponían su instalación de SonarQube se podría hacer lo mismo que se indica en el Howto.

Así que vayamos a ver el Dashboard de SonarQube, he puesto en rojo el ID de la Tarea (Task) en la imagen para su rápida identificación.

Tareas en Background SonarQube

Efectivamente podemos ver que la tarea del análisis lanzada desde Codefresh se esta ejecutando en mi instancia de SonarQube y al finalizar puedo revisar la calidad del código del proyecto.

Escritorio Proyecto SonarQube

Con esto comprobamos la integración del escaneo de código usando SonarQube lanzado desde un pipeline en Codefresh.

Si necesitas ayuda puedes contactarme en este enlace.

So, Kubernetes is deprecating Docker support and you’re either nervous or confused. That’s okay! I would like to help you understand what’s happening. A thread! 1/10

— Kat Cosgrove, but ✨festive✨ (@Dixie3Flatline) December 2, 2020

Quienes trabajamos con Kubernetes o en Desarrollo de Software hemos usado Docker para desarrollar y generar las imágenes que finalmente usaremos en nuestro clúster, por supuesto que existen mas proveedores compatibles con OCI (Open Container Initiative) y esto quiere decir que las imágenes que generamos en Docker cumplen con esta normativa.

Ayer 3 de Noviembre 2020, Docker publico un articulo (en inglés) detallando quá sucederá con este cambio dándonos una tranquilidad a toda la comunidad que usa la tecnología de contenedores.

What developers need to know about Docker, Docker Engine, and Kubernetes v1.20

En si, lo que se eliminará probablemente en un año será dockershim, por lo tanto, las imágenes que generes con Docker seguirán funcionando en tu clúster Kubernetes, el cambio es mas para los operadores y administradores de Kubernetes donde el acceso a la inspección de los contenedores usando comandos de Docker no podrán ser usados.

Así que mantén la calma y sigue usando Docker.