Crane cause docker to re-pull remote image every time provision being run about crane HOT 12 CLOSED

I am guessing this comes from the fact that in docker, pulling an image pulls all tags by default, while running it pulls/runs the :latest by convention. So I would recommend always explicitly defining a tag, even if that's :latest in your crane.yaml.

To avoid that in the future, we could either enforce the presence of a tag, or append :latest if it's not explicitly given. I'd go for the first option as the implicit default tag is good enough for quickly starting containers from the command line with docker, but brings some confusion/inconsistencies such as the one you are facing, and is not really a substantial time win when the image is defined in a static file anyway.

from crane.

I just added :latest and it is still pulling new layers. I noticed that I use postgres:9.3 before and it was pulling every provision as well.

from crane.

Then the behavior is correct then? The tag was updated remotely, so either crane provision or docker pull will download the layers introduced with the update so that the local tag is reflecting that (docker history would show that). Either stick to an image where tags are effectively immutable/stable on the remote registry, or don't explicitly re-provision. Or maybe I am misunderstanding your workflow?

from crane.

For example, if you have a Dockerfile like this:

FROM dockerfile/redis

And run docker build ., docker will only pull the image the very first time. From second time it will get the image from the cache.

If I declare a container in crane.yml without specify the dockerfile, crane will tell docker to pull the image every time it provision. I'd rather go with docker behavior: only pull if the image cannot be found in local cache. I think crane should check with docker images for non-existence before telling docker to pull the image. We can have a --refresh to force the pull though.

from crane.

I agree that lift should check if the image exists already and not do any work that is not absolutely needed. After all, it's just a convenience shortcut. provision however should default to standard build/pull behaviour in my eyes.

from crane.

Not sure I agree here - currently lift has provision && run semantics, and I think it's a great way to say "run the latest version" (it's the most used command amongs our devs). If you want to run containers from your local cache (or pull if not present), then you can simply use run. I guess the only issue here is what to do with base images when a container provides a Dockerfile in the config.

from crane.

@phuongnd08 Does using runinstead of liftas suggested by @bjaglin work for you?

from crane.

run doesn't do provision so if the Dockerfile changed, the new container won't be rebuilt so I don't think it's the solution here. Though I think this can be closed as using one line Dockerfile works for me.

from crane.

I must say that I agree with @phuongnd08 about checking the cache before pulling the image. I specify an image in the crane file. The image is built locally with Packer and the current implementation of lift forces me to push the new image to the registry before it can be used. I'd rather have Crane pick-up the (newer) image from local cache so that I can significantly shorten my image development cycle.

I guess the default behavior doesn't need to change but it needs to be made configurable, either by providing a --refresh (pull from registry) or --cache (try to find local image first) flag. If we can work out the details here then I'd be willing to create a pull-request.

from crane.

+1 --cache flag to prefer local image over reigstry

from crane.

@phuongnd08 @iverberk @tpaz Do you guys use lift -r or just lift?
I'm wondering whether lift should prefer local images, and lift -r update to the latest possible image. Not sure though. I'm not against a --cache/local flag, maybe that's the best option.

from crane.

Closing since building images and the behaviour of lift might change with #195.

from crane.