Drop the sh, and inspect the script before you run it. It just checks a few dependencies and system items, and then retrieves the docker binary, and puts it in /usr/local/bin. All of this can be done by hand by any Linux sysadmin .. And of course, it wouldn't take much to make a .deb for it either.

However, I would like to discuss the docker design a little more in detail, on the basis of its ease of use. First of all, I too do not like to have random stuff piped into my shell, so I went looking for the Docker sources. It was darned easy to build from sources, and quick too. At the end, I had a single binary.

And the cool thing about this binary is that its both the server and the client in the same package! So - the sysadmin of your Linux machine can (and should, manually, for now) build from sources, install in a local/ or ~/bin, and add the daemon to start up as needed.

Then, anyone else on the machine - not needing su rights - can run docker images, and so on.

This isolation, simplicity of install, and .. frankly .. rocking feature set .. is a beautiful thing. Can it be that golang is the secret sauce here? I say: yes.

Docker author here. Yes, the ability to produce a single binary that "just works" is one of the reasons we chose Golang. The operational simplicity is hard to beat, and you don't have to convince python hackers to install gems, java hackers to mess with virtualenv, and so on.

For the record, another reason we chose Golang is because it was not python. Docker is a rewrite of a 2 year old python codebase which has seen a lot of action in production. We wanted the operational learnings but not the spaghetthi code. So we made it impossible to cut corners by changing languages. No copy-pasting!

Well I for one was quite surprised that a) docker compiled so rapidly on my system, and b) its a very sublime binary. I guess I'm learning another reason why golang ought to get more of my free-time attention, so thats enough HN for me, I'm off to spend the afternoon reading your code.. Cheers to you and what I'm about to learn from docker! :)

Yes it's written in go... though Docker could have been written to the same effect in something else (Haskell or whatever).

If there were a 'secret sauce' I'd say it's the kernel features it takes advantage of (cgroup, lxc, kernel namespaces, aufs, etc). :)

You're right about that! What I'm enjoying, perhaps a little meta-, is how easily that swell soup of jewels is ground up into a fine sonic-screwdriver of a tool. Seems to me right now, I've got yet another reason to enjoy the golang experience ..

> And of course, it wouldn't take much to make a .deb for it either.

It seems to be on its way : http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=706060

If you are using Ubuntu 12.04 or 13.04 the recommended installation method is to use the Docker PPA.

More information available here: http://docs.docker.io/en/latest/installation/ubuntulinux.htm...

Seems like it may solve one set of issues, but will create an entirely new class of potential problems that I'm not sure are any better. A lot of the teething issues seem to be getting some focus though and maybe this will get better over time.

What dependency issues with Django apps have you been having a hard time solving? You should be able to solve everything with a decent configuration management system like puppet/chef/saltstack/ansible.

> Is it really that hard to ask people to download and run the script themselves?

Why? Isn't that exactly what "curl get.docker.io | sh -x" does? It's the cli equivalent to clicking on a download link and then executing it. I think what you mean is "wouldn't it be better for the user to first read the script's code before executing it or run it in a VM?"

No, with the "curl get.docker.io | sh -x" you have absolutely no reproducability or accountability, as there is way to find out which code was actually run during installation. This is the dream situation for attackers that managed to trojan the install script or MITM the connection (note that the curl call does not even use https) to target specific users.

The -x flag printa each line as your shell executes it. Not perfect, but a reasonable tradeoff of control and ease of use.

You could throw a "tee" into the pipe if you want to save the script as well as run it.

just as secure as the containers! ;-)

Can you back up that claim?

well yes.. LXC uses containers.. its as secure as what it uses. Heh.

Not yet... LXC is not even production ready yet in terms of security. Will take a year or two but it's getting there.

I guess it depends on what you mean by production ready. dotCloud, Heroku and others already use LXC in production, and they have been for a while.

You just need to know what the limitations are, and make sure you build your system around LXC so that you are protected.

stackato as well.

production ready doesn't mean much tho. you can use anything you like for prod. it doesn't make it better or worse.

a ton of things that are considered "production ready" today are crippled with bugs, design flaws, etc.

The major issue of linux namespaces (or containers or "lxc" if you will) is that they're generally used as a security feature and haven't not been designed primarily as a security feature. (it wouldn't have entered the kernel if it had been designed as such anyways) vm's provide a better level of isolation so far, even thus they're not perfect either.

and for what it's worth, freebsd for example (among some others) provide a similar namespacing that is much better security wise. also openvz, vservers are doing similar things. Oh and rsbac's jail too. (it might be the "strongest" of the list)

Pretty sure that was the point of what they said :)