La etiqueta :latest en Docker: El amigo que te traiciona cuando menos lo esperas

En el mundo de Docker, la etiqueta :latest parece ser el héroe de la película. La forma más rápida y conveniente de obtener la última versión de una imagen, ¿cierto? Es fácil de usar, tentadora e intuitiva.

¿Quién no ha caído en la trampa? Es tan seductora como un amigo que te dice: "¡No te preocupes! Yo te apoyo en todo", solo para luego dejarte en la estacada cuando más lo necesitas.

Aunque la etiqueta :latest puede parecer inofensiva y útil, en realidad es un desastre esperando a suceder. En este artículo, te contaré por qué deberías dejar de usarla y cómo evitar que se convierta en tu peor pesadilla.

---

---

¿Qué es la etiqueta :latest y por qué es peligrosa?

Primero, aclaramos el concepto. La etiqueta :latest no significa "última versión". ¡Sorpresa! En realidad, significa "la imagen que se etiquetó como latest más recientemente". Esto no es lo mismo que tener siempre el código más actualizado, y es aquí donde comienza el lío.

La etiqueta :latest puede ser etiquetada sobre una imagen con código de hace seis meses, o incluso un código con errores. ¿La peor parte? Docker no tiene forma de saber si realmente es la versión más reciente de tu código. Solo se basa en la última imagen que recibió la etiqueta. Así que, si alguien se equivocó y subió una versión errónea, esa será la que se ejecute en producción.

---

Historias de no son on-fire, pero con mucho thriller a lo Michael Jackson con la etiqueta :latest

Para que entiendas mejor el peligro de usar :latest, déjame contarte unas historias de terror sobre cómo esta etiqueta ha arruinado despliegues, ha hecho desaparecer aplicaciones y ha dejado a equipos de desarrollo luchando por encontrar el problema.

1. Kubernetes se vuelve loco

Tu equipo de desarrollo despliega un Helm chart con la imagen roxsross:latest. Todo va bien en staging, pero cuando se lleva a producción, todo explota. Los pods se caen, y tu aplicación no funciona. ¿Por qué?

Porque alguien más subió una versión diferente de roxsross:latest desde su notebook/laptop. Aunque la etiqueta es la misma, el código es diferente. Kubernetes descarga la imagen incorrecta, y el despliegue se arruina. El resultado: la versión que funcionaba en staging ahora no sirve en producción.

2. CI/CD se convierte en un juego de azar

Imagina que tienes una pipeline de GitHub Actions que construye app-roxsops:latest. Las pruebas pasan, todo parece perfecto. Pero horas después, otro pipeline se ejecuta, esperando que :latest sea lo mismo, pero un nuevo commit ha sobrescrito la imagen. Las pruebas fallan y el equipo comienza a buscar errores en el código, pero el problema es mucho más simple: la imagen :latest estaba equivocada.

3. Terraform te apuñala por la espalda

Tienes un entorno de producción en AWS ECS que utiliza la imagen webroxsapp:latest. Todo parece funcionar bien, hasta que un redeploy se ejecuta y ECS toma una nueva versión de :latest. Pero no hay cambios en el código ni en la infraestructura; simplemente es una versión equivocada de la imagen.

Terraform dice que todo está bien, pero la aplicación responde con un error 404. Nadie sabe por qué. La etiqueta :latest ha causado el caos.

4. Rollbacks imposibles

El despliegue con :latest falla. Intentas hacer rollback, pero ahora :latest está apuntando a la versión rota. La versión anterior ya no está disponible. El proceso de rollback se convierte en un juego de adivinanza, buscando imágenes antiguas en los registros. El tiempo de inactividad se extiende y nadie sabe qué hacer.

---

¿Cómo funciona realmente la etiqueta :latest en Docker?

Es crucial entender cómo funciona Docker para ver por qué :latest es tan peligrosa. Aquí te muestro cómo Docker maneja las etiquetas:

Construcción y Etiquetado

Cuando ejecutas un docker build, si no especificas una etiqueta, Docker por defecto le asignará la etiqueta :latest a la imagen.

# Construcción con versión explícita
docker build -t devopsconrox:0.1 .

