-
Notifications
You must be signed in to change notification settings - Fork 0
Container Strategy
The goal of this page is to outline the initial thoughts, musings, and strategies around implementing containers with Mistify. Looking at more mature container implementations (illumos zones, bsd jails) there are certain aspects we would like to capture which are not currently implemented in Linux. We hope to close that gap. Some of those goals include:
The concept of lightweight containers and how to operate them are not universally agreed upon. There are typically 3 models in use; single process per container, single "service" per container, and treat each container as a lower overhead VM. We believe we can support all three of these model at the technical level, and leave which model to use up to the operator, however, we are partial to the "services container" model.
On the technical side, if we start with the systemd-nspawn approach - as discussed here - we can build service level containers. Unfortunately Linux still has an incomplete picture of cgroup/namespace interaction for truly secure containers, but we believe that it is possible to list out those missing pieces and then fill them in.
Containers still need to live on disk, and our goal is to build on top of ZFS, so that moving (or copying) containers can be as easy as sending around ZFS snapshots.
To solve this problem, we need some of the ZFS bits from our zfs roadmap, including introducing some zfs namespacing within the system to tie datasets to the containers we want to do above. This would give achieve our goal of integration with ZoL.
Currently systemd-nspawn supports the following namespaces: mount, proc, IPC, and UTS. net support appears to be experimental. we need support for user (so processes inside the container can be unprivileged wrt the host we would need to create a zfs namespace to do zfs delegation (this needs to happen everywhere)
A quick FAQ on some our initial throughs around containers in Mistify:
Q: Docker Docker Docker Docker?
A: Docker is still new and has some less than optimal facets. Until the landscape settles a bit, for us an all Docker solution is not a great fit. That said, we do have Docker support in Mistify, we just want to have an escape hatch.
Q: What about rkt / appc?
A: The container space on Linux is actively changing, however most solutions can be decomposed into a base set of files which can be consumed and managed with the systemd-nspawn approach. There is an example of this with Docker outlined here. So we now have Docker support, without being tied down by it. We think we can leverage this for other emerging formats as well.
That said, since we view ZFS as a first class citizen in Mistify, the larger the gap between ZFS and a container speck, the lower on our roadmap integration is likely to go.
Q: Why not just use libcontainer?
A: Libcontainer has more namespace support baked into itself than systemd-nspawn, however support for that isn't as widespread, since Docker is the only consumer. We think we can fill in any of those missing gaps with systemd-nspawn route.
Some key links that have informed our initial thoughts
https://github.com/phusion/baseimage-docker#docker_single_process
https://chimeracoder.github.io/docker-without-docker/#1
https://github.com/dineshs-altiscale/docker/commit/104725d70a3bad8541a53dde8ddb72616dc96174