Docker sur un routeur industriel ou une passerelle Edge dédiée : quand cohéberger, quand séparer

Prenons un exemple de déploiement sur site. Un routeur industriel est déjà installé dans l'armoire, et il faut maintenant exécuter un programme de conversion de protocoles. Puisque le routeur prend en charge Docker, placer le conteneur dessus semble efficace : un équipement, une alimentation et un câblage de moins.

La réponse change rapidement s'il s'agit d'une base de données locale, d'une analyse vidéo ou d'une application qui écrit des journaux en continu. La vraie question n'est pas seulement de savoir si le conteneur peut démarrer. Il faut aussi déterminer si un processus très sollicité, un disque plein ou une mise à niveau échouée pourrait emporter la connectivité du site.

À retenir

La cohabitation est souvent pertinente lorsque les limites de ressources du conteneur sont claires, que les écritures restent limitées, que les privilèges peuvent être réduits et que le cycle de maintenance peut suivre celui du routeur. Une passerelle Edge dédiée est préférable dès que l'application consomme durablement du CPU ou de la mémoire, conserve une grande quantité de données locales, exige des privilèges élevés sur l'hôte ou doit pouvoir tomber en panne pendant que le réseau reste disponible.

L'ordre de décision compte : préserver d'abord le routage, les tunnels chiffrés, le pare-feu et l'administration à distance ; attribuer ensuite au conteneur les ressources restantes ; puis valider le choix avec des tests de redémarrage, de coupure d'alimentation, de perte de liaison amont et de retour arrière après une version défectueuse.

Ne commencez pas par Docker : commencez par la charge de travail

Les conteneurs peuvent donner l'impression que le déploiement est presque terminé dès qu'une image est téléchargée et qu'un processus démarre. Ce n'est que le point de départ.

Deux niveaux sont facilement confondus. L'image décrit la manière dont une application est empaquetée et apportée sur l'équipement ; l'environnement d'exécution décrit la manière dont elle fonctionne réellement. L'OCI Image Specification et l'OCI Runtime Specification définissent ces deux niveaux, mais elles ne répondent pas à trois questions plus concrètes pour le site : quelle marge reste sur l'hôte, quelle quantité de données l'application va écrire et une version défectueuse peut-elle être restaurée sans risque ?

Reprenons les deux charges de l'exemple initial. Un programme de conversion de protocoles avec un trafic limité, peu d'état et des privilèges strictement limités peut rester sur le routeur. Une base de données locale ou une charge d'analyse vidéo sollicite en continu le CPU, la mémoire et le stockage, tandis que son calendrier de versions peut ne pas correspondre à celui du firmware du routeur. Les deux sont des conteneurs Docker, mais ils représentent des charges complètement différentes pour l'hôte.

Ne décidez donc pas à partir de la taille de l'image ou du simple fait que le processus démarre. Commencez par mesurer la charge stable et les pics, la variation de ressources au démarrage, le volume quotidien d'écriture, les interfaces nécessaires et l'impact métier d'une panne de l'application. Une fois la charge de travail décrite, le choix de l'emplacement devient concret.

Réservez d'abord les ressources du routeur au routage

Un routeur industriel n'est pas un petit serveur vide qui attend des applications. Les sessions cellulaires, la surveillance de liaison, les tunnels chiffrés, le pare-feu, les protocoles de routage, l'administration Web et la maintenance à distance utilisent déjà ses ressources. Une marge visible en fonctionnement normal ne garantit pas la même marge pendant une reconnexion, la reconstruction d'un tunnel ou une mise à niveau distante du firmware.

La documentation Docker sur les limites de ressources explique qu'un conteneur non limité peut entrer en concurrence avec les autres processus de l'hôte pour le CPU et la mémoire. Lors de l'évaluation, observez les fonctions réseau en fonctionnement normal, en période de pointe et pendant la reprise.

Vérifiez ensuite, via l'interface d'administration du firmware cible ou avec docker info, les capacités réelles en CPU, mémoire et cgroups. Ce n'est qu'après avoir confirmé que le firmware cible prend en charge les contrôles nécessaires qu'il faut définir des limites mesurées pour le conteneur. Un conteneur qui fonctionne n'est pas automatiquement un conteneur isolé.

La mémoire est visible ; le stockage est plus facile à sous-estimer. Les pilotes de stockage Docker gèrent les couches de l'image et la couche inscriptible du conteneur, tandis que les volumes séparent les données à conserver du cycle de vie d'un conteneur. Avant le déploiement, documentez les données de base de données, de cache, de file d'attente et de configuration qui doivent être conservées, ainsi que celles qui peuvent être reconstruites.

Les journaux sont aussi des écritures. Lorsque l'équipement utilise json-file, local ou un autre pilote de journalisation qui stocke les données sur l'hôte, la sortie standard et la sortie d'erreur consomment continuellement l'espace local. Une application peut avoir une petite image et accumuler malgré tout un historique de journaux important en quelques mois. La taille de l'image n'est qu'un point de départ ; les écritures continues et la croissance dans le pire cas sont plus proches du risque réel sur un site sans présence permanente.

Les privilèges accordés au conteneur atteignent le routeur

Les conteneurs n'offrent pas la même frontière d'isolation que les machines virtuelles. Ils partagent généralement le noyau de l'hôte. Le fait d'être conteneurisée ne crée donc pas automatiquement une frontière de sécurité indépendante entre l'application et le système de routage. Cette différence est déjà importante sur un serveur classique ; elle devient immédiate sur un routeur industriel qui contrôle le chemin réseau du site.

Le modèle de sécurité du daemon et du socket Docker implique généralement des privilèges élevés sur l'hôte. Toute personne capable de les contrôler doit être considérée comme une entité de confiance. Monter le socket dans un conteneur métier, exposer une API distante non protégée, activer le mode privilégié ou monter des répertoires de l'hôte sans précaution peut permettre à une vulnérabilité applicative de franchir la limite du conteneur et d'atteindre le routeur lui-même.

Une approche plus sûre consiste à examiner séparément la provenance de l'image, l'utilisateur d'exécution, les capacités Linux, les mappages de périphériques, les ports réseau et les montages de répertoires hôtes, puis à réduire chaque privilège au minimum nécessaire.

Lorsque le build Docker Engine cible prend en charge seccomp et que le noyau de l'hôte active la capacité correspondante, le profil seccomp par défaut limite les appels système au moyen d'une liste d'autorisation. Vérifiez les Security Options réelles sur le modèle cible ; ne supposez pas que tous les firmwares utilisent la même configuration. seccomp=unconfined peut résoudre un problème de compatibilité tout en supprimant une partie de la frontière de sécurité.

Le guide du NIST Application Container Security Guide considère ensemble les risques liés à l'image, au registre, à l'environnement d'exécution, à l'hôte et aux opérations.

Pour un projet industriel, transformez ce principe en règle pratique : si un conteneur doit seulement envoyer des données vers l'amont, il ne devrait pas pouvoir modifier le routage, les règles du pare-feu, les interfaces cellulaires ou les tunnels chiffrés. Si l'accès série, le réseau brut ou un répertoire de l'hôte est réellement nécessaire, documentez chaque privilège, sa justification, la procédure de retrait et la méthode de récupération de l'équipement.

Le redémarrage automatique ne signifie pas que le métier est rétabli

Voir le conteneur revenir à l'état running peut être rassurant. Mais si le processus a redémarré, les données vers le système amont sont-elles forcément de nouveau disponibles ? Pas nécessairement.

Les politiques de redémarrage Docker gèrent principalement la sortie du conteneur et le cycle de vie du daemon. Si une application est bloquée alors que son processus reste vivant, le conteneur peut continuer à apparaître comme actif. En cas de plantages répétés, il peut simplement redémarrer en boucle.

Une vérification de santé révèle une partie de l'état, mais ne remplace pas un test métier.

Il faut au minimum vérifier trois niveaux : le conteneur fonctionne-t-il, l'application est-elle saine et le système amont reçoit-il les bonnes données ? La connectivité cellulaire, les tunnels chiffrés et l'administration à distance doivent rester disponibles en parallèle.

La même logique s'applique aux mises à niveau. Donnez à l'image applicative, à la configuration, aux données persistantes et au firmware du routeur des versions et des chemins de retour clairement définis. Avant le déploiement, répondez aux questions suivantes : où l'ancienne image est-elle conservée, comment retirer une version défectueuse, comment récupérer après une coupure d'alimentation pendant la mise à niveau et l'accès distant reste-t-il disponible ? Sans essai d'ingénierie sur l'équipement cible, présentez ces points comme des actions de validation et non comme des capacités de reprise déjà démontrées.

Quand garder Docker sur le routeur et quand l'externaliser

Gardez la charge sur le routeur lorsque sa frontière est étroite et claire. L'adaptation de protocoles, le filtrage de données, la remontée d'état ou un agent de supervision peuvent convenir lorsque la charge est faible, que les pics sont mesurables, que la persistance est limitée et que les privilèges sont réduits, à condition de pouvoir mettre à niveau le conteneur pendant la fenêtre de maintenance du routeur. La cohabitation supprime un équipement et rapproche le traitement des automates, instruments ou caméras. Le critère important est la frontière de la tâche, pas le nom de l'application.

Utilisez une passerelle Edge dédiée lorsque l'application possède déjà son propre cycle de vie. Une base de données locale, une analyse vidéo, plusieurs services interdépendants ou un logiciel qui exige des versions fréquentes et de larges privilèges sur les équipements ne constitue généralement plus une petite fonction du routeur.

Le Fog Computing Conceptual Model du NIST fournit le contexte architectural pour placer le calcul à la périphérie du réseau. La séparation permet d'isoler les effets des ressources de l'hôte, des mises à niveau du firmware et de la maintenance applicative dans des domaines de panne distincts.

Un équipement supplémentaire ne crée toutefois pas automatiquement de haute disponibilité. La passerelle Edge et le routeur peuvent encore partager l'alimentation, le commutateur, la liaison amont et le plan de gestion. Ces points de panne communs doivent eux aussi être vérifiés.

Terminez la décision par une question : si l'application épuise les ressources, si son image est corrompue ou si une mise à niveau échoue, la connectivité cellulaire, les tunnels chiffrés et l'accès de secours doivent-ils rester disponibles ? Si oui, et si l'équipement actuel ne peut pas démontrer une marge suffisante d'isolation et de reprise, séparez les charges.

Un équipement en moins est un avantage. Réduire le domaine de panne partagé est l'objectif de conception.

Validez le déploiement avant la mise en production

La décision d'architecture doit finalement fonctionner sur l'équipement cible. Notez le modèle exact, le firmware, l'architecture de l'image, l'utilisation normale et maximale du CPU et de la mémoire, les écritures persistantes, la croissance des journaux, les ports et les privilèges périphériques, la fréquence des versions et l'objectif de reprise. Si l'une de ces données manque, il devient difficile de déterminer si un test est réellement réussi.

Effectuez d'abord les tests de panne sur un équipement de réserve hors production ou dans un laboratoire isolé. Exportez la configuration et les données persistantes avant de commencer, préparez une console locale ou un accès indépendant hors bande, puis confirmez une image connue comme fonctionnelle et une procédure de retour arrière.

Pour les tests de pression sur le stockage, utilisez des quotas et des alertes contrôlés ; ne remplissez pas réellement la partition système. Les tests de coupure d'alimentation ne doivent être exécutés que si le fabricant les autorise, qu'aucune écriture de firmware n'est en cours et qu'une récupération locale est possible. Injectez une seule panne à la fois tout en observant le routage, les tunnels, le pare-feu et l'administration à distance.

Selon la confirmation produit interne actuelle, tous les routeurs industriels Wavetel de la série 6 peuvent exécuter Docker. La gamme de routeurs industriels sert de point de départ pour examiner les modèles. Si un projet évalue cette série, fournissez l'architecture de l'image, les pics de CPU et de mémoire, le volume d'écriture prévu, les privilèges d'interface et l'objectif de reprise avant de choisir un modèle précis. Ces éléments permettront d'associer l'équipement au besoin et de définir le plan de validation.

FAQ

Quelles informations sur l'équipement faut-il confirmer avant de déployer Docker ?

Confirmez le modèle cible, la version du firmware, l'architecture CPU, la mémoire et le stockage disponibles, l'environnement d'exécution des conteneurs et l'architecture de l'image. Vérifiez ensuite les contrôles de ressources, les chemins de persistance, la rotation des journaux, les privilèges des interfaces et la procédure de retour arrière. C'est en mettant ces informations en regard des courbes de charge mesurées que vous pourrez juger si la cohabitation convient.

Quelle quantité de CPU, de mémoire et de stockage faut-il réserver à un conteneur léger ?

Il n'existe pas de valeur universelle pour toutes les images et tous les modèles. Mesurez d'abord les fonctions réseau propres au routeur en fonctionnement normal et pendant une reprise sur panne. Mesurez ensuite le pic au démarrage du conteneur, son utilisation stable, la croissance des journaux et celle des données persistantes. La réservation doit être déterminée par ces deux ensembles de mesures.

Un conteneur Docker peut-il affecter le routage, les tunnels chiffrés ou le basculement de la liaison amont ?

Oui. Un conteneur qui épuise le CPU, la mémoire ou le stockage, modifie le réseau de l'hôte ou reçoit des privilèges excessifs peut affecter les services réseau du même équipement. Validez l'impact réel sur le modèle, le firmware et la configuration cibles avec une injection de panne contrôlée et un fonctionnement prolongé ; le démarrage réussi du conteneur ne suffit pas.

Les données du conteneur doivent-elles être placées dans la couche de l'image, un volume ou un stockage externe ?

Une image doit pouvoir être récupérée ou reconstruite. Les données qui doivent survivre à la recréation, à la mise à niveau ou à la suppression du conteneur ne doivent pas rester uniquement dans la couche inscriptible. Placez-les dans un volume de données ou un stockage externe conçu pour la capacité, la sauvegarde et la cohérence après une coupure d'alimentation.

Quels signaux indiquent qu'une passerelle Edge dédiée est préférable ?

Une charge élevée et continue, une persistance locale importante, plusieurs services interdépendants, des privilèges étendus sur l'hôte ou les équipements, un cycle de publication indépendant et l'exigence que le réseau reste disponible en cas de panne applicative sont de forts signaux. Une passerelle Edge dédiée peut séparer les effets des ressources de l'hôte, du firmware et de la maintenance applicative, mais les dépendances communes d'alimentation, de LAN, de liaison amont et de plan de gestion doivent toujours être examinées séparément.