Carte PINE A64, Node.js, Balena, PM2 et ResinOS (Partie 2) …
Je pars ici d’un nouveau design qui va exploiter à la fois des cartes PINE A64, Raspberry Pi 3 et OrangePi Zero …
avec ces descriptions techniques :
Comme d’habitude, j’utilise Etcher pour flasher les images d’OS sur ces cartes :
Je vais utiliser Debian Stretch comme OS pour ces cartes via Armbian :
et DietPi :
Pour cela il faut commencer après avoir effectuer le flash des images sur les cartes à scanner son réseau pour retrouver les adresses IP fournies via le DHCP de ma passerelle :
et je peux voir les caractéristiques de ces dernières :
J’en profite pour y installer de nouveau un moteur Docker CE :
et je peux initier un cluster via Docker Swarm Mode très rapidement :
C’est la carte Orange Pi Zero qui sert de noeud maître ici :
avec un overlay local :
Je peux tagger ces noeuds de ce cluster pour les différencier en fonction de leur architecture matérielle respective :
Je peux alors tester l’installation de Portainer pour visualiser graphiquement les caractéristiques du cluster :
J’en profite alors pour modifier légèrement le design précédent pour substituer une carte PINE A64 par une carte OrangePi Zero :
Et je peux recréer un cluster Docker Swarm Mode où la carte RPi3 sert de noeud maître :
Là encore je différencie les noeuds du cluster en fonction de leurs caractéristiques matérielles (ARMv7 32 Bits ou ARMv8 64 Bits) :
avec comme d’habitude le test du démonstrateur FranceConnect Particulier en ARMv7 :
ou en ARMv8 :
Je peux utiliser les binaires multi-architectures de Traefik sous la forme d’images Docker pour obtenir un endpoint global pour mon cluster :
Lancement de Traefik dans le cluster :
et lancement des démonstrateurs FranceConnect Particulier :
Ils apparaissent dans le tableau de bord de Traefik avec deux endpoints specifiques aux architectures ARMv7 et ARMv8 :
Et pour permettre l’accès externe à ces cartes qui tournent localement, on peut reprendre encore une fois Ngrok :
ou bien de la stack OpenFaaS pour y tester des fonctions à la demande en mode Serverless :
avec sa ligne de commande :
ou bien graphiquement :
Et si je souhaite une alternative à l’utilisation du moteur Docker, encore une fois PM2 de Keymetrics peut oeuvrer avec ces cartes :
et PM2 Plus offre un tableau de bord :
On peut imiter un mode de déploiement à la “Capistrano” pour les Rubyistes avec un fichier de configuration qui va exploiter des connexions SSH vers ces cartes :
Ici je déploie le démonstrateur FC Agent directement depuis les sources sur Github vers ces cartes via PM2 :
et le mode cluster de PM2 est actif sur celles-çi :
avec les métriques dans une logique d’APM avec PM2 Plus et son tableau de bord :
ou plus classiquement vers l’ancienne formule offerte par Keymetrics :
L’utilisation d’un utilitaire dédié au Reverse Proxy via le registre NPM me permet d’obtenir un seul endpoint local pointant sur les différents endpoints locaux fournis par PM2 pour accéder au démonstrateur FC Agent :
Là encore NGROK permet un accès exterieur sur ce reverse proxy local :
et une autre alternative à NGROK est SERVEO comme dans le précédent article :
Finalement avec toutes ces opérations, la consommation CPU/mémoire est restée relativement correcte …
Pour boucler avec l’article précédent, on pourrait retrouver ici la logique du Edge Computing :
D’ailleurs je teste ici le service Azure IoT Hub de Microsoft :
Je peux installer le runtime d’Azure IoT Edge sur la carte RPi3 qui va utiliser encore une fois le moteur Docker CE :
On peut prendre en compte le fait que ce noeud Edge pourrait servir à analyser localement les données avec Azure Stream Analytics on IoT Edge (via un container Docker utilisant des briques de Machine Learning) pour n’envoyer que certaines données utiles à Azure IoT Hub (pour le moment ceci est limité aux périphériques ARMv7 32 Bits : https://hub.docker.com/r/microsoft/azureiotedge-azure-stream-analytics/ ) :
et je peux connecter toutes ces cartes à Azure IoT Hub :
avec les première remontées :
En utilisant sur chacune des cartes le SDK Node.js d’Azure IoT :
et ces exemples : ici remontées de données de capteurs simulés sur ces cartes avec le protocole MQTT
en y insérant la chaine de connexion pour chaques cartes :
et les données sont remontées :
attention au fait que pour le plan gratuit on est limité à 8000 messages par jour …
Enfin pour finir, je peux aussi utiliser le service cloud de monitoring dédié à l’IoT fourni par la société Datadog en compilant sur ces cartes les sources de son agent dedié :
et ces graphes dans des tableaux de bord :
Ces cartes pourraient servir à la constitution de micro datacenters de proximité comme l’explique la société Picocluster et ses différents designs :
Un domaine à suivre puisque l’Edge computing constitue un nouveau terrain de bataille des géants du Cloud computing ! …
