Hacker News Reader

Comment by 23david | Hacker News Reader

This is great news, particularly for Enterprise customers adopting containers. IMO, Docker's 'new' direction completely ignored the tremendous amount of support they had from the sysadmin and devops communities.

But crucially, they also crossed the business models of many startups (including CoreOS, Weave, Flocker, etc.) that rely on Docker maintaining an Open Platform. So this is an entirely logical response.

I'll be surprised if now Docker in response doesn't unveil an 'enterprise' Docker version that basically just strips away the unnecessary features and has more security by default. The enterprise market is just too valuable to let it just slip away like this. Your move...

View on HN

What is Docker's 'new' direction? I don't see any related announcements on their blog besides adding support on new platforms.

I attended Docker Global Hack Day #2 on Oct 30 from Austin. A talk was given on an active Docker project for host clustering and container management, which was non-pluggable, and made no reference to and used none of the code from CoreOS's etcd/fleet/flannel projects.

This was where I first started worrying about CoreOS and Docker divergence.

But since the hack day there has been a pretty reasonable (IMO) GitHub discussion about the tradeoffs between out-of-box ease of use and customizability.

https://github.com/docker/docker/pull/8859

I saw that same presentation at the same event, but came away with a very different impression: the container management they showed was implemented completely outside of docker itself, with no patches to the docker codebase needed. Also, IIRC it actually did use significant code from etcd for coordination.

Are we talking about the same thing?: https://github.com/docker/docker/pull/8859 ???

It had no etcd in it and the POC was implemented as part of the Docker API/CLI, as best I recall. There were significant questions in the discussion about etcd not being there.

Docker's 'new' direction is to direct its attention towards solving the orchestration and management problems involved in actually running infrastructure on Docker.

A number of third parties had begun work on various (sometimes proprietary) orchestration and management systems for creating a reliable/scalable/easily manageable cluster with Docker as a building block. CoreOS is one. But Docker is pushing towards an official, open-source orchestration/management system that threatens to make all of those companies irrelevant.

I think it is a great stand for Docker. Very recently (IMHO in 1.3), it merged the functionality of Fig into Docker.

I think Docker orchestration and coreos can coexist - if I had to use COREOS to use the goodness of Docker, then systemd-nspawn would come and eat Docker's lunch.

I wish that Docker bless one of Ansible/Chef as the official orchestration base and take it forward. I really don't want to earn something Docker specific.

Fig functionality was not merged into Docker's 1.3 release.

Ansible/Chef orchestration IMHO solves a very different problem than container orchestration.

You're right - I was referencing this bug here (https://github.com/docker/docker/issues/8637), but seems it was not merged into mainline.

I agree that Chef and Ansible are different than container orchestration today - especially, when you look at low level stuff like networking, mounts, etc... But I guess what I was saying is that it is not hard to add these features to them.

They already have a specification format that works well and check for idempotency at its core. Unless you mean something like etcd is fundamental to container orchestration, which I don't believe it is (we run a couple of containers in production using Fig)

> Docker's 'new' direction is to direct its attention towards solving the orchestration and management problems involved in actually running infrastructure on Docker.

IME examining Docker, this is actually the hard problem.

Reply on news.ycombinator.com