Il transforme Google en trafiquant D'ARM

Archi con

Prank, ça tourne mal ! Je me suis frotté à une demande de mon client tout à fait légitime, mais pas simple :

Builder des libs Python + C pour l’environnement d’exécution Raspberry pi + mission subsidiaire, construire des golden images Raspberry pi.

Alors attention quand je dis golden image, rien à voir avec les trucs bizarres qu’on fait dans la douche. 🙄

On ne va pas pisser non plus sur des Raspberry pi, par contre on va rager et cracher du sang. 🤪

Moi je fais dans le sonore et le dégueulasse ! C’est mon style. (Marv, sin city)

Une golden image c’est tout simplement une image système packagée prête à partir en prod avec une version propre.

Yeux en maintenance, cerveau en vacance

Je n’y connais rien en compilation, rien en archi de proc, presque rien en virtu. 🤷

Moi mon truc c’est de pop des VM et des services managés, faire de la glue entre les services, rager, et brutforcer des solutions jusqu’à l’épuisement.

J’appelle ça la méthode Blitzkrieg en hommage à la technique de guerre allemande qui consiste à percer les lignes ennemies et avancer le plus vite vers la capitale ennemie.

J’aime autant vous dire que cette fois ci, on passera pas par les Ardennes, on va plutôt faire tout le tour de la belgique en autostop. 🤪

Je ne lis pas trop les docs, et le hardware c’est pas trop mon histoire. Moi je pousse les murs dans tous les sens et je boloss mon CPU à coup de pied dans l’horloge.

Donc bon, j’ai fait une VM Debian 11 x86 sur mon poste, j’ai mis du Qemu dedans, j’ai réussi à faire tourner une Debian ARM dans une Debian x86.

J’ai builder un docker armv7 dans ma connerie de VM, ça tourne sur Rasberry pi (qui est ma cible finale) et ça simplifie grandement le temps d’exécution et de build de mes dépendances Python + C.

J’ai un truc 🤷, c’est moche, mais c’est tombé en marche.

J’aurais pu m’arrêter là, mais la haine m’a aveuglé

Je mets ça dans une VM sur GCP et je me dis que quand même, c’est bien de la merde. 🤪

Ça fait une VM dans une VM qui va peut être lancée aussi des dockers. 😏

Je n’ai pas envie de maintenir ça, je ne veux pas qu’à mon départ, quelqu’un reprenne ce truc, avec mon nom dessus. 😆

Je me dis : putain de bordel de merde, j’ai mis une VM dans une VM, je vais descendre d’un niveau.

Je vais prendre ma putain de VM ARM et la rentrer dans GCP à gros coup de pied de biche. 🕵️

Ça tourne dans Qemu, peut être que ça rentre dans GCP. 🤷

Non, ça ne rentre pas, on me l’a dit hein 😏 j’ai compris le concept, mais j’ai quand même fait le forceur. 🤷

Scoop, j’ai ragé comme un gamin refusé à l’entrée du Space Mountain. 🤷

J’ai réussi à faire rentrer mon image dans le bon format dans l’image registry de Google, mange toi la doc tu verras comme c’est chiant. 😆

Je lance mon image, ça a l’air de booter, mais j’ai oublié un détail :

Je n’y connais rien en proc et en virtu, donc je fais n’importe quoi.

On ne rentre pas de l’ARM sur du x86 sans une méga couche de traduction (encore une fois on me l’avait dit). 😅

Qemu fait ça, pas GCP. 🤷

Je n’y peux rien les gars, on me demande de rendre service, je rends service.

Retour à la raison, ou pas

Bon, on arrête les conneries ? Hum, spoilers, NON.

Idéalement, je ne veux pas d’une VM bricolée qui tourne dans une autre VM.

Si ça doit tourner en permanence pour faire des builds de CI/CD, il me faut une façon propre de la superviser et de redémarrer les deux VM sans erreurs et sans galère.

Le temps de build est moins important que la fiabilité de la CI/CD pour moi, donc je vais faire une double VM manageable avec Libvirt.

L’idée c’est de sauvegarder l’état de la VM ARM64 et de faire en sorte que quand on reconstruit la machine x86 et à chaque redémarrage, cette seconde VM boot dans la VM hôte automatiquement.

Tu me suis ? C’est la merde un peu non ? Les yeux qui saignent ? La gueule de bois ? Prend une banane, ça aide. :)

Body build des golden images raspbian

Maintenant que le sort des lib est scellé, on passe aux golden images.

On a investi du temps sur du Packer et du Qemu pour mettre en place la première machine, on va recycler le bouzin. 😏

On peut utiliser Packer et Qemu pour faire un Packer dans Debian et lancer des scripts dans Rasbpian. 🕵️

