Deis is for orchestration. He's the conductor of the orchestra. It's the next level up, for managing how multiple containers get set up and talk to one another.
Once Deis is up and running, developers deploy with `git push deis master` and they automatically get a configurable number of Docker "runtime" containers spread across multiple VM hosts, a set of Nginx proxies that route traffic to the Docker containers, resulting in a fully functional distributed application.
How does this work? With Deis the ops folks initialize a "formation" that includes multiple VMs/instances for a) hosting Docker containers and b) proxying traffic into those containers. When a developer creates a new application, pushes a new build, sets an environment variable, etc.. Deis automatically builds the Docker image, distributes it, executes it and reconfigures Nginx proxies to route traffic to it. Chef is used to store platform state and orchestrate changes across the formation.
So let's pick a project to be "the Rails of PaaSes" soon, okay? I neeeed one. :)
Not bashing it or anything I'm just interested in its progress but can't find anything!
Also, the required glue is a bit more complicated than you think, especially when you want to be able to scale and/or deploy on multiple servers. You need to store some extra info somewhere (at least in a database, at best in a distributed one like zookeeper, doozer, or etcd). Then things get exciting :-)
> I do wish more people would throw in with the Docker-based PaaSes that already have some momentum (Dokku, Flynn, etc.), rather than making their own.
We at OpDemand have been working on Deis (and its proprietary predecessor) long before Dokku, Flynn or even Docker existed. Also as jpetazzo mentioned, Dokku is not really a PaaS but rather a single server Heroku-style deployment system. Flynn is still in planning stages AFAIK.
> I guess the required glue left over is about on the level of a static site generator, which explains why everyone thinks doing one as a weekend project will be great fun
Are you equating Deis/Flynn with a static site generator? If so, you're dramatically underestimating the amount of work required to build a distributed PaaS that can support production applications. The difference in LOE between Dokku and Deis/Flynn is exponential.
I'm going to double down on 12 factor. The kind of encapsulation involved, storing the app in code, config in the environment, data in persisted resources, is ten times better than virtualization.
Dokku is a demonstration of what you can achieve with Docker + a very little shell script. In my humble opinion, it's very promising that you can achieve so much (something that lets you deploy applications in a Heroku-compatible way) with so little.
Also, 12-factor is totally orthogonal: you (not you specifically, but the general developer) should use 12-factor as much as possible (because most of it can be considered as "best practice", I think), then you can deploy on IAAS, PAAS, your own machines, etc.; and using 12-factor just makes the whole process easier.
12 factor is not a requirement for Docker. You're perfectly free to violate 12 factor by storing state in the file system, config in your code. Heroku makes you implement quite a bit of 12 factor through their ephemeral filesystem, but it cannot enforce following of the entire spec.
Virtualization, in my opinion, has become a crutch we lean on to avoid having to restructure apps. If you need, say, a cron job, instead of doing it the 12 factor way and using beanstalkd, you'll just run cron on your container. (not sure if that's possible but you get the idea)
Virtualization and 12 factor aren't quite orthogonal, they do overlap a bit. The former is an 'easy' solution, you just build your app however you like and as long as it will run in a container, you're fine. The latter is much harder, you have to make your app totally stateless.
I know one is using chef and the other is using saltstack, but i'm talking configuration, ease of deployment and reliability.
Any idea when out of the box Azure support is coming?
1. implemented in Go vs. Python+Ruby which means no dependencies, easier install, etc.
2. Modular architecture: in addition to Docker will also use CoreOS and etcd.
1. Built using DevOps tools widely in use (i.e. Chef) so it integrates easily into most environments and is an easier sell to conservative Ops teams
2. Implemented with Django, Celery and other components that may not be as sexy as writing from scratch in Go, but are battle tested -- which is a big plus for application platforms.
In my opinion, there's room for both approaches in the Docker PaaS world.