Ankündigung

Einklappen
Keine Ankündigung bisher.

Loxberry als Docker Container - /opt/loxberry/packages.txt

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • Loxberry als Docker Container - /opt/loxberry/packages.txt

    Hallo,

    ich bin gerade dabei einen Loxberry Docker Container zu bauen. Damit wird es dann auch einfacher sein, den Loxberry auf anderen Platformen, wie z.B. NAS-Systemen, etc. zu betreiben. Das Konzept von Docker sind kleine, handliche Container (ganz grob mit einer virtuellen Maschine vergleichbar). Im wesentlichen bin ich auch schon sehr weit, allerdings stört mich eines:

    In der Datei /opt/loxberry/packages.txt sind die notwendigen Packages für den Loxberry aufgeführt. Ich glaube aber, dass dies etwas zu grob / weit gefasst ist und viele Pakete enthalten sind, welche vielleicht für einen Raspberry-PI notewendig sind, nicht aber für die "Software" Loxberry. Als Beispiel die ganzen Raspberry-Firmware Module, etc.

    Grundsätzlich sollte jedes PlugIn, welches irgendwelche Pakete benötigt, diese auch im Rahmen der PlugIn installation angeben.

    Prof.Mobilux und @Christian Fenzl seht ihr eine möglichkeit die Datei zu verschlanken, sodass am Ende ein "schmaler" Container rauskommt?

    Grüße

    Michael

  • #2
    Die packages.txt enthält die Grundaustattung eines LoxBerrys. Alle Plugins können/müssen sich darauf verlassen können, dass diese Pakete auf dem System existieren. Da wir mit neuen LoxBerry-Versionen abwärtskompatibel sein wollen/werden, ist eine Verschlankung nicht möglich. Aber bis auf einige RaspPi-spezifischen Sachen ist das System schon recht minimal. Kein X, aber vieles, was Standard-Plugins brauchen.

    Die ganzen Raspberry-spezifischen Pakete kannst Du natürlich weglassen, die machen auf einem anderen System keinen Sinn.
    🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine


    LoxBerry - Beyond the Limits

    Kommentar


    • svethi
      svethi kommentierte
      Kommentar bearbeiten
      Lassen sich auch gar nicht erst installieren da für arm

  • #3
    Nach welchem Schema wurde die Datei initial erstellt? Ich möchte nur sehr ungern eine eigene packages.txt erstellen, da mir auch wichtig ist, dass das Docker Image von jedem genutzt werden kann und vollständig zum der nativen Raspberry installation ist.

    Trotzdem stellt sich mir die Frage, ob z.B. Libraries für X11 Screen-Saver (libxss1) benötigt werden, da auf dem Loxberry ja kein X-Server läuft.

    Kommentar


    • #4
      Ich schätze, das ist ein Auszug der installierten Pakete auf einem funktionierenden LB.
      Ich würde an deiner Stelle ein Filterscript machen, was aus der Datei alles aussiebt, was du für Docker nicht brauchst.

      Wenn das auf unterschiedlichen Plattformen ein unterschiedlicher Filter ist, ist das halt entsprechend mehr Arbeit.
      Dass wir LoxBerry Docker-spezifisch entwickeln, kannst du uns nicht aufbürden. Das ist - sorry für die Direktheit - dein Task.
      Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine

      Kommentar


      • #5
        Die packages.txt habe ich auf dem "Ur-LoxBerry" erstellt. Basis war das Minimal-Raspbian-Image. Anschließend habe ich alles installiert, was nach meiner Meinung "irgendwann einmal" von Plugins benötigt werden könnte. Dabei habe ich mich an verschiedenen Skript-Lösungen orientiert, die bereits im alten Loxone-Forum im Umlauf waren, z. B. Sonos, Kalenderanbindung usw. Nachdem ich "zufrieden" war, habe ich ein "dpkg -l > /opt/loxberry/packages.txt" gemacht. Mehr war/ist es nicht.

        Die X11-Libraries sind vermutlich drin, weil irgendein Paket diese als Abhängigkeit benötigt.
        🇺🇦 Hilfe für die Menschen der Ukraine: https://www.loxforum.com/forum/proje...Cr-die-ukraine


        LoxBerry - Beyond the Limits

        Kommentar


        • #6
          Zitat von Christian Fenzl Beitrag anzeigen
          Ich schätze, das ist ein Auszug der installierten Pakete auf einem funktionierenden LB.
          Dass wir LoxBerry Docker-spezifisch entwickeln, kannst du uns nicht aufbürden. Das ist - sorry für die Direktheit - dein Task.
          Das ist auch nicht meine Erwartungshaltung, da bin ich voll bei euch und ich sehe es auch als mein Task wenn ich es unter Docker betreiben will. Ich hab nur in vielen anderen Projekte schlechte Erfahrung gemacht, wenn man später Dinge entfernt, da es nahezu nicht überschaubar ist was dabei rauskommt. In der Community hier gab es immer mal wieder Anfragen Loxberry auf einer "nicht-Raspi" Plattform zu betreiben. Sei es eine virtuelle Maschine, Intel NUC, NAS-Systeme, oder auch vor mit schon mal nach Docker.

          Vorallem habt ihr eine wirklich tolle PlugIn Architektur erschaffen, sodass jeder PlugIn Entwickler seine benötigten Pakete direkt angeben kann.

          Mir geht es nicht darum in die "Vergangenheit" zu entwickeln, aber diese Überlegung für die kommenden Versionen aufzugreifen. Ein Aufruf an die PlugIn Entwickler, ihre apt-Dateien zu prüfen und zu erweitern, sollte machbar sein. Dann könnte man das Loxberry Basis-System / Installation deutlich schlanker und flexibler halten.

          Kommentar


          • #7
            Hallo Michael, bist du mit deinem Docker Image schon weiter gekommen? Fände ich sehr nützlich, da ich nicht extra eine VM für Loxberry laufen lassen möchte.

            Gruß
            Andreas

            Kommentar


            • #8
              Hallo Swallotail,

              ja ich habe den Loxberry im Docker Container nun seit ein paar Wochen am laufen. Das Dockerfile kannst du auf meiner GitHub Seite runterladen (https://github.com/michaelmiklis/docker-rpi-loxberry).

              Folgende Besonderheiten gibt es:
              - Der build dauert sehr lange, da extrem viele Pakete in den Container installiert werden
              - Beim ersten Start wird das Loxberry Repo / die Loxberry Datein in das gemountete Volume geclont.
              - Nach dem ersten Start des Containers muss der Loxberry Einrichtungsassistent durchlaufen werden - danach wird ein Neustart verlangt. Hier muss der Container gestopt werde und wieder gestartet werden. (noch sehr unschön - daher docker run nicht mit -rf Parameter)

              Sicherlich gibt es noch ein paar Plugin-Speziefische Baustellen, wenn die Plugins System-Dienste nachinstallieren oder benötigen.

              Interessehalber: Welche Plugin willst du nutzen?

              Gruß

              Michael

              Kommentar


              • #9
                Das sind ja schonmal gute Nachrichten - vielen Dank für deine Arbeit!

                Wäre es möglich, dass du in kurzen Worten beschreibst wie ich mir daraus ein Image bauen kann? Habe bis jetzt nur fertige Images von Dockerhub verwendet...

                Ist es möglich dem ganzen dann UID/GID zuzuweisen damit der Container nicht mit root Rechten läuft?

                Zu Deiner Frage - ich würde erst mal mit Miniserver Backup und Wunderground starten. Sofern das mit der Hardware klappt vielleicht zukünftig auch RCSwitch 433 Mhz.

                Kommentar


                • #10
                  Wie soll RCSwitch denn im Docker laufen?? Dafür brauchst Du GPIO
                  Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)

                  Kommentar


                  • #11
                    Zitat von svethi Beitrag anzeigen
                    Wie soll RCSwitch denn im Docker laufen?? Dafür brauchst Du GPIO
                    Dachte das läuft über einen USB Sender - dann hat sich das zumindest schonmal erledigt.

                    Kommentar


                    • #12
                      Zitat von svethi Beitrag anzeigen
                      Wie soll RCSwitch denn im Docker laufen?? Dafür brauchst Du GPIO
                      Das ist kein Problem - das funktioniert. Ich hab bei mir auch das 433Mhz Plugin (RCSwitch) IM Docker Container laufen und nutze einen am GPIO angeschlossenen 433Mhz Receiver und Sender. Hierzu muss einfach beim Starten für den Container (docker run) " --cap-add SYS_RAWIO --device /dev/mem" mitgegeben werden. Das steht auch als Beispiel auf meiner verlinken GitHub Seite.

                      Zum Image erstellen (ich kann es gerade nicht testen, glaube aber dass die Parameter passen)
                      - Die Dateien von Github herunterladen und in ein Verzeichnis rpi-loxberry/ packen
                      - Dann aus dem Verzeichnis darüber:
                      - docker build -t "michaelmiklis/rpi-loxberry:latest" rpi-loxberry/ (dauert sehr lange)
                      - danach sollte das Image über "docker images" sichtbar sein

                      Dann mit dem Beispielaufruf von meiner GitHub Seite (docker run ....) starten.

                      Grüße

                      Michael

                      Kommentar


                      • #13
                        Okay, und wo schließt Du den Sender dann an? Ich meine, wenn ich hier ein Docker auf meinem QNAP starte, dann wüsste ich halt gar nicht wo ich den anschließen söllte.
                        Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)

                        Kommentar


                        • #14
                          Ich hab Docker auf dem Raspberry laufen und dort verschiedenste Container (Loxberry ist nur einer davon). Angeschlossen an hab ich den Sender an die Raspi-GPIO PINs.
                          Bei einer QNAP müsstest du so oder so auf USB ausweichen. Das könnstest du aber prinzipiell auch in den Container durchreichen. Die Frage ist nur ob es 433 Mhz mit USB und Linux unterstützung gibt...

                          Kommentar


                          • #15
                            Haha, genau darum geht es doch aber. Auf einem Raspi brauche ich mich nicht zu verbiegen und ein Docker laufen zu lassen. Die Aussage war ja ganz klar, dass vom Raspi weg auf eine "richtige" Maschine umgestiegen werden soll. RAID, keine SD usw.
                            Miniserver; KNX; Vitogate; EnOcean (EnOceanPi); Loxone Air; Caldav-Kalenderanbindung; RaspberryPi und für keine Frickellösung zu schade :-)

                            Kommentar

                            Lädt...
                            X