Lab session

Git-backed Deployments with Komodo

Configure a Komodo Stack from versioned Docker Compose state, deploy it, and trace the running image back to its Git commit.

Release Date Sep 21, 2026

Due Date Sep 25, 2026

Starter Code Fork repository →

Submission Link

Open assignment in Canvas→

Overview

In this lab, you configure a Komodo Stack backed by a Docker Compose file in Git. You deploy a small web service, update it from one healthy version to another, and use Komodo's deployment state to connect the running service to the Git commit that declared it.

🎯 Learning Goals

After completing this lab, you should be able to:

• Explain how Komodo Core, Periphery, a Stack, and a Git repository participate in a deployment
• Configure and deploy a Git-backed Komodo Stack
• Update a deployed service by changing its versioned Compose declaration
• Verify that the running service came from the expected Git commit and image

Deliverables

By the end of the lab, your fork's final commit should declare a Git-backed lab04 Stack that Komodo has successfully deployed as version 2. The running service and Komodo's deployed commit must both agree with that final commit. You will submit the URL of the specific deployed commit through Canvas.

Setup

Fork the starter repository to your own account, clone your fork, and open it in the provided devcontainer. Do not push commits to the upstream course repository. Instead, work entirely in your fork.

The devcontainer starts a pinned Komodo Core, its database, and a Periphery agent connected to the local Docker daemon. Wait for the devcontainer setup to finish, then open http://localhost:9120 and sign in with the local credentials in the starter README. You are ready when the Komodo interface loads and shows the local server. If Komodo is unavailable, run ./scripts/start-komodo from the repository root and try again.

The starter repository provides:

• A nearly complete compose.yml with a placeholder image reference
• A nearly complete lab04/stack.toml with a placeholder repository name
• Two healthy, digest-pinned lab images whose /version endpoints return different fixed values
• scripts/import-stack, which loads the completed Stack declaration into the local Komodo instance
• A deterministic smoke test and final checker

Run the supplied checker before changing anything:

./scripts/check-lab

The checker should report that the starter declarations are not ready for the final deployment, then exit with a failure. This initial failure is expected.

How a Git-backed Komodo Stack works

Core stores the Stack configuration and deployment records and serves the web interface. When you deploy, Core asks the local Periphery agent to fetch the configured Git branch and apply its Compose file to Docker. The files in your uncommitted working tree are not part of that path: Komodo can deploy only a commit that your fork exposes through GitHub.

Tasks

Task 1: Connect the Stack to Your Fork

Open compose.yml and replace its image placeholder with the version 1 reference from the starter README.md. Keep the linux/amd64 platform and the complete @sha256: digest in the declaration.

Open lab04/stack.toml and replace its placeholder repository with your fork in OWNER/lab-gitops-komodo form. The remaining fields describe which server Komodo should use, which repository and branch it should clone, and which Compose file it should apply.

From the repository root, validate the Compose declaration:

docker compose config --quiet

The command should exit without printing an error.

Before continuing, predict what Komodo would deploy if you changed compose.yml locally but did not commit and push the change. Then commit both declarations and push the commit to your fork so Komodo can read them.

Check your reasoning: Which copy can Komodo read?

Komodo clones the configured branch from GitHub, so it reads the latest pushed commit on that branch. It cannot see an uncommitted change or a commit that exists only in your local clone.

A digest identifies immutable image content

A tag is a movable label, while a digest identifies immutable registry content. This lab also fixes the target platform, so the declared digest selects one specific linux/amd64 image rather than a platform-dependent image from a multi-platform index. Stable artifact identity lets a deployment record say precisely which image was selected.

Task 2: Deploy Version 1 Through Komodo

lab04/stack.toml configures where the Stack runs and where its Compose file lives. The import script sends that local configuration to Komodo Core. When you deploy the Stack, Komodo fetches the pushed Compose declaration from your fork and applies it through the local server.

Load the completed declaration into the local Komodo instance:

./scripts/import-stack lab04/stack.toml

The script should report that it created or updated the lab04 Stack from your fork's main branch. Open the Komodo interface and select Stacks > lab04. Before deploying, confirm that the Stack points to the local server, your fork's main branch, and compose.yml.

Trigger the deployment and wait for Komodo to report that it completed successfully. Run the supplied smoke test to confirm that the service reports lab04 version 1.

./scripts/smoke-test 'lab04 version 1'

Open the completed deployment record and identify:

• The repository and commit Komodo read
• The image reference Docker Compose applied
• The result of the deployment operation

Compare the recorded commit with the output of:

git rev-parse --short HEAD

The hashes should agree. You do not need to copy the deployment record into the repository.

Task 3: Update to Another Healthy Version

Replace the version 1 image reference in compose.yml with the supplied version 2 digest. Commit and push that one-line change before deploying again.

The Stack configuration has not changed, so you do not need to import lab04/stack.toml again. Return to the lab04 Stack and trigger another deployment. Wait for Komodo to report that it completed successfully and confirm that the new deployment record names your latest commit. Run the smoke test again and confirm that the service now reports lab04 version 2.

./scripts/smoke-test 'lab04 version 2'

Compare the two deployment records. The Stack configuration stayed the same, while the source commit and selected image changed.

Git-backed deployment is a building block, not continuous reconciliation

In this lab, Git holds the versioned Compose declaration, but you manually tell Komodo when to apply it. A continuously reconciling GitOps design additionally uses an agent to observe desired and actual state and attempt to close any gap automatically.

Run the supplied checker once the version 2 deployment works:

./scripts/check-lab

The checker validates both declarations, asks the local Komodo API which commit it deployed, and verifies the exact version 2 response from the running service. It does not deploy the service for you. It should finish with All Lab 4 checks passed.

Additional Resources

• Komodo Docker Compose documentation: Git-backed Stack configuration and deployment
• Komodo Resource documentation: the roles of Servers, Stacks, and other resource types
• Docker Compose specification: service, image, platform, port, and health-check declarations
• Docker image digests: immutable image references and multi-platform images
• OpenGitOps principles: the additional automatic pull and continuous reconciliation properties of GitOps

Submission

1. Commit compose.yml and lab04/stack.toml, then push that commit to your fork.
2. Deploy that commit through Komodo.
3. Confirm that git status --short produces no output, then run ./scripts/check-lab one last time.
4. Submit the URL of that exact commit—not a branch or pull request—using the Canvas link below.

Open assignment in Canvas→

This lab is graded pass/fail.