Some Notes on Making use of DigitalOcean’s Load Balancers

This is just a high-level overview of how I’ve introduced DigitalOcean’s Load Balancer service into my application environment, in place of other, self-administrated technologies; I won’t go into too much technical detail beyond where this fits, what benefits it brought me personally (and may be useful or insightful for your project!), etc.

I recently launched a project to deploy a Docker-powered OpenVPN servers using users’ DigitalOcean account to provide infrastructure in a one-step workflow:

To handle the load from the deployer, I’d leveraged native load balancing tooling as more nodes joined my cluster (and thus more containers to execute the requests), and that allowed me a lot of control over shaping my traffic to and from application containers.

With that said, I was not making the most effective use of the resources in my cluster, so I elected to add a public ingress to each node in the cluster, which would load-balancer containers across the cluster (since most tasks are not executed by those front-end services, and handed off, anyway, to not-exposed services), and then, using DigitalOcean’s Load Balancers, balance traffic across this quota:

Pretty straight-forward, right? In this case, while the LB does offer passthrough for HTTPS, I elected to manage my SSL certificate on the DigitalOcean LB directly, rather than on the downstream proxies in the cluster.

This setup, linking Droplets to the upstream load balancer, allows me to more logically manage my nodes, particularly in a frequently-changing environment, where nodes go up and down and creates happen somewhat regularly.

In this case, I monitor the nodes for certain metrics, and if a threshold is met, a call is made to the DigitalOcean API to provision more nodes to automatically join the cluster, which means, another ingress, and thus, I need some way to link that back to the DNS level (previously, it was checking in the IP to a key-value store that my top-level load-balancer was reading from). With this new feature, it becomes a single step from provisioning:

+-----------------------------+
| DigitalOcean |
| Load Balancer (HTTPS) |
| | <------ Replaces old upstream,
+------------------------+----+ k-v store-backed LBs
^
+ |
^ |
+---------+--------------+----+
| Upstream LBs |
| | <------+ Adding new ingresses
+-+-------------------------+-+ |
| | +
^ Container Nodes ^ New Nodes!
+-+-------------------------+-+ +---------------+
| || || || | | || | <------+
| || || || | | || | |
+-----------------------------+ +---------------+ |
| Block Storage | +
+--------------------+ If limit exceed, call to DO API
| Monitoring |
| | ^
+----+---------------+ |
| |
| +-------------------------+ |
| | Task Runner +----+
+-----> | (Autoscale Trigger)|
+-------------------------+

The API provides the ability to dump, modify, and then update the LB configuration; so, adding an additional call to complete this part of the process allows me to programmatically:

  1. Create the new node, run all of my relevant set-up scripts, via user-data.
  2. Wait for an IP, Test the node’s endpoint for responsiveness
  3. Then, have it join the Load Balancer:

The Load-Balancers are region specific, so when you maintain multiple application clusters, in different regions, this also makes it logical and consistent if you use a DNS provider like NS1 or Route 53 which offer things like geography-based routing rules, rather than having to make additional calls to these APIs to update your cluster’s availability, and only when you add additional load balancers will this be required.

            +---------------+
| DNS Request |
| |
| |
+-------+-------+
|
^
+-------------------+--------------------+
| Geo DNS Routing |
| | Requests routed to most
+------------------+---------------------+ ideal DO region's LB.
|
+------------------------+
^ |> ^
+----+--+ +-------+ +---+---+
| | | | | |
| NYC 3| | SFO 2| | AMS 3|
| | | | | |
+-------+ +-------+ +-------+

From my example above, I used an in-house solution to handle tasks on an as-needed basis (not unlike AWS Lambda, or Webtask.io, which can likely replicate this functionality without any trouble, and probably a little better than something most of would script ourselves), which is where the automation began to become problematic; to make it fully automated, more and more had to happen, and it had to remotely manage more and more services (to DigitalOcean, the key-value store for the load balancer, managing the rolling restarts for said load balancers). With this feature, it is now reduced to two calls (a create and update on the Droplet and Load Balancer endpoints) to the DigitalOcean API.

This is, of course, not a comprehensive guide to what you can do with the DigitalOcean load balancer, however, my usage here demonstrates the programmability of many public clouds, in general, and in the case of my provider of choice, a feature-set that seems to be evolving with the needs of these large, ephemerally-minded environments conducive to scale and consistency when highly-automated.