Tutorial: Docker-Testimage starten

Anleitungen
1

Manchmal möchte ein Entwickler ein „Test“-Docker-Image im Forum vorschlagen, damit Benutzer eine neue Integration testen können, bevor sie in die Produktion deployed wird.

Im Gegensatz zum „offiziellen“ Docker-Image, das auf dem Projektkonto gladysassistant/gladys gehostet wird, wird ein Test-Image auf dem Docker-Konto des Entwicklers gehostet, der das Image vorschlägt. Beispiel: jeanfrancois/gladys.

Um ein Test-Docker-Image zu starten, ist der Prozess derselbe wie auf der Installationsseite von Gladys via Docker beschrieben: Docker | Gladys Assistant.

Der einzige Unterschied besteht darin, dass der Name des Images im docker run durch das Test-Image geändert werden muss und einige Parameter der Befehlszeile angepasst werden müssen.

Bevor du beginnst

:warning: :warning: Wenn du nicht weißt, was du tust, vermeide es, dein Test-Image auf derselben Maschine wie deine Produktionsinstallation zu starten, da dies Auswirkungen auf deine Installation haben könnte! :warning::warning:

Test-Image starten

Angenommen, wir möchten ein Test-Image der „zwave“-Integration starten, die von „jeanfrancois“ entwickelt wurde.

Wir nehmen den docker run-Befehl von der Gladys-Website und ändern mehrere Dinge:

  • Den Namen des Containers, z. B. „gladys-zwave-test“ anstelle von „gladys“: --name gladys-zwave-test \
  • Den Port, auf dem Gladys läuft, z. B. 8001 anstelle von 80: -e SERVER_PORT=8001 \
  • Das Verzeichnis, in dem alle Gladys-Dateien (Datenbank, Konfiguration) gespeichert werden: -v /var/lib/gladysassistant_zwave_test:/var/lib/gladysassistant \
  • Den Namen des Docker-Images, das gestartet werden soll: jeanfrancois/gladys anstelle von gladysassistant/gladys

Damit erhalten wir diesen Befehl:

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

Um auf Gladys zuzugreifen:

http://IP_MASCHINE:8001

Um diesen Container zu stoppen:

docker stop gladys-zwave-test

Um diesen Container zu löschen:

docker rm gladys-zwave-test

Um eine neue Version des Images zu holen

(falls der Entwickler mit seiner Integration weitergekommen ist):

docker pull jeanfrancois/gladys

Wichtig zu wissen: Ein Docker-Container ist unveränderlich: Wenn du ein neues Image heruntergeladen hast, musst du den Container stoppen, den Container löschen und dann einen neuen Container mit docker run starten :slight_smile:

Hinweis:

Vermeide es, dein Gladys Plus-Konto mit einer Test-Instanz zu verbinden, da dies deine Produktionsinstanz abmeldet.

4

Ein paar Fragen, um zu verstehen, wie das funktioniert…

Kann man eine Testinstanz auf derselben Maschine laufen lassen, auf der die Produktionsinstanz läuft, indem man das Testimage wie oben beschrieben installiert und nur den Port ändert?

Die Testinstanz ist vollständig unabhängig, liest aber in derselben Datenbank wie das Produktionsimage und schreibt darin?

5

Ja.

Ja, wenn du EXAKT denselben Pfad und Dateinamen wie in deiner Produktion lässt,
nein, denn normalerweise änderst du das Datenverzeichnis (auf jeden Fall ist das besser!).

Wenn du Tests auf demselben Host durchführen möchtest und die vorhandenen Informationen/Konfigurationen verwenden willst, erstelle eine Kopie der Dateien (benenne sie z. B. mit -test um) und ändere dann die Dateinamen im Docker-Befehl.
Ich hoffe, ich bin klar genug :face_with_raised_eyebrow:

6

Kleine Anmerkungen:

  • Nach meinem letzten Versuch konnte ich bestätigen, dass beim ersten Konfigurieren von Gladys ein MQTT-Container erstellt/konfiguriert wird. Dieses Verhalten führt zu einem Konflikt, wenn man auf einer Produktionsmaschine testet, da die Konfiguration des ursprünglichen Containers durch die des neuen überschrieben wird. Nach dem Anhalten/Löschen des Test-Images muss die Konfiguration des MQTT-Servers in Gladys Prod neu registriert werden.
  • Ebenso tritt, wenn man auf seiner Produktionsmaschine testet (natürlich mit einer anderen Datenbank), ein Konflikt mit den externen Integrationen auf, die in der Produktion in den Zustand ‹ degradiert › wechseln. Daher müssen die externen Integrationen nach dem Anhalten/Löschen des Test-Images neu gestartet werden.
  • In Bezug auf den Befehl von @pierre-gilles würde ich den Container nicht mit restart=always, sondern mit unless-stopped setzen. Dadurch kann man den Test-Container einfach anhalten, ohne dass er ständig neu startet…
7

OK, danke für die Klarstellung!

Aber wenn wir das Test-Image auf einer Testmaschine installieren, zum Beispiel einem alten Raspberry, wie kommunizieren wir dann mit dem bestehenden Zigbee-Netzwerk (ohne es zu stören)?

8

Ah, da kannst du durch das z2m deiner ursprünglichen Installation gehen, indem du in deiner Testinstallation einen externen ZigBee-Container (der dann der deiner Produktion sein wird) konfigurierst…