Is Rancher right for my multi-DC use case?

Archive Rancher 1.x
1

Hi, potential new user here, sorry for what are probably very basic questions. Any guidance will be very much appreciated.

My scenario is that I run instances of my web-services in every public Azure DC. I have been running on Azure Web Apps, but that’s very expensive per-instance compared to Linux VMs, so I’ve Dockerised all my code and now I’m looking for something to manage my production environment. Most of the projects I’ve looked at, like Deis, Flynn, Shipyard, etc, seem to focus on managing clusters in a single DC, but the Rancher site and documentation seems to suggest it works in a multi-DC way, as well as ticking all my other boxes and just sounding generally awesome.

So my basic question is: can I run a single Rancher Server in a single Azure DC (probably East US) and then connect up Rancher hosts in other DCs, across US, EU, Asia and Australia?

If I can do that, then a couple more questions:

  • Would it work with just a single Host VM in each data-center? (The system can tolerate a DC being unavailable for a while).
  • Can a container upgrade be synchronized across the entire multi-DC network, so a new version of a particular web service only becomes available when it’s ready everywhere?

Really hoping the answer to all those questions is yes…

2

Networking: yes; we basically don’t care where the hosts are as long as they have public IPs and can talk to each other on the IPSec ports to create the overlay network (UDP 500 and 4500). There is no layer-2 adjacency requirement. So you would just deploy a single rancher/server (or multi-node for redundancy, but somewhat more complicated) and then add hosts from different providers and/or regions.

Upgrade: The “in-place upgrade” in the UI will do a rolling upgrade of $batch containers at a time, so a service will be in a mixed state while that’s happening. In rancher-compose there is another kind of upgrade where you create a new service and scale the new one up while the old one is scaling down, which can avoid having mixed live containers. Or you can do similar by pointing everything at an ‘alias’ service and then only change where the alias points once you’re happy with the new service.

3

Thanks Vincent! You’ve made my day.