Choisir le prochain port d’un service suppose de distinguer ports host et ports internes. Un binding sur l’hôte fausse le calcul du suivant disponible.
On veut ajouter un service et lui assigner un port libre. Sans audit, on tombe sur un conflit au démarrage, ou pire, sur un port déjà exposé qu’on croyait fermé.
Port host et port interne ne sont pas le même
Un conteneur écoute sur un port interne, dans son propre espace réseau. Ce port n’entre en collision avec rien tant qu’il n’est pas publié vers l’hôte. Plusieurs conteneurs peuvent écouter sur le même port interne sans se gêner.
Le port host est différent : c’est celui que le conteneur réserve sur l’interface de la machine. Deux services ne peuvent pas réclamer le même port host sur la même interface. C’est là que naissent les conflits.
Pourquoi un binding host fausse le calcul
Pour trouver le prochain port de service libre, on regarde les ports host déjà bindés, pas les ports internes. Un service exposé directement sur l’hôte occupe un port host qui ne ressort pas si on n’inspecte que les ports internes des conteneurs.
On audite donc côté hôte : ce qui écoute réellement sur les interfaces de la machine. C’est l’union des bindings de conteneurs et des services natifs. Le prochain port libre se choisit dans cet espace, pas dans celui des ports internes.
Le principe : le conflit vit sur l’hôte. On compte les ports host occupés pour trouver le suivant, sans confondre exposition externe et écoute interne.