Building common dependencies with docker-compose

It’s possible. There’s a kind of workaround. You’re close, but you were missing explicit image tags (so you had little ability on child images to declare which image you inherited from).

version: '3.2'
services:
  base:
    image: mybaseimage
    build: ./path-to-base-dockerfile
  child1:
    build: ./path-to-child1-dockerfile
    depends_on:
      - base
  child2:
    build: ./path-to-child2-dockerfile
    depends_on:
      - base

Let’s say you have no images built. You run docker-compose up. The following things will happen:

  • docker-compose sees that child1 and child2 services depend on base. So it will deploy base first.
  • docker-compose sees that you have not yet tagged any image as mybaseimage. It knows how to build mybaseimage (you gave it a build path), so it will build it now, and tag it as mybaseimage.
  • docker-compose deploys the base service.
    • ideally you should design base so that it quits immediately, or has no entrypoint. since we don’t actually want it to run this service.
  • docker-compose considers deploying child1 and child2
  • docker-compose sees that you have not yet tagged any image as child1. It knows how to build child1 (you gave it a build path), so it will build it now, and tag it as child1.
  • docker-compose deploys the child1 service
  • same sequence of steps for child2

The next docker-compose up will be simpler (we have tagged images available, so we skip all build steps).

If you already have tagged images, and want to rebuild: use docker-compose build to tell it to build all images (yes, base and children will both be rebuilt).

Leave a Comment

Hata!: SQLSTATE[HY000] [1045] Access denied for user 'divattrend_liink'@'localhost' (using password: YES)