686 - Actualiza tus contenedores Docker SIN dolor. Dockge, Cup y Homepage

Actualiza tus contenedores #docker de otra forma utilizando #dockge #cup y #homepage de forma sencilla y con todo el control en tus propias manos

1:25

-3:15

0.8x1.0x1.2x1.4x1.6x1.8x2.0x

1.0x

El último episodio, el 685, titulado Adios Portainer. Dockge lo destrona, trajo varios comentarios, y uno de ellos me llamó la atención, porque hablaba de la posibilidad de desplegar los contenedores desde Portainer utilizando la sincronización con git. Esto me llevó a una auténtica madriguera de conejo. Estuve durante horas vagando entre distintos servicios y configuraciones, incluso me llevó a descubrir un servicio que desconocía y que me parece muy interesante. Y es que, tal y como comentaban, hay muchas herramientas que hacen lo mismo. O, mejor dicho, hay muchas herramientas que parecen hacer lo mismo. Y digo que parecen hacer lo mismo, porque cada una tiene sus particularidades, y están enfocadas en aspectos distintos. Y esto es precisamente lo que mas me gusta de este mundo. Hay desarrolladores, que por la razón que sea implementan una variante de un determinado servicio o aplicación, por que la original, por llamarla de alguna forma, no se adecua exactamente a sus necesidades. Y de esta manera puedes dar con justo la que tu buscas. Es cierto, que podrías pedirle al desarrollador original que implementara esa solución. Pero hay cientos de razones para que este no lo haga, desde que no está contemplado en su roadmap, pasando porque es algo muy particular tuyo. o que simplemente no quiere. Sea como fuere, esto me ha llevado a dar una vuelta a mi proceso de actualización de imágenes utilizando distintas herramientas, y esto es precisamente lo que te quiero contar.

Actualiza tus contenedores Docker SIN dolor. Dockge, Cup y Homepage

Una observación

Me llama la atención los comentarios de hay muchas distribuciones, o hay muchos forks. Sin embargo, como decía en la introducción, esto no tiene porque ser malo necesariamente. Está claro que hay quien hace distribuciones que a ti, no te aportan nada… Pero ¿tu estás seguro que a otras personas no le aportan? Seguro que al que la hizo le aporta algo. Y por otro lado, ¿que mas te da que esa persona invierta el tiempo en hacer esa distribución?.

Hace un tiempo yo me planteaba, que si toda la gente que se dedica a hacer distribuciones se dedicara a mejorar las existentes, o aquellos que se dedican a hacer forks se dedicaran a colaborar en los originales, seguro que iría todo mejor… Hoy en día no pienso igual. La razón es sencilla, ¿y si yo no quiero colaborar en el original?¿y si yo quiero hacer lo que yo quiera hacer? Pues efectivamente, tienes toda la razón.

Empezando por Git

La verdad, no me acordaba de la posibilidad de Portainer de sincronizar vía Git, y eso, que creo que lo mencioné en la charla que dí en la WordCamp de Valencia de 2023… Pero, como te decía en el episodio anterior, lo cierto es que Portainer, con todas las opciones que tiene me abruma, y me conformo con muchas, muchas, muchas menos opciones.

Esto me hizo replantarme la posibilidad de utilizar las herramientas que tengo para hacer algo similar, y por supuesto pensé en mis dos compañeros de aventuras, Gitea y Semaphore.

Semaphore

Semaphore es un servicio de integración continua y entrega continua (CI/CD) que permite automatizar el proceso de construcción, prueba y despliegue de aplicaciones. Es una herramienta muy útil para desarrolladores y equipos de DevOps que buscan mejorar la eficiencia y la calidad de su software. Es similar a Rundeck, pero mas sencillo y mucho mas ligero. De este servicio te hablé en el episodio 489, titulado Semaphore, ansible y hardening. Todo después de asistir a un taller de hardening en Linux que impartió Jesús Amorós en Linux Center de la mano de Slimbook.

Si no estás metido en el mundo del desarrollo, es posible que esto de la integración continua y entrega continua te suene a chino. Sin embargo, si te digo, que con este servicio puedes ejecutar scripts en múltiples servidores seguro que ya le ves el increíble potencial.

