decking icon indicating copy to clipboard operation
decking copied to clipboard

decking watch?

Open makeusabrew opened this issue 10 years ago • 4 comments

Don't want to bloat config, but this might be useful; the ability to restart containers if any files in a given path change. Naturally a container's dependents would be restarted too. Could specify container or cluster level restarts.

makeusabrew avatar Feb 03 '14 09:02 makeusabrew

This sounds very useful. We were actually thinking about functionality like this.

Any thoughts about how to sort out when a restart vs a rebuild is needed?

alexandrosm avatar Feb 04 '14 06:02 alexandrosm

I hadn't considered being able to rebuild the images powering the containers themselves - that feels like it could be pretty tricky! I mainly noted it down because in dev mode I mount my code from the host so any change needs a container restart; at the moment I have a grunt task watching certain folders but I think decking could or should do a better job of it (being a bit smarter about what it's restarting etc).

makeusabrew avatar Feb 04 '14 08:02 makeusabrew

I think restart-only makes sense. Just thought i'd throw the rebuild curveball in case you come up with anything non-obvious there.

alexandrosm avatar Feb 04 '14 08:02 alexandrosm

I think the real trouble with image rebuilds is twofold:

  1. Some Dockerfile dependencies can change implicitly; i.e. the contents of an upstream FROM image might get updated, but decking has no way of checking that (short of fetching it and prodding it occasionally). Similarly, now ADDs are cached, the contents of an ADD might change too without decking knowing (although having said that.. more on this in a minute)
  2. Some containers may not specify locally built images. In one cluster I have a redis & mongo instance which are just images from the public Docker Index. Although again in these instances I suppose it's understandable that you'd never rebuild an image, since it's not yours to rebuild in the first instance...

Going back to the ADD point, I had thought about trying to be smart with watch, and in addition to allowing standard watch style syntax (e.g. file patterns), rummaging through each locally referenced Dockerfile in the images object and watching any paths specified by any ADD directives. The way I've started laying out my projects, that alone would probably be enough - meaning I could "docker watch" without having to specify any config at all... which would be awesome (it's never going to be that simple, but there's mileage in that).

Image rebuilding - or the feasibility of it - may well come out in the wash when I get around to implementing watch. I'll keep you posted :)

makeusabrew avatar Feb 04 '14 08:02 makeusabrew