Skip to content

3-node+ setup without sslh

micah requested to merge 3node into master

We only want to merge this one, or the other one, not both

When we originally talked about putting together float for vpn gateways for LEAP, we talked about doing things three different possible ways:

  1. the way we are doing it now, with the gateway inter-mingled with the frontend: the code currently does this and only selectively enables sslh when it finds that you have scheduled an openvpn service on the "frontend" node. If we use two separate groups without overlap, there wont be any sslh.
  2. we make an openvpn group that has the gateways on it, we decided that 1) was going to be easier, and if we wanted to reduce the overall resource needs of providers running lilypad.
  3. scale down the cluster to one host, so the frontend/backend are collapsed together. In this setup, you end up with your primary DNS server running elasticsearch, which isn't a great setup. It might not be worse than having 1 single DNS server in the first place, but scaling everything down to one host isn't such a great way to run a service.

This commit is about the second option, it eliminates sslh, it stops inheriting all the frontend stuff, resulting in the frontend being more clean. This way you have a 3-node+ setup, where you have a 'frontend', 'backend' and 'openvpn' group, which you can then scale out independently. This results in a much cleaner, and more logical separation, it also simplifies things.

Why not just changing the grouping for the openvpn service so it isn't scheduled on the frontend and the sslh is simply deactivated? This is a valid approach, and would involve less code churn. It would mean we would continue to support that model, and develop around it. It seems that while sslh is cool and it works, its confusing and complicating things, so I went with this method first because it seemed like this was what people were wanting.

We don't have to do it this way, we can do the sslh disabling way (see !22 (closed) as the counterpart alternative), but we need to decide the approach we want to support moving forward.

Edited by micah

Merge request reports