4.8 KiB
Lancement du module sur la machine cible
Mettons de côté le déploiement continu, pour nous concentrer sur la manière dont nous allons pouvoir exécuter notre module de relevé de compteur Linky. \
Le binaire de notre module se lance de la manière suivante :
où /dev/ttyEnedis0
est le périphérique correspondant à notre liaison série
vers le compteur. On considère qu'une règle udev
a été écrite pour créer
l'entrée correspondante dans /dev
.
\
L'objectif est d'établir la méthode qui sera la plus efficace pour Électropcool, car elle devra sans doute demander à chacune des équipes de réaliser le packaging des modules qu'elles maintiennent. Il faut pour cela tester plusieurs solutions. Certaines peuvent sans doute déjà être éliminées car inadaptées, c'est à vous de déterminer parmi les technologies d'empacketages proposées, et celles que vous connaissez, lesquelles vous écartez d'emblée, lesquelles vous souhaitez garder pour explorer davantage, et enfin laquelle retient votre attention.
Vous êtes tenu de retenir au minimum 2 solutions distinctes (on considère que les technologies listées sur la même lignes sont similaires).
La liste de technologies proposées est à la suivante :
- conteneur Docker ou podman,
- conteneur LXC (avec base alpine ou nu),
- conteneur OCI via runc,
- service systemd ou systemd-nspawn,
- packages
.ipk
via Yocto/Bitbake, - package Nix,
- paquet Snap, FlatPack ou AppImage,
- k3s,
- ...
Les sections suivantes vous donneront une idée des éléments attendus pour chacun.
Docker, podman, ...
Nous avons déjà un Dockerfile
dans notre dépôt, vous avez juste à écrire un
script shell permettant de lancer le module, il doit bien évidemment avoir
accès au périphérique correspondant au compteur.
Conteneur LXC
LXC peut s'utiliser de multiple manière différentes, y compris avec des images OCI. Choisissez la méthode qui vous semble la plus appropriée, il est attendu au moins un script pour lancer notre conteneur, s'il est différent d'un
En complément, vous pouvez inclure au dépôt de linky2influx
le modèle
permettant de créer le conteneur LXC, ainsi qu'un exemple de configuration :
Conteneur OCI via runc
runc
a besoin d'un fichier config.json
et éventuellement runtime.json
. La
ligne de commande pour lancer runc
n'est pas demandée, l'image OCI résultant
du Dockerfile
sera utilisée et présente pour l'exécution.
Service systemd ou systemd-nspawn
Le service systemd
est redondant avec un système Yocto contenant systemd
,
vous pourriez écrire le script systemd
et profiter de l'utiliser dans votre
recette bitbake
.
Un service basé sur nspawn
peut par contre être potentiellement intéressant,
il pourra être intégré au dépôt :
Yocto
Vous pourriez vouloir écrire une recette Bitbake pour créer et déployer le
module via un paquet .ipk
ou similaire en fonction de votre configuration.
Écrivez la recette au sein de meta-electropcool
:
Nix
L'expression Nix correspondant au paquet pourra être intégré au dépôt
Précisez ensuite dans un README-nix.md
à côté, la manière dont vous souhaitez
utiliser le package Nix ensuite.
Snap, Flatpack, AppImage
Intégrez au dépôt le fichier de description, par exemple :
Il faudra également préciser avec un fichier run.sh
la manière dont lancer
votre conteneur :
k3s
Si vous connaissez déjà Kubernetes, vous pourriez vouloir écrire un Chart Helm :
Votre solution ici
N'hésitez pas à apporter une autre solution originale, mais tout de même adaptée à l'objectif, que celles qui seraient listées ici. \
Commençons par appréhender la publication d'image Docker, que nous maîtrisons plutôt bien normalement.
\newpage