Docker is essentially a security construct.

The idea is that the process inside the container, like say MySQL, Python or Django, runs as a process on your machine in such a way that it can only access parts of the system and the world that it’s explicitly been granted access to.

If you naively attempted this, you’d run into a big problem immediately. Namely that a program needs access to libraries. So you need to grant access to those. Libraries might be specific to the program, or they might be system libraries like libc.

One way is to explicitly enumerate each required library, but then you’d need to install those for each such process, which is inconvenient and a security nightmare.

Instead you package the libraries and the program together in a package called a Docker image.

To simplfy things, at some point it’s simpler to start with a minimal set of known files, like say Alpine, Debian, or Fedora.

This basically means that you’re downloading a bunch of stuff to make the program run and thus is born the typical Docker image. If you look at the Python image, you’d see that it’s based on some other image. Similarly, a Django image is based on a Python image. It’s the FROM line in a Dockerfile.

A container is such an image actually running the isolated process, again, like say MySQL.

Adding information to that process happens in a controlled way.

You can use an API that the process uses, like say a MySQL client. You can also choose to include the data in the original image, or you can use a designated directory structure that’s visible to both you and the process, this is called a volume.

To run something like a Django application would require that Python has access to the files, which can be included in the image by using a custom Dockerfile, or it can be accessed y the container whilst it’s running, using a volume.

It gets more interesting when you have two programs needing access to the same files, like say nginx and python. You can create shared volumes to deal with this.

Ultimately, Docker is about security and making it convenient to implement and use.

Source: I use Docker every day.

It’s built on the shipping container parallel. In order to transport objects you obfuscate anything not required for shipping a container.

• What’s inside the container doesn’t matter. The container has everything it needs to run because the ship/host is responsible for the overhead.
• containers move. Containers are setup to run by themselves, so you can move it from one ship to another. This means you can use your container doesn’t care if it’s in the cloud or a shipping vessel
• As soon as you open a container your stuff is there. It’s very easy to onboard.
• Most importantly though, your shipping container isn’t a full boat by itself. It lives in a sandbox and only borrows the resources it needs like the hosts CPU or the boats ability to float. This makes it easier to manage and stack because it’s more flexible

I’d say it’s more like a closed-off part of the filesystem but with networking and probably lots of other stuff closed off as well.

Updates on the host are separate from updates of the containers. Ideally the host has only the minimal stuff needed to run the containers.

Containers are usually updated when the contained apps are updated. That’s actually my main concern with containers. When the main app doesn’t need an update but some dependency needs one you have to actively update the dependency unless the app maintainers keep up with what their dependencies are doing. And usually you don’t even know what the dependencies are. Because the whole point of containers is that you only care about the main app.