Docker und UI Varianten

[saschah]

Hi,
ich bin gerade dabei ein Dockerfile für OpenEMS zu erstellen.
Ich habe aber noch eine Frage.
Benötigt die BackendApp ein anderes UI als die EdgeApp.
In der Dokumentation wird über jeweils drei unterschiedlichen Builds (Eclipse, Debug u. Prod.) für Edge und Backend gesprochen.

Muss dementsprechend eine Version für das Backend und eine für Edge erstellt werden?

Zudem möchte ich kurz über das Dockerfile und seine Funktionen berichten:
Das Dockerfile besitzt 2 Modi:

1. Erstellen von ui/edge/backend als Container
2. Erstellen und exportieren von edge/backend als jar und ui als Webfiles (kein eclipse, Gradle oder nodejs notwendig)

Jedes der OpenEMS Komponenten wird als eigener Container erstellt.
Das ui wird auf einem nginx Webserver bereitgestellt.

Die Konfiguration wird als Volume eingebunden, damit diese auch bei einem Neustart und Aktualisierungen erhalten bleiben.

Zudem kann man angeben aus welcher Quelle die Komponenten gebaut werden sollen.

• git und branch (falls das Dockerfile noch nicht in den eigenen branch integiert wurden oder man eine andere Version bauen will)
• local (wenn man die locale Version bauen will)

Als Basis zum bauen dient Alpine Linux.
Als Basis der ausführenden Container dient Linuxserver.io Alpine Linux.
Der Vorteil im Linuxserver.io Image liegt darin, dass die Container mit einer anderen UID und GID ausgeführt werden können.

Eine passende docker-compose Datei ist auch verfügbar und ermöglicht über das standartmäßige stack_network die Kommunikation von edge, backend und ui.

Für Fragen und Anregungen bin ich offen.

Repo: GitHub - SMHRambo/openems at docker

[K.H.Hoefkens]

Vielen Dank, dass Du einen aktuellen Dockercontainer erstellst. Darauf warte ich schon länger. Da Docker für mich Neuland ist, habe ich mich bisher nicht daran getraut.
Kannst Du hier berichten, wenn die Container aus Deiner Sicht final fertig sind?
Vielen Dank!

[saschah]

Ich muss gestehen, ich bin kein Docker Profi.
Ich benutze Docker hauptsächlich zum Verteilen und Test von Software, da ich so relativ schnell zwischen Versionen wechseln kann, ohne groß auf Veränderungem am Hostsystem achten zu müssen rückgängig machen muss (Reste entfernen).

Die Container sind eigentlich “final”,
zumindest der für edge und backend.

Da ich bisher der einzige Tester bin und nur meinen Fall und meine Feature-Liste abdecke,
würde ich es eher als beta Status bezeichnen.

Zudem wird der UI Container bisher nur mit “openems,openems-edge-prod,prod” kompiliert.

Leichte Probleme habe ich noch mit dem Container für das UI.

Die JS Files bzgl. websocket sind angepasst, der UI Container findet auch den edge und backend Container, nur komischerweise muss man den API Port vom edge Container erst im Browser selber aufrufen bevor im UI etwas angezeigt wird.

Das Problem habe ich aber auch ohne Docker, wenn die Software nativ auf dem Hostsystem läuft.

Ansonsten müssten ein paar Leute die Container mal testen.

Besonders die Skalierbarkeit bei systemübergreifenden Dockernetzwerken kann ich nicht testen.
Da edge und backend als einzelne Container vorliegen sollte das aber kein Problem sein.

Nachtrag:
Ich habe die Container zwar bei DockerHub hochgeladen, diese sind aber nur x86_64, da ich auf meiner NAS kein QEMU einsetzten kann, um auch für andere Systeme zu komilieren.

Die Docker-Compose Datei geht davon aus das die Container lokal vorliegen.
Ich empfehle die Container selber zu bauen.

Wenn man sich eine Kopie meines Branch gezogen hat,
im Hauptverzeichnis folgende Befehle ausführen.

Für edge: docker build --tag edge --target=edge_container --build-arg SOURCE=git --build-arg BRANCH=develop .

Für backend: docker build --tag backend --target=backend_container --build-arg SOURCE=git --build-arg BRANCH=develop .

Für ui: docker build --tag ui --target=ui_container --build-arg SOURCE=git --build-arg BRANCH=develop .

Damit wird die aktuelle develop Version von openems kompiliert.
Erklärung:
–build-arg SOURCE=<git/local> Auswahl der Sourcedatein, Standarmäßig local
–build-arg BRANCH= Auswahl des Branch bei SOURCE=git, Standarmäßig main
–target=<backend_container/edge_container/ui_container> Das zu erzeugende Container-Image
–tag <backend/edge/ui> Frei wählbar, der Name des Container-Image, hier backend/edge/ui wegen docker-compose

