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

101–110 of 209 posts

Re: Docker - the Linux container runtime

#101

Post by jpetazzo »

zobzu wrote: post #88
shykes wrote: post #84

Earlier quoted context omitted.

(Copying my answer to a similar question) 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 c…

you're trying to justify the use of lxc for security, IMO. Your webpage does state "strong guarantees of isolation" if you're sharing nothing of importance on the host, then, you don't really need LXC, unless you don't know how to setup mysql with more than one database, nginx with more than one virtual host, yada yada. Here's the trick: you CAN use LXC and SUPPLEMENT it by something providing security such as SELinu…

dotCloud engineer here.

LXC lets you use cgroups, i.e. setup memory/cpu/IO limits per container. If you setup MySQL with more than database, you can't do that.

Also, we DO use LXC and SUPPLEMENT it by something providing security such as GRSEC (in the current version in production at dotCloud) and AppArmor (with docker) :-)

Re: Docker - the Linux container runtime

#102

Post by shykes »

niall_ohiggins wrote: post #71
rlpb wrote: post #56

Earlier quoted context omitted.

So why not use VM images? Why not a VMware vagrant box, for example?

One major benefit over VM images is Linux Containers have very fast spin-up time. This can be especially useful for PaaS providers and CI servers.

Other benefits: docker images are basically tarballs, which means they are much smaller.

And, importantly, Docker maintains a filesystem-level diff between versions of an image, and only needs to transmit each diff once. So you get tremendous bandwidth savings when transmitting multiple images created from the same base.

Re: Docker - the Linux container runtime

#103

Post by jpetazzo »

duked wrote: post #99
zobzu wrote: post #88

Earlier quoted context omitted.

you're trying to justify the use of lxc for security, IMO. Your webpage does state "strong guarantees of isolation" if you're sharing nothing of importance on the host, then, you don't really need LXC, unless you don't know how to setup mysql with more than one database, nginx with more than one virtual host, yada yada. Here's the trick: you CAN use LXC and SUPPLEMENT it by something providing security such as SELinu…

or use OpenVZ which has been designed with security in mind ;)

LXC is actually the work of the OpenVZ team.

When they were tired about seeing their patches rejected from the mainstream kernel, they decided to try a different approach, and that approach is LXC. In other words, LXC is a reimplementation of OpenVZ concepts by almost the same team.

LXC is actually more secure than OpenVZ, if only because it went through more scrutiny than OpenVZ.

Re: Docker - the Linux container runtime

#104

Post by emidln »

niall_ohiggins wrote: post #71
rlpb wrote: post #56

Earlier quoted context omitted.

So why not use VM images? Why not a VMware vagrant box, for example?

One major benefit over VM images is Linux Containers have very fast spin-up time. This can be especially useful for PaaS providers and CI servers.

If your images use kvm+qcow2 you can just spin up new vms as a delta image using qcow2's support for a backing store.

I want a new instance of WEBSERVER.qcow2?

    qemu-img create -b WEBSERVER.qcow2 -t qcow2 WEBSERVER-$SERIALNUMBER.qcow2
If you're doing this as a PaaS or for CI, you do this as part of your new image creation and then pass in the new qcow2 to your vm (maybe via libvirt). If you aren't doing this or something very similar, you're spinning your wheels and wasting time/resources.

Re: Docker - the Linux container runtime

#107

Post by Tobu »

jpetazzo wrote: post #103
duked wrote: post #99

Earlier quoted context omitted.

or use OpenVZ which has been designed with security in mind ;)

LXC is actually the work of the OpenVZ team. When they were tired about seeing their patches rejected from the mainstream kernel, they decided to try a different approach, and that approach is LXC. In other words, LXC is a reimplementation of OpenVZ concepts by almost the same team. LXC is actually more secure than OpenVZ, if only because it went through more scrutiny than OpenVZ.

Are you sure? I think LXC was developed by IBM. Team OpenVZ is still sticking with very old kernel releases (2.6.32 at most), they may adopt LXC for some of their features but they aren't very keen on upstream work.

Re: Docker - the Linux container runtime

#108

Post by wereHamster »

shykes wrote: post #30

Wow! Did not expect this to show up on HN before actual release! (I work at dotCloud). We're still polishing a few rough edges. If you want early access add your github ID to this thread and we'll add you right away!

wereHamster (don't be scared, I won't bite and infect you)

Re: Docker - the Linux container runtime

#110

Post by peterwwillis »

derefr wrote: post #95
peterwwillis wrote: post #77

Earlier quoted context omitted.

The trick here is that their xmame (Docker) may not be the same build on all hosts, so it may not play the ROMs all in the same way or support all ROMs. A standard works to improve interoperability between different builds/hosts/etc as well as provide an expected set of operations and their results. If all they provide is just one version of one product and call that standardized, that's like releasing a new version…

Well, this is a good first step in the "free market" standardization process, though: get a public implementation out of what you would imagine standard-conformance to look like. Then, let the other guys (e.g. Heroku) get out their competing implementations. Then, find the similarities, resolve the differences, and write it down. Now you've got a standard.

In practice that does not work. Things get broken, people end up having to support 20 edge cases to use this "universal", "standardized" thing. Depends on the implementation, though.
Post reply on HN