Load Balancers
Dboxed supports load-balancers to provide ingress into your services. For now, only Caddy is supported as the load-balancer type.
Later versions of Dboxed will support more types of load-balancers.
How Load Balancers work
Creating a load-balancer via the CLI or dashboard will internally cause Dboxed to create one or more boxes (replicas) with all the necessary configuration pre-configured. This includes compose configuration, load-balancer specific configuration (e.g. Caddyfile), port forwardings, and so on.
These boxes must then be run on internet facing machines with public IP addresses. The load balancers are then accessible through the public IPs.
You must then setup DNS records on your favorite DNS provider, pointing an A record to the public IPs.
When a load-balancer is running, you can define Load Balancer Services on Boxes, which are then served by the load-balancer.
Connectivity to your services
A load-balancer replica runs inside a box, the same way as any other box defined by you. They are always part of a network, which will allow them to access any other box from the same network, no matter where these boxes are run.
This mechanism is re-used to implement traffic from the internet -> load-balancer -> your box.
Future DNS features
Dboxed will support different DNS providers (like AWS Route53 ) in the future. It will use these to automatically setup records for (sub-)domains, so that your services will automatically get valid domain names and SSL certificates.
Future of high availability
Dboxed way of solving Load Balancer has the big advantage of being cloud provider independent, as it works on any machine that has a public internet facing IP.
It, however, will run into issues when it comes to high availability, because the IP is bound to one specific machine. Having multiple machines will not solve this issue completely, because then the DNS records would have to point to all of them, causing the round-robin nature of DNS resolution to cause random failures when a machine goes down.
Dboxed will try to solve this with four different strategies in the future:
- When run on a VPS from a supported cloud provider, Dboxed will allow putting a cloud load balancer (like AWS NLB ) in front of the Dboxed load-balancer replicas, which will solve the high-availability with the help of the cloud load-balancer. This will however add extra costs, but at least not make you fully dependent on the cloud provider.
- As an alternative, when running on a cloud provider, Dboxed will be able to dynamically attach and move around public IPs between servers, so that failure of one machine only results in a few seconds of unreachability. AWS for example offers Elastic IPs that can be used while Hetzner offers Floating IPs . Most cloud providers offer a comparable feature that can be leveraged.
- Third-party Load-Balancer solutions like Cloudflare load-balancers will be supported to be put in front of the Dboxed load-balancer replicas.
- When run on bare-metal in your own datacenter, Dboxed will leverage internet standards like BGP.