Difference between links and depends_on in docker_compose.yml
According to the Docker Compose's compose-file documentation:
- depends_on - Express dependency between services.
- links - Link to containers in another service and also express dependency between services in the same way as depends_on.
I don't understand the purpose of linking to other containers so the difference between two options still seems quite difficult for me.
It would be much easier if there is an example, but I can't find any.
I noticed, when I link container B with container A then container B will be "pingable" inside container A's shell.
I ran ping B inside container A's bash and got result like this (just for reference, image from the Internet)
The post needs an update after the links option is deprecated.
Basically, links is no longer needed because its main purpose, making container reachable by another by adding environment variable, is included implicitly with network. When containers are placed in the same network, they are reachable by each other using their container name and other alias as host.
For docker run, --link is also deprecated and should be replaced by a custom network.
docker network create mynet docker run -d --net mynet --name container1 my_image docker run -it --net mynet --name container1 another_image
depends_on expresses start order (and implicitly image pulling order), which was a good side effect of links.
This answer is for docker-compose version 2 and it also works on version 3
You can still access the data when you use depends_on.
If you look at docker docs Docker Compose and Django, you still can access the database like this:
version: '2' services: db: image: postgres web: build: . command: python manage.py runserver 0.0.0.0:8000 volumes: - .:/code ports: - "8000:8000" depends_on: - db
What is the difference between links and depends_on?
When you create a container for a database, for example:
docker run -d --name=test-mysql --env="MYSQL_ROOT_PASSWORD=mypassword" -P mysql docker inspect d54cf8a0fb98 |grep HostPort
And you may find
This means you can connect the database from your localhost port 32777 (3306 in container) but this port will change every time you restart or remove the container. So you can use links to make sure you will always connect to the database and don't have to know which port it is.
web: links: - db
I found a nice blog from Giorgio Ferraris Docker-compose.yml: from V1 to V2
When docker-compose executes V2 files, it will automatically build a network between all of the containers defined in the file, and every container will be immediately able to refer to the others just using the names defined in the docker-compose.yml file.
So we don’t need links anymore; links were used to start a network communication between our db container and our web-server container, but this is already done by docker-compose
Express dependency between services, which has two effects:
- docker-compose up will start services in dependency order. In the following example, db and redis will be started before web.
- docker-compose up SERVICE will automatically include SERVICE’s dependencies. In the following example, docker-compose up web will also create and start db and redis.
version: '2' services: web: build: . depends_on: - db - redis redis: image: redis db: image: postgres
Note: depends_on will not wait for db and redis to be “ready” before starting web - only until they have been started. If you need to wait for a service to be ready, see Controlling startup order for more on this problem and strategies for solving it.
[Update Sep 2016]: This answer was intended for docker compose file v1 (as shown by the sample compose file below). For v2, see the other answer by @Windsooon.
Containers for the linked service will be reachable at a hostname identical to the alias, or the service name if no alias was specified.
For example, assuming the following docker-compose.yml file:
web: image: example/my_web_app:latest links: - db - cache db: image: postgres:latest cache: image: redis:latest
With links, code inside web will be able to access the database using db:5432, assuming port 5432 is exposed in the db image. If depends_on were used, this wouldn't be possible, but the startup order of the containers would be correct.