Un Harbor propio para las imágenes y los charts del clúster
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. En 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.
helm push zetesis-portal-${VERSION}.tgz oci://gauss.nexolabs.dev/zetesis-portalTenerlo 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 ahí
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.
Las versiones se acumulan
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 almacén al margen: es la frontera entre las dos mitades del sistema. La integración continua construye y escribe ahí; a partir de ese punto nadie vuelve a construir nada, solo se descarga lo que ya existe.
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:
- repoURL: oci://gauss.nexolabs.dev/zetesis-portal/zetesis-portal
chart: zetesis-portalDesplegar 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 corre, y por qué no donde 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.
Lo que no tengo, y se ve en las capturas
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.
Seguir leyendo
Montar un homelab desde cero: Kubernetes y GitOps - Homelab (03/06)
Un entorno entero por cada pull request, y que se borre solo
Montar un homelab desde cero: backups y restauración - Homelab (06/06)
Un despliegue por cliente o un espacio por cliente
Búsqueda y agentes sobre tu propia documentación
