Alexa, und FHEM als stateless Docker: Probleme mit ProxyKey Persistenz

Begonnen von globus243, 31 Mai 2023, 11:57:34

Vorheriges Thema - Nächstes Thema

globus243

Hallo Fhem-Gemeinde,

ich mag Docker sehr und versuche aktuell einen zustandslosen Fhem-Container zu bauen. Die Idee ist, das Konfiguration und alles was man ändern können muss, in einem Git-Repo liegt, und die Dateien dann beim Build statisch in das Container-Image kopiert werden. Das hat den Vorteil das der Host, auf dem Fhem läuft, komplett egal ist, Backup ist auch irrelevant, Experimente lassen sich so auch leichter durchführen, weil man einfach nur einen neuen Branch im Git aufmachen müsste und sollte man sich einmal sein Fhem zerschießen: redeploy, problem gelöst.

Bezüglich Datenspeicherung speichere ich alles was von interesse ist in einer zentralen MySQL-DB. Der Rest (hauptsächlich log-files) sind für meine Zwecke unwichtig. Ich benötige als für mein Fhem keinerlei Persistenz oder volumes.

Soweit klappt das super, ich habe allerdings probleme mit alexa-fhem. Aktuell verliert das alexa-device nach jedem Neustart (also löschen und neu deployen des Containers) seinen ProxyKey und erzeugt einen Neuen. Damit müsste man nach jedem Update/Neustart/Konfigchange den Skill neu anlernen, was ein dealbreaker für diese Lösung wäre.

Hier mein Dockerfile, wie ihr seht passiert hier nicht wirklich viel. Ein paar Pakete werden installiert, Environment wird gesetzt und der Inhalt vom src/ ordner wird an entsprechende Stelle im Image kopiert. Der Rest wird von der "entry.sh" beim Deployment erledigt die bereits bei fhem/fhem:latest dabei ist.
FROM fhem/fhem:latest

RUN apt-get update && apt-get upgrade -y \
    && apt-get install -y --no-install-recommends cpanminus \
    && cpanm --notest Amazon::SNS \
    && npm update -g \
    && npm install -g alexa-fhem alexa-cookie gassistant-fhem homebridge homebridge-fhem

COPY src/ /fhem/

ENV TZ="Europe/Berlin" \
    LOGFILE="./log/fhem-%Y-%m-%d.log" \
    FHEM_UID=6061 \
    FHEM_GID=6061

Datein die ich neben der reinen Fhem-Konfig noch im Repo habe und die ins Container-Image kopiert werden:
alexa-fhem.cfg
db.conf
.ssh/id_ras, id_ras.pub, id_ed25519, id_ed25519.pub, known_hosts, config
FHEM/www/codemirror/ # der codemirror editor
FHEM/www/gplot/ # meine graphs die in einer anderen Installation erstellt wurden
FHEM/83_KFL200.pm
FHEM/83_KFL200Node.pm
FHEM/controls_KFL200.txt

Die Datein kommen von einer klassischen Fhem Installation auf einer VM, die bis jetzt alles bei mir gesteuert hatte.

Das der ProxyKey sich bei jedem redeploy ändert war Anfangs logisch, basiert das ganze doch auf SSH-keys die, sollten sie nicht vorhanden sein, bei jedem deploy neu generiert werden. Ich habe also die SSH-Keys ebenfalls in meinem Repo abgelegt, sie werden beim Build auch ins Image kopiert und in der Laufzeiz benutzt. Den Skill habe ich dann mit dem neuen ProxyKey angelernt und es funktionierte erstmal. Dann der testweise redeploy und nun die Enttäuschung, ProxyKey ist wieder anders, Alexa-Skill müsste neu angelernt werden um wieder zu funktionieren.

Meine Vermutung ist, das die SSH-Keys noch nicht alles sind, dass irgendwo im Filesystem eine config, oder Ähnliches, liegt die beim re-deploy verloren geht. Ich habe schon stundenlang mit find die Dateien im Container nach dem Key durchwühlt aber nichts finden können.

Schätze, ich habe hier einfach nur eine Wissenslücke wie alexa-fhem genau arbeitet.
Jede Idee und Input ist herzlich willkommen.

