Forem: Docker

Seven Docker Tips Every Engineer Should Know (from Docker Captains)

Mohammad-Ali A'RÂBI — Mon, 25 May 2026 07:25:00 +0000

Between June and August 2025, Docker shared a short series of practical tips from Docker Captains on Twitter/X. The format was brief, but the advice is worth unpacking. This post is revisiting those seven tips with a little more context and newer examples.

Here are the seven tips, in the chronological order they were shared!

1. Start New Projects with Docker Init

Captain intro: Mohammad-Ali A'rabi is a Docker Captain from Freiburg, Germany, a backend software engineer, Docker community leader, and the author of Docker and Kubernetes Security. His work often sits at the intersection of practical engineering, education, community, and secure-by-default container workflows.

// Detect dark theme var iframe = document.getElementById('tweet-1934618217990754462-547'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1934618217990754462&theme=dark" }

The tweet points to docker init as the fastest way to get a clean Docker setup for a new project:

docker init

The command analyzes your project and generates a set of files that follow Docker's best practices:

Dockerfile
.dockerignore
compose.yaml
README.Docker.md

Read the following article for a detailed walkthrough of docker init with a Java project: Dockerize Java 26 with Docker Init.

2. Clean Up Docker Disk Usage Carefully

Captain intro: Rafael Pazini is a Docker Captain from Sao Paulo, Brazil, and a Senior Software Engineer at Pluto TV. He has more than 10 years of experience building scalable applications, with expertise in distributed systems, microservices, Docker, and Kubernetes.

// Detect dark theme var iframe = document.getElementById('tweet-1937229925515252098-27'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1937229925515252098&theme=dark" }

The command docker system prune is no stranger to Docker users:

docker system prune -a --volumes

The terminal will say:

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all dangling images
  - unused build cache

Are you sure you want to continue? [y/N]

BTW, did you know [y/N] means "default to No if the user just presses Enter"?

The -a flag removes all unused images, not just dangling ones. The --volumes flag adds unused volumes to the cleanup list. Check it out, and the warning verifies it:

WARNING! This will remove:
  - all stopped containers
  - all networks not used by at least one container
  - all anonymous volumes not used by at least one container
  - all images without at least one container associated to them
  - all build cache

Are you sure you want to continue? [y/N]

A few more handy commands:

docker rmi -f $(docker images -q)  # Force-remove all images
docker volume rm $(docker volume ls -q)  # Remove all volumes

Satisfaction!

3. Use Multi-Stage Builds

Captain intro: Karan Verma is a Docker Captain from Jalandhar, India. He is a software engineer and community leader who has been active in the Docker community in Jalandhar since 2017, with a focus that includes AI and MLOps.

// Detect dark theme var iframe = document.getElementById('tweet-1939768473887916538-62'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1939768473887916538&theme=dark" }

It's not only AI images that can get big. It's better to trim images down, AI or not. It's cost-effective, faster to deploy, and more secure by reducing the attack surface. Multi-stage builds are the way to go for that.

To add to that, docker init already generates a multi-stage Dockerfile for you.

Also, make sure the final stage is hardened with a non-root user and limited privileges. For example, use a base image with no package manager, no shell, and no extra tools.

Another important tip is to generate SBOM attestations during the build:

docker build --sbom=true -t my-image:latest .

This command doesn't automatically include all stages in the SBOM, so you need to add the following line to each stage in your Dockerfile to ensure they are included:

ARG BUILDKIT_SBOM_SCAN_CONTEXT=true
FROM <image> AS stage

4. Choose Lightweight, Version-Pinned Base Images

Captain intro: Sergio Lopes is a Docker Captain from Sao Paulo, Brazil, and a Principal Backend Engineer at Banco Itau Unibanco S.A. Docker highlights his long backend engineering background and expertise in developer productivity, Kubernetes, modern application development, and observability.

// Detect dark theme var iframe = document.getElementById('tweet-1944758785475498198-694'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1944758785475498198&theme=dark" }

This tweet is from July 2025, but the advice is evergreen. Use Docker Hardened Images (DHI) for base images, and pin to a specific version. The DHI are:

Lightweight
Open-source
Secure-by-default

Check the catalog at dhi.io and pick the right image for your language and use case. Search for "node", get into the Node.js image catalog:

Then go to the "Images" tab to see the full list:

In the list of images:

If there is a lock, it's not free to use. Just skip it.
There are Debian and Alpine variants.
There are "dev" variants with build tools and "prod" variants without them.

Find a version, and your Dockerfile should start like this:

# The build stage
FROM dhi.io/node:26.2.0-debian13-dev AS build

# The production stage
FROM dhi.io/node:26.2.0-debian13

The dev image has 10 CVEs and the prod image has 0.

5. Use Docker Scout Quickview

Captain intro: Khushboo Verma is a Docker Captain and Platform Engineer at Appwrite in Bengaluru, India. She is also a community builder and speaker, with Docker listing her expertise in developer productivity, modern application development, and observability.

// Detect dark theme var iframe = document.getElementById('tweet-1947370272115290448-318'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1947370272115290448&theme=dark" }

The docker scout quickview command is a fast way to get a snapshot of your image's security posture. It checks for known CVEs, lists dependencies, and provides metadata about the base image. This is especially useful in CI pipelines to catch vulnerabilities before pushing images to a registry.

Let's do it on the DHI Node.js image:

docker scout quickview dhi.io/node:26.2.0-debian13

The output says:

    i New version 1.21.0 available (installed version is 1.20.3) at https://github.com/docker/scout-cli
    ✓ SBOM obtained from attestation, 20 packages found
    ✓ Provenance obtained from attestation
    ✓ VEX statements obtained from attestation

    i Base image was auto-detected. To get more accurate results, build images with max-mode provenance attestations.
      Review docs.docker.com ↗ for more information.

 Target   │  dhi.io/node:26.2.0-debian13  │    0C     0H     0M     0L
   digest │  f3fb2a06abd6                 │

So, there are no CVEs, and the image has:

SBOM attestation with 20 packages
Provenance attestation
VEX statements attestation

If you want to learn more about these concepts, check out the Docker Commandos workshop on Docker Labspaces: Docker Commandos.

6. Use .dockerignore

Captain intro: Anjan Kumar Reddy Ayyadapu is a Docker Captain and Senior Architect Solution Leader at Cloudera Inc. Docker lists his expertise across AI/ML, CI/CD, Kubernetes, observability, developer productivity, and software secure supply chain work.

// Detect dark theme var iframe = document.getElementById('tweet-1950295464433025395-539'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1950295464433025395&theme=dark" }

The tweet compares .dockerignore to .gitignore, which is exactly the right mental model. .gitignore decides what should not enter version control; .dockerignore decides what should not enter the Docker build context.

Two points on that!

When doing a docker build command, it usually looks like this:

docker build -t my-image:latest .

The . at the end is not the Dockerfile path; it's the build context path. It means, "send the current directory and all its contents to the Docker daemon for the build".

Anjan says blacklist some files with .dockerignore, I would say whitelist some files with .dockerignore. Start with a clean slate, and add only what you need. For example:

# .dockerignore
*

!src/
!package.json
!package-lock.json

