alternatives Docker Image

[henfri]

Aber ich kann das gerne versuchen voran zu treiben, wenn ich von den offiziellen Maintainern das OK bekomme. henfri / SaschaG bzw. bmx / Msinn / psilo / Onkelandy

Na klar bin ich einverstanden!

[Onkelandy]

Ich denke, das ganze Projekt lebt von der Community und der Tatsache, dass es auf verschiedenen Wegen zugänglich wird. Ein "offizielles" Dockerimage, um das sich mehrere Leute außerhalb vom Core kümmern, begrüße ich sehr.
Morg ist übrigens auch im Coreteam.

[jentz1986]

Du kannst höchstens mal auf https://www.docker.com/community/ope...e/application/ schauen, ob das auch kostenlos geht für Open Source Projekte

Die Seite liest sich ja so, dass das passt. Ich würde mir jetzt nur nicht einfach so anmaßen für SHNG zu sprechen... Aber ich kann das gerne versuchen voran zu treiben, wenn ich von den offiziellen Maintainern das OK bekomme. henfri / SaschaG bzw. bmx / Msinn / psilo / Onkelandy

[jentz1986]

Hi!

Ich würde aber den existierenden "offiziellen" Weg über Hendrik bevorzugen.

Don't fix what is not broken :-) Gerne! Der einzige Haken daran ist, dass damit die Arbeit bei henfri liegt und nicht verteilt werden kann. Das wäre bei der Organisation besser, aber hmm. henfri kannst Du Dir vorstellen ein DockerHub Personal Access Token in die GitHub Secrets zu packen? Dann könnten wir die Berechtigungen für das Docker-Repo erweitern und trotzdem den bewährten Distributionskanal verwenden.

Codebase auf Github

Das ist das Entscheidende - eine Codebase. Die Zusammenarbeit erfolgt über Pull Requests und Code-Reviews. Sprechende Commit-Kommentare retten die Kommunikation und Feature/Strategiediskussionen dann von mir aus hier oder über Gitter. Mein Fork ist aus der "Not" geboren, die Dinge nachvollziehbar zu teilen ohne das Original in Frage zu stellen und nicht, weil ich was eigenes aufziehen will. henfri Machst Du das Quality-Gate, ich stell dann einen Pull-Request?

Wie binde ich User Plugins mit ein

Mein Vorschlag ist der: Nutze ein Plugins-Default Verzeichnis im Image um die Standard Plugins aus dem Repo "vollständig" vorzuhalten. Das Einkopieren der Plugins aus dem Plugins Verzeichnis außerhalb des Containers passiert nur für die Plugins an denen man fummelt. Vorteil: Einfach das Verzeichnis löschen, das stört, und sofort nach dem Containerneustart ist alles wieder fein. In meiner Pipeline zuhause führt jede Konfigurationsänderung zu einem Containerneustart, und alle Plugins werden aus den jeweiligen individuellen Repositories neu geladen (dauert <2 sek). Damit zwinge ich mich über Git zu arbeiten und meine Änderungshistorie nachzuhalten.

Mounten aller Plugins unter einem bestimmten Pfad.

Hatte ich auch überlegt, aber das sind schon echt viele Plugins und das ist auch unübersichtlich. Um hier dann wieder "auf Standard" zurückzukommen muss man wieder git bemühen.

Ich würde für das Gesamtsystem irgendwie gerne dahin kommen, dass die Plugins jeweils einzeln in Github-Repositories liegen und man quasi nur eine Registrierung (Ähnlich "Packagesource") in das offizielle Repo macht, um die Plugins versionskontrolliert an das offizielle Release zu binden (ich glaube HomeAssistant macht das auch so). Dann könnte man den Usern auch die Möglichkeit geben, über die GUI ein Git-Repo als Plugin-Quelle zu definieren, zack ist das ganze Problem gelöst und das Ökosystem kann florieren, damit lässt sich auch das "Lizenzproblem" lösen, wenn man dritten Code im Plugin nicht über pip-Sourcen einbinden kann. Das ist natürlich ein vollständiger Strategiewechsel und sicher nicht in einem Release getan. Und wahrscheinlich übersehe ich noch sechshundertdrölfzigtausend Gründe die dagegen sprechen. Evtl. ist diese Diskussion aber einen eigenen Thread wert.

