Docker solves building and running containers. Everything else — seeing what is going on without diving into docker ps, knowing why an image is heavier than it should be, catching vulnerabilities before publishing, running your own registry, testing against a real database — is solved by the ecosystem around it. This lesson is not a catalog: it is the equipment selected with judgment, plus the judgment for selecting it yourself.

1. The three levels of extensibility
2. Build your own docker aurora
3. Daemon plugins and desktop extensions
4. Management interfaces
5. Image inspection and optimization
6. Security
7. Private registries
8. Development and testing
9. Building without a Dockerfile
10. Cleanup and maintenance
11. Networking and diagnostics
12. Criteria for adopting a tool
13. The recommended minimum kit

The rule that follows: experiment freely at the CLI level, be conservative at the daemon level. A badly written logging plugin blocks the startup of every container on the host.

The CLI plugin mechanism is astonishingly simple: any executable called docker-something in ~/.docker/cli-plugins/ becomes docker something. That is how docker compose, docker buildx and docker scout work. The only formal requirement is answering the hidden docker-cli-plugin-metadata subcommand.

Forty lines and the whole team stops memorizing long commands. Keep it in the repository with a make install-plugin and it becomes part of onboarding. The asterisk in the help output means it is a plugin, not a native command.

Daemon plugins extend Docker from underneath. You install them with docker plugin install and manage them separately:

The serious warning: a logging plugin that hangs can stop containers from starting at all, because the daemon waits for it to accept the stream. Before putting it into production, test it with the destination deliberately down and check that mode: non-blocking is configured.

Docker Desktop extensions are containers with a user interface that plug into the dashboard. Convenient, and with the same caution as any third-party code with access to the daemon socket: whoever controls the socket controls the host (05-03).

With the Aurora Libros stack up, lazydocker gives you all four containers on a single screen, with their live logs and their resource usage, and it lets you restart aurora-api with one keystroke. For local debugging it is faster than any GUI.

Portainer is only justified when there are several people operating several hosts and per-user permissions are needed. For one server and a small team on Compose, Dockge is lighter and does not hide the YAML: you still have your files and you edit them from the browser.

A caution common to all of them: they expose the Docker socket. Portainer or Dockge reachable from the Internet without strong authentication is the same as handing over the host.

That 98 % is the result of the work from 05-04: the multi-stage build left the compilation dependencies out and there are no duplicated files across layers. In integration mode, dive returns a non-zero exit code if the project drops below the threshold, and that plugs straight into the pipeline:

About slim: it slims images down automatically by running the application and keeping only what it touched. It can take a 400 MB image down to 30 MB, and it can also break it silently the day a code path that was not exercised during the analysis gets executed. Use it with a complete test suite behind it, and always prefer fixing the Dockerfile if you have access to it.

hadolint is the cheapest to adopt and the one that prevents the most problems, because it acts before anything gets built. Against an early version of the API's Dockerfile:

Six warnings that are exactly the syllabus of modules 2 and 5: pin the base image, clean up package caches, pin versions, use COPY instead of ADD, do not finish as root, and quote variables in RUN. Against the current Dockerfile of aurora-api:2.0.0 not one of them appears, because the base is pinned by digest and the final USER is not root. Integrating it costs four lines:

Falco covers the gap nobody else covers: the others analyze artifacts sitting still; Falco watches live syscalls and alerts when a container does something it should not — opening a shell inside aurora-api, writing to /etc, connecting to an unknown IP. It is the last line of defense when the vulnerability was not in any database.

About the first three in the table: you do not have to pick just one. Trivy in the pipeline as the gate that fails the build, Scout on the desktop for the early check, and Grype as a second opinion when a result is surprising. Each scanner uses different sources and they do not always agree.

One use that almost always pays off and that almost nobody sets up: a Docker Hub mirror on the local network. It saves bandwidth, dodges pull rate limits and keeps the pipeline working when Hub is having a bad afternoon.

Harbor is only justified when there are several teams, retention policies, cross-region replication and a need for auditing. It is a platform with a database, Redis and several components: somebody has to maintain it.

Testcontainers is the one that changes your life the most and the one fewest people know about. In 06-02 you set up PostgreSQL and Redis services in the CI workflow; Testcontainers makes the test itself bring them up, so the tests run identically on your laptop and in the pipeline with no duplicated configuration:

The second test is what justifies the tool: checking that cache-aside returns source: cache requires a real Redis. With a test double you would have validated your own mock-up, not the real behavior. Testcontainers needs an accessible daemon; in CI you already have one, and it works just the same against Podman with the compatible socket (07-05).

Tilt and Skaffold solve a different problem: when you develop against a cluster, the build-push-deploy cycle takes minutes. Both cut it down to seconds by syncing files inside the Pod. They only pay off if your inner loop is Kubernetes; if you develop with docker compose watch (04-07), you do not need them.

There is the trade-off in a single line. Buildpacks saves you writing and maintaining the Dockerfile, and in exchange it produces an image four times bigger. When does it pay off?

For Aurora Libros, with a well-optimized, multi-architecture, signed image, it does not pay off. For an internal platform with forty microservices, it probably does.

The disk fills up on its own. Automate it before an alert wakes you up:

The until filter is the difference between a safe cleanup and a full pull the following morning. And the comment line is the most important one in the script.

netshoot is an image with every networking tool that your production images, quite rightly, do not carry: dig, curl, tcpdump, ss, iperf3, nmap.

The second form is the powerful one: --network container: shares the network namespace of aurora-api (05-07), so you see exactly its connections and its ports without installing anything inside it or modifying the image. It is the same thing docker debug does, with a public image and no subscription.

dockviz draws the image and container tree; useful for making sense of a legacy host with forty images of unknown origin.

Two golden rules. First: the closer to the pipeline, the more demanding you should be. A local TUI that gets abandoned is replaced in five minutes; a plugin that signs your images and stops receiving patches is a security problem and a deployment problem at the same time. Second: validate with your security lead any tool that enters the build chain or that needs the daemon socket, and check its license with whoever is responsible before integrating it into a commercial product. Adding a dependency to the pipeline is an architectural decision, not a personal preference.

If you could only adopt three for the rest of your career: hadolint (it prevents mistakes before you build), Trivy (it stops you publishing something vulnerable) and Testcontainers (it makes your tests mean something). All three are open source, maintained, and they tie nobody down.

• Exposing Portainer or Dockge to the Internet. They control the daemon socket: whoever gets in is root on the host. VPN or internal network, always, and with strong authentication.
• Installing a logging plugin without testing what happens when the destination fails. If the destination does not answer and the mode is blocking, containers do not start. Test with Loki deliberately down.
• Trusting slim alone. It slims down by observing one run; what was not executed disappears. Without a complete test suite behind it, it is a time bomb.
• Piling up three scanners that say the same thing. One as the pipeline gate, another as an occasional second opinion. Any more only generates noise nobody reads.
• Adding --volumes to the scheduled cleanup. It is the fastest way to lose aurora-data on a Sunday night.
• Adopting a tool because it showed up at a conference. Apply the table from §12 first: maintenance, license, criticality and exit cost.
• Tip: put hadolint in the pipeline today. It costs four lines and prevents half a dozen bad practices per Dockerfile.
• Tip: keep the docker aurora plugin in the repository. Team shortcuts stop living in everybody's individual bash history.
• Tip: learn netshoot with --network container:. It solves 90 % of network debugging without touching the image.

Exercise 1 — Extend docker aurora. Start from the plugin in §2 and add three subcommands: scan, which runs Trivy against the local API image and fails if there are critical vulnerabilities; weigh, which shows the image size and runs dive --ci with a 95 % efficiency threshold; and net, which launches netshoot in the network namespace of aurora-api and checks that it resolves aurora-db and reaches aurora-cache. The plugin must keep working with nothing installed beyond Docker.

Exercise 2 — Linting and fixing a Dockerfile. Deliberately write a bad Dockerfile for aurora-api (untagged base, apt-get without cleanup, ADD instead of COPY, npm install with no pinned version, no USER), run hadolint over it and note every warning code. Fix them one by one until the lint comes out clean, explaining in a comment which real problem each fix prevents. Then add the check to the pipeline with a warning threshold.

Exercise 3 — Adoption assessment. A colleague proposes adding a tool to the pipeline that automatically optimizes images before publishing them. It is published by an individual developer on Docker Hub, it has 900 stars on GitHub, the last commit is eleven months old and the image is not signed. Apply the criteria table from §12 and write a reasoned answer: your recommendation, the three concrete risks you identify, and what conditions would have to be met for you to accept it.