7. Limit Container Privileges

Captain intro: Mohammad-Ali A'rabi appears again in Docker's series, this time with a security tip. It's not me promoting myself, it's Docker!

// Detect dark theme var iframe = document.getElementById('tweet-1953561787623788652-733'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1953561787623788652&theme=dark" }

Just for context: Linux capabilities are granular permissions that can be independently enabled or disabled for processes. Similar to the whitelisting approach of .dockerignore, you can start with a clean slate by dropping all capabilities and then adding only the ones your application needs. For example:

docker run --cap-drop=ALL --cap-add=NET_ADMIN my-image:latest

It's similar in a Kubernetes pod spec:

apiVersion: v1
kind: Pod
metadata:
  name: my-pod
spec:
  containers:
    - name: my-container
      image: my-image:latest
      securityContext:
        capabilities:
          drop: ["ALL"]
          add: ["NET_ADMIN"]

To learn more about Linux capabilities and how to use them in Docker and Kubernetes, check out the book Docker and Kubernetes Security.

Conclusion

I wish Docker starts sharing more tips from Docker Captains, and I hope this post helps expand on the original tweets with more context and examples. If you have any questions or want to share your own Docker tips, feel free to reach out on LinkedIn or Twitter/X.

Happy Dockerizing!

Book Review: Operational AI with Docker

Mohammad-Ali A'RÂBI — Wed, 20 May 2026 07:32:00 +0000

In my Q1 2026 Docker Read List, I dropped a little hint that I was involved in reviewing an exciting upcoming book for Q2. Well, the secret is finally out! I had the absolute honor of being a technical reviewer for Operational AI with Docker, written by my friends and fellow experts Ajeet Singh Raina and Harsh Manvar.

The Complete Docker Read List: Q1 2026 Edition - Docker and Kubernetes Security - Docker and Kubernetes Security

A curated reading list of the best books on Docker and Kubernetes for the first quarter of 2026, featuring releases from Docker Captains and industry experts.

dockersecurity.io

I love a good narrative in my technical books. The authors definitely brought some drama to the text, which I absolutely loved about this book. I had the chance to review the last four chapters of the book, and would love to share some exclusive behind-the-scenes insights about the book, as well as my thoughts on it.

Authors

Well, the authors need no introduction, but I'll still give you one.

Ajeet Singh Raina was a Docker Captain for six years until he was hired by Docker as a Developer Advocate. He was my first point of contact when I started my journey in the Docker community, and we published three blog posts together on the Docker blog. He is an absolute legend, the man behind the Collabnix Community, and a great mentor to many in the container ecosystem.

Harsh Manvar is a Senior Software Engineer at Oracle, a Docker Captain, and a CNCF Ambassador. Similarly, he is also an absolute star in the Indian container ecosystem, and has been a great mentor to many in the community. I had the pleasure of meeting him in person at the Docker Captains Summit in 2025, when he shared with me his plans for the book, and I was immediately excited about it.

The Book's Final Act: From MCP to KAgent

Chapter 6. The authors introduced the Docker MCP Gateway flawlessly. Before getting into the details, they did a great job of setting the stage by showing exactly why we need a gateway, and why it is painful to connect different MCP servers directly. It's great that the authors let you feel the pain, instead of just telling you about it.
Chapters 7 and 8. These chapters dive heavily into using AI agents and orchestrating multiple AI agents using Python. The chapters are packed with multiple examples and Docker Compose projects. The chapters might feel a bit overwhelming or tedious for readers, but it perfectly shows how one can use AI agents in a real-world scenario, and create a complex system that can solve a problem end-to-end. These two chapters are practically every Hollywood movie 70 minutes in, when it feels we're at impossible odds, and there is no way out.
Chapter 9. The grand finale covers Docker Sandboxes, Docker Agent, and KAgent. Let me tell you, this is an awesome way to end the book. It suddenly becomes clear that any pain we had to endure in Chapter 8 was entirely intentional: it was just to make the out-of-the-box experience of Docker Agent and KAgent shine! Suddenly eagles come and Frodo is on his way to Valinor!

Final Thoughts

The book is purely practical, impossibly fresh, and skillfully dramatic. It teaches you the basics and the advanced features of Docker MCP, Docker Agent, and KAgent. It lets you feel the pain and the joy of better tools. It is a must-read for anyone interested in the future of AI and how it can be operationalized using Docker. It's a great read, sometimes a bit overwhelming, but always rewarding. You need it in your library, and you need to read it.

Generating SBOM with Docker Scout

Mohammad-Ali A'RÂBI — Thu, 23 Apr 2026 18:40:34 +0000

Knowing what's inside your container is the first step to securing it. In the first commando mission, we dockerized a Java 26 project using Docker Init. Now that we have an image, it's time to see what's actually in it.

The Mission: Who Lives in Asgard?

Rothütle, the tactician of the Docker Commandos, asks Thor for a list of all Asgard residents. Why? Because you can't defend a city if you don't know who's inside. By getting this list, you can later cross-reference it with known threats and identify the shadows in disguise.

Technical Requirements

Docker Desktop that is not too old, or
Docker Scout CLI plugin installed.

To make sure you have the Docker Scout plugin, run:

docker scout --help

Generate the SBOM

We'll use docker scout sbom to peek inside our image. If you followed the previous post, you have an image built from your project. Let's assume you tagged it hello-wowlrd:latest.

docker scout sbom hello-wowlrd:latest --format list

The --format list flag gives you a clean table of all the packages, their versions, and types (e.g., deb, maven).

Exporting to Standard Formats

While a table is great for humans, tools prefer standard formats like SPDX or CycloneDX. Let's export our SBOM to a JSON file using the SPDX format:

docker scout sbom hello-wowlrd:latest --format spdx --output sbom.spdx.json

If you investigate the file, you will see a detailed inventory:

jq . sbom.spdx.json | less

This file contains every package, its version, and its license—perfect for compliance and automated scanning. You can check available formats by running docker scout sbom --help. Try exporting in CycloneDX format and compare it with the SPDX output!

Exercise: Comparing Base Images

One of the best ways to understand the value of an SBOM is to compare different base images. For example, let's look at the difference between a standard Node.js image and its Alpine counterpart:

docker scout sbom node:25 --format list

Versus:

docker scout sbom node:25-alpine --format list

You'll notice that the Alpine version is significantly smaller, with fewer packages. This is why "minimal base images" are a core tenet of container security—fewer residents mean fewer places for CVE monsters to hide.

What's Next?

Now that we have our list of residents, the next mission is to find the monsters. In the next post, we'll use Docker Scout to scan for CVEs.

Want the full mission? Visit Docker Commandos or request a workshop.

Dockerizing a Java 26 Project with Docker Init

Mohammad-Ali A'RÂBI — Tue, 31 Mar 2026 13:56:57 +0000

Docker Init was introduced in Docker Desktop 4.27, before LLMs became the default answer to everything. It's a "smart" interactive wizard that analyzes your project and generates:

A Dockerfile (multi-stage, production-ready)
A compose.yaml file
A .dockerignore file
A README.Docker.md with build and run instructions

What makes it valuable is that it's deterministic—not a probabilistic guess. It produces the same correct output every time, following Docker's own best practices.