Zurück zum Container:
Ich bin übrigens nicht so der "Linux-Admin" - d.h. die ganzen chown, gosus etc. verstehe ich zwar grob, aber so richtig fit erlebe ich mich darin nicht. D.h. das was ich jetzt ergänzt habe muss von jemandem, der/die/* das kann nochmal gecheckt und ggf. ergänzt werden.
Was ich auch noch nicht gerafft habe ist das Faktum, dass ich bei mir immer noch ein chmod +x für die Entrypoint/Wrapperscripte machen musste um den Container lauffähig zu bekommen. Ich finds zwar logisch und konsequent, frage mich aber, warum das in euren Varianten bisher nicht nötig war...

Danke fürs Lesen bis hierhin 🙃

Grüße,
Jens

[SaschaG]

Hallo

Ich denke es ergeben sich verschieden Fragestellungen die wir evtl. aufsplitten sollten:

1. Wann tellen wir den Usern ein aktuelles Image zur verfügung? Hier sit der Verbreitungsweg evtl. egal. Ich würde aber den existierenden "offiziellen" Weg über Hendrik bevorzugen.
2. Wie arbeiten wir zusammen? Die Codebase auf Github von Hendrik scheint mir dafür ausreichend.
3. Wie binde ich User Plugins mit ein?
   1. Hendriks Vorschlag: Manuelles Mounten der Plugins. Vorteil: Native Docker Bordmittel. Nachteil: Kann bei vielen Plugisn unübersichtlich werden.
   2. Jentz Vorschlag: Kopieren von (ZIP?) Datein in das Image? Vorteil? Einfacher zu konfigurieren. Nachteil: Neustart für Update?
   3. Neuer Vorschlag: Mounten aller Plugins unter einem bestimmten Pfad. Vorteil: Einfach zu konfigurieren. Direktes bearbeiten der Dateien möglich. Nachteil: ?

Gruß
Sascha

[bmx]

jentz1986 Du kannst höchstens mal auf https://www.docker.com/community/ope...e/application/ schauen, ob das auch kostenlos geht für Open Source Projekte

[jentz1986]

henfri - Ich hätte den Knopf "create organization" vorher drücken sollen, bevor ich hier das mit der Organisation poste. Das kostet mindestens 35 EUR/Monat. Das würde ich bei aller Liebe fürs Thema nicht persönlich ausgeben wollen. Zumal der Wert ja nur ist, dass man den Container dann von mehreren Ecken erstellen kann. Aber das geht mit Github Actions ja auch, weil man den Workflow dann über Berechtigungen aufs Repository steuern kann.

Aktuell verwenden Core und Plugins die Github Actions zum automatisierten Testen

Wieviel von den 2000 kostenfreien Minuten pro Monat wird da bisher genutzt? Einmal Container bauen und auf dem Hub veröffentlichen sind ca. 5 Minuten - hab ich gestern getestet 😁.

[henfri]

henfri, SaschaG Sollten wir auf DockerHub eine Organisation SmarthomeNG gründen? Dann könnten wir ein "offizielles" Docker Image bauen...

Ja, gerne!

[bmx]

... dann auch der Ansatz mit den GitHub Actions

Aktuell verwenden Core und Plugins die Github Actions zum automatisierten Testen

[jentz1986]

henfri, SaschaG Sollten wir auf DockerHub eine Organisation SmarthomeNG gründen? Dann könnten wir ein "offizielles" Docker Image bauen...

[jentz1986]

Hi!

das Dockerfile hat sich seitdem ordentlich weiter entwickelt.

Danke für den Hinweis, das hatte ich nicht wahrgenommen.

Ich habe jetzt den Branch oben noch einmal neu aufgebaut und alle relevanten Änderungen, die ich gemacht habe auf eurem Dockerfile neu abgespielt. Die Commit-Historie sollte jetzt einen angemessenen Überblick geben, was ich mir wo gedacht habe.

Hier: jentz1986/shng-docker at publish (github.com)

pack doch pymysql einfach immer rein

Danke für die Freigabe, das habe ich dann einfach gemacht :-) (siehe letzter Commit).

Ich habe das Teil so noch nicht getestet, ich muss das noch bei mir lokal auf diesen Stand drehen. Wenn das dann läuft, baue ich die Github-Actions Datei.

EDIT: Meine echte Umgebung läuft nun auf Basis dieses Dockerfiles. So mag ich das!
EDIT2: Ist jetzt per GitHub Actions auf den Dockerhub gepusht, als: jentz1986/smarthomeng:v1.9.2beta0

[henfri]

Finde ich gut. Aber Vorsicht: das Dockerfile hat sich seitdem ordentlich weiter entwickelt.

Aber pack doch pymysql einfach immer rein.
Schadet doch nicht.

[jentz1986]

Hi!

Ich freue mich, dass wir jetzt in diese Diskussion kommen :-) Ich hätte das zwar eher versucht, auf Gitter zu machen, aber so ist das ja auch gut ;-)

Warum sind mehrere Varianten nötig?

Scheinbar wird ja mysql immer noch als Underdog betrachtet - weil es in keinem der Images vorhanden ist, und für die Mehrheit auch nicht nötig ist. Ich brauche mysql, daher muss ich die Library haben. Das sind schon zwei Varianten. Alles andere ist mehr ein "weil es geht" :-) Mit dem nächsten Release von SHNG wird Python 3.10. Standard, daher fliegt dann zwave raus. Das könnte Variante 3 werden. Oder auch nicht, dann baut man allerdings wieder ein "alles geht" Maximal-Image.

Wäre es nicht sinnvoll auf dem Dockerfile von Sascha und mir aufzubauen?

Das ist es ja. Es ist das Dockerfile, welches ich im Juli vom ersten Post heruntergeladen habe. Nur eben um Bugfix(es) erweitert und mit der Funktionalität ausgestattet, die es möglich macht, Plugins einfach in ein Verzeichnis zu packen, statt neu zu mounten. Das soll es Einsteigern leichter machen - und mir nebenbei auch, weil ich mehrere andere Workflows daran gekoppelt habe. (Ich bastele an fünf Plugins mit rum, da war die Mountliste schon unübersichtlich).

Ich will ja gar nicht unnötig Varianten und unterschiedliche Herangehensweisen propagieren, und wenn alles im Standard für mich funktioniert hätte, wäre ich sofort auf Standard "zurück" gegangen. Was ich brauche, entwickle ich, und wenn es jemand auch brauchen kann, bitte.

Wir (SmarthomeNG Entwickler Community) sollten in der Lage sein, die Docker-Images automatisch auf dem passenden Stand zu halten, daher dann auch der Ansatz mit den GitHub Actions, damit das wechseln der Version nach einem Release der Quellrepos schnell geht. Ich baue das gerne weil das mir Spaß macht - für meinen Stack zuhause habe ich das in Gitlab realisiert - brauche das also nicht.

[henfri]

Hallo,

Plugins kann man doch ganz einfach über das mounten eines Plugin-Verzeichnis in das entsprechende Docker-Verzeichnis machen.

Warum sind mehrere Varianten nötig?

Wäre es nicht sinnvoll auf dem Dockerfile von Sascha und mir aufzubauen?

Gruß,
Hendrik

[jentz1986]

Das Ziel ist, den Bugfix von oben, die pymysql-lib, die Möglichkeit dynamisch eigene Plugins nachzuladen und das Update auf 1.9.2 in einer nachvollziehbaren Art und Weise für einen Merge anzubieten… Ggf. noch automatisches bauen mehrerer Varianten (mit/ohne mysql, python 3.9 vs. 3.10.) basierend auf einem neuen Tag im SHNG Repo. Und das kann man nur im eigenen Repo bauen.

EDIT: Hier mein Dockerfile jentz1986/shng-docker at publish (github.com) - jetzt muss ich nur noch einen Weg finden einen vernünftigen Diff zu bauen, aktuell sind das leider zwei völlig unabhängige Stränge, weil ich mit den Dateien hier im Forum gestartet bin und nicht mit nem Repo.

Nächster Schritt: Github Actions einbauen um bei Pushes automatisch nach Dockerhub zu veröffentlichen.