No sabría entender este trabajo sin la investigación. Tras tres años en el CERN, al volver a Bilbao decidí trabajar por mi cuenta y seguir investigando y aprendiendo. Creo que emprender es el reto profesional definitivo, y a la vez una expresión de creatividad y un reclamo de libertad.
Zetesis viene del griego ζήτησις, indagación: buscar la causa antes de proponer la solución.
Un registro de imágenes propio suena a cosa que solo necesitas si tienes una obligación normativa detrás. Lo monté por algo más simple: no quería que desplegar en producción dependiera de que un servicio ajeno estuviera disponible y de buen humor, ni del límite de descargas del registro público.
Imágenes y charts en el mismo sitio
Harbor guarda las imágenes de contenedor y también los charts de Helm como artefactos OCI. Si recordamos el homelab, la aplicación entera va empaquetada como un chart almacenado ahí, y ese chart define los recursos de la web, el servidor MCP, el runtime de agentes y la pasarela de modelos.
Tenerlo todo en el mismo registro quita una pregunta al desplegar: la versión de la imagen y la del chart que la despliega viven juntas, con las mismas credenciales y la misma política de acceso. Un proyecto por sistema, privado por defecto.
Quién escribe en el registro
Nadie con nombre y apellidos. Los despliegues y los nodos no usan mi usuario: Harbor tiene cuentas robot, que son credenciales de servicio con permisos acotados a un proyecto y sin capacidad de administrar nada.
El reparto es el de siempre y conviene decirlo en voz alta: la integración continua es la única que escribe, y el clúster solo lee. Una credencial filtrada del lado del clúster no permite publicar una imagen envenenada, porque esa credencial no sabe escribir.
Qué queda registrado de cada versión
Cada artefacto queda con su digest, su tamaño y su etiqueta de versión. Aquí es donde el registro deja de ser abstracto: se ve la historia entera de un servicio, versión a versión, con cuándo se subió cada una y cuándo se descargó por última vez.
Esa última columna es más útil de lo que parece. Una imagen que nadie ha descargado en meses es una candidata a borrar, y sin ese dato la limpieza es a ojo.
Donde acaba la integración y empieza el despliegue
El registro no es un simple almacén, sino la frontera entre la integración y el despliegue. La integración continua empaqueta el código y lo publica allí, garantizando la inmutabilidad del artefacto: a partir de ese punto, el sistema no vuelve a recompilar el software, sino que los entornos de destino consumen y ejecutan exactamente el mismo binario validado.
Quien lee es ArgoCD. En producción se descarga el chart del propio registro como artefacto OCI, y las imágenes que ese chart referencia salen del mismo sitio:
Desplegar una versión nueva es cambiar una etiqueta en un fichero de configuración del repositorio de infraestructura. ArgoCD ve el cambio, se descarga esa versión del registro y reconcilia. Nadie ejecuta un despliegue a mano, y volver atrás es revertir un commit: la versión anterior sigue en el registro, intacta.
Los entornos de preview funcionan igual con una diferencia deliberada: el chart no viene del registro sino del commit del pull request, porque en un preview quieres probar el chart tal como lo has dejado en la rama, no el último publicado. Las imágenes sí salen de aquí, etiquetadas con el número del PR y el commit.
Ese ritmo es también el argumento para no depender de un registro ajeno. Con varios pull requests abiertos, un límite de descargas por hora deja de ser una cifra teórica y pasa a ser el motivo por el que un entorno no levanta.
Dónde ubicar el registro, y por qué no junto a la aplicación
Tengo dos clústeres: uno para la plataforma —el gestor de secretos, el registro y la observabilidad— y otro para la aplicación pública. El registro vive en el de plataforma, a propósito.
Si corriera en el mismo clúster que la aplicación, un incidente que tumbe ese clúster te deja sin la aplicación y sin la forma de volver a desplegarla. Perder el registro no es perder lo que ya está corriendo: es perder la capacidad de arrancarlo otra vez.
Próximos pasos: lo que todavía se podría evolucionar
Harbor trae escaneo de vulnerabilidades, firma de artefactos y generación de SBOM. En mis proyectos las tres columnas dicen lo mismo: no soportado, sin firmar. No es que Harbor no pueda; es que no lo he configurado.
Para un homelab donde el único que publica soy yo, el riesgo que cubre la firma es bajo. En cuanto publique alguien más, deja de serlo: firmar es lo que permite comprobar que la imagen que estás desplegando la construyó tu integración continua y no otra cosa con el mismo nombre.
Escribirlo aquí es la forma barata de que deje de ser invisible. La regla que falta no es complicada —conservar las últimas N versiones y lo que esté desplegado, borrar el resto—, y Harbor la aplica solo desde su propia configuración.
Cuándo no montarlo
Con un despliegue al mes y un solo consumidor, no compensa: es un servicio más con su almacenamiento, su TLS y sus credenciales, a cambio de resolver un problema que todavía no tienes.
El punto de inflexión llega cuando desplegar a menudo empieza a chocar con los límites del registro público, o cuando aparece la primera imagen que no puede salir de casa. A partir de ahí, el coste de operarlo es menor que el de convivir sin él.
01
02
03
04
