Tutorial: Lanzar una imagen Docker de prueba

A veces, un desarrollador quiere proponer una imagen Docker « de prueba » en el foro para permitir que los usuarios prueben una nueva integración antes de que se despliegue en producción.

A diferencia de la imagen Docker « oficial » que se aloja en la cuenta del proyecto gladysassistant/gladys, una imagen de prueba se alojará en la cuenta Docker del desarrollador que propone la imagen. Ejemplo: jeanfrancois/gladys.

Para ejecutar una imagen Docker de prueba, es el mismo proceso que se describe en la página de instalación de Gladys a través de Docker: Docker | Gladys Assistant.

La única diferencia es que hay que cambiar el nombre de la imagen en el docker run por la imagen de prueba, y modificar algunos parámetros del comando.

Antes de empezar

:warning: :warning: Si no sabes lo que haces, evita ejecutar tu imagen de prueba en la misma máquina que tu instalación de producción, ya que podría tener consecuencias en tu instalación. :warning::warning:

Ejecutar la imagen de prueba

Imaginemos que queremos ejecutar una imagen de prueba de la integración « zwave », desarrollada por « jeanfrancois ».

Tomaremos el comando docker run del sitio Gladys y modificaremos varias cosas:

  • El nombre del contenedor, por ejemplo « gladys-zwave-test » en lugar de « gladys »: --name gladys-zwave-test \
  • El puerto en el que funciona Gladys, por ejemplo 8001 en lugar de 80: -e SERVER_PORT=8001 \
  • La carpeta en la que se guardarán todos los archivos de Gladys (base de datos, configuración): -v /var/lib/gladysassistant_zwave_test:/var/lib/gladysassistant \
  • El nombre de la imagen Docker a ejecutar: jeanfrancois/gladys en lugar de gladysassistant/gladys

Esto nos da el siguiente comando:

docker run -d \
--log-driver json-file \
--log-opt max-size=10m \
--cgroupns=host \
--restart=always \
--privileged \
--network=host \
--name gladys-zwave-test \
-e NODE_ENV=production \
-e SERVER_PORT=8001 \
-e TZ=Europe/Paris \
-e SQLITE_FILE_PATH=/var/lib/gladysassistant/gladys-production.db \
-v /var/run/docker.sock:/var/run/docker.sock \
-v /var/lib/gladysassistant_zwave_test:/var/lib/gladysassistant \
-v /dev:/dev \
-v /run/udev:/run/udev:ro \
jeanfrancois/gladys

Para acceder a Gladys:

http://IP_MACHINE:8001

Para detener este contenedor:

docker stop gladys-zwave-test

Para eliminar este contenedor:

docker rm gladys-zwave-test

Para obtener una nueva versión de la imagen

(si el desarrollador ha avanzado en su integración):

docker pull jeanfrancois/gladys

Hay que saber que un contenedor Docker es inmutable: si alguna vez has descargado una nueva imagen, hay que detener el contenedor, eliminar el contenedor y luego ejecutar un nuevo contenedor con docker run :slight_smile:

Nota:

Evita conectar tu cuenta Gladys Plus a una instancia de prueba, ya que esto desconectará tu instancia de producción.

Preguntas pequeñas para entender cómo funciona…

¿Se puede ejecutar una instancia de prueba en la misma máquina en la que se ejecuta la instancia de producción instalando la imagen de prueba como se describe arriba y cambiando solo el puerto?

¿La instancia de prueba es completamente independiente pero va a leer y escribir en la misma base de datos que la imagen de producción?

sí

sí si dejas EXACTAMENTE la misma ruta y nombre de archivos que tu producción,
no porque normalmente cambias el directorio de los datos (en todo caso ¡es mejor!).

Si deseas hacer pruebas en el mismo host y quieres recuperar la información/configuración existente, haz una copia de los archivos (renombras con -test por ejemplo) y luego modificas los nombres de los archivos en el docker run.
Espero que sea lo suficientemente claro :face_with_raised_eyebrow:

Pequeñas observaciones:

  • Tras mi último intento, pude confirmar que al configurar Gladys por primera vez, se crea/configura un contenedor MQTT automáticamente. Este comportamiento provoca un conflicto cuando se prueba en una máquina de producción, ya que la configuración del contenedor original se sobrescribe con la del nuevo. Después de detener/eliminar la imagen de prueba, es necesario volver a registrar la configuración del servidor MQTT en el Gladys de producción.
  • De manera similar, al probar en una máquina de producción (con otra base de datos, por supuesto), surge un conflicto con las integraciones externas que, en la producción, pasan a un estado ‹ degradado ›. Por lo tanto, después de detener/eliminar la imagen de prueba, es necesario reiniciar cada una de las integraciones externas.
  • En cuanto al comando dado por @pierre-gilles, no pondría el contenedor en restart=always, sino en unless-stopped. Esto permite simplemente detener el contenedor de prueba sin que se reinicie constantemente…

¡De acuerdo, gracias por estas aclaraciones!

Pero si instalamos la imagen de prueba en una máquina de prueba, por ejemplo, un viejo Raspberry, ¿cómo hacemos para comunicarnos con la red Zigbee existente (¡sin perturbarla!)?

Ah, mira, lo que puedes hacer es pasar por el z2m de tu instalación original configurando, en tu instalación de prueba, un contenedor ZigBee externo (que será el de tu producción)…