Portainer deja de ser el almacén: compose, secretos y configs pasan a GitOps

Un administrador de self-hosting ha publicado la documentación de cómo sacó sus archivos compose, sus secretos y sus configs de Portainer y los movió a Git. Portainer sigue en pie, pero pasa a leer los despliegues desde el repositorio en lugar de guardarlos él. El motivo que da el autor es concreto: quiere que los ficheros sean independientes de la herramienta para poder mover el stack más adelante y para tener copias de seguridad que no dependan de un backup interno del panel.

El montaje es GitOps con Portainer como consumidor. Los compose viven en Git y el panel solo los aplica. Lo mismo con los secretos y las configuraciones, que salen del almacén propio de Portainer y quedan versionados como cualquier otro archivo del repositorio. Eso convierte al stack en algo portable: si mañana cambia de herramienta, el estado ya no está encerrado dentro de una interfaz.

Renovate y un panel de un clic

La segunda pieza es Renovate. El autor lo engancha al repositorio para que vigile las imágenes de los contenedores y abra las actualizaciones como cambios propuestos, en vez de ir contenedor por contenedor comprobando a mano qué tag ha salido. Sobre eso monta un panel en la sección de issues del repositorio que lista qué contenedor tiene actualización pendiente y permite decidir con un clic cuál se actualiza.

El detalle de Renovate, con el renovate.json incluido, está en la documentación de actualizaciones de imagen, y la parte de GitOps con Portainer, en la guía de GitOps con Portainer.

El autor aclara que esto no es una aplicación ni una herramienta nueva: es documentación de cómo encadenar cosas que ya existen, en este caso sobre Docker Swarm. También reconoce que usó IA para que le guiara durante el proceso y para redactar los apuntes al final, aunque las decisiones sobre qué usar y cómo debía funcionar fueron suyas.

Para quien mantiene un laboratorio en casa o un swarm pequeño, el interés está en el patrón más que en la receta concreta. Sacar el estado de la interfaz y ponerlo en Git es lo que permite versionar, revisar y revertir un despliegue como se hace con el código, y Renovate cubre la parte que siempre se queda sin hacer: mantener las imágenes al día. Queda por ver si el autor publica el flujo completo, con la automatización de los issues, o se queda en las dos páginas que ya tiene colgadas.