This sounds like a reimplementation of virtual machines at the os layer instead of hardware layer.
Docker - the Linux container runtime
11–20 of 209 posts
Re: Docker - the Linux container runtime
#12I'm not entirely sure that I understand what this does. Is it some sort of hybrid between provisioning automation and deployment automation?
Containerization has been around a long time. Probably the start would be chroot, which was developed further by BSD's jails, Solaris zones, and Linux containers.
Basically, these are all ways a way of running programs with a partitioned subset of access to the OS - in some cases, it may even appear to be an entire installation under that subset.
This (and many of the other mentioned solutions) adds to that by being able to capture and deploy an environment for running a specific app.
Re: Docker - the Linux container runtime
#13I'm not entirely sure that I understand what this does. Is it some sort of hybrid between provisioning automation and deployment automation?
A very bad description would be: "containers are essentially what you get when you cross virtualisation with chroot".
The reason why I give that description to begin with is because containers solve a lot of problems that often lead people towards the virtualisation route. And to the guest "OS", all the applications think they're running on a unique machine from the host. However containers differ from virtualisation in that it's just one OS (one shared kernel). This means you can only run one unique OS (though if you know what you're doing, you can run multiple different distros of Linux in different containers - but you couldn't run FreeBSD nor Windows inside a Linux container). Containers can also have their own resources and network interfaces (both virtual devices and dedicated hardware passed through).
Because you're not virtualising hardware with containers and because you're only running one OS, containers do have performance advantages over virtualisation while still being just as secure. So I personally think they're a massively underrated and under utilised solution.
If you're interested in investigating a little more into containers, Linux also has OpenVZ, and FreeBSD and Solaris has Jails and Zones (respectively). The wikipedia articles on each of them also offer some good details (despite the stigma attached to wikipedia entries).
I've not used Docker specifically, but I have used other containers in Linux and Solaris, so I'm happy to answer any other questions on those.
Re: Docker - the Linux container runtime
#14This sounds like a reimplementation of virtual machines at the os layer instead of hardware layer.
It sounds like they are just building on cgroups etc, which are already part of the Linux kernel.
I would argue that virtual machines at a hypervisor/hardware level were just a hack for OSs not living up to their isolation promises/obligations. Strong OS level isolation implementations (cgroups, namespaces etc) allow people to put isolation back where it belongs, the OS.
The job of the OS is to control the hardware, wrapping the OS is software to emulate hardware is ridiculous and VMs generally have much more performance overhead than isolation containers.
Re: Docker - the Linux container runtime
#15This sounds like a reimplementation of virtual machines at the os layer instead of hardware layer.
Containers have existed as long as virtual machines have. FreeBSD implemented "Jails" back in the late 90s / yr2000. Linux also has OpenVZ and Solaris has Zones.
If you couple a container with a CoW file system that supports snapshotting (eg ZFS or BtrFS), then you can have most of the features you'd expect from virtualisation but without as heavy footprint.
Containers are an underrated and often forgotten solution in my opinion.
Re: Docker - the Linux container runtime
#16That 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 ?
Re: Docker - the Linux container runtime
#17I'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.
I am familiar with Microsoft App-V, VMWare ThinApp, and Symantec Workspace Virtualization. They can help you as a security sandbox but not as a full protection. A virtual machine will be much more secure (and theoretically very strong), although there are security bugs there that enable you to escape it.
Those products work at two levels: using filtering drivers for registry and the filesystem, and hooking into the Windows operating system API.
Re: Docker - the Linux container runtime
#18Why should I use this when systemd offers the same (minus the AUFS root fs)?
Re: Docker - the Linux container runtime
#19I'm not entirely sure that I understand what this does. Is it some sort of hybrid between provisioning automation and deployment automation?
There've been quite a few articles on containers on LWN over the last few months; worth digging around there if you're interested. A couple of the more recent ones:
https://lwn.net/Articles/524952/ - Glauber Costa's talk on the state of containers at LinuxCon Europe 2012
https://lwn.net/Articles/536033/ - systemd containers; these follow on from a theme of containerizing whole distros rather than single apps
Re: Docker - the Linux container runtime
#20Earlier quoted context omitted.
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…
> The Linux namespace stuff is evolving pretty fast, and I personally wouldn't trust it as the main line of defense for anything important. If I recall, Heroku uses cgroups (EDIT: and namespaces) exclusively for multitenant isolation (and by the looks of this, dotCloud does too), so that's two big votes in the "if it's good enough for them" category.
Sure, but cgroups and namespaces are kind-of-orthogonal features that both happen to be useful for making container-like things. cgroups are for limiting resource usage; namespaces are for providing the illusion of root access while actually being in a sandboxed environment.
And as far as I'm aware (speaking as an interested non-expert, so please correct me if I'm wrong) cgroups have no effect on permissions, whereas UID namespaces required a lot of very invasive changes to the kernel.