Route traffic to a Swarm service

After Interlock is deployed, you can launch and publish services and applications. Use Service Labels to configure services to publish themselves to the load balancer.

The following examples assume a DNS entry (or local hosts entry if you are testing locally) exists for each of the applications.

Publish a service with four replicas

Create a Docker Service using two labels:



The label instructs Interlock where the service should be available. The label instructs what port the proxy service should use to access the upstreams.

Publish a demo service to the host demo.local:

First, create an overlay network so that service traffic is isolated and secure:

$> docker network create -d overlay demo

Next, deploy the application:

$> docker service create \
    --name demo \
    --network demo \
    --label \
    --label \

Interlock detects when the service is available and publishes it. After tasks are running and the proxy service is updated, the application is available via http://demo.local.

$> curl -s -H "Host: demo.local"

To increase service capacity, use the Docker Service Scale command:

$> docker service scale demo=4
demo scaled to 4

In this example, four service replicas are configured as upstreams. The load balancer balances traffic across all service replicas.

Publish a service with a web interface

This example deploys a simple service that:

  • Has a JSON endpoint that returns the ID of the task serving the request.

  • Has a web interface that shows how many tasks the service is running.

  • Can be reached at

Create a docker-compose.yml file with:

version: "3.2"

    image: ehazlett/docker-demo
      replicas: 1
      labels: demo_demo-network 8080
      - demo-network

    driver: overlay

Note that:

  • Docker Compose files must reference networks as external. Include external:true in the docker-compose.yml file.

  • The label defines the hostname for the service. When the layer 7 routing solution gets a request containing in the host header, that request is forwarded to the demo service.

  • The defines which network the ucp-interlock-proxy should attach to in order to be able to communicate with the demo service. To use layer 7 routing, your services need to be attached to at least one network. If your service is only attached to a single network, you don’t need to add a label to specify which network to use for routing. When using a common stack file for multiple deployments leveraging MKE Interlock / Layer 7 Routing, prefix with the stack name to ensure traffic will be directed to the correct overlay network. When using in combination with the label in mandatory, even if your service is only attached to a single network.

  • The label specifies which port the ucp-interlock-proxy service should use to communicate with this demo service.

  • Your service doesn’t need to expose a port in the Swarm routing mesh. All communications are done using the network you’ve specified.

Set up your CLI client with a MKE client bundle and deploy the service:

docker stack deploy --compose-file docker-compose.yml demo

The ucp-interlock service detects that your service is using these labels and automatically reconfigures the ucp-interlock-proxy service.

Test using the CLI

To test that requests are routed to the demo service, run:

curl --header "Host:" \


  • <mke-address> is the domain name or IP address of a MKE node.

  • <routing-http-port> is the port you are using to route HTTP traffic.

If everything is working correctly, you should get a JSON result like:

{"instance":"63b855978452", "version":"0.1", "request_id":"d641430be9496937f2669ce6963b67d6"}

Test using a browser

Since the demo service exposes an HTTP endpoint, you can also use your browser to validate that everything is working.

Make sure the /etc/hosts file in your system has an entry mapping to the IP address of a MKE node. Once you do that, you’ll be able to start using the service from your browser.