Construire une plateforme IoT avec l’approche Cloud Native et Kubernetes

L’agriculture intensive ainsi que le changement climatique ont eu des causes très négatives sur les sols. En effet, l’utilisation excessive de produits phytosanitaires, l’épuisement des réserves d’eau et l’élévation de la température ont appauvri voire desséché les terres dans certaines zones du monde comme en Andalousie.

Aujourd’hui, les technologies de l’Internet des Objets initient une révolution numérique dans tous les domaines et apportent également des solutions à l’agriculture. Elles aideraient les agriculteurs à améliorer leurs rendements, à préserver les sols, à optimiser l’utilisation de l’eau et des produits phytosanitaires : une de ces solutions est la mesure de l’humidité et de la température des sols. En effet, comme indiqué dans la figure 1, des stations agricoles mesurent l’humidité et la température du sol et envoient régulièrement ces informations à un serveur distant. L’agriculteur via un appareil (portable, ordinateur ou tablette) visualise les données du sol grâce à une application connectée au serveur. Il peut ainsi suivre en temps réel et à distance l’état de ces sols. Cela lui permet de savoir quand et où arroser efficacement.

Il est possible de créer tout un écosystème agricole où cette station serait associée à d’autres dispositifs comme celui de l’ouverture/fermeture à distance des dispositifs d’irrigation, celui de la mesure du niveau d’eau, de fuel et de gaz et celui de la mesure météorologique. Cela permettrait au serveur distant de déterminer et d’enclencher au bon moment l’arrosage avec la bonne quantité d’eau à utiliser, le tout sans l’intervention de l’agriculteur.

Voici en vidéo le prototype construit. Nous avons utilisé un capteur Adafruit pour mesurer l’humidité et la température du sol. Ce dernier est relié à un Raspberry Pi qui se charge de collecter et d’envoyer les mesures à une plateforme IoT installée sur GKE, le service Kubernetes de GCP. De plus, une application développée en Vue.js est également disponible et permet de visualiser les mesures en temps réel.

Pour ce prototype, nous avons défini les besoins suivants : recevoir les données agricoles, stocker et traiter les données et finalement donner accès à des utilisateurs. Nous avons découpé la plateforme IoT en microservices selon ces besoins, voir la figure 2.

• Device Management : gère la réception des données agricoles tout en assurant la sécurité des communications, l’authentification et l’autorisation des stations.
• Data Indexing : gère l’indexation des nouvelles données.
• Data Processing : applique différents traitements sur les données.
• Data Access : fournit aux utilisateurs l’accès à leurs données de façon sécurisée.

Selon l’approche Cloud Native, le déploiement de l’infrastructure ainsi que des microservices ne doit pas se faire par des actions manuelles mais à partir d’un pipeline CI/CD. Ce dernier doit s’assurer de la qualité du code grâce à différents niveaux de tests, packager le code et déployer l’infrastructure et les microservices.

Le fichier .gitlab-ci.yml, à la racine du projet, décrit ce pipeline qui comporte cinq stages. La création du cluster Kubernetes se fait lors du premier stage setup_cluster_deploy qui ne s’exécute que sur la branche Git setup-cluster. La création est réalisé grâce à l’outil Terraform qui permet de décrire des infrastructures sous forme de code.

L’exécution des quatre autres stages, sur d’autres branches Git, est décrite sur la figure 4 ci-contre :

1. Exécuter tous les tests unitaires du projet pour s’assurer de la qualité du code.
2. Construire et déposer sur un registre GCR les images Docker de chaque microservice de la partie précédente “Conteneurs & Kubernetes“. Nous avons utilisé le hash du commit GitLab comme tag pour les images.
3. Déployer l’infrastructure exprimée sous forme de code (infra-as-code) et les microservices avec Helm, un gestionnaire de package pour Kubernetes. En outre, GitLab stocke les mots de passe qui sont déployés en tant que secret Kubernetes car aucune image Docker ne contient de mot de passe. Chaque microservice a été configuré pour que Kubernetes démarre les conteneurs à partir des images dans GCR et associe les secrets à leurs volumes.
4. Lancer un test de bout en bout pour s’assurer du fonctionnement souhaité de la plateforme. En effet, nous simulons l’envoi de données agricoles que l’on doit être capable de retrouver dans l’API REST.