Para mi es un servicio muy, pero que muy interesante, porque me permite dar los primeros pasos a la hora de configurar un servidor, instalar y configurar aplicaciones, y realizar todo tipo de operaciones de forma remota.

En concreto, para el caso de las actualizaciones de imágenes Docker, cuando algún stack, no se ha reinicializado correctamente después de una de estas actualizaciones, utilizo un playbook de ansible, que me permite reiniciar el stack y que todo vuelva a funcionar de forma correcta.

Y ¿para que quiero utilizar Semaphore en este contexto? Pues esto me permitiría mantener actualizados los stacks de Docker utilizando para ello un repositorio Git. Así, de forma programada, podría ejecutar un playbook que sincronizara todos los stacks de Docker con el repositorio Git, y si hubiera algún cambio, lo aplicaría automáticamente.

Indicar que esto es simplemente una idea a raíz de ese comentario del episodio anterior. Tengo que madurarlo y ver si tiene sentido o no.

Tengo que confesarte que con la integración de Dockge

Gitea

La siguiente pieza en este puzzle sería Gitea o GitHub, dependiendo de tu caso. En el mío particular, algunos de los repositorios, dependiendo de los datos los tengo en Gitea, y este podría ser el caso de los compose. La idea sería mantener en este repositorio personal todos los compose de los servicios que tengo desplegados, tal y como ahora mismo los tengo expuestos en el repositorio de GitHub de selfhosted. La cuestión, es que el repositorio anterior está pensado mas para que cada uno se lo pueda configurar como quiera, mientras que este repositorio del que te hablo sería una réplica de lo que tendría en mi servidor. Por lo tanto, no tendría sentido que tuvieras un compose para un servicio que no tienes desplegado.

Para esto de nuevo, utilizaría Dockge, a la hora del despliegue de los contenedores que me da la posibilidad de tener un control de cada uno de los compose que actualmente tengo desplegados.

Registry

Otra pieza a tener en cuenta, pero que es mucho mas especializada, y que entiendo que en la mayoría de casos, no sería necesaria es el registry de Docker. Este servicio permite almacenar imágenes de contenedores en un registro privado, lo que puede ser útil si deseas mantener tus imágenes de contenedores en un entorno controlado y seguro. Además, puedes utilizarlo para almacenar versiones específicas de tus imágenes y facilitar el acceso a ellas desde diferentes servidores.

Actualmente, estoy utilizando mi propio registry para determinadas imágenes que creo de algunos servicios que estoy implementando en Rust + TypeScript.

En este caso sería ir un paso mas allá, es decir, que cada vez que actualice el repositorio donde se encuentra el proyecto, directamente se generara la imagen del contenedor y se subiera al registry. Esto me permitiría tener siempre la última versión de la imagen del contenedor, y no depender de que el desarrollador del servicio lo haga. En este caso, el proceso sería similar al de Gitea, pero en lugar de utilizar un repositorio Git, utilizaría el registry para almacenar las imágenes.

Pero, como te digo esto es algo que se sale bastante del objetivo que andaba buscando.

Dockge

Después de lo que te conté en el episodio anterior, lo cierto es que he seguido migrando mis compose a Dockge. Y es que me permite lo mejor de los dos mundos, estar cerca de la terminal y de la interfaz gráfica. Ahora, reiniciar un contenedor no me obliga a tener que conectarme a un terminal, desde mi tablet Android, me puedo conectar en cualquier momento desde la interfaz web.

Además otro punto muy interesante es poder actualizar las imágenes de los contenedores, igualmente, desde la interfaz web de Dockge.

Comentarte que sigo en esta migración de tener los compose gestionados por Dockge. Me lo estoy tomando con mucha calma, y voy migrando conforme voy necesitando, porque como ya te comenté, lo cierto es que esto me da una enorme pereza.

Watchtower

De Watchtower te he hablado en varias ocasiones. Se trata de uhn servicio que te permite actualizar de forma completamente automática las imágenes de tus contenedores, y además reiniciarlos y tenerlos al día.

Sin embargo, tiene un importante problema y es que, precisamente, el proyecto de Watchtower, lleva un tiempo que no se actualiza, parece que no está mantenido. Y es que, si vas al repositorio de GitHub de Watchtower verás que hace un par de años que no tiene actividad.

