
Moby: An open-source project to advance containerization - craneca0
https://blog.docker.com/2017/04/introducing-the-moby-project/
======
mdekkers
I have a real issue with Docker Marketing Speak bullshit. "Democratizing
containers"? When were they not democratic? What were they before? Tyrannical?
or - _gasp_ \- communist? And now they are going to _ADVANCE THE SOFTWARE
CONTAINERIZATION MOVEMENT_ what does that even mean. Hacker News commenters
tend to be pretty smart, and at the time I am posting this, most comments are
along the lines of "eh? say what now?" When their core consumers don't
understand the message, you can bet your hat that they are not the real target
of the message. Or the people at Docker are not good at marketing, which I
find harder to believe.

~~~
jingler
You're right: as an individual user of Docker, you're not the customer. You're
the product being sold to the customer, which is enterprises that see adoption
by users as a proof point Docker (the company) boasts about.

~~~
jacques_chester
Red Hat, Google, Amazon and Microsoft will probably make more money from
Docker than Docker.

Disclosure: I work on Cloud Foundry on behalf of Pivotal.

------
shrikrishna
A marketing-speak filtered out version of this announcement: You will be able
to assemble your own docker engine by stripping out components you don't need
(that have until now been shipped in a single docker binary) and keeping the
ones you do. This is like assembling PCs, for docker.

I think this was mainly intended as an answer to the criticism docker has been
receiving (by kubernetes maintainers and others) ever since they decided to
ship swarm with docker. I think this move is great as it goes a step further
and allows you to swap out build systems, volume mgmnt too. Even though I did
not mind docker shipping with swarm, others in the community were, and this
shows docker listened, which is great.

EDIT: grammar fix

~~~
dkarapetyan
Aren't they doing it kinda backwards? Shouldn't you start with the pieces and
then let people assemble them how they want?

It's fine to offer off-the-shelf supported configurations but why start with
everything and the kitchen sink and then try to backtrack?

~~~
chatmasta
Because nobody would use docker if installing it required a custom complex
build process. This way docker can keep docker CE for its standard use case
but also satisfy power users with specific requirements by allowing
customization.

~~~
ReverseCold
I use docker because I can go from

"Hey cool project, I want to try it!"

To already setup in under a minute depending if I'm at home or not.

Also the VMs start really fast, so it's good for getting exotic compiler
toolchains on Windows running quickly. Everything has a dockerfile.

------
shykes
This is a transcript of a keynote I just gave at Dockercon. But the keynote
had in-depth demos and the blog post doesn't. It will make more sense with the
demos.

I will try to summarize: when we build Docker for Mac, Docker for Windows,
Docker for AWS etc, we assemble a lot of individual components into a complete
platform. Then we pack that platform into a bootable artifact for the target
environment. That's a lot of work, and it gets harder as the number of targets
multiply. We developed a framework to make this more efficient. That framework
has become the de-facto upstream of the Docker platform - it sits between the
individual upstream projects and the finished product. So we're open-sourcing
it as Moby, moving all of our open-source process under it, and inviting the
community to come play. Think of it as the "Fedora of Docker".

Here's more technical details from the readme:
[https://github.com/moby/moby/blob/moby/README.md](https://github.com/moby/moby/blob/moby/README.md)

TLDR: \- If you're a Docker user, nothing changes: Docker remains the same \-
If you're a Docker open-source contributor, you're now a Moby contributor.
Everything is basically the same, except more modular and more open, and you
are less tied to Docker. \- If you're building non-Docker container platforms,
it's easier to share components and ideas with the Docker community, without
being forced into anything you don't like.

The Moby tooling itself is pretty neat: you define all the components in your
system (including the OS and hypervisor, if required), then pack them into the
artifact of your choice. For example you can assemble
LinuxKit+ContainerD+Redis into a tiny "RedisOS", and then boot it straight
from bare metal; or virtualize it with HyperKit and run it on a Mac; or
virtualize it with HyperV and run it on Windows. Moby does all of this for you
automatically (this is one of the keynote demos).

We also showed a "Kubernetes in a box" assembly, to show that you don't have
to stick to Docker-built components.

~~~
tjfontaine
Here's a different reason (jbergstroem also alludes to [1]) why Docker (the
company) would rename Docker (the open source project) to a name that cannot
be confused with Docker (the product): Trademark (Enforcement).

