Load Balancer Management¶

We run HAProxy on each and every container node. For clusters, they will keep a duplicate copy of the current configuration, as well as, any certificates installed.

This way, in the event of an IP failover even, the other load balancer is already running and ready to start serving requests.

IP Settings¶

SSL Settings¶

You must install a Wildcard SSL certificate for the LoadBalancer. The LoadBalancer will not start without one.

During the installation process, a self-signed certificate was automatically generated and installed to the load balancer. To install a valid certificate, you have two options:

1. Purchase a wildcard certificate and install it yourself
   • (You may optionally purchase one from us for $50/year. Please contact us for details.)
2. Use our ACME (LetsEncrypt) service to generate a wildcard certificate for free.

A wildcard certificate can only be validated over DNS, so ComputeStacks must be able to write the validation record. Either:

• the load balancer's domain is hosted in ComputeStacks: a zone covering it must exist in the Settings -> DNS menu, and the nameservers must be correctly configured (see the example below), or;
• the domain stays at another DNS host and delegates only its validation to ComputeStacks through a DNS alias zone.

Example¶

If your shared container domain was a.cmptstks.net, you would create a new zone in Settings -> DNS for cmptstks.net. If your domain was a.region.cmptstks.net, you would still create the domain cmptstks.net.

Once that's added, you will now need to update the nameserver settings for your domain to point to ours. For this, you have two options:

1. Point your root domain (by editing the nameserver settings at domain registrar) to our nameservers, or;
2. Keep your existing nameserver and use delegation. This is where you create new NS records for a subdomain, and point to our nameservers. Here is an example guide for doing that with Cloudflare.

If your loadbalancer App URL was a.fra.example.net, you would create the following nameserver entries to point to our hosted dns service:

fra.example.net 86400 IN NS ns1.auto-dns.com.
fra.example.net 86400 IN NS ns3.auto-dns.com.
fra.example.net 86400 IN NS ns3.autodns.nl.
fra.example.net 86400 IN NS ns4.autodns.nl.

Domains not hosted on our DNS¶

If a load balancer's domain is hosted somewhere else and you'd rather not move or delegate it, you can still use the ACME service by validating the certificate through a DNS alias zone. The domain delegates a single record, _acme-challenge.<domain>, to a name in a zone that ComputeStacks controls, and ComputeStacks answers the validation there.

1. Pick a zone for the purpose, such as acme.example.net, delegate it to our nameservers (as in the example above), and create it in Settings -> DNS.
2. Enter that zone as the DNS Alias Zone in the ACME Certificates section of the admin settings.

3. Each load balancer whose domain is not hosted in ComputeStacks now gets its own name in the alias zone, lb<id>.<zone>, where <id> is the load balancer's ID. The load balancer's edit form shows the exact record to add, for example:

   _acme-challenge.a.fra.example.net. CNAME lb3.acme.example.net.
   

4. Add that CNAME at the domain's DNS host. The target must match exactly; any other target is reported as invalid.

5. Click Deploy (the rotate button on the load balancer list) to re-validate the domain. When the domain is invalid, Deploy re-runs domain validation, even if the load balancer has no certificate yet.

Until the CNAME is in place, the load balancer's domain is marked invalid, and certificate renewals stop before asking Let's Encrypt to validate the wildcard. The renewal event names the missing record, so a missing CNAME doesn't turn into a string of failed validation attempts.

Load balancers whose domain is hosted in ComputeStacks are unaffected: a local zone covering the domain is always used first. Leave DNS Alias Zone blank to turn the feature off.

Renewals that write to the same DNS zone, which every load balancer using the alias zone does, are serialized, so they no longer overwrite each other's validation records. A renewal that fails to push the zone to the DNS server reverts its change, so the zone isn't left with uncommitted changes that would block later renewals.

The domain validation event reports the problem with one of these codes: