mirror of
https://github.com/docker/docs.git
synced 2026-06-19 07:35:16 +00:00
Merge pull request #24614 from mikesir87/add-new-labs
Create new guides for several new labspaces
This commit is contained in:
@@ -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
|
||||
|
||||
@@ -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.
|
||||
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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).
|
||||
|
||||
@@ -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).
|
||||
|
||||
@@ -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") }}
|
||||
Generated
+15
-39
@@ -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": [
|
||||
|
||||
Reference in New Issue
Block a user