Je ne vais pas donner les sources que j’utilise, pour des raisons évidentes de légalité. (J’ai fait ça sur mon temps de travail donc techniquement le code appartient à mon client.)

Par contre je peux te donner deux trois trucs qui te feront moins galérer et gagner un peu de temps, tu me suis ? Pas de codes, pas de procès. 🤪

Par contre aucun souci pour vous détailler comment j’ai installé mon Bouzin et ce à quoi il faut faire gaffe pour avoir une installation qui marche. 👮

Être un vrai cyberpunk à chien, c’est parfois savoir respecter la loi. 🤣🤣🤣

Premier truc important, j’utilise une Debian 11, donc si tu veux tenter avec autre chose, il te faudra adapter les paquets.

Premier truc très très très énervant, on s’appuie sur un driver Qemu custom versionné dans Github, mais jamais tagué.

Là on dit bravo, parce que bien entendu le driver s’accroche à une version de Packer, mais pour savoir qui va avec quoi, bonne chance. 😭😭😭😭

Donc moi j’ai validé ma connerie avec une version fixée de Packer, une version fixée du driver ARM Packer et une version fixée de Raspbian.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20

#image Raspbian headless et sont checksum (tu peux utiliser des fichiers locaux au lieu de télécharger l'image à chaque fois)
https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-05-28/2021-05-07-raspios-buster-armhf-lite.zip
https://downloads.raspberrypi.org/raspios_lite_armhf/images/raspios_lite_armhf-2021-05-28/2021-05-07-raspios-buster-armhf-lite.zip.sha256

#version de packer fixé avec son driver
https://releases.hashicorp.com/packer/1.7.8/packer_1.7.8_linux_amd64.zip

#version de go utilisé pour builder le driver
https://dl.google.com/go/go1.14.2.linux-amd64.tar.gz

#version du driver qui match la version de packer avec le commit fixé
https://github.com/mkaczanowski/packer-builder-arm
version: b2f3c64f88e1ae3d49766e4a84db473abeac5dc5

#builder le driver
go mod download && go build'

# activation de binfmt_misc (requis au moment du build avec packer, non persisté au reboot)
echo 1 > /proc/sys/fs/binfmt_misc/status
echo ':arm:M::\x7fELF\x01\x01\x01\x00\x00\x00\x00\x00\x00\x00\x00\x00\x02\x00\x28\x00:\xff\xff\xff\xff\xff\xff\xff\x00\xff\xff\xff\xff\xff\xff\xff\xff\xfe\xff\xff\xff:/usr/bin/qemu-arm-static:' > /proc/sys/fs/binfmt_misc/register

Je te conseille dans un premier lieu de partir de là, fais marcher le merdier et après ça, customise comme tu veux 😏

Croquant gourmand, n’oublie pas le piment et les bouts de verre 🤷

C’est quoi ton bordel, on y comprend plus rien

Voici un petit schéma pour recadrer un peu, parce que franchement c’est la merde on ne pige plus rien hein ?

Donc on a une VM au premier niveau en x86 dans laquel on met Qemu, Packer et Gitlab runner. Dans cette VM comme on a un Qemu qui tourne déjà on virtualise un Debian 11 ARM caca et on y met un runner Gitlab-ci avec Docker. De cette façon, on ne fout plus jamais les pieds dans la seconde VM, et ça nous build en pagaille et dans du Docker.

On fait une CI/CD avec ça ? et tu veux pas 100 balles et un mars ?

On part sur un truc un peu sérieux pour déployer, on pourrait faire un git Hook, mais mon client a déjà un Gitlab et utilise des runners Gitlab. 🤪

Donc on va faire un Runner Gitlab dans le serveur Debian 11 x86.

Pour que Packer et Qemu marche bien, il faut que le runner Gitlab soit sudoer et lancer la commande Packer en sudo. 🙄

C’est moche, mais c’est comme ça , il faut des droits privilégiés pour faire du chroot. 🙂

Pour faire ça, c’est au niveau user Linux qu’il faut donner le groupe sudoer à l’utilisateur Gitlab-runner + activer le sudo no passwrd pour cet utilisateur. 😏

Petite verrue au cul, comme Packer est privilégié, il faut supprimer le Packer cache créé par root au moment du provisioning, avant de finir le build.

Sinon prochain run bloqué, car Gitlab refusera de delete les fichiers de cache.

Vous pouvez utiliser une image locale à condition d’avoir un sha256 dans un fichier et de respecter le même format que Packer.

Je vous encourage à faire ça avec une image de base déjà update pour gagner du temps à chaque builds.

Tout ça dans un tar gz c’est moins lourd.

Il vous faut ensuite un blob storage pour ranger vos images bien au chaud. 🤷

Pour avoir le droit de faire ça proprement j’ai attaché un service account avec les droits admin object storage, comme ça le compute peut pousser sur GCS sans traîner une clef d’API dans Gitlab secret. 🙂

Tu sais quoi ? j’emmerde cette merde, fuck it, I quit

raaaaaaaaaaaah, mais c’est nul, c’est nul, c’est nul, c’est nul, dégager moi cette dauble infâme !

Donc on est d’accord, ce machin ne peut pas être une solution long terme, ça pue de la gueule tellement fort qu’il faut une intervention RH.

Ce n’est pas possible de travailler professionnellement comme ça à l’échelle.

J’ai respiré un bon coup et je me suis dit, mais comment font les autres ?

Google viens pas chez moi flasher le google assistant, ou alors je ne les vois pas rentrer par effraction chez moi. 😏 il ne doit surement pas faire des connexions ssh sur ma machine et sur les milliers de devices connectés dans le monde.

Alors j’ai cherché et j’ai trouvé balena.io.

Je ne pense pas que Google utilise ça en interne, mais le produit répond à un paquet de sujets :

• gestion de flotte
• bulk update
• build de containers de façon industrielle (sur des cibles serveur plus costauds que moi je pense)
• distribution porte-container auto updatable à distance et rollback en cas d’échec
• supervision des ressources des machines
• mode dev qui permet un accès ssh passwordless depuis la console balena.io
• stream de container

10 premiers devices gratuit, avec toutes ses features.

Après le pricing semble correct pour le service rendu.

J’ai joué avec en mode dev, c’est vraiment très cool pour pousser du code au km sans savoir si ça tourne ou pas. Plus besoin de run local, ça déploie à cible directement, dinguerie, mais pourquoi je me fais autant chier moi ?

Et vous savez quoi ? Les containers c’est encore plus drôle, j’ai fait un Docker in Docker ARM depuis une image Docker dind qui marche aussi en x86. Docker dind c’est pour builder des docker dans docker par exemple, mon besoin c’est d’utiliser un runner Docker Gitlab pour builder des images Docker ARM.

Parce que maintenant j’ai décidé de faire des containers Docker ARM mais sans passer par Balena.

Je vais trouver la vérité, sur ARM, Google, et la déviance des reptiliens pédo-satanistes.

Con clusion intestinale

J’ai les boyaux en vrac et la sale impression d’avoir fait de la merde. Ça fait bien chier tout ça !

Pourquoi tant d’amateurisme dans les outils et les procédures que j’ai mis en place sur ce projet ?

On a l’impression que le monde de l’embarqué manque de solutions simples et efficaces pour travailler sereinement et avec des procédures d’automatisation industrielle.

J’aurais pu lâcher l’affaire et passer vers des machines ARM AWS à tout moment, c’est vrai. Mais j’ai essayé de me projeter dans une stratégie à long terme.

Si on multiplie trop les services de cloud, on risque de perdre la trace des différents comptes et souscriptions, perdre la trace des machines pour des runners Gitlab.

Mon choix à été de tordre un peu GCP plutôt que multiplier les factures et les souscriptions.

Il est prévu que GCP sorte des machines ARM en 2023, j’espère bien que d’ici là mon immonde bricolage ne sera plus nécessaire. 😏

Cette solution pour moi est temporaire, j’espère qu’elle sera utile et fiable le plus possible. Je pense que moyen et court terme, une solution à base de containers pourrait être une solution qui scale beaucoup plus dans la durée, à condition d’avoir des outils performants et professionnels pour permettre des mises à jour à distances et contrôlées.

Ce n’est pas une solution viable de ramener les machines en SAV, les démonter et reflasher la carte pour les mettre à jour, pas plus qu’un humain connecté à distance pour bricoler dans les machines.

Il me semble important que les versions livrées soient atomiques et sans trop de manipulations manuelles (idéalement aucune), pour être certain de la qualité de la version livrée et pouvoir à tout moment rollbacker de version en cas de problème.

Une fois n’est pas coutume, Hashicorp c’est relou, mais ça aide un peu pour les trucs à l’ancienne. 😏 Je vous ai dit que je n’aime pas Packer ? Peux-être dans un prochain article ? 🤭🤭

Fun fact, je cherchais des illustrations sur google image en tapant packer, je suis tombé là-dessus, l’occasion était trop belle pour ne pas le mettre ! Packer, ça veut dire scrotum en argot anglais, c’est marrant non ?

Balena semble répondre à un paquet de problématique et c’est une erreur à mon sens de ne pas mettre de l’effort dessus, néanmoins il faut quand même prévoir une solution de repli sans Balena en cas de problème ou de shift technologique majeur. Ça à l’air cool Balena hein? Et si je vous en parlais dans un prochain article ? (c’est surement une promesse en l’air, mais vous avez l’habitude. 🤭)

et dans la pure tradition déglingos, prank ça part en prod.