3 ms·

For those that have thought about running something similar in production, I have a few questions: 1. Shared kernel - in this model all of the containers have

by sharms 13y ago

For those that have thought about running something similar in production, I have a few questions: 1. Shared kernel - in this model all of the containers have a shared kernel, so any activity or even tuning (ie io scheduler) would impact all of the containers right? 2. Patching - when you need to apply a kernel security patch, all containers would need to agree on a change window unless you were using something like KSplice? 3. User space / kernel space dependencies - if we imagine even 5 years down the road, will containers using for example Red Hat Enterprise Linux 5 apps be containerized but broken? Ie the hosting provider will likely want to stay ahead of the curve and upgrade their kernel, but the app teams may not be as progressive, so when these upgrades occur the apps would break

icebraining 13y ago
Is (3) a real problem? After Linus' strongly-worded[1] email, I assumed kernel backward compatibility was fairly robust. Isn't it? [1]: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75
- mhurron 13y ago
  It doesn't appear to be a problem. We built something relatively similar to this where I work, but with generic Linux utilities like chroot. We have 11+ year old Linux environments running on RHEL6 just fine. The other is not so easy, very recent Linux environments don't always run on RHEL6.
cdjk 13y ago
Those are problems, but they're problems with all container/jail based virtualization platforms like OpenVZ, FreeBSD jails, Solaris containers. The first question is a valid point. But you also get benefits from not having the overhead of N different kernels running. This is easiest to see when looking at VPS providers - a 512MB OpenVZ vps means you have 512MB of memory for your application to use. Yeah, kernel overhead isn't that much, especially if you're running a few high-resource instances, but it can help if you have lots of low memory instances. There's lots of discussion online about OpenVZ vs. xen/kvm vps hosts if you're curious. As for patching - OpenVZ at least makes it very easy to do live migration of instances between servers (barring some weirdness if you have NFS mounts in the guest), although it appears that lxc (and therefore docker) can't do that [1]. In any event, it shouldn't hard to shutdown the guest, migrate, and restart the guest - especially if you're using shared storage of some sort. As for your third point - backward compatibility with RHEL/Centos is generally quite good (since that's kind of the point of RHEL). At work we're currently on Centos 5, and our migration strategy to Centos 6 is probably going to be to install Centos 6 OpenVZ hosts, then move the guests and worry about upgrading the guests later. Forward-compatibility is an issue, but I don't think there's an easy solution to that. [1] http://en.wikipedia.org/wiki/Operating_system-level_virtualization http://en.wikipedia.org/wiki/Operating_system-level_virtuali...
- zobzu 13y ago
  KSM makes the overhead pretty low memory wise

by sharms 13y ago

icebraining 13y ago

Is (3) a real problem? After Linus' strongly-worded[1] email, I assumed kernel backward compatibility was fairly robust. Isn't it? [1]: https://lkml.org/lkml/2012/12/23/75 https://lkml.org/lkml/2012/12/23/75

mhurron 13y ago
It doesn't appear to be a problem. We built something relatively similar to this where I work, but with generic Linux utilities like chroot. We have 11+ year old Linux environments running on RHEL6 just fine. The other is not so easy, very recent Linux environments don't always run on RHEL6.

cdjk 13y ago

Those are problems, but they're problems with all container/jail based virtualization platforms like OpenVZ, FreeBSD jails, Solaris containers. The first question is a valid point. But you also get benefits from not having the overhead of N different kernels running. This is easiest to see when looking at VPS providers - a 512MB OpenVZ vps means you have 512MB of memory for your application to use. Yeah, kernel overhead isn't that much, especially if you're running a few high-resource instances, but it can help if you have lots of low memory instances. There's lots of discussion online about OpenVZ vs. xen/kvm vps hosts if you're curious. As for patching - OpenVZ at least makes it very easy to do live migration of instances between servers (barring some weirdness if you have NFS mounts in the guest), although it appears that lxc (and therefore docker) can't do that [1]. In any event, it shouldn't hard to shutdown the guest, migrate, and restart the guest - especially if you're using shared storage of some sort. As for your third point - backward compatibility with RHEL/Centos is generally quite good (since that's kind of the point of RHEL). At work we're currently on Centos 5, and our migration strategy to Centos 6 is probably going to be to install Centos 6 OpenVZ hosts, then move the guests and worry about upgrading the guests later. Forward-compatibility is an issue, but I don't think there's an easy solution to that. [1] http://en.wikipedia.org/wiki/Operating_system-level_virtualization http://en.wikipedia.org/wiki/Operating_system-level_virtuali...

zobzu 13y ago
KSM makes the overhead pretty low memory wise