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

31–40 of 209 posts

Re: Docker - the Linux container runtime

#31

Post by shykes »

derefr wrote: post #28
rlpb wrote: post #25

How 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…

Correct. Docker is the direct result of dotCloud's experience running hundreds of thousands of containers in production over the last 2 years. We tried very hard to put it in a form factor which makes it useful beyond the traditional PaaS.

We think Docker's API is a fundamental building block for running any process on the server.

Re: Docker - the Linux container runtime

#32

Post by shykes »

zimbatm wrote: post #24
zdw wrote: post #5

Are the aufs filesystems easily navigable from the host OS, ala Solaris's zones feature?

The aufs mount is (probably) only mounted on the guest's VFS so I'm not sure how you would access it from the host.

Docker lets you visualize changes on any container's filesystem live, as they happen. It also lets you snapshot changes from any container into a new image, and immediately start running new containers from that image. No manual post-processing of the image, no configuration files to templatize. The whole thing is 2 commands and maybe half a second.

Re: Docker - the Linux container runtime

#33

Post by themckman »

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!

Would REALLY love to take a look at this.

Github: 198d

Re: Docker - the Linux container runtime

#34

Post by bradrydzewski »

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.

This is still technically a virtualization technique, known as "operating system-level virtualization". http://en.wikipedia.org/wiki/Operating_system-level_virtuali...

Here are some of the technologies explained:

cgroups: Linux kernel feature that allows resource limiting and metering, as well as process isolation. The process isolation, also called namespaces, is important because it prevents a process from seeing or terminating other running processes.

lxc: this is a utility that glues together cgroups and chroots to provide virtualization. It helps you easily setup a guest OS by downloading your favorite distro and unpacking it (kind of like debootstrap). It can then "boot" the guest OS by starting it's "init" process. The init process runs in its own namespace, inside a chroot. This is why they call LXC a chroot on steroids. It does everything that chroot does, with full process isolation and metering.

aufs: this is sometimes called a "stacked" file system. It allows you to mount one file system on top of another. Why is this important? Because if you are managing a large number of virtual machines, each one with 1GB+ OS, it uses a lot of disk space. Also, the slowest part of creating a new container is copying the distro (can take up to 30 seconds). Using something like AUFS gives you much better performance.

So what about security? Well, like every (relatively) new technology LXC has its issues. If you use Ubuntu 12.04 they provide a set of Apparmor scripts to mitigate known security risks (like disabling reboot or shutdown commands inside containers, and write access to the /sys filesystem).

Re: Docker - the Linux container runtime

#36

Post by jpetazzo »

zimbatm wrote: post #24
zdw wrote: post #5

Are the aufs filesystems easily navigable from the host OS, ala Solaris's zones feature?

The aufs mount is (probably) only mounted on the guest's VFS so I'm not sure how you would access it from the host.

The AUFS mountpoint is also reachable from the host. However, each container uses its own `mnt` namespace, so further mounts (done within the container) will not automatically be visible.

Re: Docker - the Linux container runtime

#37

Post by shykes »

zimbatm wrote: post #26
duked wrote: post #16

That sounds like a definitive improvement over LXC specially the isolation properties but I'm not sure what is the added value of Docker compared to OpenVZ ? Any ideas ?

My guess is that the container specification is orthogonal to the sandboxing feature. In fact they're using LXC.

Correct, Docker is currently based on lxc, but that is an implementation detail. In theory it could be ported to any process-level isolation tech with similar features: OpenVZ, Solaris Zones - you could also try using BSD jails although I don't know if they have all the required features.

To answer the original question: Docker extends LXC with a higher-level API which operates at the process level. OpenVZ helps you create "mini-servers". Docker lets you forget about servers and manage processes.

Re: Docker - the Linux container runtime

#39

Post by batgaijin »

derefr wrote: post #28
rlpb wrote: post #25

How 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…

What about virtsandbox from fedora? how does this project overlap with that? can this handle certain situations better?
Post reply on HN