Page 10 - Docker

docker exec and docker attach look interchangeable at first glance, both give access to a running container. Technically, though, they are two fundamentally different mechanisms. Anyone who does not understand the difference risks accidentally stopping the main process in production, simply because a terminal window was closed.

Anyone maintaining three separate compose files for dev, test and CI ends up writing configuration three times and regularly forgets to sync changes across them. Docker Compose Profiles solve this problem at the root: services are only started when the matching profile is active, one file for every environment.

Docker containers are not magic and not lightweight virtual machines either, they are ordinary Linux processes that the kernel starts with a restricted view of processes, networking, and the filesystem through namespaces, while cgroups cap their resource usage. Understanding both mechanisms lets you inspect and reason about any running container directly from the host.

Container tooling like Docker and Kubernetes ships with powerful CLIs, but only Bash automation ties health checks, rollout control and alerting into a complete workflow. Teams that automate Docker and Kubernetes workflows with Bash cut down on manual intervention and make deployments traceable, repeatable and safe.

A container that suddenly dies with exit code 137, no panic, no log output, no visible error, is one of the most frustrating Docker problems there is. In the vast majority of cases the Linux OOM killer is behind it, and the actual problem is rarely the code, it is a poorly estimated memory limit.

The choice of minimal base image determines compatibility, debugging capability and maintenance effort for the entire lifetime of a Docker image. Alpine with musl libc, Debian slim with the full glibc ecosystem, distroless without any shell, and scratch as a completely empty foundation solve different problems and each fit different project requirements.

Docker is not just a runtime, it is a portable build environment. Teams that create deployment artifacts from Docker builds get reproducible binaries, static assets and archives without installing the build toolchain on the CI server or the developer machine.

docker compose config shows the configuration actually merged from multiple -f files and checks it for syntax errors before the stack is even started, surfacing override problems far faster than debugging an already running container.

Anyone debugging Magento errors constantly switches between PhpStorm and a terminal running tail -f exception.log. PhpStorm offers built-in ways to follow, filter and link log files with the source code directly in the IDE, without that context switch.

Docker Compose can do more than launch main services. Sidecar containers forward logs and export metrics. Utility containers provide CLI tools without a local install. Init containers run before the main service and carry out database migrations. One off jobs handle maintenance tasks on demand. This article explains all four patterns, each with the right tool for the right purpose.