Présentation de la réalisation

Cette réalisation, la plus récente de mon alternance chez Alcante, est un projet de démonstration de faisabilité (PoC) mené autour de l’infrastructure d’accès distant des appareils Modlink. L’entreprise s’appuie sur un serveur distant central (alcante.eu) vers lequel les objets connectés établissent leur tunnel SSH ; la question était de savoir s’il serait possible, le jour où l’on souhaiterait migrer vers un serveur plus performant, de le faire sans rompre la connexion des appareils déjà déployés.

J’ai donc réalisé une bascule complète du serveur distant vers une nouvelle machine, en conservant le même nom de domaine, afin de vérifier que les appareils Modlink — encore en phase de test, non déployés en production — se reconnectaient d’eux-mêmes au nouveau serveur, sans aucune reconfiguration sur le terrain.

Introduction et objectifs

L’objectif de ce test était d’anticiper une éventuelle migration de serveur en production et d’en mesurer l’impact sur les appareils connectés. Il s’agissait de valider les points suivants :

• Migration transparente pour les appareils : s’assurer que les objets Modlink rétablissent seuls leur tunnel SSH vers le nouveau serveur, sans intervention manuelle sur chacun d’eux ;
• Portabilité du nom de domaine : conserver le même nom de domaine (alcante.eu) afin que le changement d’adresse IP du serveur reste invisible du point de vue des appareils ;
• Facilité de migration : vérifier que l’entreprise pourra, à l’avenir, changer de serveur pour une machine plus performante avec un impact minimal sur le service.

Contexte humain

Comme pour mes autres réalisations, ce test a été mené dans le cadre de mon alternance au sein de l’entreprise Alcante, dont j’étais le seul intervenant technique : j’ai conçu et exécuté la bascule de bout en bout. L’entreprise est composée de deux personnes :

• Jorge Beja, mon tuteur, dirigeant et technicien de l’entreprise, à l’origine de la demande d’évaluation de cette migration ;
• Isabelle Saraiva, secrétaire, qui gère les commandes clients et assure en partie la comptabilité de l’entreprise.

Contexte technique

Le principe de la bascule repose sur la conservation du nom de domaine. Les appareils Modlink ne se connectent pas à une adresse IP fixe mais au nom de domaine du serveur (alcante.eu) : en faisant pointer ce nom vers la nouvelle machine au niveau du DNS, le changement d’adresse IP du serveur devient totalement transparent du point de vue des objets, qui continuent de viser la même destination.

J’ai d’abord préparé le nouveau serveur, puis migré l’ensemble des données et de la configuration de l’ancien vers le nouveau à l’aide de rsync — un outil de synchronisation de fichiers que j’ai découvert à cette occasion et qui permet de copier fidèlement une arborescence complète tout en ne transférant que les différences. J’ai ensuite modifié l’enregistrement DNS du domaine pour le faire pointer vers l’adresse IP de la nouvelle machine.

Pour valider la transparence de l’opération côté appareils, j’ai consulté directement les journaux (logs) SSH sur les objets Modlink. Ces journaux m’ont permis de vérifier que, malgré le changement d’adresse IP du serveur, les appareils rétablissaient bien leur tunnel de manière autonome une fois la nouvelle adresse résolue. La bascule s’est accompagnée d’une courte interruption : le temps que la modification du DNS se propage, les appareils ont momentanément perdu la connexion avant de la retrouver automatiquement grâce à la reconnexion assurée par autossh et à la nouvelle résolution du domaine.

L’enjeu

L’enjeu central était d’éviter d’avoir à reconfigurer chaque appareil sur le terrain en cas de changement de serveur. Une fois les objets Modlink déployés en production chez les clients, il serait en effet coûteux, voire impossible, d’intervenir manuellement sur chacun d’eux pour leur indiquer une nouvelle adresse de serveur. Il fallait donc démontrer qu’une migration pouvait s’opérer de façon centralisée, côté serveur uniquement.

Au-delà de ce cas précis, l’enjeu était aussi de garantir à l’entreprise une liberté de choix pour son infrastructure : pouvoir migrer vers un serveur plus performant ou mieux adapté à ses besoins, sans être prisonnière de la machine initiale ni des adresses configurées dans les appareils.

Les risques

Plusieurs risques devaient être maîtrisés lors de la bascule. Le premier était la perte de données au moment de la migration : un transfert incomplet ou incohérent entre l’ancien et le nouveau serveur aurait compromis le fonctionnement du service. L’usage de rsync, qui vérifie et synchronise fidèlement les fichiers, a permis de limiter ce risque.

Le deuxième risque était l’interruption de service et la désynchronisation entre le serveur et les appareils pendant la période de propagation du DNS. Cette interruption, inhérente au changement d’enregistrement DNS, a bien été observée mais est restée temporaire, les appareils se reconnectant automatiquement une fois la nouvelle adresse résolue. S’agissant d’un test réalisé hors production, cet impact était sans conséquence et a précisément permis d’en mesurer la durée et le comportement réels.

Les étapes

La bascule s’est déroulée selon les grandes étapes suivantes :

• Préparation du nouveau serveur distant (installation et configuration de l’environnement, du service SSH et du reverse proxy) ;
• Migration des données et de la configuration de l’ancien serveur vers le nouveau à l’aide de rsync ;
• Modification de l’enregistrement DNS du domaine alcante.eu pour le faire pointer vers la nouvelle adresse IP ;
• Vérification, via les journaux SSH des appareils Modlink, de la reconnexion automatique au nouveau serveur ;
• Analyse du comportement observé, notamment de la durée de l’interruption liée à la propagation du DNS.

Méthodologie de suivi

S’agissant d’un test de faisabilité, la démarche a été essentiellement expérimentale et empirique : préparer la bascule dans un environnement de test, l’exécuter, puis observer directement le comportement des appareils à partir de leurs journaux. Cette approche par l’observation m’a permis de valider concrètement la transparence de la migration et d’en tirer des enseignements fiables en vue d’une éventuelle mise en œuvre en production.

Les acteurs

Trois types d’acteurs sont concernés par ce projet :

• Moi-même, en tant que concepteur et exécutant unique de la bascule, de la préparation du serveur jusqu’à l’analyse des résultats ;
• Jorge Beja, mon tuteur, à l’origine de la demande d’évaluation de cette migration ;
• Les appareils Modlink et, à terme, les clients qui les hébergeront, premiers bénéficiaires de la portabilité ainsi validée.

Les résultats

Le test a été concluant : après la bascule, les appareils Modlink se sont bien reconnectés d’eux-mêmes au nouveau serveur, sans aucune reconfiguration, dès que la nouvelle adresse du domaine a été résolue. La seule conséquence observée a été une brève interruption de connexion pendant la propagation du DNS, suivie d’un rétablissement automatique.

Ce résultat valide la portabilité de l’infrastructure : l’entreprise pourra, le moment venu, migrer vers un serveur plus performant sans avoir à intervenir sur les appareils déployés sur le terrain, en n’acceptant qu’une courte coupure maîtrisée le temps de la bascule.

Les lendemains du projet

Ce test ouvre la voie à une migration sereine de l’infrastructure en production lorsque le besoin s’en fera sentir. Il a également mis en évidence l’intérêt de réduire autant que possible la durée d’indisponibilité liée au DNS, par exemple en abaissant à l’avance la durée de vie (TTL) des enregistrements avant une bascule planifiée. Les enseignements tirés serviront de base à toute évolution future du serveur central sur lequel reposent les appareils Modlink.

Mon regard critique

Bien que court, ce projet s’est révélé très formateur sur le plan de l’administration système. Il m’a fait découvrir rsync pour la synchronisation fidèle de données entre serveurs, mais aussi le mode rescue des serveurs et la gestion des partitions — des notions d’exploitation que je n’avais encore jamais manipulées et qui élargissent nettement mon autonomie sur les questions d’infrastructure.

Avec le recul, le principal axe d’amélioration porte sur la réduction de la coupure liée au DNS : une préparation plus fine, notamment un abaissement anticipé du TTL, permettrait de rendre la bascule quasi imperceptible. Ce test m’a néanmoins conforté dans ma capacité à anticiper les contraintes d’exploitation d’une solution avant sa mise en production, une compétence essentielle pour fiabiliser les projets sur la durée.