MadMax-FHEM

#1
Eigentlich sollte es reichen /opt/fhem/.ssh zu sichern und zurückzuspielen.
EDIT: ist im "normalen" fhem Backup nicht enthalten... Sichere ich per tar zusätzlich. tar deshalb, damit die Rechte etc. bleiben...

Ohne Docker (weil eben eine weitere "Indirektion", die [zusätzliche] Probleme macht/machen kann: wie man sieht ;) ) hat das bislang bei diversen Ümzügen (komplett neues Image teilw. sogar neue HW) ohne Probleme und "neu anlernen" geklappt.

Passen die Rechte?
Alle Dateien vorhanden?

Gruß, Joachim

P.S.: für mich erschließt sich der Sinn von Docker für ein "lebendes System" noch nicht so wirklich. Backup muss ja trotzdem, klar. Neu Aufsetzen (nach Crash o.ä.) dauert bei mir auch nicht lange und wenn HW-/OS-Wechsel dazukommen geht es mit Docker auch nicht schneller (zumindest würde ich nicht sehen wie)... Und durch die "Indirektion" kommen "Probleme" mit Netzwerk, USB, ...
Ich verstehe Docker z.B. in der Entwicklung (da nutze ich das auch), wo ich z.B. sicherstellen will, dass eine Generierung immer gleich abläuft (stabiles/statisches immer wieder gleich aufzusetzendes System) usw.
Aber muss nat. jeder selber wissen ;)
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

globus243

moin, ja rechte passen, sind 640, wie auch beim alten system. Ich glaube sonst meckert openSSH die Keys auch wegen zu "offener Rechte" an.

bezüglich vorteile von Docker:
Ich benutze CoreOS-VMs, die sind vom design her so konstruiert das man sie mit minimalem Aufwand neu deployen kann (per ignition file, das man beim Hypervisor angibt). Auf diesen VMs laufen meine Container. Durch die Abtrennung mit Docker bist du von der darunterliegenden Maschine komplett unabhängig. Damit kann dir egal sein, ob es eine neue LTS des OS gibt oder ob die VM plötzlich spinnt, oder was auch immer. Lösung ist immer gleich: neue VM, Orchestrator deployed Container neu, fertig. Ja es ist zusätzliche Abstraktion, hat man die aber erstmal verstanden und für den Use-Case gelöst ist es umheimlich konfortabel mit Docker zu arbeiten. Docker ist einfach der nächste Schritt beim Administrieren. VMs abstrahieren dich von der Physik und Docker vom OS.

ZitatBackup muss ja trotzdem, klar

und das ist ja der jokus, wenn ich alles im Git-Repo habe und meine device-readings in eine MySQL db geschoben werden (die selbstverständlich gesichert wird), muss ich mich um den Fhem-Container und die VM auf dem er läuft überhaupt nicht kümmern. Stimmt damit mal etwas nicht -> weg damit und neu deployen, dauert 30 sekunden.

MadMax-FHEM

Zitat von: globus243 am 31 Mai 2023, 12:35:31und das ist ja der jokus, wenn ich alles im Git-Repo habe und meine device-readings in eine MySQL db geschoben werden (die selbstverständlich gesichert wird), muss ich mich um den Fhem-Container und die VM auf dem er läuft überhaupt nicht kümmern. Stimmt damit mal etwas nicht -> weg damit und neu deployen, dauert 30 sekunden.

Wie man an deiner Anfrage sieht ;)

Egal, wie geschrieben muss jeder selber wissen.
Docker an sich und auch VMs verstehe ich schon...
...nur die Vorteile bei einem "lebenden" System vs. der Nachteile (weitere mögliche Probleme) sehe ich (für mich persönlich) halt nicht.

Bei mir (im schlimmsten Fall): HW tauschen, OS-Image drauf, Backup einspielen -> läuft (dauert max. 30min - 1h)

Ansonsten wird ja nur das Backup eingespielt: dauert keine 5min

Da möchte ich sehen wie das mit Docker (inkl. HW-Tausch etc.) schneller geht ;)

Aber hierum geht es ja nicht 8)

