Libelektra: Erstellen Sie eine Live-Demo von Web-UI

Der einzig realistische Plan für diese Version besteht darin, ein Docker-Image mit einer manuellen Erstellung von Web-UI zu erstellen und zu hosten.

@omnidan Kannst du das machen?

Dazu gehört auch das Bienenhaus des elektrad + web.

@omnidan Hattest du Zeit, an diesem oder dem Video zu arbeiten?

Ich habe bereits ein Video erstellt: https://drive.google.com/open?id=13dSC0ereCQGusrwlIodaDostW6eEes72

Ich werde versuchen, ein Docker-Image mit der installierten Web-Benutzeroberfläche zu erstellen. Gibt es bereits ein Docker-Image, auf dem Verleumdung installiert ist? Wo würden wir das Docker-Image hosten?

Danke, das Video ist großartig! Wenn Sie manchmal ein anderes Video machen, wäre es hervorragend, ein Video ohne Schüler als Beispiel zu haben: Lächeln: (z. B. Bearbeiten von / etc / hosts)

Was ist unsere beste Option, um das Video zu hosten, damit die Wiedergabe des Videos in allen Browsern reibungslos funktioniert? (In dem obigen Link konnten zwei Browser es nicht direkt abspielen.)

Ich habe eine nextcloud Installation, wir könnten es dort versuchen.

Oder ist es nur eine Frage des Videoformats, in dem es ist?

Gibt es bereits ein Docker-Image, auf dem Verleumdung installiert ist?

Informationen zum Erstellen von Bildern finden Sie unter Skripte / Docker.

Wo würden wir das Docker-Image hosten?

Wir haben unsere eigene Docker-Registrierung unter https://hub.libelektra.org, aber soweit ich weiß, ist sie noch nicht öffentlich verfügbar. @ingwinlu weiß mehr darüber.

@ markus2330 Ich habe es auf YouTube hochgeladen (nicht gelistet), das sollte in allen Browsern funktionieren: https://youtu.be/lLg9sk6Hx-E

Warum nicht gelistet?

@ markus2330 Ich kann es öffentlich machen, ich dachte nur, Sie wollten es nur zum Einbetten in die Website verwenden.

Die Öffentlichkeit ist in Ordnung für mich. Können wir es in die nächsten Versionshinweise einbetten oder sogar als Kommentar zu den aktuellen Reaktionen der Versionshinweise veröffentlichen?

Was ist die Standard-Youtube-Lizenz?

Ich weiß nicht, ich habe es in CC BY geändert

Ich denke, ein Docker-Image mit einer vollständigen (und neuesten) vorinstallierten Elektra könnte für viele (Demo-) Anwendungsfälle (nicht nur für die Web-Benutzeroberfläche) sehr nützlich sein.

Ich bin sehr gespannt auf ein solches Docker-Image: zwinker:

@omnidan Sie können ein Stretch-Basis-Image verwenden und die Pakete von unserem Repo installieren. Das sollte ziemlich schnell und sauber sein.

Sie haben jedoch keinen Zugriff auf Funktionen, die in Debian-Paketen noch nicht vorhanden sind.

Danke für die Eingabe.

Leider enthalten die Debian-Pakete noch keine Web-Benutzeroberfläche. Und es wäre eine ziemlich schwierige Sache (irgendwelche Verpackungsexperten von nodejs hier?).

Und Teile von Elektra als Pakete und andere Teile von "make install" zu installieren, klingt für mich nicht wirklich sauber (die Versionen können leicht nicht übereinstimmen).

@ingwinlu Könnten Sie ein Docker-Image auf a7 hosten, das von @omnidan erstellt wurde? Oder möchten Sie selbst eine Docker-Datei für die Web-Benutzeroberfläche schreiben?

Ein Dockerfile + Image (möglicherweise in einer öffentlichen Docker-Registrierung, wenn wir unsere Registrierung privat halten möchten?) Mit der neuesten installierten Elektra wäre wirklich großartig.

Das Repository von a7 ist nicht für den öffentlichen Zugriff konfiguriert. Und wenn es vom Build-System nicht benötigt wird, ist es sinnvoller, es in die öffentliche Docker-Registrierung aufzunehmen.

