bacongobbler

this is more of a Docker than a Deis question, but a Docker image is composed of layers. Each tagged image keeps an ancestry list of all of the layers it requires. In your case, if you run 5 docker containers on the same host on top of ubuntu:14.04, it will initially pull the parent's layers (ubuntu:14.04), then it will pull its own layers. They all share the same layers, which is why it's so powerful. You get the exact same execution environment every time.

From the outside, not much. Both model the Heroku-style workflow with application deployment.

Asides from Deis being production-ready and tacking on a few extra features like `deis pull` and Dockerfile deployment workflows, we take a different approach to our components. We use the best-of-breed components from other OSS projects and focus entirely on the application deployment workflow. Flynn is focused on building the platform from the ground up. They provide the network equipment and messaging primitives (layer 0, as they call it) as well as the platform itself (layer 1) completely from scratch. Deis uses common OSS tools such as nginx and ceph to provide our layer 0 and part of our layer 1 for us and focus entirely on using those components to serve our needs.

We hear this conversation quite a bit. Kubernetes is not a competitor to Deis. Kubernetes is a container cluster manager; a scheduler, if you will. You give it a container and some desired state and it will schedule it out to a cluster of nodes. Deis utilizes schedulers to deploy apps. We currently support Fleet at the moment but we have attended a few mesos hackathons to get a PoC working with Deis as well as kubernetes. If you have a use case, we'd be happy to hear it in the mailing list or in a github issue as a proposal :)

That's ancient documentation -- v0.3.0!

That being said, we support any provider which runs CoreOS. Deis is just an platform which utilizes Fleet, Etcd and Docker. The best place to start would be to take a look at the Quick Start documentation: http://docs.deis.io/en/latest/installing_deis/quick-start/

Hi, I'm also a maintainer :) to answer your questions:

1) we expose ceph in the router, so your apps could use it. This will have to be managed by you however as we don't have a user story for plugging apps into backing services asides from `deis config:set`[1]... Yet.

2) Performance is still something we're working on. When you deploy an application using a Heroku buildpack[2], your app is compiled into a container which sits on top of Heroku's cedar stack, which is around 800MB[3]. It's a beefy stack so fleet will take some time deploying that image. This should only occur the first time it's scheduled onto a new host as future images will just use the cache for that image, significantly speeding up deployment times. If you deploy an app using a Dockerfile and it's been optimized correctly (we have an app sitting under 5MB for test purposes)[4], deployment times should be very speedy.

Hope that answers your question!

[1]: https://github.com/deis/deis/issues/231

[2]: http://docs.deis.io/en/latest/using_deis/using-buildpacks/

[3]: https://github.com/progrium/cedarish

[4]: https://registry.hub.docker.com/u/deis/example-go/

rancher is a bit different. It's based on lower-level APIs which allow your containers to hook into a certain cloud-provider features like Amazon's EBS, ELBs and VPCs. Deis uses the docker engine to ship and run applications, providing an easy developer workflow. We're similar to other PaaS solutions like Dokku[1], Flynn[2], and Cloud Foundry[3].

[1]: https://github.com/progrium/dokku

[2]: https://flynn.io/

[3]: http://cloudfoundry.org/

Just gonna leave this here... http://docs.deis.io/en/latest/using_deis/using-dockerfiles/

It's on the roadmap :)

Yep. It was because slugbuilder didn't lock buildpacks to a known working version when you ran a `docker build`. It always pulled master, which may or may not work. We fixed that up, and we're in sync with Heroku's buildpack version that's running in prod now: https://github.com/deis/slugbuilder/blob/deis/builder/instal...

What download issues do you speak of? They work great in Deis' test infrastructure: http://ci.deis.io/view/example-apps/job/test-integration-rub...

Well, "open source Heroku" implies that they're compatible with Heroku's API. That means application release management, runtime configuration (config:set), application collaboration via "sharing"... From what I see in https://github.com/flynn/flynn/tree/master/demo, half of the API isn't there yet. We'll see how it goes over the next few months.

FWIW, Deis really wants to help orchestrate multiple containers across nodes. There's talk about scheduling/pinning apps to certain nodes (such as if you really need your workers on a machine with more CPU), and currently we also support deploying from both Dockerfiles and pulling images bit-for-bit from an in-house registry or from DockerHub. We have documentation, but ASCIIcasts seem to show this workflow better. Check it out! http://deis.io/demo-deis-pull-in-action/

If you need any help getting set up, we're quite receptive to questions on #deis!

> I'm a huge fan of Dokku, and Deis seems to be a very similar project with the added bonus of handling scaling for you.

Deis is built to be a distributed system spanning an entire CoreOS cluster, so scaling occurs horizontally and is naturally fault-tolerant. We have fleet to thank for that :)

FYI there are some really cool ways that you can recycle and re-use dockerfiles with ONBUILD commands. We actually do that for some of our containers as well, such as when you have multiple python projects. https://github.com/deis/dockerfiles/blob/master/python-runti...

Just add "FROM deis/python-runtime" to the top of your project and declare a CMD or an ENTRYPOINT in your Dockerfile and suddenly you have a python project installed and ready to go.

Still a work in progress. See https://github.com/dotcloud/docker/issues/4023

Indeed we do. Feel free to contribute to the conversation here: https://github.com/deis/deis/issues/231

Deis maintainer here. I'll be happy to answer any questions you may have either here or on twitter :)

https://twitter.com/bacongobbler

You can handle database migrations the same way as you would on Heroku. Deploy the application, then do the migrations afterwards with `deis run`.

yes, it's still lxc-docker.

A small enhancement to your HOST_IP grepping, the host's public and private IP is available in /etc/environment. docker0 may or may not be present before a docker run as well due to socket activation, so your results may vary with a brand new CoreOS VM where docker has not started yet. For example, we are resolving this in Deis with https://github.com/deis/deis/pull/851

We'll be updating the website in preparation for our next release. Most users are still on v0.7.0 or earlier. Once it's been released then our website should reflect the changes in master.

Deis dev here. We've removed the Chef dependency as of v0.7.0 in favour of CoreOS and fleet for container/machine job scheduling. That ship set sail only recently in master. :)

Most people pass their code to a CI system after it's been pushed. Run your unit tests locally, push your code, run it through your CI system (integration and unit tests, anything else), then push goldbits to production.

Another tool that does just this would be Deis[1]. We specifically combine CoreOS (in heavy development[2]), Docker, Heroku Buildpacks, and also Dockerfile deployments[3], too!

[1]: http://deis.io/

[2]: https://github.com/opdemand/deis/issues/530

[3]: http://docs.deis.io/en/latest/developer/dockerfile/#deploy-u...

> When scaling web instances, does it provision a new machine per instance?

We host application instances in Docker containers, so each instance is essentially a container on a VM. We have a very basic scheduler implementation (read: round-robin) that deploys the containers evenly across nodes under the Runtime Layer[1]. As gabrtv mentions in another comment, we are looking to replace this scheduler with something more sophisticated like Apache Mesos[2].

As for creating backing services, we are looking to implement a service registry[3] where it would communicate with third-party services much like how Heroku Addons work. For the moment, most users set an environment variable for their application as per the docs: http://docs.deis.io/en/latest/developer/manage-application/#...

[1]: http://docs.deis.io/en/latest/components/layer/#runtime-laye...

[2]: http://mesos.apache.org/

[3]: https://github.com/opdemand/deis/issues/231

As noted in the release notes, I've recently transitioned from being a weekend contributor to a full time maintainer on Deis. It has been awesome working with Docker since v0.1.2 and with Deis since v0.1.0, and I am certainly looking forward to contributing more upstream improvements in the future.

Look out for more pull requests to the registry! :)

The only logo that looks pleasing to the eye is Mailman's.

I found this one a couple weeks ago! https://stackmachine.com/

I work at ActiveState on Stackato, which is a private Platform as a service. Similar to Heroku, only for private hosting (e.g. you host it on your own hardware or hypervisor). We use Docker as of our v3 beta release today (http://beta.stackato.com/). Our use of docker in 3.0+ means that we bring their tuned security along with us (they integrate with apparmor really well, in fact they require it to start up a container). Here's a really good overview of LXC (and docker) security in general: http://blog.docker.io/2013/08/containers-docker-how-secure-a...

Stackato is built for large enterprises who want the convenience of a public PaaS (like Heroku), but with the flexibility to run it in the datacenter of their choosing. With that, our pricing is built for large enterprise, which entails support calls, training sessions, webinars, bug reports, and all of the other good stuff that comes with enterprise support models. We really pamper you through the startup process to get you running on your feet. I understand though that our pricing is unreasonable for smaller businesses. We are however very open with our customers, and a lot of our existing customers really like that aspect. A great example of this would be the interview we did with Chris Turra at Mozilla on Wired: http://insights.wired.com/profiles/blogs/upholding-the-open-...