Docker 1.5: IPv6 support, read-only containers, stats, and more

In this particular comment I could only spot one specific criticism: the lack of built-in user segmentation, so I will talk about that. I agree that this would be a nice feature. But we decided to not rush it, and instead tell operators to rely on the underlying system features for authentication, segmentation etc. In practice that means:

* If you have an https auth infrastructure in production, drop the appropriate middleware in front of your docker daemon, and rely on that.

* If you rely on ssh keys and unix access control in production, keep the default configuration of listening on a unix socket, and use regular unix users to decide who gets to talk to the socket.

* If you run trusted payloads, or if you run untrusted payloads with acceptable mitigation in place (no root inside the container, apparmor/selinux, inter-container networking disabled etc.), then go ahead and pool all your machines into a single swarm.

* If you run untrusted payloads, then map each trust domain to an isolated group of underlying machines. This is what Amazon, Google and others do when running customer payloads on Docker for example.

It would be a nice feature to segment Docker API endpoints by user, so that different users have different views (and different levels of access) of the same underlying daemon. But that requires implementing an authentication and authorization layer, and it requires changing some aspects of the Docker API which imply privileged access to the system. For example, the 'docker run -v /foo:/bar'. This represents serious engineering work, and as much as I would like to make you happy tomorrow, I don't think you will be any happier if we ship an unfinished feature.

Give up any idea that you have control over this. You don't.

As a user, I don't want you to have control over this, because it is directly contrary to my interests to not be able to redirect requests for "docker pull ubuntu" as per your example, to go somewhere I have full control over, so that I can choose to get exactly the image I expect matches the "ubuntu" image name rather than whatever the index will currently return for that name, and do so without having to change every reference to that name to something relative to my own registry.

You can make this hard, and have it continue to annoy users, or you can fix this, but this is a the biggest usability problem with Docker to me the way it stands now.

I find it hard to take you seriously when you claim usability first, and then claim that there is predictable meaning of image names: That is only true if you by "predictable meaning of image names" means "I don't really know what I'll get". This is especially true because of the lax use of tags all over the place.

The irony is that your "key technical requirement" for "flexibility over time, step 2" is far more important with the current situation than in actually would have been if we had the flexibility you describe for that step:

If Docker provided that flexibility today, then I could have easy complete control over exactly which images gets accessed if I wanted to. Instead I need to resort to firewall rules and/or DNS hacks or changing the source if I want to prevent accidentally pulling in images different than what I expect.

Containerization on Linux is really poised to be the "next big thing", enabling all sort of new workflows, deployments, etc. In order for it to really take off, people need a universal standard image format which is portable to other implementations. There must be multiple competing implementations. It must avoid vendor "lock-in".

Back when virtualization was getting off the ground, there was no standardized format. Every vendor had their own format, and all were completely incompatible with one another. This made migrations incredibly painful, sometimes impossible.

It created a "vendor lock-in" even when it came to the open source hypervisors -- ie. once you decided on a product, you were stuck.

The OVF (Open Virtualization Format) came along after years of this... not without it's imperfections -- but it was a real life saver in a great many ways. Vendors and open-source projects alike started to support the format, allowing users to export their VM's and import them into a different hypervisor with relative ease -- no weird hacky work-arounds, no re-imaging your vm, no nonsense.

~~~~

For this kind of industry-changing technology, it's more important to have an open standard than an open implementation.

Alternate implementations of docker run (e.g. Garden), although a daemonless mode for Docker may satisfy most of these cases.

Alternatives to docker build (plenty of room for innovation here IMO).

Alternative registries.