Technical Requirements

Docker Desktop 4.27 or later

Create a New Project

I'm using a Spring Boot project. Because it's early Spring now and I haven't touched one in a while—so let's go.

Head to start.spring.io and create a project with:

Project: Maven
Language: Java
Spring Boot: 4.0.5 (or whatever the latest stable is)
Packaging: Jar
Java: 26

I used these coordinates, but pick your own:

Group: io.dockersecurity
Artifact: hello-wowlrd
Package Name: io.dockersecurity.hello-wowlrd

Download, unzip, and step into the directory:

cd hello-wowlrd

Run Docker Init

As my British friend say, "It's Docker, innit?"

docker init

The interactive wizard detects your Java project automatically. Accept "Java", confirm the source directory and Java version, and enter the port:

? What application platform does your project use? Java
? What's the relative directory (with a leading .) for your app? ./src
? What version of Java do you want to use? 26
? What port does your server listen on? 8080

Docker Init generates four files. The one that matters most is the Dockerfile:

# syntax=docker/dockerfile:1

################################################################################
# Stage 1: resolve and download dependencies
FROM eclipse-temurin:26-jdk-jammy as deps

WORKDIR /build

COPY --chmod=0755 mvnw mvnw
COPY .mvn/ .mvn/

RUN --mount=type=bind,source=pom.xml,target=pom.xml \
    --mount=type=cache,target=/root/.m2 ./mvnw dependency:go-offline -DskipTests

################################################################################
# Stage 2: build the application
FROM deps as package

WORKDIR /build

COPY ./src src/
RUN --mount=type=bind,source=pom.xml,target=pom.xml \
    --mount=type=cache,target=/root/.m2 \
    ./mvnw package -DskipTests && \
    mv target/$(./mvnw help:evaluate -Dexpression=project.artifactId -q -DforceStdout)-$(./mvnw help:evaluate -Dexpression=project.version -q -DforceStdout).jar target/app.jar

################################################################################
# Stage 3: extract Spring Boot layers
FROM package as extract

WORKDIR /build

RUN java -Djarmode=layertools -jar target/app.jar extract --destination target/extracted

################################################################################
# Stage 4: minimal runtime image
FROM eclipse-temurin:26-jre-jammy AS final

ARG UID=10001
RUN adduser \
    --disabled-password \
    --gecos "" \
    --home "/nonexistent" \
    --shell "/sbin/nologin" \
    --no-create-home \
    --uid "${UID}" \
    appuser
USER appuser

COPY --from=extract build/target/extracted/dependencies/ ./
COPY --from=extract build/target/extracted/spring-boot-loader/ ./
COPY --from=extract build/target/extracted/snapshot-dependencies/ ./
COPY --from=extract build/target/extracted/application/ ./

EXPOSE 8080

ENTRYPOINT [ "java", "org.springframework.boot.loader.launch.JarLauncher" ]

This is already a proper multi-stage build: separate stages for dependency resolution, compilation, layer extraction, and a minimal runtime image with a non-root user. Gord would approve.

A Note on Java 26 Base Images

The generated Dockerfile references eclipse-temurin:26-jdk-jammy and eclipse-temurin:26-jre-jammy. Since Java 26 was just released, these Eclipse Temurin images may not be fully available on Docker Hub yet.

Swap them out for SAP Machine images instead—SAP's free OpenJDK distribution ships Java 26 on Ubuntu 24.04 (Noble Numbat):

sapmachine:26-jdk-ubuntu-noble
sapmachine:26-jre-ubuntu-noble

Find them on Docker Hub: hub.docker.com/_/sapmachine. Just replace eclipse-temurin with sapmachine in both FROM lines.

Build and Run

docker compose up --build

The generated compose.yaml is minimal:

services:
  server:
    build:
      context: .
    ports:
      - 8080:8080

The application starts, and immediately stops with exit code 0. That's expected: there's no HTTP endpoint to keep it alive.

Add a Controller

Create src/main/java/io/dockersecurity/hellowowlrd/HelloController.java:

package io.dockersecurity.hellowowlrd;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
public class HelloController {

    @GetMapping("/")
    public String hello() {
        return "Hello, Docker Security!";
    }
}

Add the Spring Web dependency to pom.xml:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
</dependency>

Build and run again:

docker compose up --build

Verify:

curl http://localhost:8080
# Hello, Docker Security!

See It Live — Jfokus 2026

I presented Docker Init and Docker security at Jfokus in Stockholm in February 2026. If you want to see the commands in action rather than reading about them, the full talk is on YouTube:

Conclusion

Java 26 just shipped and Docker Init handles it cleanly out of the box—multi-stage build, layer extraction, non-root user, bind mounts for caching. You get a production-ready Dockerfile in under a minute. When Eclipse Temurin catches up, swap the base images back. Until then, SAP Machine has you covered.

Docker Init is Gord's move. The rest of the Commandos handle what comes after.

The Docker Commandos

Docker Init is assigned to Commando 1: Gord. In the Docker Commandos workshop, each Docker security feature is taught through a character on a mission to defend Asgard from CVE monsters. The ten commandos are:

Gord — docker init: establish a secure base from day one ← you are here
Rothütle — SBOM: inventory every dependency in your image
Jack — Docker Scout: hunt CVEs across your supply chain
The Valkyrie — SBOM Attestations: cryptographically sign your component inventory
Artemisia — Docker Hardened Images: near-zero-CVE base images
Mina — VEX Exemptions: mark false-positive CVEs as not exploitable
RuinTan — VEX Attestations: attach signed exemptions to your image
Captain Ahab — Docker Bake: codify your entire build pipeline in one file
Evie — Cosign: sign images and attestations cryptographically
Agent Null — Zero-Day Defense: harden against unknown, unpatched threats

The workshop has been delivered at WeAreDevelopers World Congress, Jfokus, and Rabobank. More at dockersecurity.io/commandos.

The Complete Docker Read List: Q1 2026 Edition

Mohammad-Ali A'RÂBI — Thu, 26 Mar 2026 17:21:39 +0000

2026 has been phenomenal in the number of books published on Docker or by Docker Captains so far. So, I decided to compile the books published in the first quarter of 2026 into an article for more people to discover them.

You can also read the article here, which looks slightly better.

1️⃣ Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security

Author: Mohammad-Ali A'râbi (Docker Captain)

If you've ever thought learning about Kubernetes and container hardening was a bit dry, Mohammad-Ali A'râbi is here to prove you wrong. Black Forest Shadow is a highly creative, dark fantasy guide to Docker and Kubernetes security.

—Claude

What it's about: The book weaves complex concepts like runtime security, SBOM generation, and container hardening into an exciting narrative set in the mystical Black Forest of 1865.
Why you should read it: It transforms standard cybersecurity challenges—like tracking down CVEs and preventing lateral movement—into an immersive, story-driven adventure. It's ideal for developers and security engineers seeking a distinctive, memorable approach to DevSecOps.
Where to get it:

2️⃣ The Rust Programming Handbook: An End-to-end Guide to Mastering Rust Fundamentals

Author: Francesco Ciulla (Docker Captain)

