Tutorial: Lanzar una imagen Docker de prueba

Parfois, un développeur veut proposer une image Docker « de test » sur le forum pour permettre à des utilisateurs de tester une nouvelle intégration avant qu’elle soit déployée en production.

Contrairement à l’image Docker « officielle » qui est hébergée sur le compte du projet gladysassistant/gladys, une image de test sera hébergée sur le compte Docker du développeur proposant l’image. Exemple: jeanfrancois/gladys.

Pour lancer une image Docker de test, c’est le même process que décrit sur la page d’installation de Gladys via Docker: Docker | Gladys Assistant.

La seule différence c’est qu’il faut changer le nom de l’image dans le docker run par l’image de test, et modifier certains paramètres de la commande.

Avant de commencer

:warning: :warning: Si tu ne sais pas ce que tu fais, évite de lancer ton image de test sur la même machine que ton installation de production, car cela pourrait avoir des conséquences sur ton installation ! :warning::warning:

Lancer l’image de test

Imaginons que l’on veut lancer une image de test de l’intégration « zwave », développée par « jeanfrancois ».

On va prendre la commande docker run sur le site Gladys, et modifier plusieurs choses:

  • Le nom du container, par exemple « gladys-zwave-test » au lieu de « gladys » : --name gladys-zwave-test \
  • Le port sur lequel tourne Gladys, par exemple 8001 au lieu de 80: -e SERVER_PORT=8001 \
  • Le dossier dans lequel seront enregistrés tous les fichiers Gladys (base de données, configuration): -v /var/lib/gladysassistant_zwave_test:/var/lib/gladysassistant \
  • Le nom de l’image Docker à lancer: jeanfrancois/gladys au lieu de gladysassistant/gladys

Ce qui nous donnes cette commande :

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

Pour accéder à Gladys:

http://IP_MACHINE:8001

Pour stopper ce container:

docker stop gladys-zwave-test

Pour supprimer ce container:

docker rm gladys-zwave-test

Pour aller chercher une nouvelle version de l’image

(si le dev a avancé sur son intégration):

docker pull jeanfrancois/gladys

A savoir qu’un container Docker est immutable: si jamais tu a pull une nouvelle image, il faut stopper le container, supprimer le container puis docker run un nouveau container :slight_smile:

Note:

Evite de connecter ton compte Gladys Plus à une instance de test, car cela déconnectera ton instance de production.

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)…