Can someone explain how this is different from Docker? As someone who hasn't used either, I'd really appreciate an explanation of the nuanced differences/how they relate.
docker is the brains, by talking to the operating system it makes easy to use OS containers (which are analogous to VMs but much cheaper since they are one process rather than a whole "machine").
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.
peterwaller got it right, but let me try and give a little more color. Deis is provides a private Heroku-like platform powered by Docker & Chef.
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.
This is an awesome example of the kinds of things Docker is making possible. It seems like these PaaS solutions are just sprouting up left and right now, and it's exciting! It wasn't so long ago that "deploying" meant dragging folders into an FTP window and hoping things worked just fine.
It surely is exciting, but 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. I mean, 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--but just like a static site generator, one weekend (or even one fulltime developer) isn't gonna make something I'm willing to build projects for clients on top of. Which is something I really, really want to do.
So let's pick a project to be "the Rails of PaaSes" soon, okay? I neeeed one. :)
Does Flynn actually have any momentum yet? From what I can see they reached their funding goal then dropped under the radar, I even popped by their IRC channel to see if anything was active there but found it to be partially infested with tumbleweeds.
Not bashing it or anything I'm just interested in its progress but can't find anything!
Others will correct me if I'm wrong, but Deis particularly makes sense, since Dokku has a more restricted scope, and Flynn isn't out yet.
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 :-)
Gabriel Monroy, creator of the Deis project here..
> 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 started to use Dokku, got it installed and my app deployed, then realized that it only supported one app. Such a strange design decision for a virtualization platform. It really drove home to me how unfinished these new PaaS solutions are. We're still another five years or so from "the Rails of PaaSes".
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.
Allow me to apologize if I sound blunt, but I think you missed the point of Dokku. It is a, what, 100 lines shell script? It supports a single app, but you can run it multiple times. The same way that Heroku supports a single app per git repository. It's a kind of design decision, and not a limitation per se.
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.
That's an odd statement. Isn't 12-factor a requirement for Docker apps? It's not like you're "stopping and forking containers" in production; that's just a convenience for development. The image you deploy to production is supposed to be a sealed "slug" with an ephemeral container on top, like on Heroku.
With a 12 factor app, you don't need virtualization. The entire app is stateless, all state is pushed off to various resources. All you have to do is pull the repo and run the service.
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've never seen Docker/LXC as a "virtualization" solution; it's an isolation tool, to firewall off exploited services from their siblings and hosts (which then allows things like PaaS multitenancy.) Used in that sense--where anything that breaks isolation (like host-mounted volumes) is disallowed--Docker does indeed require 12-factor-structured apps, to do anything of use.
We started the Azure integration and got hung up with their Python SDK. We're actively working with the Microsoft guys on it, but I wouldn't expect anything usable for a few months.
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.
