Scale up as you grow — whether you're running one virtual machine or ten thousand.

From GPU-powered inference and Kubernetes to managed databases and storage, get everything you need to build, scale, and deploy intelligent applications.

This textbox defaults to using Markdown to format your answer.
You can type !ref in this text area to quickly search our full set of tutorials, documentation & marketplace offerings and insert the link!
Did you mean ‘443’ instead of 80 in the “Things to Check” section?
" […] want your servers to use only HTTPS, you will want to make sure that your web servers (e.g. www-1, www-2, etc.) are only listening on their private IP addresses on port 80. Otherwise, users will be able to access your web servers via HTTP (unencrypted) […]"
It’s a small matter. I’m thoroughly reading the articles you are hosting here! I’ve been hearing a lot of great things about your droplets from several friends; not to mention TechSnap, one of my favorite podcasts. The team I’m working with now is using, I won’t say it outright, a competitor… linear poems… an ode… to a line… a line…ode… anyway.
Keep up the great work.
I don’t think you will hear this much, but I’m convinced. Run from docker like the plague. I don’t have anything against them in particular, but there is going to be some sad suckers, docents in a sense I suppose, when china haz root on their servers; at least, it was easy though, right?
I’m of the opinion that any management / provisioning frameworks that require a running process (Puppet and Chef included) will all introduce the same basic risk; increased attack surface - unnecessarily. SSH based provisioning frameworks are not as popular; but frameworks like Ansible or Python’s Fabric are less risky. Nothing is risk free, but they do not increase your system’s attack surface nor do they use computational resources beyond those resources used doing their assigned task, as opposed to, waiting / listening for a client to assign them a task.
I’d love to see an article from you guys on Ansible or Fabric… or maybe write one for you?
@ssullivan: Thank you for the feedback :) Glad to hear you’re enjoying our tutorials!
I believe Mitchell meant to emphasize the “private IP addresses” bit. Because SSL is handled by HAProxy, the webservers don’t need to bother about it. They accept unencrypted connections from HAProxy over the private network, so they listen on port 80 on the private interface. If they were listening on the public interface instead, anyone would be able to access them directly without passing through HAProxy first and as a result not using HTTPS.
As for Ansible and Fabric, we have some tutorials on them as well: Configuration Management Tutorials & Popular Questions. But you’re welcome to write an article (or more) and get paid for it!
@ssullivan / kamal: Sorry for the late reply. Yes, Kamal is correct. All the SSL is handled by HAProxy in this setup.
@Kamal / Michell: Thanks for the great info.
I imagine you would want to have the proper iptables rules in place to limit communications between only the haproxy and www-1 / www-2 boxes as per: how-to-isolate-servers-within-a-private-network-using-iptables
Could someone still listen to the unencrypted port 80 traffic on the private interface using something like wireshark from another node on the shared private network? Or would the iptables rules be enough? If not how can I have SSL all the way to www-1 / www-2?
Thanks again for your great work!
The most important thing is that your web servers are listening on port 80 on the private interface only (via web server configuration), or the public interface port 80 is blocked. You may also block out other connections, like in the tutorial you linked, but that’s not strictly necessary.
If you want to pass SSL through HAProxy to your web servers, one way to do it is to change the HAProxy mode to layer 4 tcp (vs. the default layer 7 http) and install the identical SSL cert on each of your web server backends (in the web server configuration). With this setup, HAProxy would not look at the contents of the packets and just send them to the backends, which would have to handle the SSL.
Thank you very much! It was very hard to find a good tutorial on this subject. I tried the configuration you suggested and it worked perfectly. :)
@arun_shop: I’m not 100% sure, but I think you need two different public IP addresses to use two different SSL certificates in the same HAProxy server. Because the ssl cert parameter is part of the bind parameter, which binds to an IP address. I would guess you need two different frontends, which bind to separate IP addresses.
If your domains are subdomains (e.g. xyz.abc.com and abc.com), you use a wildcard SSL cert, you can redirect the traffic to the proper subdomains using ACLs.
Without SSL, you can definitely server two different hosts with the same frontend, using ACLs. Something like this would do that:
frontend www-https
bind haproxy_www_public_IP:80
acl is_abc hdr_end(host) -i abc.com
acl is_xyz hdr_end(host) -i xyz.com
use_backend abc-backend if is_abc
use_backend xyz-backend if is_xyz
default_backend abc-backend
backend abc-backend
server abc-1 abc_1_private_IP:80 check
server abc-2 abc_2_private_IP:80 check
backend xyz-backend
server xyz-1 xyz_1_private_IP:80 check
server xyz-2 xyz_2_private_IP:80 check