Rancher is an orchestrator built on Docker. It handles scheduling of containers and certain auxilary objects (load balancers, for example) within that universe. Rancher builds on the Docker Engine and can integrate with things like Mesos and Kubernetes, but doesn't require anything else to get up and running; it comes with its own container scheduler.
Deis is an entire PaaS, designed to handle end-to-end deployment and hosting of apps. It requires Kubernetes to run, which is notoriously complex (even on Google's Cloud) and probably not worth the effort if you have a small number (some people say >10) machines.
Thank you, you really clarified my view on these tools. I don't have experience with K8 and GCE, but when it comes to AWS, it doesn't seem so complex: http://kubernetes.io/docs/getting-started-guides/aws/ but I don't have production experience with this setup either, so who knows ;).
Kubernetes is complex — no matter where you run it. Docker itself is also complex; any orchestration/scheduling system layered on top of it will by definition add a dynamism that involves complicated things happening whenever something needs to be shuffled around.
Kubernetes makes some good design decisions. For example, you can kill the master and the cluster will continue to work just fine, except no scheduling will happen. You get some operational simplicity through how Kubernetes dedicates an IP to each container, too. Several other systems (including Rancher) make the mistake of relying on DNS to abstract the locations of services from clients, but Kubernetes dedicates a single, permanent IP to each service, which is then routed it at the network level. (In case you're curious, DNS is a huge mistake because it's almost never used correctly [1], and there are numerous Rancher issues filed that all stem from this design flaw.)
I wouldn't consider Kubernetes for simple setups, even on GCE, where it's "managed". (Scarequotes because GCE starts a master for you from a prebuilt VM image, but everything else is up to you; the only real UI is the standard one the master runs.) For smaller setups, you might want to consider a simpler solution such as Docker Compose, Docker Swarm or (once it's mature enough) Nomad.
Rancher is nice, but IMHO not ready for prdoctuon; it's much too unstable for an 1.0 release. I set it up to test recently, and within a few minutes I had encountered several serious bugs and several design flaws, including the fact that Rancher's load balancer (which is just HAProxy) loses traffic whenever it's reconfigured.
AWS has the EC2 Container Service (ECS), which is essentially a proprietary Docker scheduler that AWS preinstalls on your VMs. The consensus seems to be that it's one of Amazon's worst products, which my own brief attempt at playing with it confirmed.
Sorry about the long-winded reply, it got out of hand. :-)
In my anecdotal experience with 10 machines and 40 services, half of machines dedicated and half in amazon - i've tried:
k8s - great but for >>10 machines and you need a devops to watch and configure it + every configuration example on site is broken in one way or another. skydns is working for dns. has it's own overlay network.
nomad - great, but doesn't manage dns or network + i didn't get how to save it to file, only upload to nomad. What if it fails? Where cluster config is stored? May be it should be used with Terraform, but i did't like it. Thou for it's purposes it working good. Has concept of long running tasks and can run VM's
helios - i don't remember exactly why but i didn't like it. Something with configuration management. No network or dns.
maestro-ng - this is as raw as it gets. Basically docker compose. I was using it for a while, but it hit it's limits pretty fast. No network or dns.
rancher - after seeing it in action i fell in love. Beautiful UI (you can even view logs and start shell from web ui, and it works great!). Has DNS, manages your overlay network. Store configuration in mysql (i use amazon's rds with MZ). It has it's own perfectly capable scheduler - Cattle. And it can run k8s and mesos if you want it to. I highly recommend OpenVPN package that will connect you to internal overlay network and you will be able to work with services walled from outside world.
Another thing on the k8s configuration guides is that few (none?) of them include SSL authentication. All the ones I tried were entirely insecure, allowing anyone to point the command line client at the cluster and do whatever they pleased. There was also no documentation for fixing this or any warning that the example configurations were entirely lacking in security.
If you want to use k8s, I strongly suggest that you entirely ignore their own documentation and instead use the excellent documentation from CoreOS.
Helios is probably closer to Docker Swarm more than any of the other tools mentioned. It starts containers and isn't very sophisticated beyond that.
We evaluated it for a while, but discarded for various reasons, particularly the fact that it doesn't support private container registries [1].
I'd say Helios suffers from being an internal Spotify project. They're not under pressure to support any use cases except their own. For example, Helios is tightly coupled with Zookeeper, and they have rejected the possibility of supporting anything else (e.g., etcd). Their prerogative, of course.
I found the same. It is an all-in-ram distribution, so every docker layer is fully loaded into ram (I think there are 3). The core images must be built on something like Ubuntu. Maybe they have trimmed it down more recently. With something like an Alpine base you could probably get to a few hundred MB ram footprint without any loss in functionality. It would be great to see the bare minimum -- something like busybox+runit/dumb-init. Something with < 100MB footprint would be great for those cheap 512MB vps systems.
RancherOS is separate entity from Rancher. It's their attempt at smallest possible OS for running docker. You may use rancher and never use rancher os.
Said that i personally use RancherOS on t2.micro instances without any problems.