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 buildmybaseimage(you gave it a build path), so it will build it now, and tag it asmybaseimage. - docker-compose deploys the
baseservice.- ideally you should design
baseso that it quits immediately, or has no entrypoint. since we don’t actually want it to run this service.
- ideally you should design
- docker-compose considers deploying child1 and child2
- docker-compose sees that you have not yet tagged any image as
child1. It knows how to buildchild1(you gave it a build path), so it will build it now, and tag it aschild1. - docker-compose deploys the
child1service - 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).