Wenn die Rechte passen, alexa-fhem auch dort die ssh-Dateien findet und akzeptiert, dann weiß ich nicht woran es liegen könnte...
...wie geschrieben ziehe ich schon seit Jahren genau so um: Backup (inkl. /opt/fhem/.ssh) einspielen und gut.

Die alexa-fhem.cfg liegt ja mitlerweile im fhem-Ordner und heißt auch anders und ist somit im standard-fhem-Backup enthalten.

Irgendwelche Maschinen-Infos können es eigentlich auch nicht sein, denn ich habe auch die HW schon gewechselt und keine Probleme...

Rechte: ja
Eigentümer? ;)

Sind ja "zwei Paar Stiefel" ;)

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

globus243

ZitatWie man an deiner Anfrage sieht ;)

Startschwierigkeiten gibts ja immer.

ZitatIrgendwelche Maschinen-Infos können es eigentlich auch nicht sein
Dachte eben auch kurz beim Hostnamen die Lösung gefunden zu haben, aber das ists leider auch nicht.

Übrigens, meine bestehende FHEM installation ist auch ein Docker-Container (fhem/fhem:latest), hier funktioniert Alexa-Fhem wunderbar. allerdings habe ich bei diesem deployment auch ein festes volume angegeben, davon möchte ich ja weg.

ZitatRechte: ja
Eigentümer? ;)

freilich
root@263182cccaa3:/opt/fhem# ll .ssh/
total 32K
drwx------  2 fhem fhem 4,0K Mai 31 12:33 .
drwxr-x--- 16 fhem fhem 4,0K Mai 31 12:33 ..
-rw-r-----  1 fhem fhem  509 Mai 30 20:48 config
-rw-------  1 fhem fhem  411 Mai 30 20:48 id_ed25519
-rw-r-----  1 fhem fhem   98 Mai 30 20:48 id_ed25519.pub
-rw-------  1 fhem fhem 3,4K Mai 30 20:48 id_rsa
-rw-r-----  1 fhem fhem  742 Mai 30 20:48 id_rsa.pub
-rw-r-----  1 fhem fhem 1,4K Mai 31 12:33 known_hosts
root@263182cccaa3:/opt/fhem#

MadMax-FHEM

#5
Gut, bei mir sind die Besitzverhältnisse zwar fhem:dialout, mag bei dir aber passen...

Hostname, hmm, den wechsle ich denke ich nicht so häufig, kann aber durchaus sein, dass ich auch das schon mal ohne Probleme gemacht habe ;)

Hmmm, dann fällt mir nichts mehr ein...
...außer: mal "bare metal" das gleiche Setup (wenn das geht? So genau habe ich das mit wo liegen wie die Daten noch nicht durchdrungen ;) ) und sehen, ob es da auch nicht geht.
Dann muss es irgendwas sein, was an dem speziellen Setup liegt und nicht am Docker...
Wobei es ja mit Docker und "üblichem Setup" zu gehen scheint...

EDIT: was mir noch auffällt ist das Unterforum ;) Evtl. verschieben, vielleicht liest ja dann einer der Entwickler mit... 8)
EDIT: oder in das Docker-Unterforum, sollte es doch eine "Docker-Spezialität" sein...

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

globus243

ZitatEDIT: was mir noch auffällt ist das Unterforum ;) Evtl. verschieben, vielleicht liest ja dann einer der Entwickler mit... 8)
EDIT: oder in das Docker-Unterforum, sollte es doch eine "Docker-Spezialität" sein...

Oh es gibt ein extra sub-forum dafür oder meinst du diesen thread??

MadMax-FHEM

Zitat von: globus243 am 31 Mai 2023, 13:37:56
ZitatEDIT: was mir noch auffällt ist das Unterforum ;) Evtl. verschieben, vielleicht liest ja dann einer der Entwickler mit... 8)
EDIT: oder in das Docker-Unterforum, sollte es doch eine "Docker-Spezialität" sein...

Oh es gibt ein extra sub-forum dafür oder meinst du diesen thread??

Jep.

Wäre das für Docker ;)

Falls es ein alexa-fhem Problem ist, dann das hier:Module: 39_alexa.pm Maintainer: justme1968 Forum: Frontends/Sprachsteuerung

Gruß, Joachim

Gruß, Joachim
FHEM PI3B+ Bullseye: HM-CFG-USB, 40x HM, ZWave-USB, 13x ZWave, EnOcean-PI, 15x EnOcean, HUE/deCONZ, CO2, ESP-Multisensor, Shelly, alexa-fhem, ...
FHEM PI2 Buster: HM-CFG-USB, 25x HM, ZWave-USB, 4x ZWave, EnOcean-PI, 3x EnOcean, Shelly, ha-bridge, ...
FHEM PI3 Buster (Test)

globus243

Update:
mit den Tips aus dem oben verlinkten thread, habe ich es hinbekommen. konkret war das problem das /FHEM/FhemUtil/uniqueID fehlte. Bei der Gelegenheit habe ich aber den alexa-fhem server aus meinen fhem-image herausgenommen und per extra container deployed.

einen Dockerimage für fhem/alexa-fhem:latest gibt es ja bereits. dort muss man einfach nur seine config und seinen .ssh-folder statisch mit reinkopieren.

FROM fhem/alexa-fhem:latest

COPY src/ /alexa-fhem/

ENV TZ="Europe/Berlin" \
    LOGFILE="log/fhem-%Y-%m-%d.log" \
    FHEM_UID=6061 \
    FHEM_GID=6061

ein Dockerimage für gassistant konnte ich nicht finden, ist aber einfach erstellt:

FROM python:3-alpine as build

RUN apk add nodejs npm git build-base \
    && cd / \
    && git clone https://github.com/fhempy/gassistant-fhem.git \
    && cd gassistant-fhem \
    && npm install

FROM node:lts-alpine

COPY --from=build /gassistant-fhem /gassistant-fhem

RUN mkdir -p /root/.fhemconnect
COPY src/config.json /root/.fhemconnect/gassistant-fhem.cfg

ENV TZ="Europe/Berlin"

CMD [ "node", "/gassistant-fhem/bin/gassistant-fhem" ]


hier muss dann ebenfalls eine, in meinem Fall sogar die selbe, config beim build bereitgestellt werden.

Das ganze wird dann mit dieser compose deployed:

version: '2.1'

services:
  fhem:
    image: xxxxxxx.dkr.ecr.eu-central-1.amazonaws.com/fhem:latest
    container_name: fhem-stateless
    restart: always
    ports:
      - "8080:8083"
    networks:
      - fhem_net
    devices:
      - "/dev/ttyACM0:/dev/ttyACM0"
    logging:
      driver: "json-file"
      options:
        max-size: "5m"

  alexa-fhem:
    image: xxxxxxx.dkr.ecr.eu-central-1.amazonaws.com/fhem-alexa
    container_name: fhem-alexa
    depends_on:
      - fhem
    restart: always
    networks:
      - fhem_net
    logging:
      driver: "json-file"
      options:
        max-size: "1m"

  gassistant-fhem:
    image: xxxxxxx.dkr.ecr.eu-central-1.amazonaws.com/fhem-gassistant:latest
    container_name: fhem-gassistant
    depends_on:
      - fhem
    restart: always
    networks:
        - fhem_net
    logging:
      driver: "json-file"
      options:
        max-size: "1m"

networks:
  fhem_net:
    driver: bridge

(xxxxxxx.dkr.ecr.eu-central-1.amazonaws.com ist mein privates ECR bei AWS, hier müsste man dan seinen eigenen Wert eintragen)

Das Resultat lässt sich sehen. In Git kann ich nun Änderungen an der Config machen (die ich ggf. vorher in der Laufzeit getestet habe), git push, lokaler Jenkins baut und deployed aktualisiertes Image. Damit habe ich ein völlig zustandsloses Fhem, ohne eine einzige Datei im Host-Filesystem um die ich mich kümmern müsste. Der CoreOS-Host werden regelmäßig automatisch weggeschmissen und neugebaut, um den frischestem patchstand zu gewährleisten. Ein zusätzlicher Vorteil ist, dass ich nun meine Fhem-Config sauber im Git versionieren kann. Kann man sicherlich auch ohne all das, aber hier fällt es einfach mit ab :)