Actionable walkthroughs on containerization, multi-stage builds, microservices orchestration, container networking, and DevOps pipelines.
The Compose specification is the schema that defines what a compose.yaml file can contain. It is not a Docker-specific format; it is an open specification that Docker Compose, Docker Swarm (partially), and other tools implement. The specification defines the top-level elements — services, networks, volumes, configs, secrets, and the project-level settings — and the sub-elements…
A multi-container application has an order. The database must be ready before the API can connect. The API must be ready before the frontend can proxy to it. The migration must complete before the application starts serving traffic. Compose’s depends_on is the key that expresses this order, and the key has two forms with very…
A Compose service is an abstract definition of a container. When the service is started, Compose creates one container for it. The scale option and the –scale flag create multiple containers for the same service, and Docker’s embedded DNS server load-balances the requests across them. The scaling is horizontal: more containers of the same service,…
The Compose file is not a single static document. It is a base configuration, and it can be layered with override files, scoped with profiles, and merged into a final model that Compose resolves before starting any container. This layering is what allows a single repository to serve development, testing, and production without duplicating the…
A microservices application has several services, and each one has its own codebase, its own dependencies, and its own runtime. Running the whole stack locally is the daily reality of a developer working on one of those services. The naive approach is to run the service under development with a local toolchain and run the…
Every container writes to stdout and stderr. That much is universal. What happens next depends entirely on the logging driver. The driver decides where the output goes, how it is formatted, and how long it is kept. Docker ships with a set of built-in drivers that cover the common cases: the local JSON files, the…
A single container’s logs are accessible with docker logs. A hundred containers across ten hosts are not. The logs are scattered across the machines, and the search requires the SSH into each one. The centralized log aggregation solves the problem: the container logs are shipped to a central system, indexed, and searchable from the single…
A running container is not the same as a healthy container. The docker ps shows the Up status, but it does not show the CPU spikes, the memory growth, the network saturation, or the disk I/O. The monitoring stack answers the question the docker stats cannot: what is the trend, what is the historical baseline,…
The Docker daemon is the background process that builds, runs, and manages every container on the host. It listens on the socket, pulls the images, starts the containers, and writes the logs. By default, it works well enough for the basic use, but the production environment demands the control over the logging, the storage, the…
A Docker host accumulates garbage. The stopped containers linger, the dangling images pile up, the build cache grows, and the unused volumes sit idle. The disk fills slowly, and then suddenly the builds fail, the pulls fail, and the daemon stops responding. The cleanup is not a one-time task; it is the ongoing maintenance. The…