0% found this document useful (0 votes)
72 views

Different Docker Compose File Versions Notes

The document compares versions 1, 2, and 3 of Docker Compose files. Version 1 files specify services directly without encapsulation, have limitations around networking and dependencies. Version 2 files encapsulate services under a "services" key, automatically create a dedicated bridge network, and support dependencies with "depends_on." Version 3 is similar to version 2 but also supports Docker Swarm. It allows defining multiple networks and attaching services to different networks.

Uploaded by

Akhil Sai
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
72 views

Different Docker Compose File Versions Notes

The document compares versions 1, 2, and 3 of Docker Compose files. Version 1 files specify services directly without encapsulation, have limitations around networking and dependencies. Version 2 files encapsulate services under a "services" key, automatically create a dedicated bridge network, and support dependencies with "depends_on." Version 3 is similar to version 2 but also supports Docker Swarm. It allows defining multiple networks and attaching services to different networks.

Uploaded by

Akhil Sai
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 5

Version 1 docker file

redis:

image: redis

db:

image: postgres:9.4

vote:

image: voting-app

ports:

- 5001:80

links:

- redis

Limitations:

If want to deploy containers on different networks other than default bridge network , there is no
way of specifying that in this version of file

Alos say you have a dependency or start up order of some kind, for eg: you db container must come
up first and only then and should the voting application be started there was no way you could
specify that in version 1 of the docker compose file.

Support for these came in version 2.

The version 2 and up the format of the file also changed a little bit, you no longer specify your stack
information directly as you did before. It is all encapsulated in ‘services’ section. So create a
property called services in the root of the file and then move all the services underneath that.

Version 2:

docker-compose.yaml

services:

redis:

image: redis

db:

image: postgres:9.4
vote:

image: voting-app

ports:

- 5001:80

links:

- redis

Unlike in version 1 , version 2 will not use default bridge for communication, it creates dedicated
bridge network and uses it for communication between containers:

Another difference is with ‘networking’ in version 1 docker compose attaches all the
containers it runs to the default bridge network and use links to enable communication between the
containers as we did before with the version 2 docker compose automatically creates dedicated
bridge network

For this application and then attaches all containers to that new network. All containers then able to
communicate to each other using each other’s service name

So you basically don’t need to use links in version 2 of docker compose.

Eg:

docker-compose.yaml

services:

redis:

image: redis

db:

image: postgres:9.4

vote:

image: voting-app

ports:

- 5001:80

Q)How does the docker compose know what format you are using?

Ans) Version 2 and up you must specify the version of the docker compose file you are intending to
use by specifying the version at top of the file in this case ‘version: 2’
docker-compose.yaml

version: 2

services:

redis:

image: redis

db:

image: postgres:9.4

vote:

image: voting-app

ports:

- 5001:80

links:

- redis

If voting web application is depends upon redis application then we need to specify depends_on
property as below.

Start up oder:

Used depends_on property

docker-compose.yaml

version: 2

services:

redis:

image: redis

db:

image: postgres:9.4

vote:

image: voting-app

ports:

- 5001:80
depends_on:

- redis

version 3 ( latest as of 16-07-2019)

Version 3 is similar to version 2 in structure meaning it has a verison specification at the top and
services section under which you put all your services just like in version 2.

Version 3 comes with support for ‘docker swarm’

What if, if there is separate network for front end app and another separate network for backend
app,

Step 1:

Then create new property called networks at root level adjacent to the services in the docker
compose file and add a map of networks we are planning to use.

Step 2:

Then under each ‘service’ creates a networks property and provide a list of networks that service
must be attached to in case of Redis and DB it’s only the back-edn network, in case of fron-end app

They required both FE and BE nwt.

Eg:

version: 3

services:

redis:

image: redis

networks:

- back-end

db:

image: postgres:9.4

networks:

- back-end
vote:

image: voting-app

ports:

- 5001:80

depends_on:

- redis

networks:

- front-end
- back-end

result

image: result

networks:

- front-end
- back-end

#step 1

networks:

front-end:

back-end:

Note: add back-end to worker

You might also like