![]() ![]() That would still point to the prior version (e.g., 0.1.7-dev). This would put the versioned build into your repository. There must be commands like the following run somewhere: docker build -t :5000/ourcompany/buildchaintest:0.1.8-devĭocker push :5000/ourcompany/buildchaintest:0.1.8-dev That means that running docker-compose build doesn’t take any action in regards to :5000/ourcompany/buildchaintest:0.1.8-dev. Your docker-compose.yml uses image to refer to :5000/ourcompany/buildchaintest:0.1.8-dev. If anyone has tips on this or can point to a best practices tutorial for this kind of setup that would be much appreciated also. The goal is to have our build process build and create tagged versions of the images needed in a docker-compose.yml, push those to our private registry and then for the "release to production-step" to simply copy the docker-compose.yml to the production server and run a docker-compose pull & docker-compose -f docker-compose.yml up -d for the new image to start in production. should I always do a docker-compose rm -f before running up again, even on production servers? Or am I doing something against the grain here, which is why it's not working? Is this intended behaviour of docker-compose? i.e. Only if I run docker-compose stop & docker-compose rm -fĪnd then run the docker-compose up command do I get the new version to show up on screen as expected. Status: Downloaded newer image for :5000/locotech/buildchaintest:0.1.8-dev However the output of the pull command would suggest that a new version of the image was fetched: Pulling application (:5000/ourcompany/buildchaintest:latest). In a folder on my computer, where the contents is only the docker-compose.yml and the necessary Dockerfiles to build the nginx and php services, the output I get is not the latest version number as has been tagged in the registry or is shown in the docker-compose.yml (0.1.8), but the version before that, which is 0.1.7. ![]() If I now run docker-compose pull & docker-compose -f docker-compose.yml up -d This seems to be doing what it's supposed to be since I get a new version tag in our repository each time the build completes and the version nr has been bumped. On our jenkins server I run the following to build and tag the image cd $WORKSPACE & PROJECT_VERSION=$(cat VERSION)-devĭocker tag :5000/ourcompany/buildchaintest :5000/ourcompany/buildchaintest:$PROJECT_VERSIONĭocker push :5000/ourcompany/buildchaintest Image: :5000/ourcompany/buildchaintest:0.1.8-dev OS: tested on both CentOS 7 and OS X 10.10 using docker-toolbox The version nr is displayed if I browse to the nginx server that is created (this works as expected locally). I created a simple test project for this in which the only goal is to get a version nr to increase on each new build. ![]() I would like for compose only to detect the new version of the changed images, pull them and then restart the services with those new images. I looked at How to get docker-compose to always re-create containers from fresh images? which seemed to be similar to my issue, but none of the provided solutions there work for me, since I'm looking for a solution I can use on the production server and there I don't want to be removing all containers before starting them again (possible data loss?). It looks like compose is using the previously started image even though docker-compose pull has fetched a newer image. I don't know what I'm doing wrong, but I simply cannot get docker-compose up to use the latest image from our registry without first removing the old containers from the system completely.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |