Imagine an online store:
One container for the web front-end (React or Angular)
One for the backend API (Python, .NET, Node, etc.)
One for the database (PostgreSQL, MongoDB…)
Maybe others: authentication, caching (Redis), logging...
Each container handles one responsibility — but all of them must communicate.
If you had to start each with docker run and wire their networks manually, it
would be messy.
First Solution : Using Links
1. Docker run –link <container_name>:<alias_inside_target>
2.
The left “redis” → real container name that already exists.
The right “redis” → alias/hostname that the voting-app container will use to
reach it.
That’s exactly the problem Docker Compose solves.
What Compose does
Compose lets you define all your containers and their relationships in a single
YAML file (usually [Link]).
It does two main things:
1. Describes each service (its image, ports, volumes, networks, environment
variables, etc.)
2. Manages them together as one logical application:
o docker compose up → starts all containers
o docker compose down → stops and removes them
o You can also rebuild, restart, or view logs for all services at once.
Steps to create docker [Link] :
0-create services and specify version 3
Networking is automatic: every service is on a custom bridge network,
with name-based DNS.
1-create a dictionary of container names
2-specifiy image name of the propriete container
Image :
3-adding ports :
Ports :
- 5000:80
When specifiying an image name he check docker registery if I want to use my
own image
Image : deviant build : ./vote
./ current path
3.5 controls startup order, not networking:
- depends_on: container name
4-building the docker compose
1. docker compose up
This command:
Starts all the containers defined in your [Link]
Creates networks & volumes if they don’t exist
Uses existing images (it will NOT rebuild them)
So if your images are already built — this just runs them.
But if your source code or Dockerfile has changed, it won’t pick up the changes —
it’ll still use the old images.
1. docker compose up --build
This does everything the normal up does, plus:
This does everything the normal up does, plus:
Rebuilds the images from your build: paths
(reads your Dockerfile again, re-copies your code, installs dependencies,
etc.)
Then it starts the containers using those freshly built images.
So this is the one you use when you’ve changed:
Any code that gets copied into the image
Any dependency (like [Link], [Link], etc.)
The Dockerfile itself
Tip: combine with -d
When you’re done testing, run detached mode (no logs in terminal):
docker compose up -d --build
That rebuilds everything and runs it in the background.
Exemples
volumes:
- sql_data:/var/opt/mssql
#Take a storage space (called sql_data) and attach it to the path /var/opt/mssql
inside the container.”
sql_data is a named Docker volume that lives on your host (under
/var/lib/docker/volumes/…).
It is mounted into the SQL Server container at /var/opt/mssql.
In the end
volumes:
sql_data: