Nous avons vu dans les articles précédents en quoi consistait la distribution industrielle Eris Linux et comment l’installer aisément sur une carte du commerce, un Raspberry Pi 5 en l’occurrence.
J’avais indiqué que j’aimais comparer Eris Linux à un vaisseau porte-containers. C’est le moment de lui faire jouer ce rôle et d’embarquer ses premiers containers.
Nous verrons dans le prochain article comment créer son propre container embarquant un code métier personnalisé. Dans un premier temps, nous allons nous concentrer sur des containers de démonstration disponibles directement pour toutes les cartes supportées par Eris Linux.
Durée : environ 20 minutes pour tester les containers indiqués ci-dessous.
Matériel nécessaire :
– une carte supportée par Eris Linux sur laquelle Eris est installé,
– un accès réseau pour que la carte puisse joindre le Device Manager,
– un ordinateur avec accès réseau pour communiquer avec le Device Manager.
Une fois l’installation d’Eris achevée, notre carte apparaît dans le Device Manager, comme nous l’avions vu dans l’article précédent.
Pour le moment les quatre slots pouvant contenir des containers sont vides (voir la table en haut à droite de l’écran). Cliquons sur un des boutons représentant un container. La fenêtre suivante apparaît.
Cette fenêtre permet de choisir parmi les containers disponibles pour ce modèle de carte, celui que nous souhaitons installer dans le slot concerné.
À noter que la configuration des slots s’effectue au niveau du groupe : le container sélectionné sera donc déployé sur tous les équipements appartenant à ce groupe.
En cliquant sur la liste déroulante, on voit les containers de démonstration apparaître :
Containers de démonstration et test
Les containers de démonstration sont proposés systématiquement pour toutes les cartes supportées par Eris Linux, cela permet entre autres de valider le bon fonctionnement de l’interface de développement du code applicatif (API).
Toutefois, en usage courant, pour des équipements déployés, la présence des containers de démonstration peut s’avérer plus perturbante qu’utile. Pour cela une option « Include demo containers in the list » est présente dans le menu de configuration du groupe d’équipements. Activée par défaut, cette option peut être décochée si on le souhaite.
Dans ce cas, seuls les containers applicatifs développés spécifiquement seront visibles. Dans la fenêtre ci-dessous les containers de démonstration ont disparu.
Réactivons l’option qui nous permet de voir les containers de démonstration.
Voici ceux proposés au moment de l’écriture de cet article. Il est très probable que d’autres démonstrations seront disponibles dans l’avenir :
- « LED trigger access » : ce container contient un script shell qui sélectionne alternativement les « triggers » (déclencheurs) allumant et éteignant les LEDs de la carte. Toutes les quinze secondes, les LEDs adopteront un comportement parmi « clignotement avec une période d’une seconde » , « allumage permanent » , « clignotement en battement de cœur » et « extinction complète« . Ce container nécessite un accès au matériel physique (les LEDs) et est donc protégé par un mot de passe qu’il faut saisir pour son installation. Dans le cadre de cette démonstration, le mot de passe (rappelé dans la description du container) est «
eris« . - « Turn all LEDs off » : lorsqu’on retire le container précédent, les LEDs conservent le dernier comportement configuré (par exemple un clignotement). Si on veut éteindre complètement toutes les LEDs, il est possible de charger ce container. Comme le précédent, il est protégé par le mot de passe «
eris« . - « API Test using console HMI » : un container qui installe un serveur sur le port TCP/IP 10000. Une connexion sur ce port (avec un outil comme
telnet,screen,nc, etc.) donne accès à une IHM minimale permettant de tester une partie de l’API de programmation d’Eris Linux. Nous en verrons un exemple plus loin. - « API Test using Web HMI » : ce container ouvre un serveur Web sur son port 80 redirigé sur le port 8080 de l’équipement. On peut s’y connecter à l’aide de n’importe quel navigateur en utilisant l’URL «
http://<device IP address>:8080/» puis utiliser les menus proposés pour tester l’API d’Eris Linux. - « API Test using Qt-based HMI » : un container affichant une application graphique basée sur la bibliothèque Qt 6 pour évaluer l’API de programmation d’Eris Linux. Ceci nécessite bien sûr que l’équipement sur lequel on installe le container dispose d’un écran graphique.
- « SSH Server on port 2222 » : ce container dans lequel s’exécute un serveur SSH auquel on peut accéder sur le port TCP/IP
2222de l’équipement. On peut se connecter en utilisant le nom de login «eris» et le mot de passe «linux» ou en utilisant le login «root» et le mot de passe «root« .
Container de test d’accès aux LEDs
Commençons par installer le container qui teste l’accès aux LEDs de la carte.
Comme nous l’avons indiqué plus haut ce container est protégé par un mot de passe. Comme ceci n’est qu’un exemple, le mot de passe est rappelé dans la description du container, mais en temps normal ce mécanisme permet de protéger la confidentialité du code métier applicatif.
Lorsqu’un container est protégé par un mot de passe, il est chiffré avant d’être enregistré sur le serveur Eris Linux. La clé n’est jamais stockée en clair, elle est transmise (sous chiffrement fort) aux équipements du groupe sur lequel on installe le container. Le déchiffrement du container ne se produit qu’une fois arrivé sur l’équipement final, juste avant son installation.
Pour entrer le mot de passe, une zone de saisie apparaît sous la liste déroulante.
Au bout d’une minute environ (période de contact entre l’équipement et le Device Manager), le container est téléchargé sur la carte, installé puis démarré et le clignotement des LEDs du Raspberry Pi 5 commence.
Au bout d’une seconde période d’une minute, son état est remonté au Device Manager, dont le tableau en bas à droite affiche « Running » indiquant que le container est bien en activité.
Container de test d’API via IHM Web
Nous pouvons à présent charger un second container dans un autre slot. Par exemple « API test using Web HMI« .
Celui-ci nous offre une interface réseau de type Web pour essayer une partie des fonctionnalités proposées par l’API de développement du code métier pour Eris Linux.
Au bout de quelques instants, le container aura démarré et sera indiqué « Running » .
Il sera alors possible d’accéder au petit serveur Web Nginx embarqué dans le container. Pour cela il faut se connecter dans un autre onglet du navigateur sur l’adresse IP de l’équipement indiquée dans le quart inférieur droit du Device Manager (ici : 192.168.3.36) ainsi : http://192.168.3.36:8080
On voit alors apparaître l’écran suivant, qui permet de tester les fonctionnalités offertes par Eris Linux pour programmer des applications :
Nous reviendrons sur le détail de l’API Eris Linux dans le prochain article, consacré à la création de containers applicatifs.
Container serveur SSH
Essayons à présent un autre type de container qui nous permettra, via une connexion SSH, de passer des commandes à l’intérieur de notre container.
Le serveur SSH est accessible à l’adresse IP de notre carte, sur son port TCP 2222.
Attendons qu’il soit installé et ait démarré :
Différentes méthodes existent pour se connecter sur ce serveur : les outils comme PuTTY permettent une connexion graphique, tandis que la commande en ligne ssh permet un accès depuis un terminal. C’est cette dernière méthode que j’utilise car elle est plus lisible dans un article comme celui-ci :
[~]$ ssh -p 2222 eris@192.168.3.36
The authenticity of host '[192.168.3.36]:2222 ([192.168.3.36]:2222)' can't be established.
ED25519 key fingerprint is: SHA256:M7q7+mdoBAcWlqt4sZRg/U3IoRwtWctVGhk1ByE+sj8
This key is not known by any other names.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '[192.168.3.36]:2222' (ED25519) to the list of known hosts.
eris@192.168.3.36's password: linux
Welcome to Alpine!
The Alpine Wiki contains a large amount of how-to guides and general
information about administrating Alpine systems.
See <https://wiki.alpinelinux.org/>.
You can setup the system with the command: setup-alpine
You may change this message by editing /etc/motd.
f753f1399242:~$
Nous voyons que le container embarque une distribution Alpine minimale. C’est un choix lors de la création du container. Contrairement à ce qu’écrit le prompt un peu trop enthousiaste de cette distribution, la commande setup-alpine n’existe pas dans cette installation minimale.
Voyons quelques commandes qui nous donnent des informations sur le système :
f753f1399242:~$ uname -a
Linux f753f1399242 6.6.63-v8-16k #1 SMP PREEMPT Fri Dec 6 10:10:05 UTC 2024 aarch64 Linux
f753f1399242:~$ cat /proc/cpuinfo
processor : 0
BogoMIPS : 108.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 1
processor : 1
BogoMIPS : 108.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 1
processor : 2
BogoMIPS : 108.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 1
processor : 3
BogoMIPS : 108.00
Features : fp asimd evtstrm aes pmull sha1 sha2 crc32 atomics fphp asimdhp cpuid asimdrdm lrcpc dcpop asimddp
CPU implementer : 0x41
CPU architecture: 8
CPU variant : 0x4
CPU part : 0xd0b
CPU revision : 1
Revision : d04170
Serial : 0e7a28ef8acca700
Model : Raspberry Pi 5 Model B Rev 1.0
Ces premières informations sont celles du système hôte : contrairement à une machine virtuelle, le container utilise le même noyau Linux que l’équipement. D’autres informations, comme la liste des processus, sont en revanche propres à l’espace d’exécution du container.
f753f1399242:~$ ps aux
PID USER TIME COMMAND
1 root 0:00 /sbin/docker-init -- /usr/sbin/sshd -D
7 root 0:00 sshd: /usr/sbin/sshd -D [listener] 0 of 10-100 startups
18 root 0:00 sshd-session: eris [priv]
20 eris 0:00 sshd-session: eris@pts/1
21 eris 0:00 -sh
26 eris 0:00 ps aux
f753f1399242:~$ free
total used free shared buff/cache available
Mem: 8133264 194764 7620308 42748 318192 7833216
Swap: 0 0 0NB : la commande free affiche la mémoire visible depuis le container, mais comme aucune limitation ne lui est imposée, il s’agit également de la mémoire système globale.
Il est aussi possible de se connecter en utilisant le compte root avec le mot de passe root.
L’intérêt de cette connexion en tant que telle est très limitée. Son utilité est surtout de servir d’exemple si on souhaite ajouter un serveur SSH dans un container pendant la phase de mise au point du code applicatif.
Code source des containers
Les fichiers sources permettant de produire les containers présentés ici, et plusieurs autres, sont disponibles librement sur https://github.com/Eris-Linux/Eris-Linux-containers.
Nous les utiliserons comme base de travail dans le prochain article traitant du développement du code métier applicatif, mais n’hésitez pas à les examiner et à jouer avec en attendant.
Conclusion
Avec les opérations décrites dans cet article, il est possible de déployer des containers d’exemple sur des groupes d’équipements, de vérifier leur fonctionnement, de les supprimer, etc.
Nous recherchons actuellement des entreprises partenaires souhaitant expérimenter Eris Linux sur un cas d’usage réel. Ces premiers utilisateurs pourront bénéficier de conditions commerciales avantageuses et leurs retours d’expérience contribueront directement à l’évolution du projet.