Der Plan ist also, dass Entwickler ihre eigenen Docker-Images neu erstellen? Oder sollten wir alle Bilder in ein öffentliches Repo stellen?

Gibt es einen möglichen Schaden, wenn wir den schreibgeschützten Zugriff zulassen?

Der Plan ist also, dass Entwickler ihre eigenen Docker-Images neu erstellen?

Dies ist eine Option oder um das Image manuell von einem der Build-Slaves in das öffentliche Repository zu verschieben. Oder um den Reverse-Proxy vor der Registrierung neu zu konfigurieren, damit anonyme Abrufanforderungen an den Endpunkt weitergeleitet werden können.

Oder sollten wir alle Bilder in ein öffentliches Repo stellen?

Dies wird das Build-System für Image-Updates erheblich verlangsamen.

Gibt es einen möglichen Schaden, wenn wir den schreibgeschützten Zugriff zulassen?

Im Moment nein, da die Bilder keine vertraulichen Anmeldeinformationen enthalten sollten. Eine Fehlkonfiguration kann jedoch dazu führen, dass Schlüssel / Zugriff, die für das Build-System erforderlich sind, in die Images gelangen.

@ingwinlu Ja, ein Job, der in eine öffentliche Registrierung

@omnidan Ist es in Ordnung, eine Docker-Datei für die Web-Benutzeroberfläche zu schreiben?

@ markus2330 Ich habe eine Docker- elektra -Gruppe in der Docker-Registrierung erstellt (ich kann Sie als Eigentümer hinzufügen, wenn Sie mir Ihre Docker-ID geben), einen elektra/web:1.4.0 -Container in der Docker-Registrierung veröffentlicht und die Dokumentation mit Informationen aktualisiert Informationen zum Ausführen von elektra web über Docker und zum Erstellen neuer Container / Releases.

@ingwinlu können Sie dieses Docker-Image auf v7 hosten? (Damit es automatisch startet, wenn der Server startet?)

Sicher.

@omnidan kannst du pushen auf: neueste auch? Dann werde ich es so einrichten, dass nach neuen Versionen gesucht wird, die automatisch auf Folgendes verschoben werden: Neu bereitstellen und erneut bereitstellen, wenn ein Update vorliegt.

@ markus2330 können Sie einen DNS-Eintrag auf a7 zeigen. so etwas wie webui oder webdemo vielleicht?.

@ingwinlu Vielen Dank!
webui.libelektra.org webdemo.libelektra.org sollte in Kürze auf a7 verweisen.

@omnidan Das Webui ist möglicherweise interessanter, wenn Sie einige Mountpunkte in den Bildern erstellen. kdb mount-info und kdb mount --with-recommends /etc/hosts system/hosts hosts wären ein guter Anfang!

@ingwinlu Sie können bereits :latest , es verwendet jetzt :1.4 (wird :1.5 spätestens veröffentlichen, wenn die PR zusammengeführt wird).

Ich würde es vorziehen, wenn wir sofort 1.5 haben können, es gibt wenig Sinn, 1.4 jetzt zu testen. Ich dachte, Zusammenführen ist nicht notwendig?

@omnidan Sie scheinen falsch zu latest -Tag funktioniert: https://medium.com/@mccode/the -misunderstood-docker-tag-latest-af3babfd6375

https://hub.docker.com/r/elektra/web/tags/ zeigt nicht latest . Sie müssen es explizit pushen.

Vielen Dank für den Hinweis!

Können Sie das Docker-Image 1.5.0-beta auf a7 starten, damit wir morgen in der Besprechung etwas ausprobieren können?

http://a7.complang.tuwien.ac.at : 33334 /

Ich konnte den Proxy nicht umkehren, da die Ports fest codiert sind (und das funktioniert mit dem aktuellen Setup nicht). Beachten Sie auch, dass elektra als Root-Benutzer im Container ausgeführt wird, was mich höllisch unbehaglich macht.

http://webui.libelektra.org : 33334 / funktioniert auch! Danke: 100: mal.

Beachten Sie auch, dass elektra als Root-Benutzer im Container ausgeführt wird, was mich höllisch unbehaglich macht.

Keine Sorge, es ist nicht root (sondern 999) und es ist nicht einmal möglich, auf Systemschlüssel zu schreiben: could not create configuration directory: Could not create directory "/etc/kdb", because: "Permission denied" uid: 999, euid: 999, gid: 999, egid: 999

Ja, aber es ist kein Proxy, also auch kein https. Es ist nur manipuliert, um zu rennen
jetzt aber würde es auf lange Sicht nicht so halten.

markus2330 [email protected] schrieb am Fr., 1. Juni 2018, 10:38:

http://webui.libelektra.org : 33334 / funktioniert auch! Vielen Dank 💯 mal.

Beachten Sie auch, dass elektra als Root-Benutzer in dem Container ausgeführt wird, der
macht mich höllisch unbehaglich.

Mach dir keine Sorgen, es ist nicht root (aber 999) und es ist nicht einmal möglich
Schreiben in Systemschlüssel: Konfigurationsverzeichnis konnte nicht erstellt werden: Konnte nicht
Verzeichnis "/ etc / kdb" erstellen, weil: "Berechtigung verweigert" uid: 999, euid:
999, gid: 999, egid: 999

- -
Sie erhalten dies, weil Sie erwähnt wurden.
Antworte direkt auf diese E-Mail und sieh sie dir auf GitHub an
https://github.com/ElektraInitiative/libelektra/issues/1901#issuecomment-393810941 ,
oder schalten Sie den Thread stumm
https://github.com/notifications/unsubscribe-auth/AEOv-lxXTk85wCl8ipo7okci3PKztfWhks5t4P1jgaJpZM4TRVIf
.

Die Ports sind fest codiert

Das Problem hierbei ist, dass wir elektrad und webd in einem Container ausführen, was gegen die Docker-Prinzipien verstößt. Daher kann ich nur einen der beiden Ports einstellbar machen (was jedoch ausreichen sollte, solange elektrad eingeschaltet ist: 33333)

Beachten Sie auch, dass elektra als Root-Benutzer im Container ausgeführt wird, was mich höllisch unbehaglich macht.

Ich habe speziell darauf geachtet, einen elektra Benutzer in der Docker-Datei zu erstellen und zu verwenden, es sei denn, ich habe etwas falsch gemacht?

Ja, entschuldigen Sie die überstürzte Nachricht (ich bin voll mit Terminen an diesem Wochenende + mein letzter PR hat Master Builds gebrochen).

Es gibt zwei große Probleme mit der aktuellen Docker-Datei:

mehrere Prozesse :
Während Sie bereits gesagt haben, dass dies gegen „Prinzipien“ verstößt, wird dies hauptsächlich als Prinzip bezeichnet, denn wenn Sie gegen die Regel verstoßen, müssen Sie verstehen, was passiert und warum dies ein Problem ist.
Sie erstellen ein Shell-Skript, das zwei Prozesse startet. Dieses Shell-Skript wird über PID 1 ausgeführt. Dies ist etwas Besonderes für Docker, da es als Init-System verwendet wird, das Sie von herkömmlichen Betriebssystemen kennen. Daher ist dies die PID, die alle anderen Prozesse, die Sie starten, steuern / neu starten / protokollieren muss.
Für einzelne Prozesscontainer ist dies trivial, da der gestartete Prozess dies normalerweise sowieso für sich selbst tut. Für mehrere Prozesse benötigen Sie einen Wrapper.
Es ist eine Dokumentation verfügbar: https://docs.docker.com/config/containers/multi-service_container/
http://supervisord.org/ ist sehr beliebt, um das Problem ebenfalls zu lösen.
Oder Sie werfen einen Blick darauf, wie die aktuellen Homepage-Container funktionieren, die ich im letzten Monat geschrieben habe, um sie in einzelne Service-Container aufzuteilen.

