Workflow for upgrading containers

[jayofdoom]

This is less a direct "issue" and more a question about how you guys do things, and if the cookbook facilitates something in a way I don't expect right now.

Lets say I have a container running some software. I build the container using something like this in my chef repo:

git '/data/software' do
  repository "https://github.com/org/software"
  revision "master"
end

docker_image "software-image" do
  path "/data/software"
  cmd_timeout 60000
  action :build
end

docker_container "software-container" do
  container_name "software-container"
  image "software-image"
  init_type "upstart"
  volume ["/data/persistentdata:/data/persistentdata"]
  command "--datadir /data/persistentdata"
  detach true
end

What would be the steps you'd follow to update the container when the git repository updates? Should I have to write out all the orchestration in chef? Create a versioned image and container? Something like this, perhaps?

docker_image "software-#{version}" do
  path "/data/software"
  action :build
end

docker_container "software-container-#{oldversion}" do
  [snip]
  action :remove
end

docker_container "software-container-#{version}" do
  [snip]
  action :create
end

All the options I've found seem tedious or difficult, and I'm curious how you're solving that problem.

Thanks,
Jay

[bflad]

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.

[jayofdoom]

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

[bflad]

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

[jayofdoom]

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?

[bflad]

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.

[jayofdoom]

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

[jayofdoom]

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

[bflad]

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.

[bflad]

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.

[jayofdoom]

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