Docker for DevOps: What to Learn and What to Skip

Why Docker comes after running an app by hand

At step 5, you installed a language runtime, packages and config files on a server, one command at a time. Then you rebuilt it from your notes and saw how easily the steps go wrong. A new server may also have a different version of something, and the app breaks.

Docker solves that problem. Your runbook turns into a Dockerfile, which builds the same image every time. Because you know what each line replaces, the Dockerfile will make sense. It also sets up CI/CD, which will build this image for you.

What to learn, in order

1. Images and containers. Start with the Docker overview. Run an existing image with docker run, and use docker ps to see what is running.
2. Publishing ports. Containers have their own network. -p 8080:8000 sends port 8080 on your machine to port 8000 in the container. You will use your networking skills to debug this.
3. Writing a Dockerfile. Learn FROM, COPY, RUN, CMD and WORKDIR. Turn your app's install steps into these lines.
4. Layers and the build cache. Each step creates a layer, and Docker reuses layers that did not change. Copy your dependency list and install it before you copy your code. Otherwise every code edit reinstalls everything.
5. .dockerignore. This file keeps things like .git and .env out of the build. It makes builds faster and helps keep secrets out of the image.
6. Multi-stage builds. A multi-stage build uses one stage to build the app and another to run it. Build tools stay out of the final image, so it is smaller and exposes less.
7. Running as non-root. Add a USER line to your Dockerfile. If someone breaks into the app, they then have fewer rights inside the container.
8. Volumes. A container's own files are lost when you remove it. A volume keeps data outside the container, which your database needs.
9. Compose. Docker Compose starts several containers from one file. Your app can reach the database by its service name, such as db, instead of an IP address.
10. Debugging. Use docker logs first, then docker exec -it <container> sh to look around inside. docker inspect shows settings such as the exit code. Very small images may not include a shell.
11. Registries. A registry stores images, so servers can pull them. Docker Hub and GitHub Container Registry are common choices.

What to skip for now

• Docker Swarm. Kubernetes is the orchestration tool on this roadmap.
• Comparing Docker with Podman and other tools. The ideas carry over.
• Writing your own container runtime, or studying how namespaces work in depth.
• The Docker Certified Associate (DCA) exam.
• Advanced custom network setups. The default Compose network is enough for your project.

Common mistakes

• Putting secrets in the image. Anyone who can pull the image can read its layers, and deleting a file in a later layer does not remove it from an earlier one. Pass secrets in when the container starts.
• Copying your code before installing dependencies. One code edit then invalidates the cache, and every build starts over.
• Keeping database data only inside the container. Removing the container then removes the data. Use a volume, and take care with docker compose down -v, because -v deletes volumes too.
• Using the latest tag in production. It does not tell you what version is running, and it can change without warning. Tag images with a version or a Git commit.
• Publishing the database port. On Linux, Docker's published ports can bypass ufw rules. In Compose, your app can reach the database without publishing its port at all.
• Using --privileged or mounting the Docker socket to fix a permission error. Either one can give the container control over the host. Find out which permission is missing, and fix that.

Your project

Package the app from step 5:

1. Write a multi-stage Dockerfile that runs as non-root. Note the image size before and after you make it multi-stage.
2. Write a Compose file with the app, Postgres and a named volume. Use a .env file for the password, and keep it out of Git.
3. Prove that the data survives docker compose down and docker compose up.
4. Restore your pg_dump backup into the Postgres container, to show that your backup still works here.
5. Push the image to a registry, and run it on your server from there.

Then look back at your runbook and mark each step Docker now handles. The steps left, such as building and pushing the image on each change, are what CI/CD automates next.