Workflow for upgrading containers about docker HOT 10 CLOSED

Honestly, I think this is related to #56. Without build building every run, you'd have to do something like you suggested with the image. A notifies :build won't help in the Git resource either.

from docker.

@bflad I'm sure #56 is part of the path to fixing this; but somewhere in there you'd still need to create a new container against the new image, right?

Just trying to figure out how to make all the pieces fit together, and if there's something we can do in the cookbook at a higher level to make it easier (i.e. automatically removing and recreating a container if the underlying image has been updated and a flag is set on the container)

from docker.

Thinking out loud, I'd imagine you'd be able to add a notifies [:kill, :remove, :run], 'docker_container[software-container], :immediately' to your docker_image resource (when it actually can build repeatedly).

Seeing that notifies of three actions makes me want to just have a shorthand one like :redeploy or something...

from docker.

Yeah, that's what I'm saying. There seems like a shortcut should exist that doesn't currently. And if we added a redeploy, we could make it so something like a docker stop; wait $timeout, then docker kill if it hasn't died, remove the container, and recreate it.

Along with this, something like a docker_container_cleanup and docker_image_cleanup LWRP would be helpful for ensuring you don't end up with 200 old images and containers.

WDYT?

from docker.

Sorry, the docker stop command already does that stop, wait for timeout, kill sequence you mentioned. Meant to say :stop, :remove, :run above.

I'm not sure the cookbook should manage extraneous images/containers in your environment. I'd think that's a non-trivial operation. It'd likely have to be a library method that loads all the known Chef docker_image/docker_container resources and removes objects that aren't in that list.

from docker.

@bflad I guess my concern is that if you're rebuilding images, the chef cookbook itself is creating extraaneous images -- the ones you're replacing with a new build, the intermediate images that may need to be created by extra builds, etc.

For instance, in my example (admittedly, building on the host is not the best workflow though), if I run chef twice a day, and both times it had an update to the repo which triggers a rebuild, and the first command in the dockerfile is "add . /data/myapp", then in 5 days time, I could have twenty or thirty old, intermediate images. My concern would be to ensure those got cleaned up occasionally, although I do agree that a blanket cleanup is probably a little too dangerous for the cookbook, on further reflection.

from docker.

I'm going to add :redeploy today. Hopefully #56 can get fixed up soon too then this workflow will be great.

from docker.

Didn't see any commits to your repo, so went ahead and implemented it myself. Will be released in 0.30.0 later tonight. Not going to close this out until #56 happens.

from docker.

build action was changed in 0.30.0 as well. I'm going to close this issue, but we should create another one if anyone feels strongly towards handling extraneous builds.

from docker.

Thanks, I had implemented this but was finishing up the docs and didn't get it pushed.

from docker.