Um das Leben unseres Dieners @pierre-gilles zu vereinfachen und damit er noch mehr Zeit für den Code verbringen kann , können die Builds des raspbian-Images automatisiert werden.
Ich habe pi-gen eingerichtet und konfiguriert, um ein Gladys-Image zu erstellen. (pi-gen ist das offizielle Tool der Raspberry Foundation).
Ich habe es auf einem rpi 3 B+ getestet, aber ich brauche Freiwillige!
Weißt du, ob es möglich wäre, die Verarbeitung, die du beim ersten Start durchführst, vorher zu machen? Ich habe Angst, dass dies ein Schritt ist, der bei den Nutzern oft schiefgeht (schlechte Verbindung zum Beispiel, der Nutzer hat keine Ahnung, wann es fertig sein wird…)
Das Bild mit den erstellten Containern bereitstellen? Ja, das ist möglich
Hier habe ich einen Dienst (systemctl) erstellt, der darauf wartet, dass das Netzwerk hochgefahren ist.
Bei jedem Start überprüft er, ob die Container existieren.
Der Vorteil ist, dass es immer die neueste Version herunterlädt.
Meine Meinung ist, dass die Option oder das Bild nur beim Booten heruntergeladen wird, das ist eine sehr frustrierende Erfahrung für die Benutzer: Es ist unmöglich zu wissen, wie weit es ist, wenn deine Verbindung nicht gut ist, wird es 2 Stunden dauern, aber du weißt nicht, was passiert.
Danach, wenn wir das Raspbian-Bild bei jedem Build des Docker-Bildes erstellen, ist es am Ende dasselbe, das Bild wird immer auf dem neuesten Stand sein
Ja, ich sehe, kein Problem (ich hab mich nur aufgeregt, einen Service zu machen / nicht schlimm, ich hab was gelernt ^^ ).
Ich werde also das Build ändern, die Container werden bereits erstellt. Ich werde auch den Service ändern, um diese Container zu „monitoren“ und in dmesg zu loggen.
Ich komme auf das zurück, was ich gesagt habe, der Cross-Build ermöglicht es mir nicht, ein Image während des Builds zu pullen, da Docker nicht weiß, auf welcher Architektur es ausgeführt wird.
level=error msg="failure getting variant" error="getCPUInfo for pattern: Cpu architecture: not found"
Ach Mist, gibt es keine Möglichkeit, das zu umgehen? Kann man nicht die Architektur im docker pull-Befehl angeben?
Ich bevorzuge das trotzdem im Vergleich zum Download, der von deiner Verbindung abhängt. Bei einem Typen mit ADSL wird der Download mehr als 1 Stunde dauern, während ein Untar die Zeit konstant hält
Gut gemacht in jedem Fall für all diese Untersuchungen!
Super! Kleine Frage übrigens, du machst doch ein load style:
docker load --input ton-image.tar
Hast du das Bild nicht komprimiert? Ich sage das, um zu sehen, ob wir nicht Zeit sparen können, wenn es komprimiert ist, dauert es meiner Meinung nach länger, um zu dekomprimieren!
Ich habe noch keine Lösung, der Docker-Daemon weiß nicht, auf welcher Architektur er sich befindet (QEMU-Bug). Der Daemon wird während des Builds nie gestartet.
Das Problem liegt nicht am Docker-Image. Ich kann den Docker-Daemon des Raspbian-Images während des Builds (chroot / qemu) nicht ausführen, da es einen QEMU-Bug gibt. QEMU gibt keine Informationen zur Architektur, und der Docker-Daemon stürzt ohne diese Informationen ab.
Um das zu umgehen, speichere ich das Image mit Docker des Hosts, der das Raspbian-Image erstellt.
Hinweis für Tester 
, können die Builds des raspbian-Images automatisiert werden.
/ nicht schlimm, ich hab was gelernt ^^ ).