Rust is the new C, and it's been on my list for 5 years now. Now, finally, I know which book to read to learn it. Written by my dear friend and fellow Docker Captain, Francesco Ciulla, who has been teaching Rust for many years now.

What it's about: This handbook takes you from foundational syntax to advanced features like memory safety and concurrency models. Crucially for this list, it includes dedicated, hands-on sections on Dockerizing and deploying your Rust applications!
Why you should read it: It bridges the gap between beginner tutorials and production-ready coding for low-level system components or high-performance web services.
Where to get it:
- Packt Publishing
- Walmart

3️⃣ Docker for Front-end Developers (Featuring React.js)

Author: Kristiyan Velkov (Docker Captain)

Front-end developers, rejoice! As a backend engineer, it has always been hard for me to onboard frontend people to Docker, because I spoke Klingon for them. My dear friend, Docker Captain Kristiyan Velkov, has done an awesome job writing a containerization guide specifically tailored to how front-end engineers think, build, and ship. I should say, it also looks good.

What it's about: Moving past backend-centric explanations, this book walks you through containerizing real-world applications (with a heavy focus on React). You'll learn how to write clean Dockerfiles, configure NGINX properly, implement multi-stage builds, and handle caching securely.
Why you should read it: It's a purely practical, visually-driven guide that teaches you how to take full ownership of your environments without getting bogged down in abstract backend theory.
Where to get it:

4️⃣ The Ultimate Docker Container Book (Fourth Edition)

Author: Dr. Gabriel N. Schenker

Hitting shelves on March 31, 2026, this absolute heavyweight of a book clocks in at over 750 pages and leaves no stone unturned. Jeez, I need an extra bookshelf just for this book's weight.

What it's about: It takes you from basic container concepts all the way to running production-grade platforms. The fourth edition places a massive new emphasis on security, enterprise governance, compliance, and AI-driven automation patterns.
Why you should read it: It is designed for system administrators, DevOps engineers, and architects who need to build and scale secure, future-ready container platforms across major cloud providers.
Where to get it:
- Packt Publishing

5️⃣ Docker: Das Praxisbuch für Entwickler und DevOps-Teams (5th Edition)

Authors: Bernd Öggl & Michael Kofler

For the German-speaking tech community, the definitive Docker reference guide gets a major Q1 2026 update.

What it's about: A comprehensive, 580+ page practical guide covering everything from setting up Docker to CI/CD pipelines, GitLab integration, Swarm, and Kubernetes orchestration.
Why you should read it: It's an excellent, hands-on resource that balances basic principles with advanced, modern use cases like modernizing legacy applications and working with specialized databases.
Where to get it:
- Rheinwerk Verlag

Honorable Mentions from 2025

Well, while researching the new 2026 Docker books, I stumbled upon a recent video by Bret Fisher interviewing the author of a rather interesting book. That inspired me to add this honorable mentions section. I promise my original intention wasn't to sneak my own book in here, but hey, it just happened!

Learn Docker in a Month of Lunches (Second Edition)

Author: Elton Stoneman

Published in 2025, this is the much-anticipated update to one of the most beloved Docker books on the market.

What it's about: A complete refresh of the classic guide. It breaks down Docker fundamentals into digestible, daily lessons. This edition covers multi-platform builds, the latest cloud container services, and navigating the modern Kubernetes ecosystem.
Why you should read it: If you are a beginner looking for a structured, manageable way to learn—or an experienced dev needing to catch up on years of ecosystem changes—this is the gold standard.
Where to get it:
- Manning Publications

Getting Started with Docker (2025 Edition)

Author: Nigel Poulton (Docker Captain)

Nigel Poulton's fast-paced introduction to Docker received a significant 2025 update, adding a dedicated chapter on running local LLMs with Docker Model Runner — including building a multi-container chatbot app.

What it's about: A streamlined, hands-on guide to container fundamentals, Docker Compose, and microservices — now with a practical AI chapter for developers who want to run models locally.
Why you should read it: It's the quickest path from zero to productive with Docker, and the new AI content makes it uniquely relevant for 2025 and beyond.
Where to get it:
- Leanpub

Docker and Kubernetes Security

Author: Mohammad-Ali A'râbi (Docker Captain)

A DevOps Dozen 2025 finalist for Best DevOps Book of the Year, this practical guide covers container security across the full development lifecycle—from build to production.

What it's about: Ten chapters spanning supply chain security (SBOMs, OCI 1.1 attestations, vulnerability scanning with Docker Scout, Trivy, and Snyk) and runtime protection with Falco, RBAC, and Kubernetes pod security.
Why you should read it: It is the most comprehensive hands-on resource available for teams serious about securing their container platforms end-to-end.
Where to get it:
- DockerSecurity.io
- Amazon

Conclusion

The Docker and Kubernetes ecosystem has never had a stronger reading list, to be completely humble! From dark fantasy security guides to hands-on Rust handbooks and front-end containerization primers, Q1 2026 proves that the community is producing more creative, accessible, and production-focused material than ever before.

Stay tuned as more books are coming in Q2. I'm involved in reviewing one of them, so I'm excited for the quarter to come.

Have a book that should be on this list? Leave a comment.

Docker Just Made Hardened Images Free for Everyone – Let's Check Them Out!

Anil Kumar Moka — Mon, 29 Dec 2025 02:03:18 +0000

Hey everyone! If you're like me and spend a lot of time building and deploying containers, you've probably worried about security at some point. Supply chain attacks are no joke these days, and starting with a solid, secure base can make a huge difference. That's why I'm super excited about the recent news from Docker: they've made Docker Hardened Images (DHI) completely free and open source for all developers!Back in May 2025, Docker launched these hardened images as a way to give us minimal, secure, production-ready bases. And just a couple weeks ago (December 17, 2025), they announced that the whole catalog – over 1,000 images and Helm charts – is now free, under Apache 2.0. No subscriptions needed for the basics, no restrictions, no gotchas. This feels like a game-changer for making secure containers the default instead of an afterthought.Let me break it down for you based on the official blog post and docs, and share some practical ways you can start using them today.

What Are Docker Hardened Images?

In simple terms, DHI are container images that Docker maintains with security front and center. They're built on familiar bases like Alpine and Debian, but stripped down to the essentials. No unnecessary shells, compilers, or package managers that could open up attack vectors.The result?
Images up to 95% smaller

Way fewer CVEs (they aim for near-zero)
Secure defaults, like running as non-root
Full transparency with SBOMs (software bill of materials),
SLSA Level 3 provenance, and no hidden vulnerabilities

They're inspired by distroless ideas but keep enough tools so you don't have to fight with them in real workflows. And unlike some proprietary options, these are open, compatible with what you're already using, and easy to adopt.

There's a free tier for everyone, and an Enterprise version if you need extras like FIPS compliance, customizations, or super-fast patching SLAs.

Why This Matters (And Why Now)

Supply chain attacks are exploding – projected to cost $60 billion this year alone. A lot of that risk comes from bloated base images pulling in stuff your app doesn't need. By starting with a hardened image, you're shrinking that attack surface right from the first docker build.Docker's basically saying: let's make secure-by-default the new normal. And with partnerships from folks like Google, MongoDB, and CNCF, plus companies like Adobe and Qualcomm already using them, it seems like it's catching on fast.

