The previous lesson gave you strong isolation at a high price: every virtual machine carries its own kernel, takes half a minute to start, occupies gigabytes on disk and reserves memory simply by existing. For a test environment that is reasonable. For deploying an application and being able to recreate it in seconds, it is extremely expensive.

This lesson builds the alternative, and it starts with the idea you have to be clear about before writing your first docker run, because getting it wrong conditions everything that comes after:

A container is not a small machine. It is an isolated process.

There is no operating system inside. There is no kernel. There is no boot. There is an ordinary host process, running with a restricted view of the filesystem, the network and the process table, and with a resource limit. Everything you will see — images, volumes, networks, Compose — is machinery built around that idea.

And you already know the three kernel pieces that make it possible, separately: cgroups are literally the ones behind the MemoryMax=512M you set in 05-05, capabilities are the ones from 05-02, and mount namespaces are the evolution of the chroot you used to repair GRUB in 07-01.

1. The three primitives: namespaces, cgroups and capabilities
2. User namespaces and the sysctl you left commented out
3. Installing Docker, and why the docker group is equivalent to root
4. Images, containers and registries
5. docker run and the options that matter
6. Dockerfile: building the Tramontana image
7. Multi-stage builds and choosing a base image
8. Data: volumes, bind mounts and tmpfs
9. Networking and publishing ports
10. Docker Compose
11. Container security
12. Alternatives, and when not to use containers

A container is not a kernel feature. There is no create_container() system call. It is a convention: a process launched with certain restrictions enabled all at once. Seeing that directly, with no Docker in the way, is what makes everything else fall into place.

A namespace isolates one class of global kernel resource, so that the processes inside it see their own instance of it. There are seven:

Every process shares the same namespaces, because there is no container running. Let us create one by hand, without Docker:

There is the effect: bash is PID 1 and sees only two processes. From the outside, that same process has an ordinary PID:

The process is the same. The only thing that changes is what it sees. And this explains why a container starts in milliseconds: there is nothing to start, only a clone() with a few flags.

The network namespace is especially illustrative, because the isolation is total:

No enp0s3, no IP, no routes, not a single socket. And lo is DOWN. That is the starting point of any Docker container before a virtual interface is attached to it.

In 07-01 you used chroot to enter an installed system and repair GRUB. chroot changes the root of the filesystem for a process — that is, it does part of what a mount namespace does.

But only that part, and that is why chroot is not a security mechanism:

A privileged process inside a chroot can escape from it fairly easily — there are known, documented techniques — and even if it did not escape, it has full access to the host's network, processes and devices. The mount namespace solves the escape; the other six namespaces solve the rest.

Namespaces control what a process sees; cgroups control what it consumes. And you have used this already:

It is exactly the same technology. When you set MemoryMax=512M in the systemd unit in 05-05, you were creating a cgroup with memory.max. Docker does the same thing with --memory 512m. The wrapper is what differs, not the mechanism.

From 05-02: instead of "root or not root", the kernel divides privileges into some forty independent capabilities.

This is what allows a container's main process to be "root" and still be unable to do almost anything dangerous: nearly all of its capabilities are taken away. Docker leaves about fourteen of the forty by default.

And with the three primitives together, you can now define what a container is with no magic involved:

A container is a process launched with namespaces of its own, inside a cgroup with limits, with a reduced set of capabilities, and with the root of the filesystem pointing at the image.

The user namespace is the most recent one and the one with the most security consequences. It allows a UID inside to map to a different UID outside:

Read that slowly, because it is counterintuitive: id says uid=0(root), but it cannot write to /etc. The uid_map explains why — UID 0 inside is UID 1000 outside. It is root of its own namespace and of nothing else.

That is what makes unprivileged (rootless) containers possible: an ordinary user can create namespaces, mount filesystems inside them and be root within their container, without being root on the host.

And now, the parameter you left commented out in 06-06:

The tension is real and it is worth understanding in both directions:

The decision for srv-tramontana: leave it enabled, because it is going to run containers. And here is the note added to the file, because the reasoning is what has to be documented:

A hardening measure ruled out with its reason written down is knowledge; ruled out in silence it is an omission.

Docker is not in the Ubuntu repositories at the current version, so it is installed from the official repository applying what you learned in 05-03: the key in /etc/apt/keyrings/ and signed-by.

Note that adding a third-party repository is a security decision, as was said in 05-03: from now on, whoever controls that repository can install packages on your server. signed-by restricts the key to that specific repository, which is the bare minimum you should demand.

That command turns up in every tutorial as a convenience, and its real implication is almost never explained:

Belonging to the docker group is equivalent to having root with no password, and without leaving the trail that sudo leaves.

That is not an exaggeration. The demonstration fits on one line:

The Docker daemon runs as root, and -v /:/host asks it to mount the host's root inside the container. Anybody in the docker group can read /etc/shadow, write to /etc/sudoers.d/, or modify /etc/tramontana/secrets/. And they do it without appearing in auth.log.

The practical consequences, which have to be applied:

1. The docker group is treated like the sudo group, with the same control over who joins it and why. On srv-tramontana only operator, and it is recorded in the 06-06 checklist.
2. It is never added to a service account or an application user. If svc-tramontana were in docker, a compromise of the application would be instant root.
3. The right alternative when several people are involved is sudo docker, with a rule in sudoers.d that records who runs what — consistent with what you did in 05-02 with deploy-safe.
4. Or use podman, which has no privileged daemon and solves the problem at the root. It is covered at the end of the lesson.

Three concepts that get confused and that are worth separating once and for all:

The most important property of an image is that it is made of layers, each one a set of changes on top of the previous one, identified by its cryptographic checksum:

Layers are shared between images: if ten images are based on alpine:3.20, those 7.8 MB are stored only once. It is the same idea as qcow2 backing files in 07-04, applied to the filesystem.

And the security implication of layers, which you have to keep in mind when writing a Dockerfile: a layer never disappears. If in one layer you copy a file containing a password and in the next one you delete it, the file is still in the image and can be extracted. We will come back to this.

And now the check that closes the first section. From the host:

The nginx process is in the host's process table, with an ordinary PID, and pgrep finds it. All it has is namespaces of its own and a cgroup. There is no machine, no kernel, no boot. It is a process.

The docker run options that actually get used:

The lifecycle management ones:

docker stop sends SIGTERM, waits 10 seconds and then sends SIGKILL — exactly the signal discipline from 03-06. If your application needs more time to shut down cleanly, --time 30.

A Dockerfile is an image's recipe. Every instruction that modifies the filesystem creates a layer.

The instructions, and what you need to know about each one:

Docker reuses a layer if the instruction and its context have not changed. As soon as one layer is invalidated, every one after it is rebuilt. Hence the rule:

Order the instructions from least to most frequently changing.

In the first version, changing one line of code forces every dependency to be downloaded again: minutes on every build. In the second, seconds.

And the other layer rule, the chaining one:

The rm in a later RUN does not reduce the size: the previous layer already contains the files, and layers are immutable. It is the same reason a secret that is copied and then deleted can still be extracted from the image.

.dockerignore matters for two reasons: speed — the whole context is sent to the daemon — and security, because without it a COPY . . can put the .git directory with the entire history into the image, or a .env with credentials.

19.4 MB. The comparison with a single-stage build explains where that comes from:

And the benefit is not only disk. The 850 MB image contains the Go compiler, git, make and dozens of libraries: every one of them is attack surface and a potential source of CVEs. The 19 MB one has none of that. It is the minimum-surface principle from 06-06 applied to an image.

The usual bases:

Alpine, which was mentioned in 01-03 when discussing distributions, has a peculiarity you need to know about: it uses musl instead of glibc. A binary compiled against glibc does not work on Alpine, and some applications — notably Python with native extensions — have subtle performance problems with musl's memory allocator. With Go and CGO_ENABLED=0 there is no problem, because the binary is static.

Distroless images go one step further: they have no shell, no ls, no package manager. An attacker who gains execution has nothing to work with. In exchange, debugging requires docker debug or a parallel image with tools in it.

A container's filesystem is ephemeral: when you delete it, the writable layer disappears. Data that has to survive is mounted from outside, and there are three ways of doing it:

That noexec,nosuid on the tmpfs is the same criterion you applied to /tmp in 06-06.

The preference for volumes over bind mounts when it comes to data has concrete reasons: Docker manages them (creation, permissions, backing them up with docker run --volumes-from), they are portable between hosts, and they do not depend on a specific path existing. Bind mounts are better for configuration — because you want to edit it from the host with your own tools — and for development.

