4 ms·

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

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.

sandGorgon 12y ago
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.
- monatron 12y ago
  Fig functionality was not merged into Docker's 1.3 release. Ansible/Chef orchestration IMHO solves a very different problem than container orchestration.
  - sandGorgon 12y ago
    You're right - I was referencing this bug here (https://github.com/docker/docker/issues/8637 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)
pnathan 12y ago
> 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.

sandGorgon 12y ago

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.

monatron 12y ago
Fig functionality was not merged into Docker's 1.3 release. Ansible/Chef orchestration IMHO solves a very different problem than container orchestration.
- sandGorgon 12y ago
  You're right - I was referencing this bug here (https://github.com/docker/docker/issues/8637 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)

pnathan 12y ago

> 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.