Edge Router Design

[faddat]

I'm putting this here for notability's sake. I went through this morning how exactly I think all of this should work, and here is my semifinal conclusion:

Container Routing Steps

1. Customer Orders a container
2. Customer enters subdomain/domain/containername, these are stored in rethinkdb
3. Container is launched by kdaemon
4. Kdaemon -> https://github.com/magneticio/vamp-router
5. vamp-router -> Haproxy
6. kDaemon -> Caddyfile or Caddy-Docker (This step is optional and several viable alternatives do exist)

   Reasoning/Pluses

   • uses the fewest components of any approach I am aware of
   • uses the fastest reverse proxy on the market
   • takes advantage of rethinkDB's native JSON
   • reversible for takedown of containers
   • We'd save Vamp-Router from abandonware-ness
   • Because HAPROXY supports protocols other than http/https, we would be able to host non-webapp containers, like virtual worlds and games
   • Allows us to use Caddy in front of http services to ensure that we serve every single one with https via the ambitious and awesome let's encrypt automatic TLS configuration system (unless customer requests http).

     Disadvantages

   • vamp-router seems to be semi-abandonware
   • We should add path validation (ensure that the container is genuinely runnning) to vamp-router, and probably take up its maintenance.

     Alternatives

   • Consul-Registrator-consultemplate-Haproxy
   • Consul-registrator-nginx
   • Traefik
   • caddy-docker + Consul + Registrator (while this is technically one fewer component, it does not provide the flexibility that haproxy does.

[Ozzadar]

Make this an issue on taiga.

It'll make it more visible when planning work timelines :) On Feb 15, 2016 08:11, "Jacob Gadikian" notifications@github.com wrote:

I'm putting this here for notability's sake. I went through this morning how exactly I think all of this should work, and here is my semifinal conclusion:

Container Routing Steps

1. Customer Orders a container
2. Customer enters subdomain/domain/containername, these are stored in rethinkdb
3. Container is launched by kdaemon
4. Kdaemon -> https://github.com/magneticio/vamp-router
5. vamp-router -> Haproxy 6. (for automated TLS, executed at the edge node after haproxy) kDaemon -> Caddyfile or Caddy-Docker (This step is optional and several viable alternatives do exist)

Reasoning/Pluses

• uses the fewest components of any approach I am aware of
• uses the fastest reverse proxy on the market
• takes advantage of rethinkDB's native JSON
• reversible for takedown of containers

Disadvantages

• vamp-router seems to be semi-abandonware
• We should add path validation (ensure that the container is genuinely runnning) to vamp-router

Alternatives

• Consul-Registrator-consultemplate-Haproxy
• Consul-registrator-nginx
• Traefik
• caddy-docker (current favorite alternative

— Reply to this email directly or view it on GitHub https://github.com/Superordinate/kDaemon/issues/7.

[faddat]

K

[faddat]

It seems our network is going to be a bit more robust than planned. Right now I have Discourse on one of the xeons on the 4th floor, which is then served to the world via Caddy on a scaleway in France. The lag time between the two machines is 250ms. but......

technologistguild.com

Did you notice any lag?

[olafmol]

Vamp-Router is still useful for simple/basic setups, but it's superseded by Vamp Gateway Agent (VGA) https://github.com/magneticio/vamp-gateway-agent. VGA is designed from scratch to run as a lightweight resilient distributed agent in High-Available setups, something that Vamp-Router isn't designed for. So both are useful, but in our humble opinion when you need to run in production, a SPOF is simply not acceptable. This is why we designed VGA. You can still manage VGA through the Vamp (core) REST API, which we believe is the right seperation-of-concerns.