Originally published on docker.learnio.dev — part of the Docker fundamentals course. View this lesson on the original site.

When something breaks, resist the quick fix inside the container

The tempting move is to jump into a running container and patch it by hand:

docker exec -it hello-nginx sh

Inside that shell, you might install a package, edit a config file, or change permissions so the app starts. That can get you unblocked in the next five minutes. It also creates a container that no longer matches what is in the repo.

Put the fix in the files Docker builds from

The repeatable workflow looks like this:

  1. change the Dockerfile, Compose file, or application code
  2. rebuild the image
  3. run or deploy from that rebuilt image
flowchart LR
    A["change Dockerfile or Compose"] --> B["rebuild image"]
    B --> C["run a fresh container"]

Your source of truth should be the files in the repo, not whatever happened to exist inside one running container five minutes ago.

Example with a Dockerfile

Suppose nginx is missing a tool you need. Put the change in the Dockerfile:

FROM nginx:stable-alpine
RUN apk add --no-cache curl

Rebuild the image and run a fresh container:

docker build -t hello-nginx:local .
docker run --rm -d --name hello-nginx -p 127.0.0.1:8080:80 hello-nginx:local

docker build creates a new image from the Dockerfile. docker run starts a new container from that image instead of reusing the old patched one.

Example with Compose

If the project already uses Compose, rebuild and restart the service from the files:

docker compose build
docker compose up -d

You can combine those into one step when you are iterating locally:

docker compose up -d --build

That rebuilds what changed and brings the stack back up from the updated image.

What belongs in the build, not in a live shell

Runtime problems often belong in the build story:

  • a missing package
  • the wrong system library
  • file permissions that block startup

Fix those in the Dockerfile or related config, then rebuild. That way the same fix shows up for the next developer, in code review, and in CI.

From Docker fundamentals — Install Docker, see the value, and learn the basics