# Construcción sin etiqueta
docker build -t devopsconrox .

¿Qué sucede? La segunda construcción recibe la etiqueta devopsconrox:latest. Si luego construyes una nueva versión:

docker build -t devopsconrox:0.2 .

¿Crees que :latest se actualizó? ¡No! Sigue apuntando a la construcción anterior. Docker no sabe cuál es la imagen más reciente si no le especificas una etiqueta clara. Es un caos total.

---

¿Cómo evitar los problemas con :latest?

Ahora que sabes lo peligrosa que puede ser la etiqueta :latest, te voy a contar cómo puedes evitar que esta trampa te cause problemas en tu equipo.

1. Usa versiones semánticas o SHAs de commits

La clave es etiquetar las imágenes de manera precisa. Usa versiones semánticas o el SHA de los commits. De esta manera, siempre sabrás qué versión estás utilizando, y no tendrás que depender de la ambigua etiqueta :latest.

docker build -t devopsconrox:1.3.7 -t devopsconrox:commit-b6fa2e1 .
docker push devopsconrox:1.3.7
docker push devopsconrox:commit-b6fa2e1

2. Usa Digests para un control aún más preciso

Los digests son inmutables, lo que significa que la imagen no podrá ser sobrescrita accidentalmente. Usar digests es una forma de asegurarte de que el despliegue sea siempre el correcto.

# Despliegue en Kubernetes con Digest
spec:
  containers:
    - name: devopsconroxapp
      image: devopsconroxapp@sha256:abcdef1234567890abcdef1234567890abcdef1234567890abcdef1234567890

3. Automatiza el etiquetado con tu pipeline CI/CD

Para evitar errores manuales, automatiza el etiquetado dentro de tu pipeline de CI/CD. De esta forma, nunca tendrás que preocuparte de que alguien etiquete mal la imagen.

name: Build and Deploy
on:
  push:
    branches: [ main ]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - name: Build and tag
        run: |
          docker build -t devopsconrox:${{ github.sha }} -t devopsconrox:prod .
          docker push devopsconrox:${{ github.sha }}
          docker push devopsconrox:prod

4. Prohíbe :latest en tu pipeline y en tus registros

Usa herramientas como conftest o kube-linter para detectar el uso de :latest. Además, puedes configurar reglas en tu registro (por ejemplo, AWS ECR) para evitar que se suban imágenes con esta etiqueta.

1. Escanea tu código con conftest o kube-linter

Puedes usar herramientas como conftest o kube-linter para escanear tu código y detectar el uso de :latest. Estas herramientas te permiten asegurarte de que los manifiestos y las configuraciones de Kubernetes no incluyan esta etiqueta problemática.

Aquí tienes un ejemplo de cómo configurar una regla de Open Policy Agent (OPA) para bloquear :latest en los despliegues de Kubernetes:

package kubernetes
deny[msg] {
  input.kind == "Deployment"
  container := input.spec.template.spec.containers[_]
  contains(container.image, ":latest")
  msg := "No :latest allowed!"
}

Con esta regla, cualquier intento de despliegue con una imagen que contenga :latest será rechazado, garantizando que tus aplicaciones solo se desplieguen con versiones explícitas y controladas.

2. Agrega un paso en tu pipeline para rechazar :latest

Una de las formas más efectivas de evitar que :latest se cuele es agregar una verificación en tu pipeline de CI/CD. Con un simple script, puedes detectar la presencia de la etiqueta y fallar el pipeline si aparece.

Este es un ejemplo de un paso en tu pipeline que detecta y rechaza :latest en tus manifiestos y Dockerfiles:

if grep -r ":latest" manifests/ Dockerfile; then
  echo "Error: :latest detected!"
  exit 1
fi

Este comando busca la etiqueta :latest en todos los archivos relevantes de tu proyecto. Si la encuentra, el pipeline se detendrá inmediatamente, evitando que un despliegue potencialmente problemático llegue a producción.

Aquí tienes un ejemplo de cómo configurar una regla en ECR para rechazar la etiqueta :latest:

{
  "rules": [
    {
      "rulePriority": 1,
      "description": "No :latest allowed",
      "selection": {
        "tagStatus": "tagged",
        "tagPrefixList": ["latest"],
        "countType": "imageCountMoreThan",
        "countNumber": 0
      },
      "action": {
        "type": "expire"
      }
    }
  ]
}

---

Buenas prácticas en Docker: Despliegues eficientes y sin sorpresas

Además de evitar el uso de la peligrosa etiqueta :latest, es esencial seguir buenas prácticas en Docker para asegurarte de que tus contenedores sean eficientes, seguros y fáciles de mantener. Docker es una herramienta poderosa, pero su verdadero potencial se alcanza cuando aplicas las mejores prácticas. Aquí te comparto algunas de las principales recomendaciones para construir y gestionar tus imágenes de manera efectiva:

• Usa imágenes base pequeñas y optimizadas: Como las imágenes alpine para reducir el tamaño de las imágenes.

• Minimiza el número de capas en tu Dockerfile combinando las instrucciones en bloques.

• Ordena bien las instrucciones para aprovechar el cache de Docker.

• Usa multi-stage builds para optimizar el tamaño de la imagen.

• Elimina archivos innecesarios en cada etapa de construcción.

• Usa .dockerignore para excluir archivos que no necesitas en el contenedor final.

Para más detalles, puedes revisar la documentación oficial de buenas prácticas de Docker.

---

Conclusión: ¡Evita el thriller de :latest y asegura tus despliegues!

La etiqueta :latest en Docker es como un thriller lleno de suspenso, pero sin la emoción que deseas. Puede parecer una solución rápida y fácil, pero lo único que trae son problemas inesperados, caos en producción y confusión en tu pipeline. Como en cualquier buen thriller, todo parece ir bien hasta que, de repente, todo se viene abajo.

Para evitar que tu historia de despliegue se convierta en una pesadilla, es hora de decirle adiós a :latest. Usa versiones semánticas, digests y automatiza el etiquetado para tener un control total sobre lo que está ocurriendo en tus entornos de desarrollo y producción. Así, en lugar de enfrentarte a un thriller lleno de sorpresas, podrás disfrutar de un despliegue confiable y predecible, donde todo sigue el guion.

Recuerda, no pongas en riesgo tus despliegues por una etiqueta que suena fácil, pero esconde un montón de problemas. La etiqueta :latest es la verdadera estrella del drama, ¡y es hora de que dejes que el thriller termine y comiences una nueva era de despliegues seguros y controlados!

---

Bonus: ¡Y esto no es todo!

Si pensabas que ya habíamos cubierto todo lo importante, te tengo una sorpresa. Este artículo solo ha sido el principio de una serie de posts sobre Docker, DevOps y buenas prácticas que te ayudarán a sobrevivir al fuego.

En la próxima entrada, nos vamos a sumergir en un tema aún más ON FIRE: las historias de terror en contenedores multiarquitectura. ¡Prepárate! Este tema es más intenso que un buen thriller de suspenso. Si pensabas que el uso de :latest era un riesgo, espera a ver lo que puede pasar cuando ejecutas contenedores en diferentes arquitecturas. Vamos a hablar de las sorpresas, los problemas y las soluciones que te ayudarán a navegar sin miedo por el mundo de las multiarquitecturas.

Así que quédate atento, porque ¡esto se pone aún más emocionante! 🔥🔥

---

¡No dejes que el miedo a lo desconocido te detenga!

En DevOps y el desarrollo, la innovación y la mejora continua son el camino hacia el éxito. No temas dar el siguiente paso hacia un futuro más seguro y confiable en tus despliegues. ¡Lo único constante es el cambio y las mejoras, y con el conocimiento adecuado, puedes transformar cualquier desafío en una oportunidad!

¡Vamos por más! 💪 Nunca dejes de aprender y compartir, porque en la comunidad, todos crecemos juntos. 🚀

Sígueme en mis redes para más consejos, trucos y contenido exclusivo sobre DevOps, Docker y mucho más:

• Twitter: @roxsross

• LinkedIn: Rossana Suarez

• Instagram: @roxsdevops