Remove redundant image builds from docker-compose files about gaffer-docker

[c95560]

See https://github.com/c95560/gaffer-docker/tree/bugfix/gh-75_redundant_docker_compose_image_builds

[c95560]

On a related note, you could reduce the size of all the docker-compose with "extends" to share common configuration given many differ only on "command": https://docs.docker.com/compose/extends/

[ctas582]

Yep, you are right, docker-compose doesn't seem to recognise that the same dockerfile, context and args are being used for multiple services and unnecessarily builds them multiple times.

The reason why I decided to leave the duplicated build config in was to allow individual services to be rebuilt. For example, this doesn't work in your PR:

$ docker-compose --project-directory gaffer-docker/docker/gaffer -f gaffer-docker/docker/gaffer/docker-compose.yaml build accumulo-tserver
accumulo-tserver uses an image, skipping

Admittedly there are probably few use cases for this. Only one immediately springs to mind - local migration testing of new versions of custom iterators. I haven't actually tested this workflow works, but I image something along the lines of:

# Build all images with v1 of custom iterators
$ docker-compose build
# Spin up stack
$ docker-compose up -d
# Ingest data and query
# Stop tablet server running v1 of custom iterators
$ docker-compose stop accumulo-tserver
# Build image with v2 of custom iterators
$ docker-compose build accumulo-tserver
# Spin the tablet server up with v2
$ docker-compose start accumulo-tserver
# Run tests

If we remove the duplicated build config then you would need to know to re-build accumulo-master instead of accumulo-tserver. A minor inconvenience I guess...

Didn't know about "extends" - good spot! Would that help in this situation? Would using "extends" help docker-compose realise the services are using the same container image and only build it once, whilst still allowing us to trigger re-builds on any service?

[c95560]

Extends should let you re-trigger builds on demand, however it might be that you end up with redundant builds again... I'm not sure how intelligent docker-compose is in this regard. Might be worth a quick experiment.

Admittedly there are probably few use cases for this

You used to be able to specify multiple tags with the extends syntax, but I think the functionality has been removed since compose > 3.

[c95560]

Looks like extends was dropped for version > 3.0. (so much for the experiment)

# Stop tablet server running v1 of custom iterators
$ docker-compose stop accumulo-tserver
# Build image with v2 of custom iterators
$ docker-compose build accumulo-tserver
# Spin the tablet server up with v2
$ docker-compose start accumulo-tserver

If this is the desired behaviour then I guess you could use docker-compose.override.yml to replace the image of the accumulo-tserver service with v2 of custom iterators? This might be better practice in terms of repeatability.

e.g.

docker-compose.yml

version: "3.7"
services:
  simple-a:
    image: blah-a
    build:
      context: .
      dockerfile: blah-a.Dockerfile
  simple-b:
    depends_on:
      - simple-a
    image: blah-a

testing v2
docker-compose.override.yml

version: "3.7"
services:
  simple-b:
    image: blah-a:v2
    build:
      context: .
      dockerfile: blah-a:v2.Dockerfile

Then run aforementioned commands that stop / start simple-b (or accumulo-tserver) service only.

[d47853]

Merged into develop