Comptez les sorties du proxy séparément des répliques

Trois répliques de proxy derrière une seule passerelle de traduction peuvent encore exposer une seule sortie publique. Les adresses privées des conteneurs ne déterminent pas l'identité visible à la destination.

client → published service → proxy replica → egress/NAT → destination

Suivez le schéma en deux parties. Le service publié choisit comment un client atteint une réplique. La route de sortie et le NAT choisissent l'adresse source de la connexion ultérieure de cette réplique.

La maille de routage de Docker Swarm accepte le trafic sur un port de service publié et l'envoie à une tâche active. Cela prend en charge la répartition de l'entrée et les changements de placement des tâches ; elle n'attribue pas une sortie publique distincte à chaque réplique.

Si des sorties distinctes sont nécessaires, concevez leurs routes et adresses réelles, par exemple des hôtes routés séparément ou des passerelles de sortie dédiées, puis comptez les identités sortantes observées.

Remplacer une réplique remplace aussi ses flux actifs

Un tunnel CONNECT établi appartient à un seul processus proxy. Une autre tâche ne peut pas recréer de façon transparente l'état TCP et TLS de la destination lorsqu'elle remplace ce processus. Planifiez les reconnexions et videz les connexions de longue durée lors de la maintenance.

Transférez aussi l'authentification des clients et les politiques de destination vers les répliques. Le contrôle de port réussi d'un répartiteur de charge est plus étroit qu'un client autorisé négociant le protocole proxy requis. La capacité, l'identité de sortie et la survie des connexions sont des exigences distinctes à évaluer.