How to Get Started – It's Super Easy

Head over to the catalog on Docker Hub: https://hub.docker.com/hardened-images/catalog (you might need to sign in with your Docker ID).Or pull directly from dhi.io.

For example, let's try a Python one:bash

docker pull dhi.io/python:3.13
Then run something simple:bash

docker run --rm dhi.io/python:3.13 python -c "print('Hello from a hardened image!')"

In your Dockerfile, just swap the base:

FROM dhi.io/python:3.13 COPY . /app WORKDIR /app CMD ["python", "app.py"]

They work great in CI/CD too. And if you're on Kubernetes, check out the open source Hardened Helm Charts.
Pro tip from the docs: These images are minimal on purpose, so no shell by default in runtime variants. Use multi-stage builds – compile in a -dev or -sdk tag, then copy to the slim runtime one.

Some Practical Use Cases I Can See

Imagine you're building a Node.js API for a startup. Instead of starting with the regular node image (which has extra stuff), switch to a hardened one. Smaller images mean faster deploys, fewer vulnerabilities to scan, and you sleep better knowing it's locked down.

Or say you're deploying MongoDB in prod. Docker has hardened versions of popular MCP servers like Mongo, Grafana, and more. Drop one in, and you've got a secure foundation without rolling your own hardening scripts.

For teams in regulated spaces (finance, healthcare), the free versions already give huge wins on CVEs and size. Upgrade to Enterprise if you need FIPS or extended support after upstream EOL.Even for personal projects or learning, why not start secure? It costs nothing extra now.

This move by Docker feels huge, putting hardened, transparent images in everyone's hands for free. If you've been putting off tightening up your container security, now's the perfect time to jump in. Go browse the catalog, pull a couple images, and see the difference yourself. Planning to switch any of your projects over? Drop a comment if you've tried them already!

Docker Hardened Images are Free

Mohammad-Ali A'RÂBI — Wed, 17 Dec 2025 14:17:35 +0000

Docker introduced Hardened Images in 2025 as a secure-by-default base image line, designed to keep production and development images as close to zero known CVEs as realistically possible.

As supply chain attacks are on the rise, Docker made the Hardened Images open-source under the Apache 2.0 license to let the community audit and contribute to them.

From now on, you can use the hardened images for free in your projects:

# For build stage
FROM dhi.io/node:24-dev AS build

# For production stage
FROM dhi.io/node:24

To get started, visit dhi.io.

How to Pull Hardened Images Locally

To pull the images locally, you need to log into dhi.io first:

docker login dhi.io

The images are free to use, but you still need to authenticate before pulling them.

Use your Docker Hub credentials to login. You can use your personal Docker Hub account and a personal access token (PAT) as the password. No special subscription is required.

Then pull the desired image:

docker pull dhi.io/node:24

Check for CVEs

To check for CVEs in the images, you can use Docker Scout:

docker scout cves dhi.io/node:24

The image has 8 low-severity CVEs as of December 17th, 2025, as there are no fixed versions available for those packages:

8 vulnerabilities found in 2 packages
  CRITICAL  0  
  HIGH      0  
  MEDIUM    0  
  LOW       8

To check with Trivy:

trivy image --scanners vuln dhi.io/node:24

Trivy also found 7 low-severity CVEs on one package:

dhi.io/node:24 (debian 13.2)

Total: 7 (UNKNOWN: 0, LOW: 7, MEDIUM: 0, HIGH: 0, CRITICAL: 0)

You can still use the Alpine-based hardened images to have a smaller attack surface.

Final Words

There are more than 500 different tags just for the Node.js Hardened Images available on dhi.io, including Alpine-based, Debian-based, dev and runtime, and FIPS and STIG-compliant images. And there are some 100 different repositories for other languages and runtimes, such as Python, Go, Java, .NET, Ruby, and more. And there are Helm charts to deploy DHI images on Kubernetes clusters directly.

To explore all available images, visit the DHI Catalog.

To learn more about Docker and Kubernetes security, check out my book Docker and Kubernetes Security, currently 40% off with code BLACKFOREST25.

I Just Published My Book: Docker and Kubernetes Security

Mohammad-Ali A'RÂBI — Tue, 21 Oct 2025 12:26:34 +0000

The book Docker and Kubernetes Security is finally here, after two years, 170 git commits, and countless hours of writing, editing, and reviewing. It's available on DockerSecurity.io. You can get the eBook, paperback, or a signed copy (that I'll sign and send to you). 🐳🔐

So, why did I write this book?

An Unexpected Journey

I became a Docker Captain in March 2023. That probably put me on this publisher's radar. Shortly after that, a major UK publisher reached out to me, asking if I would be interested in writing a book on Docker Security. At first, I was hesitant. Writing a book is a huge commitment, and I wasn't sure if I had enough expertise in Docker Security. The publisher was very persuasive, though, and I eventually agreed to write a proposal.

Here is my monthly tweet about writing a proposal in July 2023:

July 2023 goals:

👾 Practice C with Exercism

🐳 Submit a Docker talk

📝 Write a piece on Telepresence

🚘 Pass the driving theory exam

📚 Finish the book proposal

Well, I never made it to that DockerCon, because my visa is still pending. But I did finish the proposal!

I finished the book, it went through multiple rounds of editing and reviewing, and the technical reviewers gave me a green light by the end of 2024. I was waiting for the final copy-editing and typesetting to be done when I got an email from the publisher in February 2025, named "Intro Call". There was some reorganization happening at the publisher, and they assigned a new team to my book. The intro call was super nice and happy. Then I got an email in March 2025, saying that they are canceling the book project "after a thorough review". I said, "Sure, just verify that the rights are reverted to me". They wrote:

Yes, the manuscripts belong to you, and you can find an alternative publisher.

I thought, "I have found a new publisher, and that's me!"

Self-Publishing

I set a deadline for myself: October 1st, 2025. I personally love October. It's the month of Oktoberfest, Hacktoberfest, and Halloween. And people are back from Summer mood.

When I posted on LinkedIn that's publishing in October, I received overwhelming support and encouragement from my network. The post received 5,000 views, 75 reactions, and 20 comments of encouragement.

So, I started reaching out to my network for help with self-publishing. Docker Captain Vladimir Mikhalev accepted to be my technical editor. Other Docker Captains accepted to read beta copies and give feedback. I typeset the book using Markdown and LaTeX, and my friend Sima Maherani designed a beautiful cover for it.

I started using Amazon's Kindle Direct Publishing (KDP) to publish the eBook and paperback versions. I also set up a website, DockerSecurity.io, to sell signed copies and provide additional resources.

I took two copies of the book to my talk at WeAreDevelopers in Berlin, where I ran a workshop on Docker Security. There, I ran into Docker Captain Francesco Ciulla, who said he would promote the book when it comes out. I also met Liran Tal, Director of Developer Advocacy at Snyk, who later wrote a foreword for the book.

The Launch

Finally, the big day arrived: October 1st, 2025. The book was launched on Amazon and DockerSecurity.io. Amazon's KDP network mostly supported English-speaking countries, plus some European countries. Many other countries were not supported, for example, India, although Amazon has a big presence there. So, I set up a signed copy option on buy.DockerSecurity.io to ship books worldwide.

