mirror of
https://github.com/docker/docs.git
synced 2026-06-19 07:35:16 +00:00
Add new guides for all of the new labspaces
This commit is contained in:
@@ -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 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 |
|
||||
@@ -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 |
|
||||
@@ -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 |
|
||||
@@ -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") }}
|
||||
|
||||
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