Donner à un conteneur sa propre adresse sur le réseau : ce que vous gagnez, ce que vous payez

L'agencement par défaut est celui-ci : le conteneur partage l'adresse de la machine et vous l'atteignez par un numéro de port. C'est simple, c'est sûr, et pour la plupart des usages cela suffit.

Il y a des cas où cela ne suffit pas, et ils sont prévisibles.

Quand un numéro de port ne suffit plus

Deux applications veulent le même numéro. Vous en déplacez une sur un autre numéro, et ensuite les liens que cette application produit elle-même ne portent pas ce numéro, et tout devient confus.

L'application s'annonce sur le réseau. Trouver des imprimantes, trouver des lecteurs multimédias, trouver des appareils domotiques : cela fonctionne par des messages d'auto-annonce. Ces messages ne survivent pas à la correspondance de ports. L'application s'annonce, mais l'adresse qu'elle annonce est celle de la machine, et l'autre côté ne peut pas la joindre.

Vous voulez voir l'application dans la liste d'appareils du routeur. Pour lui donner une adresse fixe, écrire une règle de pare-feu à part, voir son trafic séparément. Avec une correspondance de ports, cette application n'existe pas pour le réseau ; seule la machine existe.

L'autre voie : donner au conteneur sa propre identité

Le conteneur apparaît sur le réseau avec sa propre adresse matérielle, obtient sa propre adresse auprès du routeur, et figure dans la liste d'appareils comme un appareil physique.

La première réaction est souvent « pourquoi tout le monde ne fait-il pas comme ça ». La réponse est dans le prix.

Prix un : la machine ne joint pas son propre conteneur

C'est la partie qui surprend le plus, et on la découvre en général une fois le travail terminé.

Tous les appareils du réseau joignent ce conteneur. La machine qui l'héberge, non.

La raison est logique : les deux utilisent la même interface physique, et le trafic ne revient pas du commutateur. La machine envoie le paquet dehors, et le paquet ne revient pas vers sa propre carte.

Les conséquences sont quotidiennes : un contrôle de santé qui tourne sur la machine ne joint pas l'application, un autre conteneur sur la même machine ne peut pas s'y connecter, un script que vous avez écrit ne marche pas. Tout cela pendant que le réseau paraît impeccable vu de l'extérieur.

Il existe une solution, mais c'est une pièce en plus : ouvrir sur la machine une deuxième interface virtuelle rattachée à la même carte et y faire passer la route vers l'adresse du conteneur. Une fois installée le problème disparaît, mais comme c'est un ajout, si on l'oublie personne ne comprend.

Prix deux : vous consommez une vraie adresse

Chaque conteneur consomme une adresse de votre réseau. Dix applications, dix adresses. Sur un petit réseau, la limite arrive vite.

De plus, si l'adresse est un bail elle peut changer. Quand elle change, tout ce qui y était épinglé, y compris une règle que vous avez écrite, pointe silencieusement au mauvais endroit.

Prix trois : la carte réseau et le pare-feu

La carte doit accepter plusieurs adresses matérielles. La plupart des liaisons sans fil ne le font pas, et certains environnements virtuels arrivent avec cela désactivé. Ne décidez pas sans tester.

Et votre pare-feu voit désormais sur le réseau un appareil qu'il ne connaît pas. Pour vous c'est un conteneur ; pour celui qui écrit les règles c'est un appareil ordinaire. Ce n'est pas un problème, mais laissé non dit cela embrouillera quelqu'un un jour.

Une adresse ne suffit pas, il faut aussi un nom

Une application avec une adresse et sans nom, c'est la moitié du gain. Personne ne veut retenir une adresse.

Pour que le nom soit annoncé sur le réseau, il faut que quelque chose fasse ce travail. L'image propre de l'application ne contient généralement pas cette pièce, et il n'y a pas de raison qu'elle la contienne : une image de base de données n'a pas à s'annoncer sur un réseau.

La règle

Une correspondance de ports donne un numéro à une porte. Une identité réseau accorde la citoyenneté.

N'accordez la citoyenneté que lorsque le réseau doit réellement traiter cette application comme un appareil. Sinon, un numéro de port est à la fois plus simple et plus sûr.

Ce que fait Atlas

En mettant cela en place, Atlas ne touche pas à l'image propre de l'application. Il ouvre à côté d'elle un petit assistant, et cet assistant partage la pile réseau de l'application. C'est l'assistant qui demande l'adresse au routeur, et c'est lui qui annonce le nom sur le réseau.

Ce rattachement est voulu et rapporte deux choses. L'image de l'application n'a besoin ni d'un client d'adresse ni d'un annonceur de nom. Et comme la pile réseau appartient à l'application, quand l'application s'arrête l'assistant tombe avec elle, sans laisser de conteneur orphelin derrière.

Pour le problème de la machine qui ne joint pas son propre conteneur, le pont décrit plus haut est installé, et il l'est comme un service, afin de se reconstruire au redémarrage de la machine.

Ce qui mérite vraiment d'être raconté, c'est un défaut trouvé dans ce pont lors d'un essai en conditions réelles.

Le pont ouvrait une route vers l'adresse du conteneur. Mais il ne supprimait pas la route d'un conteneur disparu. Après un redémarrage, la route d'une adresse temporaire était restée suspendue. Conséquence : si un autre appareil prend plus tard cette adresse, le trafic qui lui est destiné est dévié vers le pont. Le défaut ne frappe donc pas le conteneur, mais un tiers innocent du réseau.

La correction a consisté à faire du pont non plus une chose qui ajoute seulement des routes, mais une chose qui supprime les routes ne correspondant plus à un conteneur vivant.

La leçon générale vaut aussi hors du réseau : ajouter est la moitié facile. Une route, une règle, une correspondance est une affirmation que vous faites sur le monde. Quand le monde change, une affirmation que personne n'a retirée devient un mensonge, et elle frappe le plus souvent non pas vous, mais quelqu'un qui n'a rien à voir avec vous.