Again, after the launch, I received overwhelming support from my network. People started purchasing the book and leaving reviews on Amazon and Goodreads. Docker reshared my launch post on their official LinkedIn page, as well as on Twitter.

An Indian Docker Captain reached out and said he wants to give away copies of the book to the winners of a Hackathon he was organizing. It was a challenge to get him the book in time, but we managed to do it. More Captains reached out to congratulate me and offer help with promotion.

So far, 3 weeks after the launch, we have had a slow start, but the momentum is building up. The book had sales in Japan, although I did not promote it there. Sales are mostly in Germany, where I'm based. I have received requests from readers in Iran and India who wanted to buy the book but could not find a way to do it. The signed copy is an option, but still expensive, as it's printed in Europe and shipped internationally.

I'm currently working with an Indian printer to make the book available in Asia, Africa, and the Middle East. I'm also registering my own ISBN to make the book available in bookstores. They would usually refuse to stock books with Amazon's ISBN.

If you are interested in ordering the book, you can find it here: buy.DockerSecurity.io. You can use the following code for a 10 Euros discount: DEVTO 🏷️

If you want to order on Amazon, you can find the links here: DockerSecurity.io. The website will redirect you to the appropriate Amazon store based on your location.

Conclusion

Writing and self-publishing a technical book is a challenging but rewarding experience. It requires a lot of dedication, perseverance, and support from your network. I'm grateful for everyone who helped me along the way, and I'm excited to see where this journey takes me next.

If you want to write a book, you can reach out to me, and I can share the code base I built with Pandoc and LaTeX to help you get started.

Meet the heroes who made Docker and Kubernetes Security possible:

MCP Horror Stories - Issue 1

Ajeet Singh Raina — Fri, 01 Aug 2025 15:23:10 +0000

The Model Context Protocol (MCP) is a standardized interface that enables AI agents to interact with external tools, databases, and services. Launched by Anthropic in November 2024, MCP has achieved remarkable adoption, with thousands of MCP server repositories emerging on GitHub. Major technology giants, including Microsoft, OpenAI, Google, and Amazon, have officially integrated MCP support into their platforms, with development tools companies like Block, Replit, Sourcegraph, and Zed also adopting the protocol.

Think of MCP as the plumbing that allows ChatGPT, Claude, or any AI agent to read your emails, update databases, manage files, or interact with APIs. Instead of building custom integrations for every tool, developers can use one protocol to connect everything.

The Model Context Protocol (MCP) was supposed to be the “USB-C for AI applications” – a universal standard that would let AI agents safely connect to any tool or service. Instead, it’s become a security nightmare that’s putting organizations at risk of data breaches, system compromises, and supply chain attacks.

The promise is compelling: Write once, connect everywhere. The reality is terrifying: A protocol designed for convenience, not security.

This is issue 1 of a new series – MCP Horror Stories – where we will examine critical security issues and vulnerabilities in the Model Context Protocol (MCP) ecosystem and how Docker MCP Toolkit provides enterprise-grade protection against these threats.

Click here to Read the complete blog

Docker Deep Dive Workshop at WeAreDevelopers

Mohammad-Ali A'RÂBI — Wed, 09 Jul 2025 22:30:48 +0000

Today, I conducted a workshop at WeAreDevelopers World Congress 2025 titled:

Docker Deep Dive with a Docker Captain

The workshop covered the following topics:

Docker Init
Docker Bake
Docker SBOM
SBOM attestations
Docker Scout
Docker Debug
Docker Model Runner
Ask Gordon

This article is a step-by-step guide that walks you through the topics, allowing you to recreate the workshop for yourself on demand.

Technical Requirements

Docker Desktop latest version
Git
A Bash shell (e.g., Git Bash, WSL, or any Linux terminal)

On Windows, you can install Git Bash.

1. Docker Init

Main article: Dockerizing a Java 24 Project with Docker Init

Main article: JAVAPRO: How to Containerize a Java Application Securely

Docker Init is a command to initialize a Docker project with a Dockerfile and other necessary files:

Dockerfile
compose.yaml
.dockerignore
README.Docker.md

The command doesn't use GenAI, so is deterministic, and employs best practices for Dockerfile creation.

Docker Init is available on Docker Desktop 4.27 or later and is generally available.

Usage

On the repo, go to the Flask example directory:

cd flask

Then, run the Docker Init command:

docker init

The command will ask you 4 questions, accept the defaults:

? What application platform does your project use? Python
? What version of Python do you want to use? 3.13.2
? What port do you want your app to listen on? 8000
? What is the command you use to run your app? gunicorn 'hello:app' --bind=0.0.0.0:8000

Then, start Docker Compose with build:

docker compose up --build

The application will be available at http://localhost:8000.

Exercises

1.1. If you want a more tricky example, try Dockerizing a Java 24 application using Docker Init. You can follow the instructions in the JAVAPRO article that I published last week.
1.2. Compare the Dockerfile created for the Java application with the one created for the Python application. What are the differences?

2. Docker Bake

Requirement: This step requires the Docker Init step to be completed first.

Docker Bake is to Docker Build, what Docker Compose is to Docker Run. It allows you to build multiple images at once, using a single command.

Docker Bake is available on Docker CE and Docker Desktop, and is generally available.

Usage

In the repo, go to the Flask example directory:

cd flask

Then, try to build the image using Docker Bake:

docker buildx bake

The command will build the image using the docker-bake.hcl file in the current directory. At the end, there is a Docker Desktop link shown in the output, with which you can see the build progress in the Docker Desktop UI.

Also, there are probably some warnings about the Dockerfile.

Exercises

2.1. Try to fix the warnings in the Dockerfile.
2.2. By changing the docker-bake.hcl file, try building for multiple platforms, e.g., linux/amd64 and linux/arm64.
2.3. Try to build the image with a different Python version, e.g., 3.13.1 (the Python version is defined in the Dockerfile as a build argument, PYTHON_VERSION).

3. Docker SBOM

Requirement: This step requires the Docker Init step to be completed first.

In Docker Init step, we built an image with tag flask-server:latest when running docker compose up --build. Let's check the SBOM for this image.

Docker SBOM is integrated into Docker Desktop, but is also available for Docker CE as a CLI plugin that you need to install separately.

Usage

To check the SBOM for the image, run:

docker sbom flask-server:latest

The output will show the SBOM in a table format. Try to export it to a SPDX file:

docker sbom --format spdx-json flask-server:latest > sbom.spdx.json

If you investigate the file, you will see that it contains a list of all the packages used in the image, their versions, and the licenses. It's especially useful for compliance and security purposes.

A more interesting example will be a C++ application.

Go to the C++ example directory:

cd cpp

Then, build the image:

docker build -t cpp-hello .

Now, check the SBOM for the image:

docker sbom cpp-hello

It will say there are no packages in the image, because the image is built from a FROM scratch base image. But, in the build stage, we installed many packages, and a vulnerability in those packages can affect the final image.

We'll get back to this later.

Exercises