En estos casos, siempre me surge la duda si es que no necesita mantenimiento, o cuando un proyecto no tiene actividad, es que ha muerto. En este caso, la verdad es que no lo sé. Pero lo que si sé es que no me gusta tener un servicio que no está mantenido, y menos si se trata de algo tan crítico como son las actualizaciones de los contenedores. Y esto es precisamente lo que me preocupa, y lo que me lleva a darle una vuelta al proceso de actualización.

Cup

En este ir y venir de servicios fue cuando tropecé con Cup. Si no conoces Cup, indicarte que es un servicio realmente sencillo, ligero y fácil de usar que te ofrece un informe de la situación de las imágenes. De esta manera de un simple vistazo ves que imágenes no están actualizadas. Además te ofrece una API, de forma que puedes consultar fácilmente que imágenes no están actualizadas y actualizarlas. Incluso, tan sencillo como hacer un simple script en bash, que se encargara de actualizar las imágenes y reiniciar los contenedores.

Características

Algunas características de este servicio son las siguientes,

• Extremadamente rápido. Se trata de un servicio muy ligero y rápido, lo que permite revisar el estado de todas las imágenes en cuestión de segundos.
• Compatible con la mayoría de los registros, incluyendo Docker Hub, ghcr.io, Quay, lscr.io e incluso Gitea (y derivados).
• No agota los límites de uso.
• Interfaz sencilla y elegante, tanto en CLI y web.
• El binario es diminuto. Al momento de escribir esto, solo pesa 5.4 MB. En lugar de tener una imagen de cientos de megas, aquí con unos pocos lo tienes resuelto.
• Salida en JSON, tanto en la CLI como en la interfaz web, lo que te permite integrarlo de forma sencilla con otras herramientas, entre ellas Homepage.

Integración con Homepage

En el episodio 647 en el que te hablé cobre como organizar tus contenedores Docker, te mencioné que estaba utilizando Homepage como página de inicio para tener una visión global. Como te decía, actualmente estoy realizando varios side projects, y necesito organización, y esto es precisamente lo que me ofrece esta herramienta. Un punto central donde tengo acceso a todos los servicios que tengo auto alojados y una visión global del estado de los mismos.

En este caso, Cup me permite integrar el estado de las imágenes de los contenedores en Homepage, de forma que puedo ver de un simple vistazo si hay imágenes que no están actualizadas. Esto me permite tener una visión global del estado de mis contenedores y poder tomar decisiones sobre si es necesario actualizar alguna imagen.

Y te tengo que decir que es realmente sencillo. Simplemente he tenido que añadir estas líneas a mi configuración de homepage,

    - Cup:
        href: https://cup.territoriolinux.es
        description: Cup
        icon: sh-cup-updates.svg
        container: cup
        showStats: true
        widget:
          type: customapi
          url: http://cup:8000/api/v3/json
          refreshInterval: 10000
          method: GET
          mappings:
            - field:
                metrics: monitored_images
              label: Monitored images
              format: number
            - field:
                metrics: up_to_date
              label: Up to date
              format: number
            - field:
                metrics: updates_available
              label: Available updates
              format: number
            - field:
                metrics: unknown
              label: Unknown
              format: number

Valorando el proceso de actualización

Teniendo en cuenta lo que te conté en referencia a Watchtower, y que no me gusta tener un servicio que no está mantenido, estoy valorando la posibilidad de utilizar Cup para actualizar las imágenes de los contenedores. De esta manera, tendría un control total sobre el proceso de actualización, y podría programar las actualizaciones de forma sencilla. Además, al ser un servicio ligero y rápido, no tendría que preocuparme por el rendimiento del servidor.

Todo esto me hace valorar la posibilidad de hacer un script en bash o una sencilla aplicación en Rust que se encargue simplemente de actualizar imágenes y reiniciar los contenedores. La verdad es que me lo estoy pensando muy mucho.

Por el momento lo voy a dejar tal y como está, es decir, que Watchtower se encargue de actualizar semanalmente las imágenes, o incluso mensualmente, y yo ir actualizando aquellas mas sensibles. Veremos como evoluciona el asunto.