You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
@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.
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).
+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?)
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 adocker-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, anddocker ps --format '"{{.Label "com.docker.compose.service"}}"' --filter 'label=com.docker.compose.project=myproject'
does indeed return two items, which preventsdocker-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
The text was updated successfully, but these errors were encountered: