Tutoriel: Lancer une image Docker de test

Tutoriels
1

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.

4

Petites questions afin de comprendre comment cela fonctionne…

Peut-on faire tourner une instance de test sur la même machine sur laquelle tourne l’instance de production en installant l’image test comme décrit ci-dessus et en changeant juste le port?

L’instance de test est complètement indépendante mais va lire et écrire dans la même base de données que l’image de production?

5

oui

oui si tu laisses EXACTEMENT le même chemin et nom de fichiers que ta prod,
non car normalement tu changes le répertoire des data (en tout cas il vaut mieux !).

Si tu souhaites faire des tests sur le même host et que tu veux récupérer les infos/configs existantes, fait une copie des fichiers (tu renommes avec -test par exemple) et ensuite tu modifies dans les noms des fichiers dans le docker run.
J’espère que je suis assez clair :face_with_raised_eyebrow:

6

Petites remarques :

  • Suite à mon dernier essai, j’ai pu confirmer que lorsqu’on configure une première fois Gladys, un container MQTT est créé/configuré dans la foulée. Ce comportement provoque un conflit quand on teste sur une machine de prod puisque la config du container d’origine est écrasée par celle du nouveau. Après arrêt/suppression de l’image de test, il faut réenregistrer la configuration du serveur MQTT dans le Gladys de prod.
  • De même, quand on teste sur sa machine de prod (autre base de données biens sûr), un conflit apparaît avec les intégrations externes qui passent, sur la prod, en état ‹ dégradé ›. Il faut donc par la suite, après avoir arrêté/supprimé l’image de test, redémarrer chacune des intégrations externes.
  • Par rapport à la commande donnée par @pierre-gilles, je ne mettrais pas le container en restart=always mais plutôt en unless-stopped. Ça permet de simplement stopper le container de test sans qu’il ne redémarre sans cesse…
7

OK, merci pour ces précisions!

Par contre si on installe l’image de test sur une machine de test, exemple un vieux raspberry, comment fait on pour communiquer avec le réseau zigbee existant (sans le perturber!)?

8

Ah, là, ce que tu peux faire c’est passer par le z2m de ton install d’origine en configurant, dans ton install de test, un container ZigBee externe (qui sera celui de ta prod)…