Recently I've been looking up on the Linux application portability & the
already available options. Not under the hoods, really - just the
overview, to have an educated opinion.
Docker basically is DotCloud re-organized - one of those early-birds to leave their PaaS business & take this up. It takes Linux Containers (liblxc) as its base & then provides an abstraction, implemented in Go. They're in a process to use more abstraction, and implement better environment for app-portability (using AUFS, and even BTRFS) to further reduce the complexity of dealing with containers & contained applications. It kind of targets Ubuntu as the platform - haven't stumbled upon any doc that says they've plans for other Linux distros - I may be wrong.
Going deeper, Linux Containers is a wrapper around the Kernel to expose many/most of its features. It uses Linux control-groups (cgroups) heavily, and can expose Kernel namespaces, SELinux, Seccomp etc. to work with (for the applications). Figuratively speaking, it's one kernel less than a virtual-machine - more advanced than OpenVZ or VServer - along with Go, Python & Lua language bindings, to expose Kernel features as APIs. LXC is designed to be distro-agnostic (as long as it's a Linux platform), and is available as packaged binaries for most of the popular distros.
Linux Containers itself is written in C, however, it's more layered than it's needed to be, in cases - trading off some of the advantages gained by using C. Although, I'm not entirely sure whether the other method (leaner, more direct communication with the Kernel) will lead to exclusion of some of its features though. Perhaps it'll be good to study the tagged-snapshots to understand the evolution it faced & whether these choices were made early during the designing of the project, which can/could've been avoided. It's primarily maintained by the Canonical folks, and they've done a darn good job, overall.
Anyway, next up is diving deeper into cgroups & keep up with LXC in parallel (may drop a couple of patches too, what the heck).
Docker basically is DotCloud re-organized - one of those early-birds to leave their PaaS business & take this up. It takes Linux Containers (liblxc) as its base & then provides an abstraction, implemented in Go. They're in a process to use more abstraction, and implement better environment for app-portability (using AUFS, and even BTRFS) to further reduce the complexity of dealing with containers & contained applications. It kind of targets Ubuntu as the platform - haven't stumbled upon any doc that says they've plans for other Linux distros - I may be wrong.
Going deeper, Linux Containers is a wrapper around the Kernel to expose many/most of its features. It uses Linux control-groups (cgroups) heavily, and can expose Kernel namespaces, SELinux, Seccomp etc. to work with (for the applications). Figuratively speaking, it's one kernel less than a virtual-machine - more advanced than OpenVZ or VServer - along with Go, Python & Lua language bindings, to expose Kernel features as APIs. LXC is designed to be distro-agnostic (as long as it's a Linux platform), and is available as packaged binaries for most of the popular distros.
Linux Containers itself is written in C, however, it's more layered than it's needed to be, in cases - trading off some of the advantages gained by using C. Although, I'm not entirely sure whether the other method (leaner, more direct communication with the Kernel) will lead to exclusion of some of its features though. Perhaps it'll be good to study the tagged-snapshots to understand the evolution it faced & whether these choices were made early during the designing of the project, which can/could've been avoided. It's primarily maintained by the Canonical folks, and they've done a darn good job, overall.
Anyway, next up is diving deeper into cgroups & keep up with LXC in parallel (may drop a couple of patches too, what the heck).
Comments
Post a Comment