DNS settings and routing traffic to services

Add an A record to the DNS

Since the MedStack Control managed load balancer runs on the Docker manager node, the manager node is the point of ingress for all traffic. That means that in order to make applications that run in MedStack Control clusters available to the open internet, a DNS A record that configures the service's domain to the host IP address of the manager node is required.

For example, (1) if the cluster manager node's IP address is 192.168.0.1 and (2) there is a service running in the cluster configured to handle requests to api.company.com, then the DNS settings for company.com will need to have an A record for the api subdomain that points to the host 192.168.0.1.

Verify DNS configuration

If the DNS for your domains are configured correctly, you'll see that there is an A record for each domain that points to the IP address of the manager node.

You can verify the DNS configuration of domains by using a DNS look-up tool, like this one: https://mxtoolbox.com/DNSLookup.aspx 

How traffic is routed

The MedStack Control firewall and load balancer ensure that traffic to the application layer can only come over port 443, that is, as an encrypted HTTP-based web request (HTTPS).

If you're having trouble with generating SSL certificates for services, please see our article on SSL certificate issues.

When the load balancer receives a web request, it routes traffic to the service running in Docker that has been configured to be served at the domain requested. There are two common ways traffic can be handled in the application layer.

With a web server

In cases where a web server is used to handle HTTP requests, the web server runs as a Docker service and is configured with all the domains it will need to route through to other services in the application layer.

In this example, the nginx web server could be configured for handling many domains and then routing traffic to the appropriate service. This would enable path-based routing configurations, or simply allow traffic to proxy the web server for serving clients.

Example

The Docker service configuration could look like the following.

// PATCH request body example to the /services endpoint

// Service: nginx
{
    "hosts":[
        "dashboard.company.com",
        "api.company.com"
    ]
}

The DNS settings would look the following.

// Docker manager node IP address = 192.168.0.1
// DNS records for company.com

Type | Domain    | Host        | TTL  |
---- | --------- | ----------- | ---- |
A    | dashboard | 192.168.0.1 | 60 s |
A    | api       | 192.168.0.1 | 60 s |

Directly to services

In cases where services themselves can handle HTTP requests, they can be configured to handle requests to the domain.

Example

The Docker services configuration could look like the following.

// PATCH request body example to the /services endpoint

// Service: serviceA
{
    "hosts":[
        "dashboard.company.com"
    ]
}

// Service: serviceB
{
    "hosts":[
        "api.company.com"
    ]
}

The DNS settings would look the following.

// Docker manager node IP address = 192.168.0.1
// DNS records for company.com

Type | Domain    | Host        | TTL  |
---- | --------- | ----------- | ---- |
A    | dashboard | 192.168.0.1 | 60 s |
A    | api       | 192.168.0.1 | 60 s |