Révolutionner ses déploiements IoT : Ma découverte des Pipelines CI/CD sur Azure DevOps

Si vous gérez une infrastructure, vous savez à quel point le déploiement manuel peut rapidement devenir un cauchemar logistique. Récemment, j'ai été confronté à un défi intéressant : mettre en place et maintenir une application de gestion déployée sur une flotte de Raspberry Pi, répartis sur plusieurs sites physiques de mon entreprise.

Pour résoudre ce casse-tête, j'ai plongé dans l'univers de l'intégration et du déploiement continus (CI/CD) avec Azure DevOps. Voici un retour d'expérience sur mes recherches, mon architecture et les défis techniques rencontrés (notamment avec Docker !).

Qu'est-ce qu'un Pipeline CI/CD et pourquoi l'utiliser ici ?

En termes simples, un pipeline CI/CD est une suite d'étapes automatisées qui s'exécutent à chaque modification de votre code. Il se charge de construire (Build), tester (Test) et déployer (Deploy) votre application.

Pourquoi est-ce indispensable dans mon cas ?

Imaginez devoir vous connecter en SSH à 10, 20 ou 50 Raspberry Pi répartis sur différents sites géographiques à chaque mise à jour de l'application... C'est chronophage, propice aux erreurs humaines, et tout simplement ingérable à grande échelle.

Le pipeline permet de centraliser ce processus : je pousse mon code, et la machine s'occupe de le distribuer uniformément et de manière fiable sur l'ensemble de la flotte.

L'approche choisie : Un workflow maîtrisé de bout en bout

Pour garantir la stabilité de notre système, voici le flux de travail (workflow) que j'ai mis en place :

1. Développement (Feature branch)

Chaque nouvelle fonctionnalité ou correction de bug est développée sur une branche dédiée (ex: feature/nouvelle-interface).

2. Phase de Staging (Pré-production)

Une fois le code poussé (push), le pipeline déclenche un déploiement vers un Raspberry Pi dédié aux tests. Cela permet de vérifier le bon fonctionnement de l'application dans des conditions réelles (matériel identique) sans impacter les utilisateurs.

3. Mise en Production

Une fois les tests validés sur le Raspberry de staging, la branche est fusionnée (merge) vers la branche principale. Le pipeline prend alors le relais pour déployer automatiquement la nouvelle version sur l'ensemble des Raspberry Pi de l'entreprise.

La magie de Docker et le défi du "Container Registry"

Pour faciliter le déploiement et garantir que "ça marche sur ma machine ET sur les Raspberry", l'application est conteneurisée avec Docker. Mon pipeline a donc pour mission de construire (build) une image Docker à chaque mise à jour.

Mais une fois cette image construite, il faut la stocker quelque part pour que les Raspberry Pi puissent la télécharger. C'est le rôle d'un Container Registry.

Faire face aux coûts : Le choix de l'auto-hébergement

Initialement, j'ai regardé du côté du registre natif d'Azure (Azure Container Registry). Bien qu'excellent, il s'avère être payant. Cherchant une solution plus économique pour ce projet, j'ai décidé de monter mon propre registre en utilisant l'image officielle proposée par Docker (registry:2).

C'est ici que les choses deviennent intéressantes techniquement :

L'exigence de sécurité de Docker (HTTPS) : Par défaut, Docker refuse de communiquer avec un registre non sécurisé (HTTP). Pour mes tests, j'ai mis en place un certificat auto-signé associé à un nom de domaine personnalisé.

Configuration des Raspberry : Il a fallu déclarer ce registre comme source de confiance sur les Raspberry Pi en y ajoutant le certificat.

Le pont entre Azure et le réseau local : L'Agent auto-hébergé

Sécurité réseau : Comment Azure DevOps parle-t-il à mon registre local ?

Mon registre Docker est hébergé en interne, sur le réseau de l'entreprise. Il était hors de question de l'ouvrir sur Internet (NAT/Port Forwarding) juste pour qu'Azure DevOps puisse y accéder !

La solution élégante proposée par Azure DevOps est la mise en place d'un Self-Hosted Agent (Agent auto-hébergé).

Au lieu qu'Azure essaie "d'entrer" dans mon réseau, c'est une petite machine virtuelle (ou un conteneur) située dans mon réseau d'entreprise qui va interroger les serveurs d'Azure de l'intérieur vers l'extérieur. Cet agent récupère les tâches du pipeline, construit l'image Docker, et la pousse (push) vers mon registre local en toute sécurité.

Conclusion et prochaines étapes

La mise en place de pipelines CI/CD pour des appareils physiques (Edge computing/IoT) demande un peu d'architecture, notamment autour de la gestion des images Docker et de la sécurité réseau. Cependant, le gain de temps et la sérénité lors des déploiements valent largement cet investissement initial.

J'en suis actuellement à la finalisation de l'intégration de ce registre privé. La prochaine étape consistera à optimiser la manière dont les Raspberry Pi détectent qu'une nouvelle image est disponible dans le registre pour se mettre à jour (potentiellement via des outils comme Watchtower ou des scripts de polling).

N'hésitez pas à partager vos propres expériences ou architectures IoT en commentaire !