Advantage of using docker-compose file version 3 over a shellscript?

Question

My initial reason for creating a docker-compose.yml, was to take advantage of features such as build: and depends-on: to make a single file that builds all my images and runs them in containers. However, I noticed version 3 depreciates most of these functions, and I'm curious why I would use this over building a shellscript.

This is currently my shellscript that runs all my containers (I assume this is what the version 3 docker-compose file would replace if I were to use it):

echo "Creating docker network net1"
docker network create net1

echo "Running api as a container with port 5000 exposed on net1"
docker run --name api_cntr --net net1 -d -p 5000:5000 api_img

echo "Running redis service with port 6379 exposed on net1"
docker run --name message_service --net net1 -p 6379:6379 -d redis

echo "Running celery worker on net1"
docker run --name celery_worker1 --net net1 -d celery_worker_img

echo "Running flower HUD on net1 with port 5555 exposed"
docker run --name flower_hud --net net1 -d -p 5555:5555 flower_hud_img

Does docker-swarm rely on using stacks? If so then I can see a use for docker-compose and stacks, but I couldn't seem to find an answer online. I would use version 3 because it is compatible with swarm, unlike version 2 if what I've read it true. Maybe I am missing the point of docker-compose completely, but as of right I'm a bit confused as to what it brings to the table.

Answer 1

Readability

Compare your sample shell script to a YAML version of same:

services:
  api_cntr:
    image: api_img
    network: net1
    ports:
      - 5000:5000
  message_service:
    image: redis
    network: net1
    ports:
      - 6379:6379
  celery_worker1:
    image: celery_worker_img
    network: net1
  flower_hud:
    image: flower_hud_img
    network: net1
    ports:
      - 5555:5555    

To my eye at least, it is much easier to determine the overall architecture of the application from reading the YAML than from reading the shell commands.

Cleanup

If you use docker-compose, then running docker-compose down will stop and clean up everything, remove the network, etc. To do that in your shell script, you'd have to separately write a remove section to stop and remove all the containers and the network.

Multiple inheriting YAML files

In some cases, such as for dev & testing, you might want to have a main YAML file and another that overrides certain values for dev/test work.

For instance, I have an application where I have a docker-compose.yml as well as docker-compose.dev.yml. The first contains all of the production settings for my app. But the "dev" version has a more limited set of things. It uses the same service names, but with a few differences.

1. Adds a mount of my code directory into the container, overriding the version of the code that was built into the image
2. Exposes the postgres port externally (so I can connect to it for debugging purposes) - this is not exposed in production
3. Uses another mount to fake a user database so I can easily have some test users without wiring things up to my real authentication server just for development

Normally the service only uses docker-compose.yml (in production). But when I am doing development work, I run it like this:

docker-compose -f docker-compose.yml -f docker-compose.dev.yml up -d

It will load the normal parameters from docker-compose.yml first, then read docker-compose.dev.yml second, and override only the parameters found in the dev file. The other parameters are all preserved from the production version. But I don't require two completely separate YAML files where I might need to change the same parameters in both.

Ease of maintenance

Everything I described in the last few paragraphs can be done using shell scripts. It's just more work to do it that way, and probably more difficult to maintain, and more prone to mistakes.

You could make it easier by having your shell scripts read a config file and such... but at some point you have to ask if you are just reimplementing your own version of docker-compose, and whether that is worthwhile to you.