I just did a post about this on LinkedIn (gotta build that cred).

Containers aren't a new concept. But in today's world, we're usually talking about the intersection of three Linux features:

* namespaces bundle resources (processes, disk, I/O, etc.) together, isolating them from each other. They're a teacher with a class full of rowdy kids.

* cgroups (control groups) limit and audit how many resources a group of processes can use. They're traffic cops.

* Union File System sits on top of another file system. Anything in the underlying file system is visible, but writes and new files only appear in the UnionFS mount. This layer can be thrown away at the end of a session, leaving the base filesystem pristine. It's the tracing paper you used as a kid when you were learning to draw.

Processes in a container run on the same kernel as the other apps you run, but they're isolated, controlled, and kept from scribbling all over the disk. Add some tooling and standards and you have the foundations of modern #softwaredevelopment !

This is a big over-simplification, but I think it's a good mental model:

Think of a container as a fancy chroot.

Imagine that:

   1. You have a whole separate Linux installation in some random folder.
   2. You ask your OS to launch some process, and to "trick" the process into thinking that "$YOUR_FOLDER" is actually "/".
   3. You maybe also ask your OS to add some extra isolation (network, devices, /proc, etc).
   4. The term "container" refers to the chroot, the isolation rules, and usually the process-tree running inside of it.
   5. While a container is alive, you can also ask the OS to run some other programs that exist inside of the container's sandbox

Docker is a tool that creates and manages containers. In Docker's view of the world:

- Containers are made by extracting .tar.gz files into some folder and asking the OS to create a sandbox where that folder is a "fake" root directory.

- Those .tar.gz files are called "images".

- Docker can download images from the internet, or you can build your own by asking it to follow the steps contained in a Dockerfile.

A virtual machine makes an OS believe it has the machine to itself. A container makes a process believe that it has the OS to itself.

The way I think of a container:

It's an individual OS with a filesystem of its own, based on the "image" and what is pre-installed (such as an OS, plus, if you choose: some extras pre-installed based on your project need.).

You can link your laptop or server (AKA your "host" computer) to it through Docker Volumes. And, you can link containers together through Docker Networks, for example.

So, you can see how a single compartmentalized OS (a "container") can: 1. interact with another computer's file system and 2. interact with another computer on a network. And, each one can be quite customized.

So, a container is an OS + filesystem* + network*

* = can be connected to others to transfer data