Solution 1.

Three decisions matter more than the rest. Mounting the socket is essential because both Trivy and dive inspect local images from the daemon, not remote ones; mounting ~/.cache/trivy avoids downloading the entire vulnerability database on every run, which is what makes the first run take a minute and the following ones three seconds. The --exit-code 1 turns the scan into a gate: without it, Trivy reports and returns 0, and the pipeline would pass with critical vulnerabilities. And --ignore-unfixed avoids the noise of flaws with no patch available yet, which you cannot act on. In net, --network container:aurora-api enters the real container's network namespace (05-07), so what you see is its DNS resolution and its connections, not those of some arbitrary network.

Solution 2. The bad Dockerfile and the codes it triggers:

The fixed version:

The most underestimated warning is DL3025: with CMD npm start, PID 1 is a shell that does not forward SIGTERM, and all the graceful shutdown you built in 06-01 stops working without a single test noticing. It shows up as requests cut off during deployments, and it takes days to find if you do not know where to look.

Solution 3. Recommendation: do not adopt it in the pipeline in its current state.

The three concrete risks: (1) supply chain — an unsigned image from an anonymous author, running in CI with access to your images and probably to the socket, is exactly the vector that Cosign and the attestations from 06-02 were brought in to close; (2) silent breakage, because an automatic optimization can remove a file that is only used on an infrequent code path, and you would find out in production; (3) abandonment, since eleven months without commits in a tool that touches the final artifact means that the day it breaks with a new version of BuildKit, deployment stops and the fix is yours.

Conditions for accepting it: that it runs off the critical path, as a comparative report and not as a step that modifies the published image; that the image is signed and pinned by digest; that there is an integration test suite that validates the optimized image before publishing it; and that the security lead validates the license and the provenance. A reasonable counter-proposal: your colleague's goal — smaller images — is already covered by the multi-stage build and dive --ci with a threshold, which are part of the pipeline, do not depend on third parties, and already give 98 % efficiency on aurora-api:2.0.0. The conversation is not "no", it is "this problem is already solved".

You now have the equipment that surrounds Docker and, more importantly, the judgment to choose it. You understand the three levels of extensibility and their asymmetry of risk: at the CLI level experiment freely, at the daemon level be conservative, because a blocked logging plugin stops containers from starting. And you have built your own docker aurora in forty lines of bash, discovering that the mechanism behind docker compose and docker buildx is simply an executable on the PATH that answers docker-cli-plugin-metadata.

From the tour through the categories you take away a selection, not a catalog: lazydocker and ctop for seeing the fleet without typing, Portainer only when there are several people and several hosts, Dockge when what you manage is Compose stacks; dive confirming the 98 % efficiency you earned in 05-04 and acting as a CI gate with --ci --lowestEfficiency, container-diff for auditing what changed between versions and slim with its serious warning; hadolint pointing out, in six messages, the entire syllabus of modules 2 and 5 — including the DL3025 that breaks graceful shutdown without any test noticing — Trivy as the gate, Scout as the early check and Falco watching syscalls when the vulnerability was not in any database; the Docker Hub mirror with registry:2 that almost nobody sets up and that almost always pays off; Testcontainers bringing up PostgreSQL and Redis from the test itself to check that cache-aside really does return source: cache; Buildpacks with its measured trade-off — 412 MB against your 104 — and the table of when not writing a Dockerfile pays off; scheduled cleanup with until and without --volumes; and netshoot with --network container: entering the network namespace of aurora-api without touching the image.

And you take away the adoption criteria, which are worth more than any list of tools: active maintenance, a compatible license, verifiable provenance, criticality in the pipeline, real understanding by the team, exit cost and added attack surface. With the two golden rules: the closer to the pipeline, the more demanding you should be, and validate with your security lead — and with whoever handles licensing — any tool that enters the build chain or asks for the daemon socket. If you had to keep three for the rest of your career: hadolint, Trivy and Testcontainers.

In the next lesson we take a fundamental step back: Podman, containerd and the OCI standard. You are going to discover why the images you have been building all course long are not "Docker images", what exactly the Open Container Initiative standardizes, and how ghcr.io/auroralibros/aurora-api:2.0.0 runs identically on Podman, on containerd or on a Kubernetes node without changing a single byte.