Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Docker - the Linux container runtime

docker.io

Post reply on HN
Print view View original

61–70 of 209 posts

Re: Docker - the Linux container runtime

#62

Post by shykes »

teraflop wrote: post #8
asadjb wrote: post #4

I'm not familiar with any of the technologies used in this. Anybody care to comment on how strong the isolations would be security wise, compared to normal virtualization? If the security is almost at par and the isolation is good enough that one bad process can't bring the whole system down, might this be a good alternative to virtualization, since I imagine it would definitely use less resources.

The Linux namespace stuff is evolving pretty fast, and I personally wouldn't trust it as the main line of defense for anything important. With virtualization, a buggy or malicious guest is still limited to its sandbox unless there's a flaw in the hypervisor itself. With containers/namespaces, the host and guest are just different sets of processes that see different "views" of the same kernel, so bugs are much more l…

Yes, you probably don't want to run untrusted code with root privileges inside a container if anything valuable is running on the same host.

However if that code is trusted, or if you're running it as an unprivileged user, or if nothing else of importance is sharing the same host, then I would not hesitate to use them.

Containers are awesome because they represent a logical component in your software stack. You can also use them as a unit of hardware resource allocation, but you don't have to: you can map a container 1-to-1 to a physical box, for example. But the logical unit remains the same regardless of the underlying hardware, which is truly awesome.

Re: Docker - the Linux container runtime

#67

Post by niall_ohiggins »

nicolast wrote: post #54

I recently changed our Jenkins CI infrastructure to use something like this: all jobs run in their own LXC container, using BTRFS and its snapshots/clones instead of AUFS. Works like a charm! The script is available at https://github.com/Incubaid/jenkins-lxc (no docs for now, and several improvements are possible). It expects CI job scripts to be contained in the job repository, e.g. https://github.com/Incubaid/arako…

That's pretty awesome.

At FrozenRidge.co, we work on our own CI server called Strider and have actually integrated Docker directly:

You can read about it at: http://blog.frozenridge.co/next-generation-continuous-integr...

Re: Docker - the Linux container runtime

#68

Post by shykes »

nwg wrote: post #23

Does anyone know, or can anyone speculate on exactly how the "heterogenous payloads" are specified?

The payload is anything which can be recorded on the filesystem by running a unix command. For example:

     # Run command which adds your payload
     $ docker run base apt-get install curl
     5b4a1ee8

     # Commit the result to a new image
     $ docker commit 5b4a1ee8 nwg/base-with-curl

     # Run a command from the new image. Your payload is available!
     $ docker run nwg/base-with-curl curl http://www.google.com
Docker doesn't care how the payload was added. apt-get, shell script, pip install, gem bundle... All the same. In the end it's just a change to the filesystem.

Re: Docker - the Linux container runtime

#70

Post by peterwwillis »

shykes wrote: post #59
peterwwillis wrote: post #41

Earlier quoted context omitted.

Doesn't a standard involve, you know, standards? AFAIK a product name is not a standard. What if the namespace changes? What if AuFS changes? What if LXC changes? Independently or all together? ABI changes? Version changes? Feature changes? Are all the licenses compatible? Will it ever support platforms other than just certain versions of Linux? Or languages other than Go? I don't see a standard. I see marketing for…

Hi Peter, this website was only meant to be seen once Docker is actually open-source, which will be the case very soon. I do think there is a need for a standard way to package and share software at the filesystem and process level - we don't pretend to define that standard, but hopefully we can contribute to it by open-sourcing a real-world implementation.

I guess I read too far into it when I saw the word "standard" everywhere and got excited - sorry about that. Do you plan on adding to your implementation the ability to differentiate between compatible versions/platforms, so one could use this on several cloud instances that aren't built the same?
Post reply on HN