Docker Compose will BLOW your MIND!! (a tutorial)

TL;DR

Docker Compose uses a `docker-compose.yml` file to define services, networks, and configuration so an entire stack can start with `docker compose up -d`.

Briefing Cornell Notes

Briefing

Docker Compose turns “spin up one container” work into “deploy an entire stack” with a single YAML file and one command. In practice, it can create a multi-container infrastructure in seconds—then tear it all down just as quickly—without manually running long sequences of `docker run` commands. That shift matters because it makes repeatable environments (labs, web apps, dev setups) far easier to create, share, and re-create.

The walkthrough starts with the basics: install Docker Compose on a Linux environment (the tutorial uses a Kali Linux VM in VirtualBox, but the approach is general). After installation, it demonstrates the old way—running a single Nginx container with port exposure—then mirrors the same outcome using Compose. The key workflow is to create a dedicated project folder, add a `docker-compose.yml` file, and run `docker compose up -d` from that same directory. The example defines a `services` section with a `website` container using the `nginx` image, maps host ports to container ports (host `80` to container `80`, with an alternate host port to avoid conflicts), and sets `restart: always`.

Once the Compose file is in place, the container naming and networking behavior become part of the “magic.” Compose automatically names containers using the project folder plus the service name (e.g., `coffee_time_website_1`) and creates a default bridge network when no custom network is specified. Verification is done with `docker compose ps` (showing only containers in that Compose project) and by checking the mapped localhost ports. Cleanup is equally simple: `docker compose down` removes containers and the network, while `docker compose stop` halts containers without deleting them.

The tutorial then scales up. It adds a second Nginx service by duplicating the service definition with a different host port, and it introduces a custom network defined in the Compose YAML under a top-level `networks` section. Using IP address management (IPAM) and a bridge driver, it assigns a specific subnet and gives one container a fixed IP via `ipv4_address`. When the Compose file changes, running `docker compose up -d` again updates the running setup—creating the new network and recreating affected containers.

Finally, the walkthrough uses Docker Compose to deploy WordPress, which requires multiple cooperating components. The Compose file defines two services: `wordpress` (using the official WordPress image) and `mysql` (using `mysql:5.7`). Environment variables wire them together—WordPress points at the MySQL service name for host, database name, and credentials. `depends_on` ensures MySQL starts before WordPress. A `volumes` mapping persists MySQL data by binding the container’s `/var/lib/mysql` to a host directory, so `docker compose down` and later re-`up` preserve the database and keep the same site content.

The result is a repeatable pattern: describe containers, networks, dependencies, and persistent storage in YAML; then manage the whole system with a small set of Compose commands. The same approach can be extended to larger lab environments, including multi-container vulnerable setups and other packaged stacks like Minecraft-style projects or Pi-hole deployments.

Cornell Notes

Docker Compose lets users define an entire multi-container application in a single `docker-compose.yml` file and manage it with one command. The tutorial demonstrates starting with a simple Nginx service, then scaling to multiple services and custom networks with fixed IPs. Compose automatically names containers based on the project folder and creates a default bridge network unless overridden. For WordPress, Compose coordinates two containers—WordPress and MySQL—using environment variables, `depends_on` for startup order, and a volume mapping to persist MySQL data on the host. This combination makes it easy to spin up, update, and tear down complex stacks while keeping state where it matters.

How does Docker Compose replace the “manual” `docker run` workflow in the tutorial’s first example?

Instead of running a single container with `docker run`, the tutorial creates a project folder and writes `docker-compose.yml`. In that YAML, the `services` section defines the container (service name like `website`), the image (`nginx`), port mappings (host port to container port), and a restart policy (`restart: always`). Running `docker compose up -d` from the same directory where the YAML lives starts the container(s) described in the file, and `docker compose down` removes them along with the network.

Why does the tutorial emphasize running Compose commands from the directory containing `docker-compose.yml`?

Compose uses the current directory’s project context. The tutorial notes that if the command is run from the wrong location, Compose won’t automatically find the YAML and would require specifying the file explicitly (using a `-f` option). Running from the correct folder also affects naming: the container name includes the folder name (e.g., `coffee_time_website_1`), which is why the dedicated folder matters.

What networking behavior does Compose provide by default, and how can it be customized?

With no custom network defined, Compose creates a default bridge network and attaches the containers to it automatically. To customize, the tutorial adds a top-level `networks` section in the YAML, defines a bridge driver, and uses IPAM to set a subnet. Then it assigns a container to that network and pins an IP using `ipv4_address`, so the container lands at a predictable address inside the subnet.

How does Compose ensure WordPress can talk to MySQL in the WordPress deployment example?

The WordPress service includes environment variables that reference the MySQL service by name (the tutorial uses `mysql` as the service name). Those variables include the database host, database name, and credentials (e.g., database password set to `coffee`). Because Docker Compose creates a shared network for the services, WordPress can reach MySQL at the service name rather than an external IP.

What roles do `depends_on` and volumes play in the WordPress + MySQL setup?

`depends_on` tells Compose to start MySQL before WordPress, preventing WordPress from attempting to connect to a database that isn’t up yet. Volumes persist data: the tutorial maps the MySQL container’s `/var/lib/mysql` to a host directory. That way, even after `docker compose down`, the database files remain on the host and the site comes back with the same content when the stack is started again.

Review Questions

In the tutorial’s Nginx example, what determines the container name format like `coffee_time_website_1`?
When defining a custom network in Compose, where do `networks` and IPAM configuration live in the YAML, and how is a container attached to that network?
For the WordPress deployment, which specific Compose features handle (1) startup order and (2) database persistence, and what are their YAML sections?

Key Points

1
Docker Compose uses a `docker-compose.yml` file to define services, networks, and configuration so an entire stack can start with `docker compose up -d`.
2
Compose commands should be run from the directory containing the YAML file to avoid needing `-f` and to ensure correct project-based naming.
3
Compose automatically creates a default bridge network when no custom network is defined, and it names containers using the project folder plus the service name.
4
Custom networks can be defined in the YAML under a top-level `networks` section, including IPAM subnet settings and fixed container IPs via `ipv4_address`.
5
Scaling a stack typically means adding more entries under `services` and adjusting port mappings to avoid host conflicts.
6
For multi-component apps like WordPress, environment variables connect services (WordPress points to the MySQL service name), while `depends_on` controls startup order.
7
Persisting database state requires a volume mapping so MySQL data survives `docker compose down` and later re-`up`.

Highlights

A single Compose command can create a multi-container infrastructure in seconds and remove it just as quickly with `docker compose down`.

Compose container names and networks are tied to the project directory, which is why running commands from the YAML folder matters.

Custom networking in Compose supports fixed IP assignment using IPAM and `ipv4_address`, enabling predictable inter-container addressing.

WordPress deployment hinges on service-to-service wiring: environment variables point WordPress at the MySQL service name, while `depends_on` and volumes handle reliability and persistence.

Topics

Docker Compose Basics
YAML Configuration
Container Networking
WordPress and MySQL
Persistent Volumes