3.1. Try to create a Docker Bake file for the C++ example, and build the image using Docker Bake.
3.2. Use docker sbom --help to check available formats for the SBOM output.

4. SBOM Attestations

Requirement: This step requires the Docker SBOM step to be completed first.

Main article: DockerDocs: Supply-Chain Security for C++ Images

SBOM attestations are SBOMs generated for Docker images and uploaded with them to the registry.

Usage

SBOM attestations are generated during the build and pushed to the registry automatically:

docker buildx build --sbom=true --push -t aerabi/cpp-hello .

Now, let's check the CVEs with Docker Scout (we will cover it in the next section):

docker scout cves aerabi/cpp-hello

It will say:

SBOM obtained from attestation, 0 packages found

The SBOM has no packages, because we built the image from a FROM scratch base image, and the build stage packages are not included in the SBOM. We can fix this by including the build stage packages in the SBOM.

To do that, we need to add the following line to the beginning of the Dockerfile:

ARG BUILDKIT_SBOM_SCAN_STAGE=true

This line goes before the FROM line, and it tells Docker to include the build stage packages in the SBOM.

Now, rebuild the image with the new Dockerfile:

docker buildx build --sbom=true --push -t aerabi/cpp-hello:with-build-stage .

Now, check the SBOM attestations for the image again:

docker scout cves aerabi/cpp-hello:with-build-stage

It will say:

SBOM of image already cached, 208 packages indexed

Exercises

4.1. Here, the build command was super long. Try to create a Docker Bake file for the C++ example, and build the image using Docker Bake with SBOM attestations.

5. Docker Scout

Requirement: This step requires the SBOM Attestations step to be completed first.

Docker Scout is a tool to analyze Docker images and check for vulnerabilities, misconfigurations, and other issues. It uses the SBOM attestations, when available, to provide more accurate results.

Docker Scout is available on Docker Desktop, and as a CLI plugin for Docker CE.

Usage

To check the vulnerabilities in the image, run:

docker scout cves aerabi/cpp-hello:with-build-stage

You can also check the vulnerabilities in the image using the Docker Desktop UI. Just go to the "Images" tab, select the image, and click on "Scout".

There are also recommendations for the image, which you can check by running:

docker scout recommendations flask-server

Exercises

5.1. Try to fix the vulnerabilities in the Flask image using the recommendations from Docker Scout.

6. Docker Debug

Requirement: This step requires the Docker SBOM step to be completed first.

Docker Debug is a tool to debug Docker images and containers. It allows you to run a container with a debug shell, and inspect the image and the container.

Docker Debug is a paid feature available on Docker Desktop.

Usage

Docker Debug can be used to investigate images or containers, when docker exec is not enough. For example, you can use it to inspect a scratch image:

docker debug aerabi/cpp-hello:with-build-stage

Exercises

6.1. Use Docker Debug to inspect the C++ image.
6.2. Use Docker Debug to inspect the Flask image.
6.3. Run the Flask image and inspect it with Docker Debug.
6.4. Install a tool like Vim using Docker Debug. The tools persist between different inspections. Try to inspect another container and check if the tool is still there.

7. Docker Model Runner

Main article: Run GenAI Models Locally with Docker Model Runner

Docker Model Runner is a tool to run GenAI models locally using Docker. The feature is still in beta, but is available on Linux, macOS, and Windows.

Linux: Docker CE
macOS: Docker Desktop 4.40 or later
Windows: Docker Desktop 4.41 or later

On Docker CE, you need to install the Docker Model Runner plugin:

sudo apt-get install docker-model-plugin

Usage

docker model run ai/gemma3

To use Docker Model Runner for developing GenAI applications, you can pull the models, and they will become available locally. Whenever an application needs to use a model, it can use the local models.

And example application is available here:

git clone https://github.com/aerabi/genai-app-demo
cd genai-app-demo

Edit the file backend.env and make it match the following content:

BASE_URL: http://model-runner.docker.internal/engines/llama.cpp/v1/
MODEL: ai/gemma3
API_KEY: ${API_KEY:-dockermodelrunner}

Then, run the application:

docker compose up -d

Exercises

7.1. Docker Compose now supports the model service type (learn more). Try to adapt the Compose file in the repo to declare the model as a service.

From Zero to Kubernetes: A Beginner's Guide to Orchestrating Docker Containers

Karan Verma — Sat, 31 May 2025 12:30:28 +0000

Introduction

If you've ever built or deployed applications using Docker, you've likely hit a point where running containers on your laptop just isn’t enough. You need scaling, automation, recovery, and networking across machines. Enter Kubernetes, the container orchestrator trusted by startups and tech giants alike. In this beginner-friendly guide, we’ll walk you through what Kubernetes is, why it matters, and how Docker developers can start leveraging its power.

What is Kubernetes?

Kubernetes (also called K8s) is an open-source platform that automates deploying, scaling, and managing containerized applications. While Docker helps package your app into a container, Kubernetes helps run and scale it across many machines.

Kubernetes architecture explained: The Control Plane manages the cluster while Nodes run Pods, which host your Docker containers.

Why Use Kubernetes?

- Self-Healing: Restarts failed containers automatically.
- Scalability: Scale apps up or down automatically with a single command.
- Declarative Management: Define your infrastructure and app needs using YAML files.
- Portability: Run anywhere from your laptop with Minikube to cloud providers like AWS, GCP, or Azure.

How Kubernetes Works (for Docker Devs)

Kubernetes works on a cluster model. A cluster has:

- Master Node (Control Plane): Handles scheduling, scaling, and communication.
- Worker Nodes: Run your Docker containers inside Pods.

Pods and Deployments

A Pod is the smallest deployable unit in Kubernetes. It wraps your container(s) and runs on a node. You usually don’t run Pods directly, you use Deployments to manage them.

Exposing Your App with Services

Pods can come and go. You need a stable way to expose them; that’s where Services come in. A Service routes traffic to the right Pods and load-balances across them.

Kubernetes Service: Traffic from users is routed through a Service to reach the right Pods, ensuring balanced and reliable access to your app.

Step-by-Step: Try It Yourself with Minikube

Let’s get hands-on!

1. Install Minikube & kubectl

brew install minikube
minikube start
kubectl get nodes

2. Create a Deployment YAML

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
spec:
  replicas: 2
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
      - name: nginx
        image: nginx:latest
        ports:
        - containerPort: 80

3. Deploy it to Kubernetes

kubectl apply -f deployment.yaml
kubectl get pods

4. Expose Your Deployment as a Service

kubectl expose deployment my-web-app --type=NodePort --port=80

5. Access Your App

minikube service my-web-app

Bonus: Access a Pod Directly (Port Forwarding)

kubectl port-forward pod/my-web-app-xxxx 8080:80

📚 Further Reading

Here are some trusted, beginner-friendly resources to deepen your Kubernetes knowledge, especially curated for developers coming from Docker:

