6 ms·

This is fantastic, I've been wondering how DotCloud made everything work so well. Can't wait to try this for deploying a Django application I work on — hopefull

This is fantastic, I've been wondering how DotCloud made everything work so well. Can't wait to try this for deploying a Django application I work on — hopefully it will solve my dependency headaches. One nitpick — not a big fan of the recommended installation method (curl get.docker.io | sh -x). Is it really that hard to ask people to download and run the script themselves?

zobzu 13y ago
just as secure as the containers! ;-)
- james4k 13y ago
  Can you back up that claim?
  - zobzu 13y ago
    well yes.. LXC uses containers.. its as secure as what it uses. Heh.
- gwgarry 13y ago
  Not yet... LXC is not even production ready yet in terms of security. Will take a year or two but it's getting there.
  - lholden 13y ago
    Pretty sure that was the point of what they said :)
  - KenCochrane 13y ago
    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.
    - zobzu 13y ago
      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)
23david 13y ago
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.
primitur 13y ago
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.
- shykes 13y ago
  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!
  - primitur 13y ago
    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! :)
- lholden 13y ago
patrickaljord 13y ago
> 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?"
- fhars 13y ago
  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.
  - deleted 13y ago
    [deleted]
  - ams6110 13y ago
    You could throw a "tee" into the pipe if you want to save the script as well as run it.
  - shykes 13y ago
    The -x flag printa each line as your shell executes it. Not perfect, but a reasonable tradeoff of control and ease of use.
KenCochrane 13y ago
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.html http://docs.docker.io/en/latest/installation/ubuntulinux.htm...

zobzu 13y ago

just as secure as the containers! ;-)

james4k 13y ago
Can you back up that claim?
- zobzu 13y ago
  well yes.. LXC uses containers.. its as secure as what it uses. Heh.
gwgarry 13y ago
Not yet... LXC is not even production ready yet in terms of security. Will take a year or two but it's getting there.
- lholden 13y ago
  Pretty sure that was the point of what they said :)
- KenCochrane 13y ago
  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.
  - zobzu 13y ago
    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)

23david 13y ago

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.

primitur 13y ago

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.

shykes 13y ago
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!
- primitur 13y ago
  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! :)
lholden 13y ago

patrickaljord 13y ago

> 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?"

fhars 13y ago
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.
- deleted 13y ago
  [deleted]
- ams6110 13y ago
  You could throw a "tee" into the pipe if you want to save the script as well as run it.
- shykes 13y ago
  The -x flag printa each line as your shell executes it. Not perfect, but a reasonable tradeoff of control and ease of use.

KenCochrane 13y ago

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.html http://docs.docker.io/en/latest/installation/ubuntulinux.htm...