Merge pull request #24614 from mikesir87/add-new-labs

Create new guides for several new labspaces
This commit is contained in:
Michael Irwin
2026-04-02 15:18:10 -04:00
committed by GitHub
17 changed files with 649 additions and 94 deletions
+126
View File
@@ -0,0 +1,126 @@
---
name: create-lab-guide
description: >
Create a guide page for a Labspace. This includes writing the markdown content for the guide,
structuring it according to Docker docs conventions, and ensuring it provides clear instructions
and information about the Labspace. Includes learning about the lab itself, extracting out its
learning objectives, and combining all of that into a well-structured guide markdown file.
---
# Create Lab Guide
You are creating a new guide page for a labspace. The guide should be structured according to Docker docs conventions,
with clear sections, learning objectives, and instructions for users to get the most out of the lab.
## Inputs
The user provides one or more guides to migrate. Resolve these from the inventory below:
- **REPO_NAME**: GitHub repo in the `dockersamples` org (e.g. `labspace-ai-fundamentals`)
## Step 1: Clone the labspace repo
Clone the guide repo to a temporary directory. This gives you all source files locally — no HTTP calls needed.
```bash
git clone --depth 1 https://github.com/dockersamples/{REPO_NAME}.git <tmpdir>/{REPO_NAME}
```
Where `<tmpdir>` is a temporary directory on your system (e.g. the output of `mktemp -d`).
## Step 2: Learn and extract key information about the lab
The repo structure is:
- `<tmpdir>/{REPO_NAME}/README.md` — the main README for the lab
- `<tmpdir>/{REPO_NAME}/labspace/labspace.yaml` — a YAML document outlining details of the lab, including the sections/modules and the path to their content
- `<tmpdir>/{REPO_NAME}/labspace/*.md` — the content for each section/module (only reference the files specified in `labspace.yaml`)
- `<tmpdir>/{REPO_NAME}/.github/workflows/` — the GHA workflow that publishes the labspace. It includes the repo URL for the published Compose file, which will be useful for the "launch" command
- `<tmpdir>/{REPO_NAME}/compose.override.yaml` - lab-specific Compose customizations
1. Read `README.md` to understand the purpose of the lab.
2. Read the `labspace/labspace.yaml` to understand the structure of the lab and its sections/modules.
3. Read the `labspace/*.md` files to extract the learning objectives, instructions, and any code snippets.
4. Extract a short description that can be used for the `description` and `summary` fields in the guide markdown.
5. Determine if a model will be pulled when starting the lab by looking at the `compose.override.yaml` file and looking for the any top-level `model` specifications.
## Step 2: Write the guide markdown
The markdown file must be located in the `guides/` directory and have a filename of `lab-{GUIDE_ID}.md`.
Sample markdown structure, including frontmatter and content:
```markdown
---
title: "Lab: { Short title }"
linkTitle: "Lab: { Short title }"
description: |
A short description of the lab for SEO and social sharing.
summary: |
A short summary of the lab for the guides listing page. 2-3 lines.
keywords: AI, Docker, Model Runner, agentic apps, lab, labspace
aliases: # Include if the lab is an AI-related lab
- /labs/docker-for-ai/{REPO_NAME_WITHOUT_LABSPACE_PREFIX}/
params:
tags: [ai, labs]
time: 20 minutes
resource_links:
- title: A resource link pointing to relevant documentation or code
url: /ai/model-runner/
- title: Labspace repository
url: https://github.com/dockersamples/{REPO_NAME}
---
Short explanation of the lab and what it covers.
## Launch the lab
{{< labspace-launch image="dockersamples/{REPO_NAME}" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Objective #1
- Objective #2
- Objective #3
- Objective #4
## Modules
| # | Module | Description |
|---|--------|-------------|
| 1 | Module #1 | Description of module #1 |
| 2 | Module #2 | Description of module #2 |
| 3 | Module #3 | Description of module #3 |
| 4 | Module #4 | Description of module #4 |
| 5 | Module #5 | Description of module #5 |
| 6 | Module #6 | Description of module #6 |
```
Important notes:
- The learning objectives should be based on the content of the labspace as a whole.
- The modules should be based on the sections/modules outlined in `labspace.yaml`.
- All lab guides _must_ have a tag of `labs`
- If the lab is AI-related, it should also have a tag of `ai` and aliases for `/labs/docker-for-ai/{REPO_NAME}/`
- If the lab pulls a model, add a `model-download: true` parameter to the `labspace-launch` shortcode to show a warning about model downloads.
## Step 3: Apply Docker docs style rules
These are mandatory (from STYLE.md and AGENTS.md):
- **No "we"**: "We are going to create" → "Create" or "Start by creating"
- **No "let us" / "let's"**: → imperative voice or "You can..."
- **No hedge words**: remove "simply", "easily", "just", "seamlessly"
- **No meta-commentary**: remove "it's worth noting", "it's important to understand"
- **No "allows you to" / "enables you to"**: → "lets you" or rephrase
- **No "click"**: → "select"
- **No bold for emphasis or product names**: only bold UI elements
- **No time-relative language**: remove "currently", "new", "recently", "now"
- **No exclamations**: remove "Voila!!!" etc.
- Use `console` language hint for interactive shell blocks with `$` prompts
- Use contractions: "it's", "you're", "don't"
@@ -96,6 +96,7 @@ g?libc
GeoNetwork
GGUF
Git
Gitea
GitHub
GitHub Actions
Google
+4 -24
View File
@@ -26,6 +26,10 @@ Get up and running with building agentic applications using Compose, Docker
Model Runner, and the Docker MCP Gateway. This hands-on lab takes you from
understanding AI models to building complete agentic applications.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-agentic-apps-with-docker" model-download="true" >}}
## What you'll learn
This lab covers three core areas of agentic application development:
@@ -51,27 +55,3 @@ file, and configuring your app to use those models and tools
| 5 | The Docker MCP Gateway | Set up and configure the MCP Gateway |
| 6 | Putting It All Together | Build a complete agentic application |
| 7 | Conclusion | Summary and next steps |
## Prerequisites
- Install the latest version of Docker Desktop
- Enable **Docker Model Runner** by going into Settings in Docker Desktop, choosing AI, then selecting Docker Model Runner
- Pull the Gemma 3 model before launching by running this command:
```console
$ docker model pull ai/gemma3
```
## Launch the lab
Start the labspace:
```console
$ docker compose -f oci://dockersamples/labspace-agentic-apps-with-docker up -d
```
Then open your browser to [http://localhost:3030](http://localhost:3030).
> [!NOTE]
>
> It may take a little while to start due to the AI model download.
+50
View File
@@ -0,0 +1,50 @@
---
title: "Lab: AI Fundamentals for Developers"
linkTitle: "Lab: AI Fundamentals"
description: |
Learn the core concepts of AI development — models, prompt engineering, tool
calling, and RAG — through hands-on exercises in a live environment.
summary: |
Hands-on lab: Learn the four core pillars of AI application development.
Work with the Chat Completions API, prompt engineering, tool calling, and RAG
through interactive exercises.
keywords: AI, Docker, Model Runner, prompt engineering, RAG, tool calling, lab, labspace
aliases:
- /labs/docker-for-ai/ai-fundamentals/
params:
tags: [ai, labs]
time: 45 minutes
resource_links:
- title: Docker Model Runner docs
url: /ai/model-runner/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-ai-fundamentals
---
Get hands-on with the four core pillars of AI application development: models,
prompt engineering, tool calling, and RAG. This lab runs entirely on your
machine using Docker Model Runner — no API key or cloud account required.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-ai-fundamentals" model-download="true" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Understand the Chat Completions API and how to structure messages for a model
- Use prompt engineering techniques including system prompts, few-shot examples, and structured output
- Implement tool calling and the agentic loop in code
- Build a RAG pipeline that grounds model responses in your own data
## Modules
| # | Module | Description |
| --- | ------------------------------------ | ----------------------------------------------------------------- |
| 1 | Welcome & Setup | Introduction to the lab and verifying your environment |
| 2 | Talking to Models | Chat Completions API, message roles, and stateless model behavior |
| 3 | Prompt Engineering | System prompts, few-shot examples, and structured output |
| 4 | Tool Calling | Tool definitions, the agentic loop, and executing tools in code |
| 5 | Retrieval Augmented Generation (RAG) | Retrieve, augment, and generate with your own knowledge base |
| 6 | Wrap-up | Summary of concepts and next steps |
+56
View File
@@ -0,0 +1,56 @@
---
title: "Lab: Container Image Attestations"
linkTitle: "Lab: Container Image Attestations"
description: |
Learn to attach SBOMs, build provenance, image signatures, and VEX
statements to container images for a verifiable software supply chain.
summary: |
Hands-on lab: Add supply chain metadata to a container image. Generate
SBOMs and SLSA provenance with BuildKit, sign images with Cosign, and
attach OpenVEX statements to declare vulnerability exploitability status.
keywords: Docker, supply chain, SBOM, provenance, SLSA, Cosign, VEX, attestations, security, lab, labspace
params:
tags: [labs]
time: 45 minutes
resource_links:
- title: Build attestations
url: /build/metadata/attestations/
- title: SBOM attestations
url: /build/metadata/attestations/sbom/
- title: Provenance attestations
url: /build/metadata/attestations/slsa-provenance/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-attestation-basics
---
Prove where your container images came from and that they haven't been
tampered with. This lab walks through generating SBOMs and SLSA build
provenance with BuildKit, signing images with Cosign, and writing VEX
statements to declare which CVEs affect your image — the techniques used
to meet supply chain security requirements like NIST SSDF and EO 14028.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-attestation-basics" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Generate and inspect an SPDX SBOM attached to a container image with `--sbom=true`
- Generate SLSA build provenance with `--provenance=mode=max` and understand how multi-stage builds are fully recorded
- Install Cosign and use key-based signing to sign and verify a container image
- Write an OpenVEX statement to declare CVE exploitability status and attach it as a signed attestation
- Understand how SBOMs, provenance, signatures, and VEX complement each other in a complete supply chain story
## Modules
| # | Module | Description |
| --- | --------------------------------- | ------------------------------------------------------------------------------------ |
| 1 | Introduction | Overview of supply chain attestations and the sample Go app |
| 2 | Software Bill of Materials (SBOM) | Build with `--sbom=true`, inspect SPDX contents, and understand scanner integration |
| 3 | Build Provenance | Generate SLSA provenance and explore how multi-stage builds are recorded |
| 4 | Signing Images with Cosign | Generate a key pair, sign the image, verify the signature, and learn keyless signing |
| 5 | VEX Statements | Scan for CVEs, write an OpenVEX document, and attach it as a signed attestation |
| 6 | Bringing It All Together | Run the complete build-sign-attest workflow and see the full supply chain picture |
| 7 | Recap | Summary of skills and next steps for policy enforcement and higher SLSA levels |
+56
View File
@@ -0,0 +1,56 @@
---
title: "Lab: Building Container Images"
linkTitle: "Lab: Building Container Images"
description: |
Learn to build production-grade container images using Dockerfile best
practices — layer caching, multi-stage builds, non-root users, base image
selection, and secure build-time secret handling.
summary: |
Hands-on lab: Transform a basic Dockerfile into a production-ready image.
Master layer caching, multi-stage builds, .dockerignore, non-root users,
base image selection, and build secrets.
keywords: Docker, Dockerfile, images, multi-stage builds, layer caching, build secrets, lab, labspace
params:
tags: [labs]
time: 45 minutes
resource_links:
- title: Dockerfile reference
url: /reference/dockerfile/
- title: Multi-stage builds
url: /build/building/multi-stage/
- title: Build secrets
url: /build/building/secrets/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-building-images
---
Take a working but naïve Dockerfile and progressively improve it into a
production-grade image. Each section introduces one technique, applied to
a real Python Flask app, so you can see the impact directly.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-building-images" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Read an image's layer history and understand the layer cleanup pitfall
- Restructure a Dockerfile for fast, cache-efficient incremental builds
- Write a `.dockerignore` file and run containers as a non-root user
- Use multi-stage builds to run tests as a build gate and dramatically reduce image size
- Choose the right base image for production, including Docker Hardened Images
- Inject secrets safely at build time using `--mount=type=secret`
## Modules
| # | Module | Description |
| --- | -------------------------- | ---------------------------------------------------------------------- |
| 1 | Welcome & Your First Build | Explore the sample app and build the initial image |
| 2 | Understanding Image Layers | Inspect layers with `docker history` and see the layer cleanup pitfall |
| 3 | Dockerfile Best Practices | Fix cache ordering, add `.dockerignore`, and switch to a non-root user |
| 4 | Multi-Stage Builds | Run tests as a build gate and use a slim base for the production stage |
| 5 | Choosing a Base Image | Compare slim, Alpine, and Docker Hardened Images |
| 6 | Build Secrets | Show why `ARG` leaks secrets and use `--mount=type=secret` safely |
| 7 | Wrap-up | Review the complete best-practices checklist and next steps |
+55
View File
@@ -0,0 +1,55 @@
---
title: "Lab: Docker Compose Quickstart"
linkTitle: "Lab: Docker Compose Quickstart"
description: |
Build a multi-container Flask and Redis application from scratch using Docker
Compose. Learn health checks, watch mode, named volumes, and multi-file
configurations.
summary: |
Hands-on lab: Define and run a multi-container app with Docker Compose.
Progress from a bare compose.yaml through health checks, live development
with watch mode, data persistence, and modular Compose file composition.
keywords: Docker, Compose, multi-container, Flask, Redis, watch mode, volumes, lab, labspace
params:
tags: [labs]
time: 45 minutes
resource_links:
- title: Docker Compose docs
url: /compose/
- title: Compose watch mode
url: /compose/how-tos/file-watch/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-compose-quickstart
---
Build a Python Flask and Redis hit-counter app using Docker Compose, starting
from a bare `compose.yaml` and progressively adding production-quality
features at each step.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-compose-quickstart" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Define a multi-service application in a `compose.yaml` file and manage it with Compose commands
- Control service startup order using health checks and `depends_on` conditions
- Iterate on code without manual rebuilds using Compose watch mode
- Persist data across container restarts with named volumes
- Modularize a stack across multiple files using the `include` directive
- Use `config`, `logs`, and `exec` to inspect and debug a running stack
## Modules
| # | Module | Description |
| --- | -------------------------------- | --------------------------------------------------------------------- |
| 1 | Introduction | Tour the starter app and verify the environment |
| 2 | Defining Services | Write the first `compose.yaml` and bring up the Flask and Redis stack |
| 3 | Health Checks & Startup Order | Add a Redis healthcheck and `depends_on` to eliminate race conditions |
| 4 | Live Development with Watch Mode | Configure watch mode to sync code changes without manual rebuilds |
| 5 | Persistence & Debugging | Add a named volume so Redis data survives `docker compose down` |
| 6 | Using Multiple Compose Files | Extract Redis into `infra.yaml` and compose files with `include` |
| 7 | Additional Commands | Use `config`, `logs -f`, and `exec` to inspect the running stack |
| 8 | Recap | Review what was built and explore next steps |
@@ -0,0 +1,49 @@
---
title: "Lab: Getting Started with Docker"
linkTitle: "Lab: Getting Started with Docker"
description: |
Learn Docker fundamentals by running containers, exploring the container
lifecycle, and packaging a real Node.js app into your own custom image.
summary: |
Hands-on lab: Run your first containers, write a Dockerfile, build a custom
image from a Node.js app, and optionally push it to Docker Hub.
keywords: Docker, containers, Dockerfile, images, getting started, lab, labspace
params:
tags: [labs]
time: 30 minutes
resource_links:
- title: Docker overview
url: /get-started/docker-overview/
- title: Dockerfile reference
url: /reference/dockerfile/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-container-getting-started
---
Start from zero and learn Docker's core building blocks. You'll run pre-built
containers, write a `Dockerfile` to package a Node.js app, build your own
image, and see container immutability and isolation in action.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-container-getting-started" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Understand what containers are and how they differ from virtual machines
- Run containers in the background, inspect their logs and filesystem, and manage their lifecycle
- Write a `Dockerfile` to package an application, using layer caching for fast rebuilds
- Build a custom image with `docker build` and run it as a container
- Optionally publish your image to Docker Hub
## Modules
| # | Module | Description |
| --- | ------------------------- | ------------------------------------------------------------------------------ |
| 1 | Welcome to Docker | Introduction to containers and running your first `hello-world` container |
| 2 | Running Containers | Launch Nginx, inspect logs and internals, and manage the container lifecycle |
| 3 | Building Your First Image | Write a `Dockerfile` and build a custom image from a Node.js app |
| 4 | Running Your App | Run your image, explore container isolation, and optionally push to Docker Hub |
| 5 | Wrap-up | Summary of key concepts and next steps |
@@ -0,0 +1,52 @@
---
title: "Lab: Container-Supported Development"
linkTitle: "Lab: Container-Supported Development"
description: |
Learn to use containers for local development by running a PostgreSQL
database, defining a Compose file, and adding a pgAdmin dev tool — no local
installations required.
summary: |
Hands-on lab: Run dependent services in containers during local development.
Start a PostgreSQL database, write a compose.yaml, and add a database
visualizer — all without installing anything on the host.
keywords: Docker, Compose, local development, PostgreSQL, pgAdmin, containers, lab, labspace
params:
tags: [labs]
time: 30 minutes
resource_links:
- title: Docker Compose docs
url: /compose/
- title: Bind mounts
url: /engine/storage/bind-mounts/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-container-supported-development
---
Use containers to run the services your app depends on — databases, caches,
message queues — without installing anything locally. This lab walks through
running PostgreSQL in a container, writing a `compose.yaml` your whole team
can share, and adding a pgAdmin visualizer to the dev stack.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-container-supported-development" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Run a PostgreSQL database in a container with no local installation
- Use bind mounts to seed a database with schema and initial data at startup
- Write a `compose.yaml` that codifies the entire dev stack for the team
- Add a pgAdmin container to visualize and inspect the database
- Understand how containerized dev stacks reduce onboarding time and environment drift
## Modules
| # | Module | Description |
| --- | -------------------------------- | ------------------------------------------------------------------------------- |
| 1 | Introduction | Meet the sample app and understand the container-supported development approach |
| 2 | Running a Containerized Database | Start PostgreSQL, connect the app, and seed the database using bind mounts |
| 3 | Making Life Easier with Compose | Replace `docker run` commands with a shared `compose.yaml` |
| 4 | Adding Dev Tools | Add pgAdmin to the Compose stack for database visualization |
| 5 | Recap | Review key takeaways and explore related guides |
+54
View File
@@ -0,0 +1,54 @@
---
title: "Lab: The Containerized SDLC"
linkTitle: "Lab: The Containerized SDLC"
description: |
Build a Node.js API and containerize every stage of the software development
lifecycle — local development, integration testing, CI/CD, and Kubernetes
deployment.
summary: |
Hands-on lab: Take a Node.js app from source to live Kubernetes deployment
using Docker Compose, Testcontainers, Gitea Actions CI/CD, and kubectl —
with containers at every stage of the SDLC.
keywords: Docker, Compose, Testcontainers, Kubernetes, CI/CD, SDLC, lab, labspace
params:
tags: [labs]
time: 60 minutes
resource_links:
- title: Docker Compose docs
url: /compose/
- title: Testcontainers docs
url: https://testcontainers.com/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-containerized-sdlc
---
Build a real Node.js API, then apply containers at every stage of the software
development lifecycle. You'll write a Compose file for local development,
integration tests using Testcontainers, a CI/CD pipeline, and Kubernetes
manifests — using the same container image throughout.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-containerized-sdlc" browserUrl="http://dockerlabs.xyz" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Set up a containerized local development environment with Docker Compose and Compose Watch
- Write integration tests that spin up a real database using Testcontainers
- Build a CI/CD pipeline that tests, builds, and pushes a container image automatically
- Write Kubernetes manifests and deploy a live application to a k3s cluster
- Configure the pipeline to cause an automatic deployment on every push to `main`
## Modules
| # | Module | Description |
| --- | ----------------------------------------- | ------------------------------------------------------------------------ |
| 1 | Introduction: Meet the App | Tour the TaskFlow API and understand the SDLC journey ahead |
| 2 | Local Dev with Docker Compose | Write a `compose.yaml` to provision a local database and visualizer |
| 3 | Containerizing Your Dev Environment | Add the app to Compose with hot-reloading via Compose Watch |
| 4 | Integration Testing with Testcontainers | Write self-contained tests that start a real PostgreSQL container |
| 5 | Continuous Integration with Gitea Actions | Build a pipeline that tests, builds, and pushes a container image |
| 6 | Deploying to Kubernetes | Write manifests and deploy to a live k3s cluster with automated rollouts |
| 7 | The Containerized SDLC: A Recap | Review the portability, consistency, and reproducibility gains |
@@ -0,0 +1,55 @@
---
title: "Lab: Building an AI Product Reviewer"
linkTitle: "Lab: Building an AI Product Reviewer"
description: |
Build a complete AI-powered feedback analysis pipeline — sentiment analysis,
semantic clustering with embeddings, and response generation — all running
locally via Docker Model Runner. No API keys required.
summary: |
Hands-on lab: Build an AI pipeline that classifies product reviews by
sentiment, clusters them by topic using embeddings, extracts actionable
features, and generates context-aware responses — all running locally.
keywords: AI, Docker, Model Runner, sentiment analysis, embeddings, RAG, lab, labspace
aliases:
- /labs/docker-for-ai/creating-ai-product-reviewer/
params:
tags: [ai, labs]
time: 60 minutes
resource_links:
- title: Docker Model Runner docs
url: /ai/model-runner/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-creating-ai-product-reviewer
---
Build a complete feedback analysis pipeline for a fictional AI product called
Jarvis. You'll write Node.js code that runs local LLMs and embedding models via
Docker Model Runner — no API keys, no cloud subscriptions, no data leaving your
machine.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-creating-ai-product-reviewer" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Run LLMs locally via Docker Model Runner's OpenAI-compatible API
- Connect a Node.js app to Docker Model Runner using the OpenAI SDK and the Compose `models:` integration
- Perform sentiment analysis using low-temperature LLM classification
- Use embeddings and cosine similarity to cluster semantically related feedback
- Extract structured data from an LLM using `response_format: { type: 'json_object' }`
- Generate context-aware responses to reviews informed by extracted product features
## Modules
| # | Module | Description |
| --- | ----------------------------------- | ---------------------------------------------------------------------------------- |
| 1 | Introduction | Overview of the pipeline and Docker Model Runner setup |
| 2 | Project Setup & Docker Model Runner | Explore the starter project and wire up Compose model integration |
| 3 | Generating Synthetic Feedback | Use the LLM to generate realistic product reviews as test data |
| 4 | Sentiment Analysis | Classify reviews as positive, negative, or neutral with low-temperature generation |
| 5 | Embeddings & Semantic Clustering | Group related reviews using vector embeddings and cosine similarity |
| 6 | Features & Responses | Extract actionable features and generate context-aware review responses |
| 7 | Wrap-up | Summary of techniques and ideas for extending the pipeline |
+54
View File
@@ -0,0 +1,54 @@
---
title: "Lab: Migrating a Node App to Docker Hardened Images"
linkTitle: "Lab: Migrating to DHI (Node)"
description: |
Migrate a Node.js application from a standard base image to Docker Hardened
Images. Use Docker Scout to analyze CVEs, compare images, and inspect
supply chain attestations.
summary: |
Hands-on lab: Replace a Node.js base image with a Docker Hardened Image.
Analyze CVEs with Docker Scout, rewrite the Dockerfile to use multi-stage
builds with DHI, and explore SBOMs, VEX, and compliance attestations.
keywords: Docker, Hardened Images, DHI, Node.js, Docker Scout, CVE, security, SBOM, lab, labspace
params:
tags: [labs, dhi]
time: 30 minutes
resource_links:
- title: Docker Hardened Images
url: /dhi/
- title: Docker Scout docs
url: /scout/
- title: Build attestations
url: /build/metadata/attestations/
- title: Labspace repository
url: https://github.com/dockersamples/labspace-dhi-node
---
Migrate a Node.js application from a standard `node:24-trixie-slim` base image
to a Docker Hardened Image. You'll measure the before-and-after impact on CVE
count, image size, and policy compliance using Docker Scout, then explore the
supply chain attestations DHI ships with every image.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-dhi-node" >}}
## What you'll learn
By the end of this Labspace, you will have completed the following:
- Analyze a Node.js container image with Docker Scout to identify CVE and policy failures
- Rewrite a Dockerfile to use a multi-stage build with DHI dev and runtime variants
- Compare image size and vulnerability counts before and after the migration
- Inspect supply chain attestations included with Docker Hardened Images (SBOMs, SLSA, VEX)
- Export VEX documents for integration with external scanners such as Grype or Trivy
## Modules
| # | Module | Description |
| --- | ---------------------------------------- | ------------------------------------------------------------------------------- |
| 1 | Introduction | Overview of Docker Hardened Images and their security benefits |
| 2 | Setup | Perform setup tasks required for the lab. |
| 3 | Analyzing the Starting Image | Build the app, scan it with Docker Scout, and review failing policies |
| 4 | Migrating to DHI | Rewrite the Dockerfile with multi-stage DHI build and compare results |
| 5 | DHI Attestations and Scanner Integration | Inspect SBOMs, FIPS attestations, STIG scans, and export VEX for external tools |
+4 -15
View File
@@ -28,6 +28,10 @@ agent concepts, then build sophisticated multi-agent teams that handle complex
real-world tasks. Learn how to create, share, and orchestrate AI agents with
Docker.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-cagent" >}}
## What you'll learn
- Create simple agents with Docker Agent
@@ -48,18 +52,3 @@ Docker.
| 5 | Sharing Agents | Package and share agents via Docker Registry |
| 6 | Introduction to Sub-agents | Build multi-agent systems with sub-agent orchestration |
| 7 | Conclusion | Summary and next steps |
## Prerequisites
- Latest version of Docker Desktop
- Basic familiarity with Docker
## Launch the lab
Start the labspace:
```console
$ docker compose -f oci://dockersamples/labspace-cagent up -d
```
Then open your browser to [http://localhost:3030](http://localhost:3030).
+5 -16
View File
@@ -23,9 +23,13 @@ params:
---
This lab provides a comprehensive, hands-on overview of the Docker MCP Gateway,
which enables you to run containerized MCP servers safely and securely. Learn
which lets you run containerized MCP servers safely and securely. Learn
how to configure, secure, and connect MCP servers to your agentic applications.
## Launch the lab
{{< labspace-launch image="dockersamples/labspace-mcp-gateway" >}}
## What you'll learn
- Learn about the Docker MCP Gateway and its architecture
@@ -46,18 +50,3 @@ how to configure, secure, and connect MCP servers to your agentic applications.
| 5 | Connecting MCP Gateway to Your App | Integrate the MCP Gateway with agentic frameworks |
| 6 | Using a Custom MCP Server | Build and run your own custom MCP server |
| 7 | Conclusion | Summary and next steps |
## Prerequisites
- The latest version of Docker Desktop with Docker Model Runner enabled
- Basic familiarity with Docker and Docker Compose
## Launch the lab
Start the labspace:
```console
$ docker compose -f oci://dockersamples/labspace-mcp-gateway up -d
```
Then open your browser to [http://localhost:3030](http://localhost:3030).
+13
View File
@@ -0,0 +1,13 @@
{{ $image := .Get "image" }}
{{ $modelDownload := .Get "model-download" | default "false" }}
{{ $browserUrl := .Get "browserUrl" | default "http://localhost:3030"}}
{{ $step1 := printf "1. Start the labspace:\n\n ```console\n $ docker compose -f oci://%s up -d\n ```" $image }}
{{ if eq $modelDownload "true" }}
{{ $step1 = printf "%s\n\n > [!NOTE]\n >\n > The lab may take a few minutes to launch, as this lab requires an AI model that will need to be downloaded." $step1 }}
{{ end }}
{{ $step2 := printf "2. Open your browser to [%s](%s)." $browserUrl $browserUrl }}
{{ printf "%s\n\n%s" $step1 $step2 | .Page.RenderString (dict "display" "block") }}
+15 -39
View File
@@ -9,23 +9,23 @@
"version": "0.0.1",
"license": "Apache License 2.0",
"dependencies": {
"@alpinejs/collapse": "^3.15.8",
"@alpinejs/focus": "^3.15.8",
"@alpinejs/persist": "^3.15.8",
"@floating-ui/dom": "^1.7.6",
"@material-symbols/svg-400": "^0.40.2",
"@tailwindcss/cli": "^4.2.1",
"@tailwindcss/typography": "^0.5.19",
"alpinejs": "^3.15.8",
"highlight.js": "^11.11.1",
"marked": "^17.0.4",
"tailwindcss": "^4.2.1"
"@alpinejs/collapse": "3.15.8",
"@alpinejs/focus": "3.15.8",
"@alpinejs/persist": "3.15.8",
"@floating-ui/dom": "1.7.6",
"@material-symbols/svg-400": "0.40.2",
"@tailwindcss/cli": "4.2.1",
"@tailwindcss/typography": "0.5.19",
"alpinejs": "3.15.8",
"highlight.js": "11.11.1",
"marked": "17.0.4",
"tailwindcss": "4.2.1"
},
"devDependencies": {
"markdownlint": "^0.40.0",
"prettier": "^3.8.1",
"prettier-plugin-go-template": "^0.0.15",
"prettier-plugin-tailwindcss": "^0.7.2"
"markdownlint": "0.40.0",
"prettier": "3.8.1",
"prettier-plugin-go-template": "0.0.15",
"prettier-plugin-tailwindcss": "0.7.2"
}
},
"node_modules/@alpinejs/collapse": {
@@ -564,9 +564,6 @@
"cpu": [
"arm64"
],
"libc": [
"glibc"
],
"license": "MIT",
"optional": true,
"os": [
@@ -583,9 +580,6 @@
"cpu": [
"arm64"
],
"libc": [
"musl"
],
"license": "MIT",
"optional": true,
"os": [
@@ -602,9 +596,6 @@
"cpu": [
"x64"
],
"libc": [
"glibc"
],
"license": "MIT",
"optional": true,
"os": [
@@ -621,9 +612,6 @@
"cpu": [
"x64"
],
"libc": [
"musl"
],
"license": "MIT",
"optional": true,
"os": [
@@ -1211,9 +1199,6 @@
"cpu": [
"arm64"
],
"libc": [
"glibc"
],
"license": "MPL-2.0",
"optional": true,
"os": [
@@ -1234,9 +1219,6 @@
"cpu": [
"arm64"
],
"libc": [
"musl"
],
"license": "MPL-2.0",
"optional": true,
"os": [
@@ -1257,9 +1239,6 @@
"cpu": [
"x64"
],
"libc": [
"glibc"
],
"license": "MPL-2.0",
"optional": true,
"os": [
@@ -1280,9 +1259,6 @@
"cpu": [
"x64"
],
"libc": [
"musl"
],
"license": "MPL-2.0",
"optional": true,
"os": [