Bottom line: Identify how the service publishes its port before explaining why a node answers or fails a probe. Keep the external load-balancer target list and actual task placement tied to that mode so a quiet node is not automatically treated as an invalid backend.
\nThe Use Swarm mode routing mesh documentation is the primary reference.
\nThe Swarm ingress routing mesh accepts published-port connections on nodes even when a service task is not running on that node, then routes them to an active container. With host publication, a node without a service task does not provide that service on the port; another application might be listening there instead. For the documented routing-mesh load-balancer arrangement, every swarm node can be a target, and task movement does not require reconfiguring that external load balancer.
\nThis article selects the target population appropriate to the documented publication mode. It does not approve firewall exposure, choose a universal health probe or establish application availability. Keep DNS round-robin endpoint mode and routing-mesh bypass design under their exact additional requirements. A TCP response alone should not establish that the intended service handled the request.
\nDSE recommends reviewing publication mode and task placement together before changing Swarm load-balancer targets.
\nObtain the current supported service inspection and load-balancer configuration. Record the published port, target port, protocol and publication mode without copying example addresses into the design. Map current task locations separately from the backend-node list. Ask the service owner to explain which relationship the selected mode is intended to create.
\nReview a node with no local task as a specific case. For an ingress design, inspect the expected routed application path. For a host-mode design, identify which nodes should actually provide the service and how the external configuration follows that population. Preserve an unrelated listener as a finding instead of counting any open port as a healthy service instance.
\nHave the network owner review allowed load-balancer-to-node reachability through the approved filtering arrangement. Keep that reachability decision separate from whether a task is local. Avoid disabling host or Docker networking controls merely because a backend probe disagrees with the current spreadsheet.
\nPlan the treatment of task movement and node maintenance before changing the target list. Identify who owns membership updates where the design requires them. Retain the previous service and load-balancer revisions so an unexpected route can be investigated without changing both systems repeatedly.
\nProposed verification, not performed: use a disposable service and authorized load balancer in a test swarm. Record a node with a task and a node without one, then predict the intended application-level response under the chosen publication mode.
\nExercise only the approved mode and collect sanitized service inspection, task placement, target configuration and actual requests. A separate host-mode comparison needs its own supported arrangement and explicit targets. If task movement is part of the accepted test, observe the resulting path rather than inferring it from a healthy probe. Keep protocol reachability, correct application identity and recovery timing as distinct observations.
\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.
\n", "content_text": "Bottom line: Identify how the service publishes its port before explaining why a node answers or fails a probe. Keep the external load-balancer target list and actual task placement tied to that mode so a quiet node is not automatically treated as an invalid backend.\nSource fact: documented behavior\nThe Use Swarm mode routing mesh documentation is the primary reference.\nThe Swarm ingress routing mesh accepts published-port connections on nodes even when a service task is not running on that node, then routes them to an active container. With host publication, a node without a service task does not provide that service on the port; another application might be listening there instead. For the documented routing-mesh load-balancer arrangement, every swarm node can be a target, and task movement does not require reconfiguring that external load balancer.\nWhat the source does not establish\nThis article selects the target population appropriate to the documented publication mode. It does not approve firewall exposure, choose a universal health probe or establish application availability. Keep DNS round-robin endpoint mode and routing-mesh bypass design under their exact additional requirements. A TCP response alone should not establish that the intended service handled the request.\nApplicability questions\n\nDoes the service use ingress or host publication?\nWhich nodes currently run its tasks?\nWhich nodes does the external load balancer target?\nWhat application response will identify the intended backend service?\n\nDSE recommendation: review mode before editing the backend list\nDSE recommends reviewing publication mode and task placement together before changing Swarm load-balancer targets.\nObtain the current supported service inspection and load-balancer configuration. Record the published port, target port, protocol and publication mode without copying example addresses into the design. Map current task locations separately from the backend-node list. Ask the service owner to explain which relationship the selected mode is intended to create.\nReview a node with no local task as a specific case. For an ingress design, inspect the expected routed application path. For a host-mode design, identify which nodes should actually provide the service and how the external configuration follows that population. Preserve an unrelated listener as a finding instead of counting any open port as a healthy service instance.\nHave the network owner review allowed load-balancer-to-node reachability through the approved filtering arrangement. Keep that reachability decision separate from whether a task is local. Avoid disabling host or Docker networking controls merely because a backend probe disagrees with the current spreadsheet.\nPlan the treatment of task movement and node maintenance before changing the target list. Identify who owns membership updates where the design requires them. Retain the previous service and load-balancer revisions so an unexpected route can be investigated without changing both systems repeatedly.\nVerification and evidence\nProposed verification, not performed: use a disposable service and authorized load balancer in a test swarm. Record a node with a task and a node without one, then predict the intended application-level response under the chosen publication mode.\nExercise only the approved mode and collect sanitized service inspection, task placement, target configuration and actual requests. A separate host-mode comparison needs its own supported arrangement and explicit targets. If task movement is part of the accepted test, observe the resulting path rather than inferring it from a healthy probe. Keep protocol reachability, correct application identity and recovery timing as distinct observations.\nOfficial references\n\nUse Swarm mode routing mesh — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "content_markdown": "Bottom line: Identify how the service publishes its port before explaining why a node answers or fails a probe. Keep the external load-balancer target list and actual task placement tied to that mode so a quiet node is not automatically treated as an invalid backend.\n\n## Source fact: documented behavior\n\nThe [Use Swarm mode routing mesh](https://docs.docker.com/engine/swarm/ingress/) documentation is the primary reference.\n\nThe Swarm ingress routing mesh accepts published-port connections on nodes even when a service task is not running on that node, then routes them to an active container. With host publication, a node without a service task does not provide that service on the port; another application might be listening there instead. For the documented routing-mesh load-balancer arrangement, every swarm node can be a target, and task movement does not require reconfiguring that external load balancer.\n\n## What the source does not establish\n\nThis article selects the target population appropriate to the documented publication mode. It does not approve firewall exposure, choose a universal health probe or establish application availability. Keep DNS round-robin endpoint mode and routing-mesh bypass design under their exact additional requirements. A TCP response alone should not establish that the intended service handled the request.\n\n## Applicability questions\n\n- Does the service use ingress or host publication?\n\n- Which nodes currently run its tasks?\n\n- Which nodes does the external load balancer target?\n\n- What application response will identify the intended backend service?\n\n## DSE recommendation: review mode before editing the backend list\n\nDSE recommends reviewing publication mode and task placement together before changing Swarm load-balancer targets.\n\nObtain the current supported service inspection and load-balancer configuration. Record the published port, target port, protocol and publication mode without copying example addresses into the design. Map current task locations separately from the backend-node list. Ask the service owner to explain which relationship the selected mode is intended to create.\n\nReview a node with no local task as a specific case. For an ingress design, inspect the expected routed application path. For a host-mode design, identify which nodes should actually provide the service and how the external configuration follows that population. Preserve an unrelated listener as a finding instead of counting any open port as a healthy service instance.\n\nHave the network owner review allowed load-balancer-to-node reachability through the approved filtering arrangement. Keep that reachability decision separate from whether a task is local. Avoid disabling host or Docker networking controls merely because a backend probe disagrees with the current spreadsheet.\n\nPlan the treatment of task movement and node maintenance before changing the target list. Identify who owns membership updates where the design requires them. Retain the previous service and load-balancer revisions so an unexpected route can be investigated without changing both systems repeatedly.\n\n## Verification and evidence\n\nProposed verification, not performed: use a disposable service and authorized load balancer in a test swarm. Record a node with a task and a node without one, then predict the intended application-level response under the chosen publication mode.\n\nExercise only the approved mode and collect sanitized service inspection, task placement, target configuration and actual requests. A separate host-mode comparison needs its own supported arrangement and explicit targets. If task movement is part of the accepted test, observe the resulting path rather than inferring it from a healthy probe. Keep protocol reachability, correct application identity and recovery timing as distinct observations.\n\n## Official references\n\n- [Use Swarm mode routing mesh](https://docs.docker.com/engine/swarm/ingress/) — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change." }, "json_ld": { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://dsesecurity.com/#organization", "name": "Detection Systems & Engineering", "alternateName": "DSE Security", "url": "https://dsesecurity.com/", "logo": { "@type": "ImageObject", "url": "https://update.dsesecurity.com/assets/dse-logo-20260812.png?v=1.8.20" } }, { "@type": "Organization", "@id": "https://update.dsesecurity.com/#editorial-team", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/", "parentOrganization": { "@id": "https://dsesecurity.com/#organization" } }, { "@type": "WebSite", "@id": "https://update.dsesecurity.com/#website", "name": "DSE Updates", "alternateName": "DSE Security Knowledge Hub", "url": "https://update.dsesecurity.com/", "inLanguage": "en-US", "publisher": { "@id": "https://dsesecurity.com/#organization" }, "potentialAction": { "@type": "SearchAction", "target": { "@type": "EntryPoint", "urlTemplate": "https://update.dsesecurity.com/?q={search_term_string}" }, "query-input": "required name=search_term_string" } }, { "@type": "WebPage", "@id": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/", "url": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/", "isPartOf": { "@id": "https://update.dsesecurity.com/#website" }, "lastReviewed": "2026-10-29" }, { "@type": "BreadcrumbList", "@id": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/#breadcrumbs", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "DSE Updates", "item": "https://update.dsesecurity.com/" }, { "@type": "ListItem", "position": 2, "name": "IT", "item": "https://update.dsesecurity.com/topic/it/" }, { "@type": "ListItem", "position": 3, "name": "Match Swarm load-balancer targets to the port publication mode", "item": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/" } ] }, { "@type": [ "Article", "TechArticle" ], "@id": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/#article", "identifier": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/", "url": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/", "headline": "Match Swarm load-balancer targets to the port publication mode", "description": "Separate routing-mesh reachability from host-mode task placement. Review the external load-balancer target population against the service’s actual…", "abstract": "Separate routing-mesh reachability from host-mode task placement. Review the external load-balancer target population against the service’s actual publication mode.", "articleBody": "Bottom line: Identify how the service publishes its port before explaining why a node answers or fails a probe. Keep the external load-balancer target list and actual task placement tied to that mode so a quiet node is not automatically treated as an invalid backend.\nSource fact: documented behavior\nThe Use Swarm mode routing mesh documentation is the primary reference.\nThe Swarm ingress routing mesh accepts published-port connections on nodes even when a service task is not running on that node, then routes them to an active container. With host publication, a node without a service task does not provide that service on the port; another application might be listening there instead. For the documented routing-mesh load-balancer arrangement, every swarm node can be a target, and task movement does not require reconfiguring that external load balancer.\nWhat the source does not establish\nThis article selects the target population appropriate to the documented publication mode. It does not approve firewall exposure, choose a universal health probe or establish application availability. Keep DNS round-robin endpoint mode and routing-mesh bypass design under their exact additional requirements. A TCP response alone should not establish that the intended service handled the request.\nApplicability questions\n\nDoes the service use ingress or host publication?\nWhich nodes currently run its tasks?\nWhich nodes does the external load balancer target?\nWhat application response will identify the intended backend service?\n\nDSE recommendation: review mode before editing the backend list\nDSE recommends reviewing publication mode and task placement together before changing Swarm load-balancer targets.\nObtain the current supported service inspection and load-balancer configuration. Record the published port, target port, protocol and publication mode without copying example addresses into the design. Map current task locations separately from the backend-node list. Ask the service owner to explain which relationship the selected mode is intended to create.\nReview a node with no local task as a specific case. For an ingress design, inspect the expected routed application path. For a host-mode design, identify which nodes should actually provide the service and how the external configuration follows that population. Preserve an unrelated listener as a finding instead of counting any open port as a healthy service instance.\nHave the network owner review allowed load-balancer-to-node reachability through the approved filtering arrangement. Keep that reachability decision separate from whether a task is local. Avoid disabling host or Docker networking controls merely because a backend probe disagrees with the current spreadsheet.\nPlan the treatment of task movement and node maintenance before changing the target list. Identify who owns membership updates where the design requires them. Retain the previous service and load-balancer revisions so an unexpected route can be investigated without changing both systems repeatedly.\nVerification and evidence\nProposed verification, not performed: use a disposable service and authorized load balancer in a test swarm. Record a node with a task and a node without one, then predict the intended application-level response under the chosen publication mode.\nExercise only the approved mode and collect sanitized service inspection, task placement, target configuration and actual requests. A separate host-mode comparison needs its own supported arrangement and explicit targets. If task movement is part of the accepted test, observe the resulting path rather than inferring it from a healthy probe. Keep protocol reachability, correct application identity and recovery timing as distinct observations.\nOfficial references\n\nUse Swarm mode routing mesh — Docker Docs.\n\nSource review completed October 29, 2026. Recheck the official documentation and deployment-specific applicability before a production change.", "datePublished": "2026-10-29T20:32:48+00:00", "dateModified": "2026-10-29T20:33:36+00:00", "mainEntityOfPage": { "@id": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/" }, "inLanguage": "en-US", "isAccessibleForFree": true, "author": { "@type": "Organization", "name": "DSE Security Editorial Team", "url": "https://update.dsesecurity.com/#editorial-team" }, "publisher": { "@id": "https://dsesecurity.com/#organization" }, "image": { "@type": "ImageObject", "@id": "https://update.dsesecurity.com/updates/match-swarm-load-balancer-targets-to-the-port-publication-mode/#primaryimage", "url": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "contentUrl": "https://update.dsesecurity.com/assets/editorial/network-infrastructure-social-v2.jpg?v=1.8.20", "width": 1200, "height": 630, "caption": "Match Swarm load-balancer targets to the port publication mode" }, "articleSection": [ "IT", "Networks & Infrastructure" ], "keywords": [ "IT", "Networks & Infrastructure", "Guide", "Advisory priority" ], "genre": "Guide", "about": [ { "@type": "Thing", "name": "IT", "url": "https://update.dsesecurity.com/topic/it/" }, { "@type": "Thing", "name": "Networks & Infrastructure", "url": "https://update.dsesecurity.com/topic/networks-infrastructure/" } ], "wordCount": 573, "timeRequired": "PT3M", "publishingPrinciples": "https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/", "usageInfo": "https://update.dsesecurity.com/usage/", "copyrightHolder": { "@id": "https://dsesecurity.com/#organization" }, "copyrightNotice": "Copyright © 2026 Detection Systems & Engineering. All rights reserved.", "citation": { "@type": "CreativeWork", "name": "Docker Docs — Use Swarm mode routing mesh", "url": "https://docs.docker.com/engine/swarm/ingress/" } } ] } }