How do you (a for profit company built on open source) enable your community,
to build and sell (their own) products, as well as enforce your trademark? If
anyone (everyone?) can build and distribute and call their build `docker`, it
becomes really hard to protect your investment (as a company and their
fiduciary responsibility to their stock holders) from dilution of
TheBrand(tm).

This is not cynicism and I don't fault Docker (the company) at all, it's just
the reality of doing business. It's why Canonical requires a contractual
relationship for infrastructure clouds to distribute Ubuntu images, it's why
you have things like Firefox and IceWeasel, so on and so forth.

[https://news.ycombinator.com/item?id=14140543](https://news.ycombinator.com/item?id=14140543)

~~~
dandandan
It's also an easy way to acquire more paying users. "Docker" has the name
recognition now, if someone wants to adopt it after hearing about it they're
likely to choose the paid product.

------
djsumdog
I too am confuzzled by this. I'm at a Docker shop where we currently run on
DC/OS and Marathon. I think the most confusing thing about Docker right now
are all the different scheduling and networking frameworks (DC/OS which adds a
web ui to mesos and marathon, Kubernetes, Nomad, CoreOS/Fleet, etc).

None of these systems scale up from a single 1 node system to a full
distributed cluster. Here was my attempt of trying to get DC/OS to run in a
minimal cluster on Digital Ocean:

[http://penguindreams.org/blog/installing-mesosphere-dcos-
on-...](http://penguindreams.org/blog/installing-mesosphere-dcos-on-small-
digital-ocean-droplets/)

We use DC/OS at work and the web UI frequently transfers over 1MB of json a
second and the failed containers tab can max out CPU at 100% O_o

Marathon, Kubernetes, Nomad and Swarm all have their own orchestration json
files in totally different formats. It gets more confusing with you take about
pluggable network layers (WeaveNet, Flannel).

I'd _like_ to think Docker is trying to bring some standardisation to
clusters, networking and scheduling ... but I'm not sure if that's the case.

~~~
drdaeman
Took me some time to figure it out, but Kubernetes actually does, with
kubeadm.

If you're on a Debian/Ubuntu-based OS, you basically `apt-get install kubeadm
kubelet kubectl`, then `kubeadm init` (and you have 1-node cluster)

Then you `kubeadm join --token $token $master_node_ip` and you have the second
node. Repeat as necessary, throw in some proper automation when you have
enough (3+) nodes.

There is a disclaimer that it's beta, though.

Still, Docker feels much simpler, and I really believe "simpler" means
"better". Maybe that's just my prejudice, but Kubernetes has awfully
enterprisey aftertaste and feels to be full of magic. If Docker or Swarm goes
haywire - and every software has bugs - I can check almost every component,
piece by piece, down to what kernel is told to do - thankfully, they're still
not too far from the actual OS primitives. If affected node number is
tolerably small, I can even "downgrade" to Compose and manual scheduling and
networking kludges, with relative ease. I'm unsure what I would do if some day
Kubernetes would insists on malfunctioning.

~~~
djsumdog
I've played with Kubernetes and I wish I had finished my post on it. I got
frustrated when looking at logs from a node wasn't supported by nodes joined
with kubeadm (that was a few months back .. I really hope they fixed that by
now).

I agree with you, Kubernetes seems insanely complicated. I haven't used it in
production though. I'm in a Marathon shop, and it is really slick once you
have a working DC/OS cluster .. but setting up that cluster requires a full
time team. It's not trivial and far from simple.

------
rubiquity
If I understand this right it sounds like Moby will be a grab bag of
components you can use to create your own container platform. This means the
Docker that we know of before today is an implementation of Moby plus some
other things (GUIs, SDKs, etc) that they hope to strip out.

Like others, I found the press release incomprehensible so the pull request
linked to in the docker/docker README is where I'm drawing this understanding
from:
[https://github.com/moby/moby/pull/32691](https://github.com/moby/moby/pull/32691)

As far as why I think Docker might be doing this:

It seems like a continuation of a similar strategy that they did with
containers in the first place back when they were known as dotCloud. Rather
than continue to compete with Heroku as a PaaS they found it better to open
source their container technology and start a container movement (for lack of
a better word).

Now that the container movement has happened there are a lot of competing
tools at the container runtime (Docker, rkt, systemd-nspawn, lxc, etc.) and
management (Swarm, Kubernetes, Mesos, Nomad, various ones that delegate to AWS
ECS, etc.) levels. Rather than compete with all of those they are pushing
themselves up a layer of abstraction to make it easy for companies to create
their own container management tools specific to their needs.

------
deizel
As I understand it (though I could be wrong) - this repository (in relation to
the old one) is intended to be a parent.

Rather than having just the Docker engine, it will coordinate docker,
swarmkit, infrakit, linuxkit in a single project.

These will be swappable, so for example you could a) swap swarmkit for
Kubernetes, b) swap linuxkit for Debian, c) swap infrakit with Terraform.

Like "Docker for Mac/Windows/AWS/Azure/GCE", etc. already exist - Moby will
likely house all these variations and allow the creation of custom
"Docker/Other for X/Y/Z".

------
chatmasta
wtf? So the docker project is now "moby"? And I have no idea what the major
changes are? How is this going to affect my usage of docker? The readme is
incredibly confusing and lists no concrete features, especially none that
justify reorganizing the entire docker project so drastically. It took me 5
minutes just to realize that github.com/docker/docker now redirects to
github.com/moby/moby.

Is this really necessary? Seems like it's just going to create tons of
confusion.

~~~
dullgiulio
It might be temporary as they split the UI (the cli tool docker) and the new
moby library.

Seems like a move made in a rush. It would have been better to spin out the
dependencies of docker into moby instead of moving the project back and forth.

Agreed that it is very confusing at this stage.

~~~
kasabali
> Seems like a move made in a rush.

You've just summarized everything Docker Inc. does.

------
jbergstroem
Thinking marketing split? Docker is the product you pay for and Moby is "may
break, use at own risk".

~~~
manbeard
Except for this blurb from Audience section on the Moby Project site:

    
    
      Moby is NOT recommended for:
    
      Application developers looking for an easy way to run their applications in containers. We recommend Docker CE instead.
    
      Enterprise IT and development teams looking for a ready-to-use, commercially supported container platform. We recommend Docker EE instead.
    
      Anyone curious about containers and looking for an easy way to learn. We recommend the docker.com website instead.

------
educar
Can someone do a eli5 ? I don't understand what the product is.

~~~
4c2383f5c88e911
This is github.com/docker/docker with a note added on top of the README.

For now you have to watch the DockerCon keynote to understand; it's intended
as a "common assembly line for container systems".

~~~
deizel
The new README[0] is in a pull request[1].

[0]:
[https://github.com/moby/moby/blob/moby/README.md](https://github.com/moby/moby/blob/moby/README.md)

[1]:
[https://github.com/moby/moby/pull/32691](https://github.com/moby/moby/pull/32691)

------
newsat13
I cannot help but think that Docker the company is in deep trouble reading
such product announcements. It's incomprehensible.

That said, what do I know. The folks at docker are brilliant marketers (with a
great product). The marketing is the main reason docker is so wildly popular.

------
willejs
So, their breaking up the monolith? Hold on to your hat!

------
pzduniak
I was pretty sure something was broken when I was browsing Docker docs and
suddenly I ended up in a moby/moby repo.

------
asimpletune
I don't really understand this, but I think the special feature from Dockercon
will help explain.

------
kentt
Didn't Docker already have a project called Moby? Is this the same thing?

~~~
deizel
It seems so - the `docker/moby` repository[0] now redirects to
`linuxkit/linuxkit`, but the `moby` cli from `linuxkit/linuxkit`[1] is being
moved to the `moby/moby` repository[2].

[0]: [https://github.com/docker/moby](https://github.com/docker/moby)

[1]:
[https://github.com/linuxkit/linuxkit/tree/master/src/cmd/mob...](https://github.com/linuxkit/linuxkit/tree/master/src/cmd/moby)

[2]:
[https://github.com/moby/moby/pull/32693](https://github.com/moby/moby/pull/32693)

------
tjfontaine
I can't stop reading this as Mooby -- the golden calf. [http://kevin-
smith.wikia.com/wiki/Mooby_the_Golden_Calf](http://kevin-
smith.wikia.com/wiki/Mooby_the_Golden_Calf)

