Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

decking watch? #27

Open
makeusabrew opened this issue Feb 3, 2014 · 4 comments
Open

decking watch? #27

makeusabrew opened this issue Feb 3, 2014 · 4 comments

Comments

@makeusabrew
Copy link
Owner

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.

@alexandrosm
Copy link
Contributor

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?

@makeusabrew
Copy link
Owner Author

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).

@alexandrosm
Copy link
Contributor

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

@makeusabrew
Copy link
Owner Author

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants