Golang UK Conf. 2016 - Liz Rice - What is a container, really? Let's write one in Go from scratch

This is precisely why I said the fact that someone would gloss over this is a red flag. The point is super critical . VMs are literally so hard to do correctly and in a performant fashion that parts of CPU instruction sets[0], and kernel subsystems (KVM[1]) were created to make them easier to run. Containers, in contrast are literally a few flags and a bunch of in-kernel antics. A few people, notably Liz Rice and Jessie Frazelle have given talks on how to make containers from scratch that are very illuminating for those that are interested: ▶ this video link [0]: link [1]: link

In the same vein: Building a container from scratch in Go (Liz Rice) @ Container Camp 2016 -> link What's a container really let's write one in go from sctach (Liz Rice) @ Golang UK Conference -> ▶ this video Cgroups, Namespaces and beyond: What are containers made from (Jerome Petazzoni) @ DockerCon 2015 - link Building Containers in Pure Bash and C (Jessica Frazelle) @ ContainerSummit 2016: link First two are basically the same talk, but it doesn't hurt to hear the same ideas more than once.

Super late to this thread but the best video I've ever seen on how docker/containers work is this one: Jessica Frazelle's (docker core maintainer) talk on how to build containers in pure bash and C: link There's also this one, which is similar: ▶ this video

I started by watching ▶ this video and reading link Also "man namespaces" on a linux machine will give some deeper documentation.

The core philosophy of "one app per container" has not changed. Strictly speaking, this will never change because containers - whether Docker, ACI, or OCI - are processes and not VMs . I recommend this accessible presentation on how to write a poor-mans Docker by hand[1] to remove some of the magic behind containers. As with any philosophy, there are many smart people who hold an opposite view. Docker itself is perhaps deviating from the architectural simplicity of container==process, while the underdog rkt is enforcing this approach even at the cost of user-land usability (e.g. rkt cannot run containers as daemons by itself). In practice, most containers must have an OS wrapping the application (unless you're distributing binaries), and that OS often ends up being a nearly fully baked version of Ubuntu/Debian/Fedora or whatever the person is most comfortable with outside of Docker. edit PS: One common exception to this philosophy is a short-lived container for admin/management/debugging. Having a full OS with devel/admin tools is useful for investigation/maintenance purposes, then you kill it and nothing is changed in prod. [1] ▶ this video