Danach im Hauptverzeichnis fogenden Befehl ausführen:

docker compose up
bzw.
docker compose up -d

Die docker-compose Datei sollte noch angepasst werden.
Entweder man legt die Volumen für die Persistenz-Daten selber an oder verlinkt diese mit Verzeichnissen.

Siehe:

Volumes

Die docker-compose.yml kann auch an einen anderen Ort kopiert und ausgeführt werden.

[stefan.feilmeier]

Vielen Dank @saschah!

Ich bin auch kein Docker-Profi und verwalte meine Server selbst am liebsten mit Systemd-Services. Ich hatte in der Vergangenheit auch schon mal Docker-Container für die Gitpod-Demo erstellt (die aktuell leider nicht funktioniert). Ich weiß nicht, ob du die gefunden hast - sicherheitshalber verlinke ich sie hier → https://github.com/OpenEMS/openems/tree/develop/tools/docker

Ansonsten ist Docker natürlich eine sehr häufige Anfrage. Am besten wäre, wenn wir unser Github Workflows entsprechend anpassen/erweitern würden, dass automatisch z. B. bei einem Release (https://github.com/OpenEMS/openems/blob/develop/.github/workflows/release.yml) offizielle Container bei DockerHub hochgeladen werden. Traust du dir das zu?

Gruß,
Stefan

[saschah]

Ich würde es versuchen.
Das wäre aber das erste mal, dass ich mich mit Gitworkflows auseinander setzte.
Ich habe mich gestern etwas durch die Dokumentation gewühlt und habe ein paar fragen.
Wie wollt ihr das aufbaut haben.

• Sollen die jar Datein importiert werden oder eine eigene Docker build stage haben?
• Habt ihr einen Account für ein Image Hub?
• Wie soll die Versionierung der Images aussehen?
• Lieber einzelne Dockerfiles für jeden Container oder wie ich es gemacht habe eins für alles.

Und nochmal zu meiner Anfangsfrage:
Braucht edge ein andere Version des UI als backend?

[Sn0w3y]

@saschah

Und nochmal zu meiner Anfangsfrage:
Braucht edge ein andere Version des UI als backend?

Das kann ich schonmal vorweg nehmen:

Wie hier zu sehen:

benötigt Edge:
ng build -c “openems,openems-edge-prod,prod”

und Backend:
ng build -c “openems,openems-backend-prod,prod”

Grüße

[saschah]

Das hatte ich auch schon gefunden.
Für mich stellte sich nur die Frage, ob dies wirklich notwendig ist.
Könnte ja auch sein, dass es sich um ein anderes Farbschema handelt und die API identisch ist.

Zudem habe ich in den Github releases immer nur eine UI Version gefunden,
genauso ist im Workflow nur ein Eintrag für “openems,openems-edge-prod,prod” vorhanden.

Deshalb wollte ich vorsichtshalber nachfragen, wo der Unterschied genau liegt.

Ansonsten müssen zwei unterschiedliche UI Container erstellt werden oder das UI in den jeweiligen Container integriert werden.

[Sn0w3y]

@saschah

Ansonsten müssen zwei unterschiedliche UI Container erstellt werden oder das UI in den jeweiligen Container integriert werden.

Ich denke auch, ja !

[saschah]

Die erste Version des Workflows steht.

Welche Arch sollen unterstützt werden?

Reichen x86_64 und arm64/aarch64?

Wenn auch armv6 und armv7 unterstützt werden sollen muss die Basis für die Images geändert werden.

Gibt es ein gewünschtes Names/Versions-Schema?

Dann noch ein paar Fragen zur Struktur, da die Benutzung vom Dockerfile auch für solche interessant ist, die die Images selber bauen wollen z.B. weil sie dem Image nicht trauen oder eine development Version wünschen.

Wo soll das Dockerfile liegen?

Wenn das Dockerfile im root-Verzeichnis liegt muss man sich um den Context Pfad keine Gedanken machen, da Dockerfile und Context Pfad an der gleichen Stelle liegen

Befehl:

docker build –target=<backend_container/edge_container/ui_container> .

Wenn man die Dockerfiles z.B. in tools/docker/… ablegt, muss dieses auch angegeben werden.

Befehl:

docker build --target=<backend_container/edge_container/ui_container> --file tools/docker/Dockerfile .

Soll es ein AiO-Dockerfile geben oder eins für jedes Image?

Das AiO Dockerfile im Root Verzeichnis kann per Target alle Container erzeugen und auch jar-Datein erstellen, die Bedienung ist durch Angabe des Targets etwas umständlich.

Bei einem Dockerfile pro Image müssen diese unterschiedlichen Namen haben, wenn sie im selben Verzeichnis liegen.

Befehl:

docker build --file edge.Dockerfile .

statt

docker build –target=<backend_container/edge_container/ui_container> .