Docker image
An image is a tarball with a promise.
That promise is: run me, and you get exactly the same application, on any machine that runs Docker. Code, runtime, system libraries, settings — everything is in there, frozen in a read-only package that no one can modify anymore. Not you, not your colleague, not the server where it accidentally ends up.
What you can do is put something on top of it. A Docker image is built from layers, and each layer is the difference from the layer below it. Install nginx, and a layer is added. Copy your application code, another layer. Delete a file, and you place a layer with a delete marker on top of the layer where that file still exists.
That is the copy-on-write principle, and it is the reason images are so efficient. Ten images that all run on `alpine` share that single base layer. Your disk pays once for the base, not ten times. And if you pull an image that your neighbor already fetched, Docker only pulls the layers you don't have yet.
At the bottom there is always a base image: `alpine`, `ubuntu`, `debian`. You build on top of that with a Dockerfile, where each instruction produces a new layer. The image itself never changes afterward. Want a security patch? Then you build a new image with a new layer. The old one remains, identifiable by its digest, a fingerprint of the contents.
That immutability is not a limitation; it is the guarantee that what you test in development is also what runs in production.
Management happens through the `docker image` subcommands. `docker image ls` shows what is stored locally: repository, tag, image ID, size, creation date. Add `--all` and you also see the dangling images — orphaned layers left over after a rebuild. They take up space and do nothing else.
`docker image inspect` gives the full story in JSON: architecture, operating system, the complete layer structure, the `CMD` that runs as soon as you start a container. With `--format` you can pull out a single field, for example `{{ .Size }}` if you only want the size. The output is detailed, but if you know where to look it is faster than a GUI.
`docker image history` tells you how the image came to be, layer by layer. Which command created which layer, when, and how big that layer is. Useful for tracking down an image that has become unnecessarily large — usually there is an `apt-get install` without `clean` in between.
You share images through a registry, public or private. But sometimes you want to move an image to another machine without a network. `docker image save -o myapp.tar myapp:latest` packages the image, including all layers and tags, into a single tar file. On the other side, `docker image load -i myapp.tar` brings it back in. No registry needed, no internet, just a USB stick or an `scp` command.
Note the difference from `docker image import`. That reads a tarball of a filesystem and turns it into an image with a single layer. The original layer structure and history are gone. Import is for migrating existing environments, not for transferring your own images. For that, use save and load.
Tags are names, not versions. `docker image tag myapp:latest myapp:v1.2` changes nothing about the image; it only adds an alias. Two names pointing to the same image, with the same image ID. It is a convenient way to prepare an image for a registry without rebuilding it.
An image can serve multiple architectures at once through manifests. One name, multiple variants: `linux/amd64` for your server, `linux/arm64` for that Raspberry Pi. Docker automatically picks the right variant when you run `docker pull`. You no longer have to remember which architecture runs where.
The choice is not whether you use images, but how you build them. An image with everything on it is easy, but large and hard to maintain. An image with only the minimal runtime is faster and safer, but requires you to understand what your application needs. The balance between convenience and control is yours to decide, layer by layer.
Whatever you choose, the image is the only artifact that survives the journey from your laptop to the production server without changing along the way. That is not a luxury. That is the foundation on which you can trust that what runs there is also what you built.