The pull_policy: always property is forcing the use of the image defined in the image property instead of using the image built in the build property
#9730
Comments
xserrat
changed the title
pull_policy: always property forces the use of the image defined in the container instead of using the image built in the build propertypull_policy: always property is forcing the use of the image defined in the image property instead of using the image built in the build property
|
Hm.., I see where you're coming from. That said; my immediate thought here would be that, while services:
myservice:
build:
context: .
dockerfile: docker/Dockerfile
image: an-image
pull_policy: alwaysIn the above;
When explicitly asking for compose to build ( docker compose up --build
[+] Building 6.2s (6/6) FINISHED
=> [internal] load build definition from Dockerfile 2.2s
=> => transferring dockerfile: 75B 0.1s
=> [internal] load .dockerignore 2.7s
=> => transferring context: 2B 0.0s
=> [internal] load metadata for docker.io/library/alpine:latest 0.0s
=> [1/2] FROM docker.io/library/alpine:latest 0.2s
=> [2/2] RUN echo foo > bar 2.0s
=> exporting to image 0.3s
=> => exporting layers 0.2s
=> => writing image sha256:72f4b292d9ee8ec274f12397a22080e8f993be28a0af77980c014a0f3d82fe5a 0.0s
=> => naming to docker.io/library/an-image 0.0s
[+] Running 2/2
⠿ Network issue-9730_default Created 0.4s
⠿ Container issue-9730-myservice-1 Created 0.8s
Attaching to issue-9730-myservice-1 |
|
Forgot to post; so the compose-spec describes this; https://github.com/compose-spec/compose-spec/blob/master/spec.md#pull_policy
From that, indeed, if both are set, compose should build the image;
The combination of some of those is a bit ambiguous, as it doesn't describe in which cases it should build (if the image is missing, or always?); effectively that would mean that adding a |
|
First of all @thaJeztah, thanks for your fast reply! I see your point... I guess that the option to produce an error is a good solution so we have fast feedback and we can understand which is the issue in our configuration. Something like: Also, we could only display a warning message and do the current behaviour, so at least the user can see which is the behaviour: Anyway, thanks for your explanation, now it's clear for me so I think I'm going to change my override YAML to the following to make it explicit: services:
myservice:
build:
context: .
dockerfile: docker/Dockerfile
pull_policy: build |
|
It's definitely a tricky one! And I recall I had some debates with others wether or not So yes, the ambiguity is mostly that there can be different intents, both of which are "valid", but from a different angle ("1" to be more for deploying, and "2" to be more for local development);
|
|
with your setup, services:
myservice:
build:
context: .
dockerfile: docker/Dockerfile
pull_policy: !resetsee https://github.com/compose-spec/compose-spec/blob/master/13-merge.md#reset-value |
Currently, we either have the docker image locally, which compose then runs or we build the image from our local docker files. We now gave a docker registry and would like to pull from the registry or build our image locally. Adding the full registry URL to the image field satisfies this behaviour by either pulling the image or creating it and tagging it with the URL/tag combo. This commit adds the docker registry URL to the image fields of our docker compose file. More info on this behviour can be found here[1]. [1] docker/compose#9730 (comment)
Currently, we either have the docker image locally, which compose then runs or we build the image from our local docker files. We now gave a docker registry and would like to pull from the registry or build our image locally. Adding the full registry URL to the image field satisfies this behaviour by either pulling the image or creating it and tagging it with the URL/tag combo. This commit adds the docker registry URL to the image fields of our docker compose file. More info on this behviour can be found here[1]. [1] docker/compose#9730 (comment)
Currently, we either have the docker image locally, which compose then runs or we build the image from our local docker files. We now gave a docker registry and would like to pull from the registry or build our image locally. Adding the full registry URL to the image field satisfies this behaviour by either pulling the image or creating it and tagging it with the URL/tag combo. This commit adds the docker registry URL to the image fields of our docker compose file. More info on this behviour can be found here[1]. [1] docker/compose#9730 (comment)
Currently, we either have the docker image locally, which compose then runs or we build the image from our local docker files. We now gave a docker registry and would like to pull from the registry or build our image locally. Adding the full registry URL to the image field satisfies this behaviour by either pulling the image or creating it and tagging it with the URL/tag combo. This commit adds the docker registry URL to the image fields of our docker compose file. More info on this behviour can be found here[1]. [1] docker/compose#9730 (comment)
Description
I have a service that is defined in the
docker-compose.yamlas well as in thedocker-compose.override.yaml. The difference is basically that in thedocker-compose.yamlI'm referencing theimageproperty while in thedocker-compose.override.yamlI have thebuildproperty to build the image based on a localDockerfile. Also, thedocker-compose.yamlcontains apull_policy: alwaysproperty that is inherited in thedocker-compose.override.yaml.The problem is that the container does not start with the generated image from the Dockerfile if I have in the parent yaml (
docker-compose.yaml) thepull_policy: always. It starts with the parentimagedefined. This is the configuration:You can see a complete example with an nginx image here -> https://github.com/xserrat/docker-compose-pull-policy
Is that the expected behaviour?
No. I expected the use of the overridden image defined in the
build.dockerfileproperty in thedocker-compose.override.yamlfile.Steps to reproduce the issue:
docker-compose.yamllike the following:docker-compose.override.yamloverriding the previous service by adding thebuildproperty to build a customDockerfile:docker compose up -d myservice.docker-compose.yamlinstead of using the image from thebuild.dockerfileproperty.Describe the results you received:
I see that the image used to run the container is not the local one built using the Dockerfile.
Describe the results you expected:
I should see that the image used to run the container is the local one because the
imageproperty defined in thedocker-compose.ymlis overridden by thebuildproperty from thedocker-compose.override.ymlfile.Additional information you deem important (e.g. issue happens only occasionally):
Output of
docker compose version:Output of
docker info:Additional environment details:
I am using a Mac M1.
The text was updated successfully, but these errors were encountered: