I'm using compose
during development and I find it _super_ useful. The only thing is that it takes so long to rebuild my environment (app, db, redis, worker, worker management). My workflow is, that I update one of the services and want to do up
right away. Unfortunately compose
recreates all containers, not just the one I updated.
Do you think it would make sense, if:
I'll gladly provide patch for this.
@TomasTomecek I had the same idea a while back... See this https://github.com/docker/docker/issues/11024
@aanm you're right, idea is the same; except that I would like to have this implemented in compose, not engine.
I agree this would be good; for now, you can explicitly name which services you want to recreate:
# recreate only 2 services
$ docker-compose up -d --no-deps SERVICE1 SERVICE2
# stream logs for all of them
$ docker-compose logs
Aha, --no-deps
, that's what I missed.
@aanand so if I created patch for this, would you merge it? (I would probably create new option for up
)
Let me make sure I understand what you're proposing.
compose would recreate containers which have updates images
This part I think I understand: if db
has image: postgres:latest
, then we ask the Docker API what the current image ID is for postgres:latest
. If there are db
containers with a different image ID, we recreate them.
This is sensible, but I'm basically already working on this as part of #1345. It'll eventually be the default behaviour of docker-compose up
, although to begin with will probably be behind an experimental command-line flag.
compose would rebuild images which have updates dockerfiles
This is the part that needs better specifying. How will you detect that the Dockerfile has changed? Are any of the concerns raised about @aanm's proposal in https://github.com/docker/docker/issues/11024 addressed?
Compose would stat
the dockerfile and if last modification is newer than creation time of the image, it would be recreated.
You would need to get the modified time of every file in the build context as well.
That's true. Maybe it could be configurable.
Hmm can't re just rebuild the image anyway and let the Docker cache take care of things? If nothing changed all instructions will hit the cache and the image will be unchanged.
+1 to @prologic
I'd suggest keeping the dockerfile, or a hash of it, somewhere, and comparing against that instead of using a plain stat()... if possible.
Issue #12 or #693 should allow for a way to build on up
.
Any improvements to the build need to be implemented in the engine (or possible the proposed builder that is being extracted from the engine). Once there is upstream support we can use it to conditionally build when the context has changed.
+1
+1 would be very useful
Does up --build
(#2601) solve this?
@dnephin I think so. Let's close this. I have to say that UX when respinning services improved greatly in last year.
Most helpful comment
Does
up --build
(#2601) solve this?