And the permissions warning, which is the number one source of frustration with volumes: UIDs are numeric and they are not translated. A file owned by UID 997 on the host belongs to UID 997 inside the container, whatever that user happens to be called in there. That is why Tramontana's Dockerfile creates svc-tramontana with UID 997 and the group with GID 1002: so that they match the server.

The difference between the default bridge network and a user network is the one that decides the design:

That is what allows app.conf to say db_host=db instead of an IP that changes on every start. On the default bridge network it does not work.

And publishing ports, with an important security detail:

A serious warning: Docker writes nftables rules and bypasses ufw. A -p 8080:8080 inserts a rule into the DOCKER chain that is evaluated before ufw's, so the port is reachable from the Internet even though ufw status says it is blocked.

It can be checked, and it has to be checked:

The two solutions: always publish with 127.0.0.1: in front — which is the right thing when there is a reverse proxy in front, as there will be in 08-01 — or disable Docker's rule manipulation:

Careful: with "iptables": false the containers lose their route out to the Internet unless you write the NAT rules yourself. The practical option in most cases is the first one.

Note "log-driver": "journald" as well: it sends the containers' output to the journal, so journalctl and the logrotate from 05-06 apply to them too. By default, Docker writes to JSON files that grow without limit and are a common cause of full disks.

A compose.yaml describes the set of services, networks and volumes in one versionable file:

depends_on with condition: service_healthy is the piece that solves a real problem: without it, depends_on only waits for the container to exist, not for the service inside it to be ready. The application would start, fail to find the database and die. With the condition, Compose waits for the healthcheck.

That -v deserves the warning: docker compose down -v deletes the volumes, which is to say the database. It is an rm -rf under another name, and the discipline from 02-04 applies just the same.

A container's isolation is weaker than a VM's, so the measures matter more. The ones to apply always:

On secrets, here is the demonstration of why ENV is a bad idea:

It is exactly the problem you solved in 06-05 with LoadCredentialEncrypted. The Docker equivalent is the secrets section of compose.yaml, which mounts the file on a tmpfs inside the container:

And image scanning:

Notice a detail that illustrates the docker group warning: that command mounts /var/run/docker.sock inside a container, which gives it complete control of the Docker daemon and therefore of the host. You do it with images you trust, and knowing what it implies.

Two more measures that close the circle with earlier modules:

AppArmor's docker-default profile and the default seccomp filter block some forty dangerous system calls. Disabling them with --privileged or --security-opt seccomp=unconfined is what turns a container into a process with almost total access to the host, and --privileged must never appear in production.

Podman deserves attention for what it solves:

podman has no daemon: every container is a child process of whoever launched it. In rootless mode it uses user namespaces, so the docker group problem does not exist. Its commands are compatible (alias docker=podman works almost always) and it integrates with systemd by generating units, which fits well with everything from Module 5. For a server where several people run containers, it is the more defensible option.

LXC is different in concept: system containers, with a full init inside, several processes and sessions. It resembles a lightweight VM more than an isolated process.

The honesty that most guides are missing:

That fourth point applies to Tramontana right now: srv-tramontana works, it is hardened, monitored and documented. Containerising it today would add complexity without solving a single outstanding problem. Containers shine when there are several services, several environments or several servers — which is precisely the territory of the next two lessons.

• Thinking of a container as a small VM. It leads to putting systemd, sshd and cron inside, and to treating the container as a machine to be administered. A container runs one process and is replaced, not administered.
• Adding somebody to the docker group without understanding what it means. It is root with no password and no trace. Treat it like the sudo group.
• Using latest. The image changes without warning, and a rebuild next week does not produce the same thing. Pin the version, and in production the digest.
• Putting secrets in ENV or in a layer. They stay in the image for ever, even if you delete them afterwards: layers are immutable. Use secrets or a mounted file.
• Copying the code before the dependencies in the Dockerfile. It invalidates the cache on every change and turns a build of seconds into one of minutes.
• Using rm in a later RUN to reduce the size. It does not work: the previous layer already contains the files. Chain with && inside the same RUN.
• Forgetting .dockerignore. A COPY . . can put the whole of .git, or a .env with credentials, into the image.
• Running as root inside the container. It is the default and it is the first thing to change with USER.
• Publishing with -p 8080:8080 and believing ufw protects you. Docker writes rules that are evaluated first. Use -p 127.0.0.1:8080:8080 and verify it from outside with nmap.
• Leaving the default logging driver. The JSON files grow without limit. "log-driver": "journald" integrates them with journalctl and logrotate.
• Running docker compose down -v without thinking. It deletes the volumes, which is to say the data.
• Reaching for --privileged "to make it work". It disables seccomp, AppArmor and the capabilities in one go. Never in production; find the specific capability that is missing.
• A tip on method. A container must be able to die and be reborn without anything being lost. If yours has state inside its writable layer, something is mounted wrong: everything that matters goes in a volume.

