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!
thanks - trotsky
Docker - the Linux container runtime
51–60 of 209 posts
Re: Docker - the Linux container runtime
#52Wow! 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!
GH: joonathan
Re: Docker - the Linux container runtime
#53I'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.
Container based virtualization can provide an impressive amount of isolation while improving density dramatically on light duty loads over virtualization. Solaris zones are very well regarded and are used for multi-tenant by Joyent, and many many linux hosts provide multi-tenant solutions based on virtuozzo which predates linux containers by a good number of years. The main theoretical difference between hypervisor i…
As trotsky mentions, we at Joyent are fervent believers in OS-based virtualization -- to the point that in SmartOS, we run hardware virtualization within an OS container. There are many reasons to favor OS-based virtualization over hardware-based virtualization, but first among these (in my opinion) is DRAM utilization: with OS-based virtualization, all unused DRAM is available to the system at large, and in the SmartOS case is used as adaptive replacement cache (ARC) that benefits all tenants. Given that few tenants consume every byte of their allocated DRAM, this alone leads to huge efficiencies from both the perspective of the cloud operator and the cloud user -- a higher-performing, higher-margin service. By contrast, for hardware-based virtualization, unused DRAM remains with the guest and is simply wasted (kludges like kernel samepage mapping and memory ballooning notwithstanding).
DRAM isn't the only win, of course: for every other resource in the system (CPU, network, disk), OS-based virtualization offers tremendous (and insurmountable) efficiency advantages over hardware-based virtualization -- and it's great to see others make the same realization!
For more details on the relative performance of OS-based virtualization, hardware-based virtualization and para-virtualization, see my colleague Brendan Gregg's excellent blog post on the subject[1].
[1] http://dtrace.org/blogs/brendan/2013/01/11/virtualization-pe...
Re: Docker - the Linux container runtime
#54I 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/arakoon/tree/1.6/jenkins
Re: Docker - the Linux container runtime
#55Earlier quoted context omitted.
It's not that it's any different, it's that it's standardized . The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead…
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…
I'm just presuming, but:
1. every one of those attributes would be fixed against a given version of the (coming) Docker spec, and a given host would specify what version(s) of the spec they were compatible with.
2. Go is, I think, just the language the glue code is written in; not the language your own things-deployed-using-Docker must be written in.
3. It might support other Linux distros (Fedora, probably), but it won't support other OSes as hosts--because the whole point is to run things that need a POSIX-alike as their "outer runtime" (i.e. not Windows programs, etc.) The way to run these containers on another host will be to run Linux in a VM on that host, and run the containers in the VM--just like the way to play a Super Nintendo game "container" on your computer is to run them in a Super Nintendo VM. [Actually, come to think of it, game ROMs are a great analogy for precompiled SquashFS containers. I would adopt it if I were them :)]
Re: Docker - the Linux container runtime
#56How is this different from what you can already do with lxc on, for example, Ubuntu Server?
It's not that it's any different, it's that it's standardized . The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead…
So why not use VM images? Why not a VMware vagrant box, for example?
Re: Docker - the Linux container runtime
#57Wow, i need this! What would be the requirements for docker? I suppose it wouldn't run on linux 2.6.x? (CentOS 5.x)? Any other requirements?
The main requirement is a modern kernel with the aufs module. We do most of our testing on Ubuntu 12.04 and 12.10. But any modern distro should be fine. There are a few people testing it on CentOS as I write this.
Re: Docker - the Linux container runtime
#58Wow! 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!
dpaola2
Re: Docker - the Linux container runtime
#59Earlier quoted context omitted.
It's not that it's any different, it's that it's standardized . The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead…
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.
Re: Docker - the Linux container runtime
#60Earlier quoted context omitted.
It's not that it's any different, it's that it's standardized . The idea is that a Docker container would be portable between different PaaS hosts (and from your own staging environment to those hosts!) without rebuilding, because they'd all be using the "Docker standard for deployment." A PaaS host saying they supported Docker would imply that they'd be using, for example, SquashFS for container format, AuFS instead…
So why not use VM images? Why not a VMware vagrant box, for example?
This might work if you only have to run three or four VMs on a box, and run several applications in each container. Full PC virtual machines are much too heavyweight, though, for isolating thousands of individual processes per box, especially when most of them might just sit there doing nothing most of the time.
Though! If you want to, you can think of this standard as specifying an "ABI format" for high-level, lightweight VMs that happens to run on a "Linux machine" instead of, say, an "IA32 machine."