

Deis 0.9.0 – Dockerfiles, Domains, and HA Routing - rgarcia
http://deis.io/deis-0-9-0-dockerfiles-domains-and-ha-routing/

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

[https://twitter.com/bacongobbler](https://twitter.com/bacongobbler)

~~~
cbsmith
So, looking at the architecture, it seems like you have some design components
that overlap with pieces design components in CoreOS. I'm not clear as to what
components are really application components vs. platform operations
components, so maybe that's it. But the use of rsyslog in lieu of systemd
seems like really going against the CoreOS grain. Is this really a function of
trying to mirror Heroku as closely as possible?

~~~
shykes
My understanding of Deis's design goals is that they will pick and choose
their favorite components from any number of sources (including but not
limited to CoreOS), but don't plan on locking themselves into any particular
distro. Instead they are relying on Docker itself as the point of
interoperability.

As a maintainer of Docker I think it's a good thing that you preserve the
freedom to run your platform on any number of distros, and are not stuck, for
example with having to install systemd everywhere.

~~~
cbsmith
I grok the container win (been using containers on non-Linux platforms and
OpenVZ on Linux platforms for ages).

I agree a nice aspect of using Docker is that you have the flexibility of
using whatever distro you want for each application component... however a
heterogeneous container platform doesn't really provide much of a win, and to
make that work you just end up implementing your own solution for each of the
components that abstract you from the platform.

~~~
shykes
That's assuming Docker doesn't expand its interface to allow for more parts of
the platform to be interoperable :)

The whole point of Docker is to introduce simple interfaces to important
components of distributed systems, and get a critical mass of people to agree
on it, producing interoperability. So far we did this for packaging and
sandboxed execution of individual components, with some success. We plan on
doing this for other areas in the future, including clustering, stack
composition, application networking, service discovery, authentication and
access control, etc. This will allow rival implementations to compete in each
of these areas, without creating fragmentation. I don't want a World where
"CoreOS containers" can't talk to "Atomic containers" or "Mesos containers"
because we couldn't agree on a common interface - we can do better than that.

We are pretty open about that plan. The Deis guys know this and are making the
bet that embracing "Docker-native" interoperability is good for them.

~~~
cbsmith
I think I didn't present what I was saying clearly.

I think you definitely want to be very open about what the inside of the
container looks like and even what the interface is between the containers and
the rest of the world.

I was thinking about the platform that the containers run on top of. You don't
gain anything by using a given host platform, but building alternate
components that handle deploying and wiring up those containers. You're better
off either using the existing platform's components or contributing patches to
it, and the latter really only makes sense if you're adding something
distinctive.

~~~
shykes
I understand. But from the point of view of Deis, CoreOS is not a platform. It
is a Linux distro with a loose collection of tools pre-installed, some of
which Deis happens to use. One such tool is Fleet. Another is the systemd log
journal. Each of those tools has dozens of competitors. Deis reserves the
right to pick and choose from those competitors without locking themselves in.
It also reserves the right to use some pieces of CoreOS without using the
other. If you think of CoreOS as an end-to-end monolithic platform, this may
seem strange. But it is perfectly aligned with the Docker philosophy, which is
that big monolithic platforms are not a good thing. What you want is a vast
ecosystem of small composable lego bricks.

~~~
cbsmith
> Deis reserves the right to pick and choose from those competitors without
> locking themselves in.

Well of course! It is your own project.

> If you think of CoreOS as an end-to-end monolithic platform, this may seem
> strange.

Yeah, but I'm not looking at CoreOS as an end-to-end monolithic platform. I'm
looking at it as a bunch of components that happen to be bundled together,
each of which is pretty nice all by itself. It doesn't mean you have to use
them all, but on the other hand, you would hope that if you were going to
replace one of them entirely you'd go with something with a significant
advantage (and I'd argue in some cases it has gone the opposite way).

> What you want is a vast ecosystem of small composable lego bricks.

Understood. I just don't think you help yourself much if you take out one
brick and replace it with one of your own, particularly if the new brick isn't
any better than the old one (and might be worse).

~~~
shykes
I should clarify that I am not part of the Deis project, although I know
Gabriel and follow their roadmap closely.. Sorry if I wasn't clear.

------
cardmagic
I just interviewed Deis CTO Gabriel Monroy about Deis and how it works with
CoreOS and how it differs from Flynn and Dokku. Great guy, great team, and
awesome project.

[https://www.youtube.com/watch?v=j5EI16DG1sg](https://www.youtube.com/watch?v=j5EI16DG1sg)

------
tristanz
Is there any story for persistent data / running database services?

~~~
bacongobbler
Indeed we do. Feel free to contribute to the conversation here:
[https://github.com/deis/deis/issues/231](https://github.com/deis/deis/issues/231)

------
benmccann
What is Deis using for this new HA routing? HAProxy, ELB, homegrown?

~~~
andyshinn
It is their own nginx HTTP / TCP router, which is backed by etcd and confd.
You can check it out at
[https://github.com/deis/deis/tree/master/router](https://github.com/deis/deis/tree/master/router).
Essentially, you can fire up multiple of these instances, and Deis uses them
to route application, controller, and git traffic to the proper container.