Ports :
Ich habe versucht, 33334 zu proxen, und es gab Probleme beim Herstellen einer Verbindung zum Backend, selbst wenn es verfügbar war.
Obwohl ich das Problem nicht vollständig behoben habe, vermute ich, dass der Speicherort für das Backend fest auf localhost: 33334 codiert ist, was in diesem Fall nicht
Eine langfristige Lösung wäre wahrscheinlich, entweder das Backend auf den Hostnamen des Containers in Ihrem Startskript zu setzen oder die Containes erneut aufzuteilen und das Frontend einfach auf das Backend zu verweisen.
Auch hier finden Sie möglicherweise Inspiration für den zweiten Fall in unseren vorhandenen Homepage-Containern (die nicht perfekt sind, aber dieses Problem lösen).

Ich habe nächste Woche mehr Zeit und kann Ihnen helfen, die Dateien neu zu schreiben, wenn Sie nicht weiterkommen.

Für einzelne Prozesscontainer ist dies trivial, da der gestartete Prozess dies normalerweise sowieso für sich selbst tut.

@ingwinlu Leider scheint es nicht so, als ob Node.js dies tut: / Ich denke, dies könnte gelöst werden, indem das Flag --init beim Ausführen von Containern übergeben wird. (https://www.elastic.io/nodejs-as-pid-1-under-docker-images/)

Ich vermute, das liegt daran, dass der Speicherort für das Backend auf so etwas wie localhost: 33334 fest codiert ist, was in diesem Fall

Der Standort ist eigentlich nicht fest codiert. Der Client wird immer auf demselben Host / Port wie das Backend (webd) bedient und greift einfach auf /api/ auf demselben Host zu.

Ich denke, der beste Weg, dies zu tun, besteht darin, die elektrad- und webd-Bilder zu trennen. Dann funktioniert das Festlegen der PORT env-Variable auch ordnungsgemäß.

node.js auf pid 1

Ich würde --init nicht vertrauen. Aber ein Wrapper-Prozess, wie er im Artikel vorgestellt wurde, klingt gut.

Der Standort ist eigentlich nicht fest codiert. Der Client wird immer auf demselben Host / Port wie das Backend (webd) bedient und greift einfach auf / api / auf demselben Host zu.

Wieder hatte ich keine Zeit, es zu debuggen. Ich habe 33334 so eingerichtet, dass es für eine der Adressen, auf die wir verwiesen haben, einen Reverse-Proxy darstellt. Das Laden der Website konnte fehlschlagen, da sie nicht auf eine Adresse zugreifen konnte, die zum Laden benötigt wurde. Dies war auch der Fall, wenn 33333: 33333 direkt belichtet wurde, wobei 33334 auf 443 (https) umgekehrt dargestellt wurde.

Ok, der neue Plan lautet also:

1. @ingwinlu erstellt eine minimale Elektra-Docker-Datei und einen Build-Job, der das Image automatisch erstellt und auf docker.com veröffentlicht ( @omnidan, können Sie uns Zugriff auf die docker.com-Registrierung für elektra gewähren? Benötigen Sie etwas anderes als Kontonamen? ?)
2. Basierend auf diesem Image erstellt @omnidan (mit Rezensionen von @ingwinlu) drei weitere Docker-Dateien / Images, die mit demselben Build-Job (oder Erweiterungen davon) erstellt wurden:
   
   
   
   1. erweitertes Bild mit voller Elektra (um die Web-Benutzeroberfläche interessanter zu machen),
   
   
   2. erweitertes Bild mit elektrad (für Live-Demo, Teil 1)
   
   
   3. erweitertes Bild mit Client / Web (für Live-Demo, Teil 2)
   
   

Als Endprodukt haben wir einen Build-Job, der vier Elektra-Images für jedes Commit in Master erstellt:

1. eine minimale für Minimalisten (oder mit wenig Bandbreite)
2. ein vollständiges Elektra-Testbild (für Leute, die Elektra ausprobieren)
3. ein Bild, das elektrad startet (für unsere Live-Demo und Leute, die die Web-Benutzeroberfläche ausprobieren)
4. ein Bild, das Client / Web startet (für unsere Live-Demo und Leute, die die Web-Benutzeroberfläche ausprobieren)

Ist das okay für euch beide?

Benötigen Sie etwas anderes als Kontonamen?

Ich brauche deine Docker Hub-Benutzernamen, das ist alles.

Basierend auf diesem Bild

Ist es schon fertig?

Vielen Dank, mein Docker Hub-Benutzername (Docker ID) lautet markus2330

https://hub.docker.com/u/elektra/ sagt, dass elektra / web bereits über 10.000 Pulls hatte. Ist es so beliebt oder macht unser Setup etwas falsch?

@ingwinlu Können wir den Build-Server erneut auslösen, damit "webui.libelektra.org" auf 1.5 aktualisiert wird? Oder können Sie bitte einen solchen Job implementieren?

Der Buildserver hat absolut nichts mit webui.libelektra.org zu tun.

Es wurde so eingerichtet, dass immer das neueste 1.5.0-Beta-Tag abgerufen wird. Ich habe es so geändert, dass es Folgendes verwendet: spätestens jetzt.

Siehe oben, ich habe einen Plan vorgeschlagen, nach dem Docker-Images erstellt und veröffentlicht werden, damit sie in Beziehung gesetzt werden können.

Meinen Sie damit, dass der Build-Server kein Webui bereitstellt? Gibt es einen Unterschied bei der Bereitstellung von Webui und der Homepage? Und wenn ja, warum?

Es wurde so eingerichtet, dass immer das neueste 1.5.0-Beta-Tag abgerufen wird. Ich habe es so geändert, dass es Folgendes verwendet: spätestens jetzt.

Danke! Wird es automatisch aktualisiert? Wann?

Siehe oben, ich habe einen Plan vorgeschlagen, nach dem Docker-Images erstellt und veröffentlicht werden, damit sie in Beziehung gesetzt werden können.

Meinen Sie damit, dass der Build-Server kein Webui bereitstellt? Gibt es einen Unterschied bei der Bereitstellung von Webui und der Homepage?

Weil es niemand getan hat. Ich habe es nur schnell eingerichtet, wie in den obigen Kommentaren zu sehen.

Und wenn ja, warum?

Weil niemand daran interessiert war, weiß ich es zumindest nicht. Es gibt auch einige Fragen, die zuerst beantwortet werden müssen:

• Woher sollen wir die Tags für die Bilder bekommen?
• Wie richte ich den Upload in die öffentliche Registrierung ein?
• Wie richte ich Zugriffsrechte auf die öffentliche Registrierung ein?
• Wann sollten Builds ausgeführt werden?
• ...

Ich habe derzeit kein Interesse daran, es umzusetzen, da ich dringendere Angelegenheiten zu erledigen habe.

Und wenn ja, warum?

Die Frage bezog sich darauf, warum es Unterschiede zwischen der Bereitstellung von Webui und Homepage gibt. Wir könnten die Web-UI-Bilder in unsere private Registrierung verschieben, um die Fragen zu lösen.

Das Pushing zu docker.com kann vorerst manuell erfolgen (für die Releases). Aber dies zu automatisieren wäre sehr dankbar.

@omnidan Haben Sie uns bereits zu hub.docker.com hinzugefügt? Benutzername: markus2330

Die neuen aufgeteilten Docker-Images (die nur einen Prozess ausführen) können identisch auf der Homepage erstellt, gepusht und bereitgestellt werden. wahrscheinlich.

@ markus2330 Ich habe Sie als Eigentümer hinzugefügt. Sie sollten jetzt in der Lage sein, neue Mitglieder auf https://hub.docker.com/u/elektra/dashboard/teams/?team=owners hinzuzufügen

Ich würde sagen, wir behalten webui.libelektra.org bei, um das öffentliche Docker-Image zu haben.

Und webdemo.libelektra.org wird bei jedem Commit im Master neu erstellt.

@ingwinlu Was denkst du?

Ich habe es in der # 2110 PR in webdemo.libelektra.org geändert

Ich denke, wir können das jetzt schließen?

@omnidan Kannst du bitte auch die Titelseite aktualisieren? Das "Upcoming:" ist jetzt länger wahr: smile: (Screenshot kann auch verbessert werden.)

Tolle Arbeit von euch beiden, danke!

@ markus2330 ja, wir können das schließen. Ich werde Ihnen morgen eine kurze PR für die Homepage schicken!

Ich danke Ihnen beiden auch, insbesondere