[TEST] Image Raspbian Beta

:warning: Avis aux testeurs :warning:

Dans l’idée de simplifier la vie de notre serviteur @pierre-gilles et afin qu’il puisse passez encore plus de temps sur le code :wink:, les builds de l’image raspbian peuvent être automatisés.

J’ai donc mis en place et configuré pi-gen pour builder une image Gladys. ( pi-gen est l’outil officiel de la fondation raspberry ).

Je l’ai testée sur un rpi 3 B+ mais j’ai besoin de volontaires !

Le dépot est sur github => https://github.com/VonOx/gladys-pi-gen

Informations sur le build:

  • Kernel 4.19
  • Base debian lite buster
  • Openssh
  • Docker
  • Reduce ( Suppression de tous les man page,doc et caches apt )

Taille de l’image 635MB

1er démarrage

  • partition de la carte SD étendue
  • reboot
  • Load des conteneurs Watchtower et Gladys

Note:

  • Il faut environ 15 minutes lors du 1er démarrage pour que le conteneur Gladys soit disponible
  • Lors de la 1ère connexion en SSH vous devrez modifier le password ( gladys/raspberry par défaut )

Download:

Le fichier info contient tout les packages installés

J’ai déposé les fichiers sur un partage OneDrive .

Screenshot:

Le build est d’aujourd’hui :slight_smile:


Changelog:

2020-05-27 - Nouvelle image => règles udev et log de 10MB maxi pour docker
2020-04-28 - Nouvelle image avec les images Docker ( docker save )
2020-04-21 - Code sur Github
2020-04-16 - First release

2 Likes

Aaaah top ! Bien joué !

Tu sais si il serait possible de faire le traitement que tu fais au first boot avant? J’ai peur que ce soit une étape qui rate souvent chez les utilisateurs (mauvaise connexion par exemple, l’utilisateur n’a aucune idée de quand ça va finir…)

Fournir l’image avec les conteneurs créés ? Oui c’est possible

La j’ai créé un service (systemctl) qui attend que le network soit up.
A chaque démarrage il vérifie que les conteneurs existent.

L’avantage c’est que ça pull toujours la dernière version.

Mon avis, c’est que l’option ou l’image est téléchargée uniquement au boot, c’est une expérience très frustrante pour les utilisateurs: impossible de savoir ou ça en est, si ta connexion est pas terrible ça va prendre 2h mais tu ne sais pas ce qui se passe.

Après, si on build l’image Raspbian à chaque build de l’image docker, au final ça revient au même l’image sera toujours à jour :slight_smile:

Oui je vois, c’est pas un problème ( me suis juste fais ch**r à faire un service :smiley: / pas grave j’ai appris des trucs ^^ ) .

Je vais donc modifier le build, les conteneurs seront déjà créés. Je vais aussi modifier le service pour “monitorer” ces conteneurs et logger dans dmesg.

1 Like

J’ai poussé sur Github , build en cours en prenant en compte les modifs

1 Like

Wow, @VonOx super idée ça. J’essaye et je fais un retour bientôt.

J’étais naze hier soir, j’ai pas upload l’image, je fais ça ce soir pour ceux que ça intéresse.

1 Like

Je reviens sue ce que j’ai dit, le cross build ne me permet pas de pull une image pendant le build car docker ne sait pas sur quel architecture il s’execute.

level=error msg="failure getting variant" error="getCPUInfo for pattern: Cpu architecture: not found"

Un contournement possible serai de sauver l’image => https://docs.docker.com/engine/reference/commandline/save/
Puid de load au firstboot => https://docs.docker.com/engine/reference/commandline/load/

Pas encore testé mais ça risque d’être aussi lent car c’est un zip / dezip.

T’en penses quoi @pierre-gilles ?

J’ai tenté avec le save/load

C’est kiff/kiff , 15 minutes pour untar sur un rpi b+

Ah mince, sûr qu’il n’y a aucuns moyens de contourner? Tu peux pas préciser l’architecture dans la commande docker pull?

Je préfère quand même par rapport au download qui est dépendant de ta connexion. Chez un gars en ADSL, le DL ça sera plus 1h, la ou un untar le temps restera constant :slight_smile:

Bien joué en tout ca pour toutes ces investigations!

J’ai push sur Github et mis une nouvelle image à disposition ( +147 MB )

1 Like

Nice ! Petite question au fait, tu fais bien un load style:

docker load --input ton-image.tar

Tu n’as pas compressé l’image? Je dis ça pour voir si on peut pas gagner du temps, si c’est compressé ça prend plus de temps à décompresser à mon avis !

Le docker save fait la compression pas le choix.

1 Like

Nouveau build:

  • Log a 10MB maxi pour gladys
  • 1ère version des règles udev ( sur l’hote uniquement / je cherche une façon élégante et safe de faire dans l’image docker )

J’attends vos retour :wink:

1 Like

Top ! :clap:

Pour l’histoire du temps un peu plus long au premier démarrage, pas de piste pour arriver à faire le docker run en amont?

Non j’ai pas encore de solution, le daemon docker ne sait pas sur quelle architecture il se trouve ( bug qemu ) le daemon n’est jamais lancé pendant le build.

Je perd pas espoir :sweat_smile:

Et si on passait par une image qui n’utilise pas l’architecture? (je ne sais pas si c’est possible)

C’est même pas l’image docker le soucis. Je ne peux pas exécuter le daemon docker de l’image raspbian pendant le build ( chroot / qemu ), il y’a un bug qemu, il ne donne pas d’information sur l’arch, le daemon docker plante sans cette information.

Pour contourner ça, je save l’image grâce au docker de l’hôte qui build l’image raspbian.

Je sais pas si c’est clair :sweat_smile:

Mmm ok, dommage! Je vois :slight_smile:

Je sais pas si tu as vu, mais maintenant la fondation Raspberry Pi fournit une image 64 bits ^^ Il va falloir qu’on build 2 images :sweat_smile: