[thaJeztah]

> confused over how many components and services you have to contend with now

You don't have to. It really depends on what you're trying to do. Using Docker alone, you'll be able to build and run containers, link them together to build a "stack" etc.

If you want to make building a stack (a group of containers that together form your application) easier, you can use an orchestration tool to automate this, for example, Fig, Crane, or now Compose. Or, create a bash script to do this; it's up to you.

If you want to build a cluster (run your containers distributed over several servers), you can do that with docker alone, but it will get hard to manage. You can build a tool for that (making use of the Docker API), or use an existing tool, like Flocker, Shipyard or now Swarm.

So if all you need is running a few containers on a single host, Docker alone may be enough for you, in that case you can safely ignore the other stuff for now.

[gtaylor]

> So if all you need is running a few containers on a single host, Docker alone may be enough for you, in that case you can safely ignore the other stuff for now.

I should have clarified on that earlier, but I'm interested in Docker for the more clustered approach. I don't really want to re-invent any wheels if I can't help it, so I'd be using existing tech.

Just in your reply, you mentioned:

* Fig * Crane * Compose * Flocker * Shipyard * Swarm

Whew. That's kind of what I'm chaffing on. I could learn all of this, but it's a lot harder to casually understand how it all would potentially fit together.

[IanCal]

> Whew. That's kind of what I'm chaffing on. I could learn all of this, but it's a lot harder to casually understand how it all would potentially fit together.

This is part of what the things mentioned in the announcement should help with. There's a clear need for clustering and linking, and so lots of people have built different tools to solve it. That's grand, but it's incredibly confusing coming into it. Particularly since tools vary from production ready to beta to "not actually implemented yet".

The aim here is to still allow people to come up with all kinds of different approaches but to have a set of components that work and are supported by docker. So that you can just get it and it works, and then start swapping bits in and out for the new hotness or some ultra-performant component/etc.

[gtaylor]

To clarify, I'm not asking for a monolithic stack. I like the modularity. It's just getting confusing to those that don't look at this stuff every day. It's more of an ergonomic issue than an approach issue.

There could be some simple solutions to this, mostly centering around education and the promotion of the most popular components. I don't have answers, here, but figured I'd share that it's getting a little confusing in case someone had ideas.

[IanCal]

I think what I said came across wrong, sorry.

I fully agree, I find the whole ecosystem really confusing. Every time I look at it there's some new combination of things, but then one turns out to be alpha/beta ...

What I hope is that the production of these new docker 'blessed' tools will allow me to go to their homepage and see a series of "getting started" tutorials and easily installable tools so I can at least get going.