Route traffic to a Swarm service¶

After Interlock is deployed, you can launch and publish services and applications. This topic describes how to configure services to publish themselves to the load balancer by using service labels.

Caution

The following procedures assume a DNS entry exists for each of the applications (or local hosts entry for local testing).

To publish a demo service with four replicas to the host (demo.local):

Create a Docker Service using the following two labels:
- com.docker.lb.hosts for Interlock to determine where the service is available.
- com.docker.lb.port for the proxy service to determine which port to use to access the upstreams.
Create an overlay network so that service traffic is isolated and secure:
```
docker network create -d overlay demo
1se1glh749q1i4pw0kf26mfx5
```

Deploy the application:

docker service create \
--name demo \
--network demo \
--label com.docker.lb.hosts=demo.local \
--label com.docker.lb.port=8080 \
mirantiseng/docker-demo
6r0wiglf5f3bdpcy6zesh1pzx

Interlock detects when the service is available and publishes it.

After tasks are running and the proxy service is updated, the application is available through http://demo.local:

curl -s -H "Host: demo.local" http://127.0.0.1/ping
{"instance":"c2f1afe673d4","version":"0.1",request_id":"7bcec438af14f8875ffc3deab9215bc5"}

To increase service capacity, use the docker service scale command:
```
docker service scale demo=4
demo scaled to 4
```

The load balancer balances traffic across all four service replicas configured in this example.

To publish a service with a web interface

This procedure deploys a simple service that includes the following:

A JSON endpoint that returns the ID of the task serving the request.
A web interface available at http://app.example.org that shows how many tasks the service is running.

Create a docker-compose.yml file that includes the following:

version: "3.2"

services:
  demo:
    image: mirantiseng/docker-demo
    deploy:
      replicas: 1
      labels:
        com.docker.lb.hosts: app.example.org
        com.docker.lb.network: demo_demo-network
        com.docker.lb.port: 8080
    networks:
      - demo-network

networks:
  demo-network:
    driver: overlay

Label	Description
`com.docker.lb.hosts`	Defines the hostname for the service. When the layer 7 routing solution gets a request containing `app.example.org` in the host header, that request is forwarded to the demo service.
`com.docker.lb.network`	Defines which network the `ucp-interlock-proxy` should attach to in order to communicate with the demo service. To use layer 7 routing, you must attach your services to at least one network. If your service is attached to a single network, you do not 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 and layer 7 routing, prefix `com.docker.lb.network` with the stack name to ensure traffic is directed to the correct overlay network. In combination with `com.docker.lb.ssl_passthrough`, the label in mandatory even if your service is only attached to a single network.
`com.docker.lb.port`	Specifies which port the `ucp-interlock-proxy` service should use to communicate with this demo service. Your service does not need to expose a port in the Swarm routing mesh. All communications are done using the network that you have specified.

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

Download and configure the client bundle and deploy the service:

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

To test your services using the CLI:

Verify that requests are routed to the demo service:

curl --header "Host: app.example.org" \
http://<mke-address>:<routing-http-port>/ping

<mke-address> is the domain name or IP address of an MKE node.
<routing-http-port> is the port used to route HTTP traffic.

Example of a successful response:

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

To test your services using a browser:

Because the demo service exposes an HTTP endpoint, you can also use your browser to validate that it works.

Verify that the /etc/hosts file in your system has an entry mapping app.example.org to the IP address of an MKE node.
Navigate to http://app.example.org in your browser.