Published by

Il y a 3 mois -

Temps de lecture 7 minutes

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

Dans un premier article, nous avons vu les avantages d’utiliser les concepts de l’approche Cloud Native pour construire une plateforme IoT. Ce présent article a pour but d’expliquer comment ces concepts peuvent être appliqués à un projet de station agricole connectée.

Station agricole connectée

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.

Fig 1 : Station agricole connectée

Démo

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.

Sous le capot

Pour rappel, l’approche Cloud Native se caractérise par l’utilisation de microservices, de conteneurs, de livraisons en continu grâce à des pipelines CI/CD, de la couverture de code par des tests unitaires et de validation de bout en bout, et d’infrastructures exprimées sous forme de code.

Microservices

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.

Fig 2 : Architecture en microservices

Conteneurs & Kubernetes

Tous les composants de chaque microservice sont déployés dans des conteneurs au sein d’un cluster orchestré par Kubernetes. Un article a été rédigé pour ceux qui voudraient s’initier aux fondamentaux de Kubernetes en 5 minutes. La figure 3 illustre l’implémentation choisie de l’architecture en microservices présentée dans la figure 2. L’installation de toutes les bases de données s’appuie sur des ressources de type Statefulset de Kubernetes. Pour les applications en Python, elle s’appuie sur une ressource de type Deployment avec la possibilité de se dimensionner en fonction de la charge grâce au mécanisme Horizontal Pod Autoscaler.

  • Device Management : les stations utilisent le protocole MQTT pour communiquer avec la plateforme d’où la présence d’un cluster VerneMQ qui joue le rôle du serveur MQTT.
  • Data Indexing : une application indexer développée en Python se charge de récupérer les données d’un topic MQTT et de les stocker dans un index Elasticsearch.
  • Data Processing : des traitements sur les données sont exécutés en utilisant le framework Apache Spark avec le langage de programmation Scala. Actuellement, un seul traitement est lancé à intervalle de temps régulier, il s’agit de la conversion des données stockées dans Elasticsearch en fichiers au format Parquet stockés dans un stockage orienté objet, Minio (une alternative Open Source de AWS S3).
    Il est tout à fait envisageable d’implémenter d’autres traitements comme par exemple des traitements de data science/machine learning.
  • Data Access : il s’agit d’une application exposant une API REST qui donne accès aux données. Celle-ci est développée à partir du framework Flask en Python et déployée dans un serveur Gunicorn.

Fig 3 : Implémentation de l’architecture en microservices

Les communications depuis l’exterieur et au sein de la plateforme sont sécurisées par différents mots de passe et chiffrées grâce à des certificats auto-signés.

De plus, une application en Vue.js également déployée sur Kubernetes a été développée pour visualiser les données accessibles depuis l’API REST. Au niveau du capteur, le code à exécuter se trouve dans une image Docker disponible depuis GCR, le dépôt Docker de GCP.

Déploiement

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.

Fig 4 : Pipeline CI/CD sur GitLab

Aller plus loin

Au travers de cette suite d’articles, nous avons pu voir pourquoi et comment il était possible de construire une plateforme IoT sur Kubernetes avec les concepts de l’approche Cloud Native. La plateforme présentée dans cet article constitue un socle idéal pour bâtir un projet prêt à être mis en production, contrairement à des PoC fait de façon quick and dirty. De plus, la plateforme peut être déployée chez n’importe quel fournisseur de cloud en modifiant seulement quelques lignes de code qui utilise gcloud (la CLI de GCP). Par conséquent, nous ne sommes donc pas enfermés par un fournisseur en particulier (vendor lock-in).

Les prochaines étapes que l’on pourrait envisager pour améliorer cette plateforme sont la mise à l’échelle pour prendre en compte des milliers de capteurs, développer une application web plus performante, intégrer et construire d’autres types de capteurs, et ajouter des nouvelles fonctionnalités comme la notification et le monitoring de la plateforme.

Published by

Commentaire

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Nous recrutons

Être un Sapient, c'est faire partie d'un groupe de passionnés ; C'est l'opportunité de travailler et de partager avec des pairs parmi les plus talentueux.