The architecture is not monolithic. I want to break down Docker into the most discrete and composable parts possible. But I want to do that without hurting the user experience. If you can point out a way to do that, I will implement it. And if you are available to help, it will happen faster.
> is there a way to easily find out containers' names and links, and exact forwarded ports, from the API without regexping `docker ps` output and "tcp/1234"-like strings that should be meant for human eyes only?
You are not expected to parse 'docker ps' output programatically. That is not and has never been the recommended way to interact with Docker programatically.
Yes, the current API expects clients to parse strings like tcp/1234. A string of the form [PROTO/]PORT seemed like a pretty reasonable thing to parse. But if you would prefer a json object like {"proto":"tcp", "port":1234}, I don't have a fundamental problem with that. Feel free to open a github issue to suggest it. In general we frown upon randomly breaking things but if it improves the situation for clients we will consider it. It could also make for a nice first patch if you're interested in that :)
> * Is it still Docker's official position that CLI is only official interface, and using HTTP API is frowned upon?*
That was never true. I'm not sure how you got that idea. The HTTP API has existed forever, the official client uses it for 100% of its functionality, and I definitely recommend using that as the primary mode of interaction with Docker. I acknowledge that the API itself is not perfect, and will welcome any suggestions for improving it (we are discussing quite a few improvements already on #docker-dev).
> Since Docker and registry API is HTTP, why can't I use http auth (even implemented by an nignx proxy) instead of certs (which are fairly new) or centralized index for authentication?
You can use all these things with the registry API. The centralized index is completely optional for authentication.
I'm curious where you got all these incorrect notions? If you read it somewhere in the docs, then it's a documentation bug and I would appreciate it if you could point it out so we can fix it.
> It should be as simple as using `https://user:pass@IP/…` URLs, what's the problem with it?
I don't understand that part. I believe Docker registry auth today uses basic auth over TLS by default, which has security issues (ie storing your password in clear in your home directory). We are working to add a more secure token-based auth. But you should always be able to use basic auth if you prefer that.
> While we're at it, why on Earth is HTTP Docker endpoint specified as `tcp://IP:PORT` rather than `https://IP:PORT`, which would make it possible and easy to proxy, use http auth in an intuitive way, and generally reflect how it works rather than obscure it?
I don't understand your question here either. Are you saying you would like the format of the command-line option docker -H to start with https://* instead of tcp://? If so, I think that's a good idea, but it also seems like a ridiculously small and cosmetic problem. I also don't understand how it affects http proxying or auth in any way. Regardless of the command-line flag, the API actually uses https*. So auth and proxying should work completely as expected (with the exception of `attach` which drops to the raw TCP socket to allow bi-directional streams. But we have a websockets endpoint for that and I would really like to deprecate the "drop to tcp" mode soon.
> It could also make for a nice first patch if you're interested in that
> I'm curious where you got all these incorrect notions?
> it also seems like a ridiculously small and cosmetic problem
A lot of your comments come across snarky and backhandedly hostile.
Regarding the tcp:// vs https:// -- I think the parent comment is pointing out that Docker seems to have just made up a new address prefix which is used nowhere else and certainly is not standard. Even if it's a "ridiculously small and cosmetic problem", it should be fixed, and probably never should of been (perhaps hinting at the comment about slowing down to think instead of focusing constantly on new features and rapid fire). If it's the only small cosmetic problem, probably wouldn't be an issue... but add up many, and well...
Regarding the constant comments to commit -- I completely understand wanting others to put their ideas and critiques into PR's... but you have to see where it can come off a little condescending. Your users, of which not all are engineers, are offering critiques which will make your platform better for all, and your responses imply you will not consider any of them as valid unless they are in code, and even then, it's only a maybe.
On suggesting commits: my intention is really not to be condescending, but to seek opportunity to recruit new contributors :) I even specified "if not, that's ok" to emphasize that. I have found that frustration about something in Docker has been the best source of new, valuable contributions. I'm just trying to catalyze that. And yes, I absolutely agree that non-code contributions are just as valuable as code contributions. Even taking the time to file a bug report, or suggest an improvement, is a contribution of your time and hugely appreciated. If you got anything else from my message, it was not intended.
This is something I've witnessed a number of Docker employees do over and over on HN -- state Docker is or is not something currently, based on a future promise.
This statement is a contradiction. You state Docker is not monolithic -- but then the next sentence says you want to break Docker down into composable parts. Which is it?
It's both.
Docker is already quite modular. For example storage and execution backends are swappable using a driver interface. Image storage is a separate binary. Clustering and machine management are a separate binary. The primitives for interacting with kernel namespaces an cgroups are in a separate project called libcontainer. We are developing authentication and security features in a separate repo called libtrust.
And at the same time, I believe we can do better, and made it a high-level goal of the project to improve modularity. I am simply stating that high-level goal.
On the other hand, it's also not very friendly for terminals, either. Huge amounts of pointless whitespace means 'docker ps' is a confusing mess on a standard 80-char terminal.
The cli a non-uniform experience. Whether you're starting or stopping a docker container, you get the same output - the name of the container you supplied. No 'starting', no 'stopping', no 'ok', just the literal string you gave it. So 'docker ps' is meant for human eyes only, but 'docker start/stop' doesn't consider it worthwhile to provide a human-friendly string?
Just recently I've been playing with docker.py, and the inconsistencies continue there. On the cli, the port and volume bindings are assigned when you 'docker create' a container, then you just start/stop it. In docker.py, the port and volume locations are exposed in 'create', but not actually bound there - they're bound in 'start'... which applies the settings to the container's config permanently, so that other methods of starting (cli) also pick them up. It's all very weird.
I see that my particular pet peeve (there's no name or link information in `docker inspect`) has been fixed. Nice! Still, I can't imagine the thought process that leads to express links in JSON as `["/foo:/bar/foo","/baz:/bar/baz"]` rather than `{"foo":"foo","baz":"baz"}` (or even `{"/bar/foo":"/foo","/bar/baz":"/baz"}` if you're attached to the weird hierarchical names). I similarly cannot imagine reasoning that leads to providing port number in JSON as a string, with prefix.
>> Is it still Docker's official position that CLI is only official interface, and using HTTP API is frowned upon? > That was never true. I'm not sure how you got that idea.
Cannot find it now: it's not easy to google out (and if it was in the docs, I'd need to go through web.archive.org), and I didn't think about archiving it myself for later use. I think this was either in (possibly earlier version of) docs, or in some GitHub issue. The sentiment seems to stand, though: Docker's own code base doesn't even include any usable API client, and many seemingly basic CLI operations are very convoluted in API (how do I `docker run` with API? Is it still split across at least two separate calls?). Some of these problems are echoed in https://github.com/docker/docker/issues/7358
Some (possibly most of all - I certainly hope so!) are solved, but the API docs were good at listing the endpoints and (some of) the parameters [I recall JSON format was incompletely described, or not kept up to date]. There was virtually no pragmatic docs on how to use the API to achieve equivalent of, say, a `docker run` invocation. And while I obviously can open an issue or fix it in a PR, reflecting problems back at community because it's open source, if it bothers you, go fix it yourself doesn't seem a proper approach. In particular, if the problem is about keeping documentation in sync with code (format of JSON described in API docs did at some point diverge from actual behaviour; if you want me to go through the docs right now and verify each piece, I'd be happy to do that, but let's discuss the consulting contract first), it's not reasonable to expect your users to pinpoint the issue by going through Git changelogs.
> You can use all these things [HTTP Auth] with the registry API.
Can I `docker pull` an image that is behind plain http auth (e.g. at a registry proxied to https://foo:bar@example.com/)? How do I specify that? Last time I tried to figure this out (before 1.2.0, after 1.0.0, so it may have changed), this was either not possible, or completely undocumented.
And while we're at it, what would exactly be the problem with letting me pull an image available at https://foo.bar@example.com/path/to/image.tar? Why there even is a separate registry API rather than plain HTTP? This part still eludes me.
Re tcp://… vs http://… it's obviously functionally equivalent and cosmetic, unless you want to write some plumbing and you have to add logic to translate from the tcp:// format (which doesn't seem to have any actual reason to be written this way) to http:// URL and back. Similar thing with `tcp://` prefix for ports forwarded from linked containers: I either have to use the long form that includes the original port number, or parse out the irrelevant `tcp://` piece (yes, I know there could be udp:// [but why the double slash? is there any URI path that could follow?]; the protocol is usually obvious from the context, and need to parse out the irrelevant text is actual overhead).
So, for Docker's convenience (or because of a bit of thoughtlessness when something was first implemented), there's a small but significant overhead incurred on a lot of current and future pieces of plumbing and containers, because for some reason (was there any?) you decided `tcp://` looks better than `http://` for an HTTP URL, and `tcp://1.2.3.4:567` looks prettier than just `1.2.3.4:567`.