Demonstrate, without using Docker, that a container is an isolated process. Create a "container" by hand with unshare that has its own machine name, its own process table and its own network, and check from the host that it is still an ordinary process. Explain what your construction is missing in order to be a real container.

Review this Dockerfile that Luis has written and correct it, explaining every problem:

Marta asks whether it would be worth migrating Tramontana Bookings to containers. Write the analysis, taking into account the server's real state and what has been covered in the last two lessons.

Solution 1

First you need a minimal root, which is exactly what an image provides:

And now, inside:

A name of its own, PID 1, two visible processes, no network, and a different distribution from the host's — all without starting a single kernel.

The line NSpid: 10415 1 is the exact demonstration: the same process has PID 10415 on the host and PID 1 inside its namespace. And uname -r gives the same kernel on both sides:

What it is missing in order to be a real container:

The conclusion the exercise asks for: Docker contributes no new primitive. The isolation has been in the kernel for over a decade. What it contributes is the packaging: an image format with shared layers, a registry to publish them to, a reproducible way of building them, and the consistent application of the eight restrictions in the table, which by hand would be a long script that is easy to get wrong. Understanding this explains why compatible alternatives such as podman exist: if the primitives belong to the kernel, anybody can orchestrate them.

Solution 2

Eleven problems. The corrected version first, and then the reason for each one:

And the .dockerignore that was missing entirely:

The eleven problems, in order of severity:

The measured result:

684 MB against 142, and the password recoverable with a single command by anybody who has access to the image.

The note Luis has to be given: the password that appears in that Dockerfile is the production one, so — following the rule from 06-05 — it is considered compromised from the moment it was written, and it has to be rotated with the create-apply-verify-retire procedure. Correcting the file is not enough.

Solution 3

Analysis: migrating Tramontana Bookings to containers To: Marta Vidal · From: Systems Operations · 18 August 2026

Short recommendation: not yet, but do prepare for it. Containerising srv-tramontana today would add complexity without solving a single outstanding problem. I propose an intermediate path with immediate benefit and no risk.

---

The starting point matters. This is not an application that was deployed any old how. srv-tramontana has atomic deployment with automatic rollback, a hardened systemd service with the best security score the tool gives, encrypted secrets, logs centralised in the journal with rotation, backups with restoration tested, change detection and an allowlist firewall. It works, it is documented and it is measured. That is the benchmark to compare against.

What we would gain

1. Deployments reproducible bit for bit. Today deploy.sh moves a symbolic link to a new directory, and the environment — system libraries, versions — is whatever happens to be on the machine. With an image, what you test is exactly what you deploy. Remember that release 3.3.0 failed in July and we did not know why until this week: a failure of that kind is less likely with images, because the environment travels with the application.
2. An even faster rollback. Going back to the previous image means changing a tag.
3. Parity between environments. The same image in testing and in production, without the drift that appears when two machines are configured separately.
4. Additional isolation of the application. A compromise would be better contained: no useful shell, no access to the rest of the filesystem, no capabilities.
5. Readiness to grow. If at some point two or three instances behind a load balancer are needed, with containers it is a matter of minutes.

What it would cost

1. Redoing work that is already done and validated. The systemd hardening, the AppArmor profile, the secrets management and the journal integration would all have to be rebuilt with the container equivalent. It is not impossible, but it is weeks of work to arrive where we already are.
2. One more layer to learn and maintain. Images, registries, virtual networks, volumes, and their own failure modes — which are different from and less familiar than the system's.
3. A new and specific security risk. The Docker daemon runs as root, and belonging to the docker group is equivalent to having root with no trace left behind. On top of that, Docker writes firewall rules that bypass ufw: a published port is left open even though the firewall says otherwise. I have verified this in the lab. It would have to be managed explicitly.
4. The database is the difficult part. PostgreSQL in a container is possible, but persistent storage adds complexity and contributes nothing on a single server. My recommendation would be to leave it outside in any case.
5. It does not solve our real problem. Our open problem is that srv-tramontana is a single point of failure. Containers do not solve it: if the machine goes down, the containers go down with it. That is redundancy, and it is the subject I will be bringing you a proposal on.

---

What I propose, in three steps

Step 1 — Now: containerise the test environment only. Immediate benefit, zero risk. It lets us bring up the application and a clean database in seconds to test a change, and learn the tool without exposing production. It is already working on srv-tramontana-test.

Step 2 — Next: build the image on every release, without deploying it. Each version additionally produces a versioned and scanned image. We gain reproducibility and vulnerability detection in the dependencies, without changing anything in production. It is a reversible step.

Step 3 — When one of the conditions is met: migrate. The conditions that would justify it:

Condition	Why it changes the decision
Two or more instances of the application are needed	That is where containers really start to pay off
More services appear (an API, a task processor)	Managing five services by hand is where Compose wins
There is more than one environment to keep in sync	Parity stops being a luxury
We have another failure caused by environment differences	It would be the second time; once is coincidence

And an observation about the alternative. If we take the step, I propose evaluating podman instead of Docker: it has no privileged daemon, it works without root, it solves the docker group problem at the root, and it integrates with systemd by generating units — that is, it fits with everything we already have in place rather than replacing it. Its commands are compatible, so nothing that has been learned is lost.

Summary. Containers are the right answer to a problem of scale and reproducibility between environments. Today we have one server, one environment and an application that works, so the benefit does not justify the cost. We start with testing and with building the images, which is where the benefit is immediate, and we reassess when one of the conditions in the table changes.

You have the right idea, which is the most valuable thing in this lesson: a container is an isolated process, not a small machine. You have seen it with no intermediaries — a bash that is PID 1 inside and has an ordinary PID outside, with NSpid: 10415 1 in /proc as proof — and you know that Docker invents no primitive: namespaces, cgroups and capabilities are in the kernel, and they are literally the same ones as the MemoryMax=512M from 05-05 and the chroot from 07-01. What Docker contributes is the packaging: layered images with shared layers, a registry, reproducible builds, and the consistent application of eight restrictions that by hand would be a long and fragile script.

You know how to build an image that weighs 19 MB instead of 850, ordering the instructions to take advantage of the cache and using two stages so that the compiler never reaches production — which is the minimum-surface principle from 06-06 applied to an image. You know that a secret in a layer is never deleted, that -p 8080:8080 bypasses ufw and has to be verified from outside with nmap, that USER is not optional, and that docker compose down -v destroys the data. And you have resolved the kernel.unprivileged_userns_clone you left commented out in 06-06: it stays enabled, with the decision and its reason written down, because the containment that containers provide is worth more than the surface it would close.

Notice now where you stand. You have srv-tramontana in production, srv-tramontana-test recreatable with cloud-init, and containers that bring up the application and its database with one command. Three ways of creating machines and services. And all three share a problem: the production configuration is still a runbook in prose plus the administrator's memory. Every user, every sudoers rule, every systemd unit, every ufw line, every sysctl and every AppArmor profile from Modules 5 and 6 was applied by hand. The 8-hour RTO that Marta approved depends entirely on somebody remembering the right order, and the rule from 06-04 — "a compromised server is reinstalled, not cleaned" — is easy to say and expensive to honour.

In lesson 07-06: Automation with Ansible that becomes code. You will see the difference between an imperative script such as deploy.sh and an idempotent desired state, you will understand why Ansible needs no agent — it works over the SSH you hardened in 06-02 — and you will write inventories, playbooks with handlers and tags, Jinja2 templates that generate app.conf with per-environment variables, and roles that organise the whole thing into reusable pieces. You will use --check and --diff, which are the course's --dry-run taken to the entire configuration, you will keep the secrets in Vault alongside your pass, and you will test every change against srv-tramontana-test before touching production. And at the end you will take the measurement that matters: how long the server takes to be rebuilt from scratch. That number — from eight hours to under one — is what turns a security rule into a procedure that can genuinely be followed.