Local Development with Docker Compose and Kubernetes

A local environment lets you try a change without touching a real service. The best setup is the smallest one that helps you answer today’s question.

You do not need a cluster for every code edit. Start with the app process. Add containers or Kubernetes when their behaviour matters to the task.

Three useful levels

• Python directly: Fast feedback for ordinary code and unit tests.
• Docker Compose: A repeatable way to run several local services.
• Local Kubernetes: Useful for testing manifests, Services, probes and rollout behaviour.

Start with one app

Copy app.py and its Dockerfile from the Docker lesson. Test the code with Python first. Then add this compose.yaml:

services:
  web:
    build: .
    image: lecturre-web:1.0
    ports:
      - "127.0.0.1:8085:8080"
    environment:
      APP_VERSION: "1.0"
    read_only: true
    tmpfs:
      - /tmp
    healthcheck:
      test: ["CMD", "python", "-c", "import urllib.request; urllib.request.urlopen('http://127.0.0.1:8080/health', timeout=2)"]
      interval: 10s
      timeout: 3s
      retries: 3

docker compose config
docker compose up --build
docker compose ps
docker compose logs web

docker compose config checks and expands the configuration. With the engine running, up builds and starts it. The app is on http://127.0.0.1:8085.

The health check calls the app from inside its container. A health result tells you something about that test, not every possible user journey.

Change one thing at a time

Change APP_VERSION in the Compose file and recreate the service. Check the returned version. Changing an environment variable does not rewrite an already running process by magic.

This example copies code into the image. Editing app.py on your laptop needs a rebuild. Bind mounts or development sync tools can make code changes faster, but that is a different setup.

Service names are addresses

Inside a Compose network, one service can reach another by service name. For example, Prometheus reaches web:8080.

Inside a container, localhost normally means that container, not your laptop or another service. This is a common reason a connection works in a browser but fails inside an app.

When to add a local cluster

Use kind or minikube when you need Kubernetes behaviour. kind runs cluster nodes as containers. Follow the named-cluster setup in the Kubernetes lesson.

Remember that a local cluster does not reproduce every managed-cloud feature. Load balancers, identity, storage and zone failures may behave differently.

Other development tools

Dev Containers can describe a shared development environment for a supported editor. Tilt and Skaffold can help rebuild or sync code in a Kubernetes workflow. Pick one after you understand the basic build-run-test loop.

Do not add three new tools to solve one slow command. Measure where time is going first.

Data and configuration

Use small demo data rather than copied customer records. Keep local secrets outside shared images and repositories. If you use a volume, write down what persists when containers stop.

Starting a database container is not the same as having a safe backup. Practise restoring a small test backup separately.

Cleanup

Stop the foreground app with Ctrl+C. Run docker compose down for this project when finished. Adding --volumes removes project volumes too, so use that option only when you intend to lose their data.

Practice

Write a README that answers: How do I start? Which ports are used? What data is saved? How do I see logs? How do I clean up? Ask another person to follow it from an empty folder.

Official references and further reading

Reviewed on 25 October 2026. Tools change, so check the official documentation for the version you use.

• Docker Compose getting started
• kind quick start

DevOps learning roadmap · All DevOps & Cloud tutorials