Add new guides for all of the new labspaces

This commit is contained in:
Michael Irwin
2026-04-02 14:42:00 -04:00
parent 346829436f
commit 4959df3e31
11 changed files with 498 additions and 40 deletions
+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 Memes-R-Us 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
- Automate deployments so every push to `main` triggers a rollout
## 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: /docker-hub/hardened-images/
- 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 | Configure Docker login, DHI tier selection, and Docker Scout org |
| 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 |
+2 -1
View File
@@ -1,5 +1,6 @@
{{ $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 }}
@@ -7,6 +8,6 @@
{{ $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 := "2. Open your browser to [http://localhost:3030](http://localhost:3030)." }}
{{ $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": [