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

docker_compose doesn't use the latest image for a service, after it's rebuilt #491

Open
giavac opened this issue Mar 31, 2016 · 3 comments
Labels

Comments

@giavac
Copy link

giavac commented Mar 31, 2016

garethr-docker module v5.1.0 (from puppet module install garethr-docker) on CentOS 7.2.1511 and Puppet 3.8.6 (stock), Docker 1.10.3, Compose 1.6.2.

I have this scenario: two services are running using docker_compose, and there are cases where the Dockerfiles change, and I'd like the changes to be reflected by the running services.
When deploying the Dockerfiles and all the related files in the building context, Puppet can detect that a Dockerfile has changed and, for example, run docker-compose build, causing the required images to be re-built.

At this point the two services are still running, but not using the latest images.

I was expecting he docker_compose resource to trigger a docker-compose up -d in order to adapt the running services to the latest images, but this is not happening.
lib/puppet/provider/docker_compose/ruby.rb only checks that the services are running, and docker ps --format '"{{.Label "com.docker.compose.service"}}"' --filter 'label=com.docker.compose.project=myproject' does indeed return two items, which prevents docker-compose up -d to execute. If I execute it manually then I have the desired behaviour, with the latest images used.

Apologies if this is not perfectly described, but do you think I have the right expectations? Why not running docker-compose up -d always, and let docker-compose deal with the latest images?

As a corollary for this, it would be nice if docker-compose up -d could also trigger the build if necessary, as I believe this improvement in Compose 1.7.0 will provide.

Thanks for reading (and of course for creating this module),
Giacomo

@garethr
Copy link
Owner

garethr commented Apr 1, 2016

@giavac thanks for the detailed writeup. The current exists? deals with the case where the change is to the underlying system, ie. a container has stopped or changed for some reason outside Puppet's control. I think it should also if the dockerfile has changed. I'll look into adding that capability when I get a moment.

I'd not run this all the time as then Puppet will always report a change event, when in reality nothing changed.

@garethr garethr added the bug label Apr 1, 2016
@giavac
Copy link
Author

giavac commented Apr 1, 2016

Thanks for your reply @garethr

I now get the point about the change event. From this perspective then perhaps what can be done is improve the filtering of the docker ps command in order to identify containers that are running with "old" images.

This worked for me:
docker ps --format '{{.Image}} {{.Label "com.docker.compose.service"}}' --filter 'label=com.docker.compose.project=myproject' | grep '^myproject'

If the output is formatted to show the image ID also, then only the latest image will have the compose-specific name (at least with the set up described earlier).

Just my 2c.

@dbason
Copy link

dbason commented Sep 27, 2016

+1 to this. If I get a chance I'll look in to modifying the provider as well.

In the meantime if you're using Puppet to manage the compose file you should be able to send a refresh to the compose type (I believe this is in 5.3.0?)

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

No branches or pull requests

3 participants