Kubernetes Official Documentation: The canonical source for Kubernetes knowledge, straight from the maintainers.
Docker + Kubernetes (Docker Docs): Docker’s own guide on moving from Docker CLI to Kubernetes orchestration.
Minikube Official Docs: Run Kubernetes locally in minutes, perfect for testing and dev environments.
kubectl Cheat Sheet: Bookmark this as your go-to for common Kubernetes CLI commands.
Build and Deploy Your First Image on DigitalOcean Kubernetes: A hands-on tutorial that ties together Docker image creation and Kubernetes deployment.
Kubernetes for Beginners (YouTube - TechWorld with Nana): A visual, practical walkthrough of key Kubernetes concepts is great for Docker users.

Conclusion

Kubernetes might seem complex at first, but if you’re already familiar with Docker, you’re well on your way to mastering it. In this guide, you took important first steps by deploying your app, scaling it, and exposing it with a service, all using tools on your own machine. With a bit of practice and curiosity, you’ll soon unlock the full power of Kubernetes to manage containers at scale, whether locally or in the cloud.

Keep experimenting, and enjoy the journey from zero to Kubernetes pro!🚀

Docker MCP Catalog & Toolkit: Building Smarter AI Agents with Ease

Karan Verma — Tue, 20 May 2025 11:43:38 +0000

Introduction: What Is Docker MCP and Why It Matters

The rise of agent-based AI applications, powered by ChatGPT, Claude, and custom LLMs, has created a demand for modular, secure, and standardized integrations with real-world tools. Docker’s Model Context Protocol (MCP), along with its Catalog and Toolkit, addresses this need.

Docker is positioning itself not just as a container platform but as the infrastructure backbone for intelligent agents. In this post, we’ll explore the MCP architecture, Catalog, and Toolkit, and demonstrate how to build your own MCP server.

Section 1: Understanding MCP: The Model Context Protocol

What it is:

MCP is an open protocol that allows AI clients (like agents) to call real-world services securely and predictably.
It's designed for tool interoperability, secure credential management (handling API keys and tokens), and container-based execution.

Why it matters:

Without standards like MCP, agents rely on brittle APIs or unsafe plugins.
Docker provides a secure, isolated runtime to host these services in containers.

Visual overview:

How an AI client communicates with containerized services via MCP

Section 2: MCP Catalog: Prebuilt, Secure MCP Servers

What it includes:

A growing library of 100+ Docker-verified MCP servers, including:

Stripe
LangChain
Elastic
Pinecone
Hugging Face

Key features:

Each MCP server runs inside a container and includes:

OpenAPI spec
Secure default config
Docker Desktop integration

Why developers care:

Plug-and-play tools for AI agents.
Consistent dev experience across services.

Visual overview:

MCP Catalog integration with Docker Desktop

Section 3: MCP Toolkit: Build Your Own Secure MCP Server

Toolkit CLI Features:

mcp init → Scaffolds new MCP server
mcp run → Runs local dev version
mcp deploy → Deploy to Docker Desktop

Security features:

Container isolation
OAuth support for credentials
Optional rate limiting and tracing

Demo walkthrough:

npm install -g @docker/mcp-toolkit
mcp init my-weather-api
cd my-weather-api
mcp run

Visual walkthrough:

MCP Toolkit Workflow: From CLI to Container

Section 4: Connecting MCP Servers to AI Clients

Supported clients:

Claude (Anthropic)
GPT Agents (OpenAI)
Docker AI (beta)
VS Code Extensions

How it works:

Agents call /invoke endpoint defined in MCP spec.
Secure token exchange handles identity.
Response returned to model for reasoning/action.

Use case example:

Claude uses a Docker MCP server to call a Stripe payment processing container during an e-commerce interaction.

Visual flow:

Shows how Claude securely calls a Stripe service via Docker MCP.

Section 5: Best Practices for MCP Server Developers

Security:

Never use root containers
Use docker scan and trivy for image vulnerability scanning
Store secrets with Docker's secret manager (or Vault)

Performance:

Keep containers lightweight (use Alpine or Distroless)
Use streaming responses for LLM interaction

Testing tips:

Use Postman + curl to test /invoke endpoint
Lint OpenAPI specs with swagger-cli

Section 6: The Future of MCP: What Comes Next?

Predictions:

Docker AI Dashboard integration
MCP orchestration (multiple services per agent)
AI-native DevOps (agents building infra with MCP servers)

Opportunities for devs:

Contribute to open MCP servers
Submit to Docker Catalog
Build agent tools for internal or public use

Closing Thoughts

Docker’s MCP Catalog and Toolkit are still in beta, but the path forward is clear: AI apps need real-world tool access, and Docker is building a secure, open ecosystem to power it.

Whether you’re building agent frameworks or just experimenting with tool-using LLMs, now’s the perfect time to get involved.

Got ideas for MCP servers you want to see? Or thinking about contributing your own? I’d love to hear from you! 😊

Forem: Docker

Seven Docker Tips Every Engineer Should Know (from Docker Captains)

1. Start New Projects with Docker Init

2. Clean Up Docker Disk Usage Carefully

3. Use Multi-Stage Builds

4. Choose Lightweight, Version-Pinned Base Images

5. Use Docker Scout Quickview

6. Use .dockerignore

7. Limit Container Privileges

Conclusion

Book Review: Operational AI with Docker

The Complete Docker Read List: Q1 2026 Edition - Docker and Kubernetes Security - Docker and Kubernetes Security

Authors

The Book's Final Act: From MCP to KAgent

Final Thoughts

Generating SBOM with Docker Scout

The Mission: Who Lives in Asgard?

Technical Requirements

Generate the SBOM

Exporting to Standard Formats

Exercise: Comparing Base Images

What's Next?

Dockerizing a Java 26 Project with Docker Init

Technical Requirements

Create a New Project

Run Docker Init

A Note on Java 26 Base Images

Build and Run

Add a Controller

See It Live — Jfokus 2026

More Links

Conclusion

The Docker Commandos

The Complete Docker Read List: Q1 2026 Edition

1️⃣ Black Forest Shadow: A Dark Fantasy Guide to Docker and Kubernetes Security

2️⃣ The Rust Programming Handbook: An End-to-end Guide to Mastering Rust Fundamentals

3️⃣ Docker for Front-end Developers (Featuring React.js)

4️⃣ The Ultimate Docker Container Book (Fourth Edition)

5️⃣ Docker: Das Praxisbuch für Entwickler und DevOps-Teams (5th Edition)

Honorable Mentions from 2025

Learn Docker in a Month of Lunches (Second Edition)

Getting Started with Docker (2025 Edition)

Docker and Kubernetes Security

Conclusion

Docker Just Made Hardened Images Free for Everyone – Let's Check Them Out!

What Are Docker Hardened Images?

Why This Matters (And Why Now)

How to Get Started – It's Super Easy

Some Practical Use Cases I Can See

Docker Hardened Images are Free

How to Pull Hardened Images Locally

Check for CVEs

Final Words

I Just Published My Book: Docker and Kubernetes Security

An Unexpected Journey

Self-Publishing

The Launch

Conclusion

MCP Horror Stories - Issue 1

Docker Deep Dive Workshop at WeAreDevelopers

Links

Technical Requirements

1. Docker Init

Usage

Exercises

2. Docker Bake

Usage

Exercises

3. Docker SBOM

Usage

Exercises

4. SBOM Attestations

Usage

Exercises

5. Docker Scout

Usage

Exercises

6. Docker Debug

Usage

Exercises