Jib: Support for using a local Docker cache for base images

[aminchekov]

Description of the issue:

Expected behavior:

Steps to reproduce:

Environment:

jib-maven-plugin Configuration:

PASTE YOUR pom.xml CONFIGURATION HERE

jib-gradle-plugin Configuration:

PASTE YOUR build.gradle CONFIGURATION HERE

Log output:

Additional Information:

[briandealwis]

Hi @menya84. Jib does support using images from private registries as a base image. Could you provide some details? There are some suggestions for fixing connection problems with registries in the Jib FAQ.

[aminchekov]

I didn’t mean private registry, I am talking about local image been just built and not pushed anywhere.
But even if I push it to some remote registry and then build new image with some changes locally then the remote one will be used as a base anyway.

[coollog]

Hi @menya84 , do you mean a local image built with Docker and accessible via your local Docker daemon?

[aminchekov]

Yes, exactly.

[chanseokoh]

Being able to pull images from the cache of a local Docker daemon is an interesting idea. #718 is related, but the difference is that #718 is about not fetching remote metadata but using Jib's local cache. But https://github.com/GoogleContainerTools/jib/issues/718#issuecomment-440394884 actually mentions the idea of using the local Docker daemon. One thing to consider in both cases is the different behavior of Docker and Jib: Docker does not check remote images, while Jib always uses the most up-to-date images. I think it would make sense to not check remote images when using local images, whether Jib's cache or Docker's.

[aminchekov]

I think we can use metadata of an image to make sure Jib always uses really latest image.
Firstly we fetch remote metadata and compare it with locally cached image metadata, and pull from remote only if remote image has newer timestamp otherwise do not pull and use locally cached imaged of the local Docker daemon.
This would be great solution because often it's much more chipper to quickly build base image locally and not push/pull every time to/from remote while we are playing in development mode.

[chanseokoh]

I think we can use metadata of an image to make sure Jib always uses really latest image. Firstly we fetch remote metadata and compare it with locally cached image metadata, and pull from remote only if remote image has newer timestamp otherwise do not pull and use locally cached imaged of the local Docker daemon.

Note that this is basically the current behavior, almost, if you haven't noticed. It's just that Jib has its own cache and doesn't use the images in the local Docker daemon for a base image.

[aminchekov]

Agree, but the problem arise when we build the base image not using Jib. And usually we build base image just using simple Dockerfile.

[chanseokoh]

Yeah, as I said, being able to pull images from the local Docker daemon would be an interesting idea.

One workaround for now would be to use a local registry, which is easy to setup, e.g.,

$ docker run -d -p 5000:5000 --restart=always --name registry registry:2

(References: https://hub.docker.com/_/registry and https://docs.docker.com/registry/deploying/)

Then push the base image built locally (would be named like localhost:5000/something) to the registry and have Jib pick that up. But I admit this is a bit involved. I like the idea of Jib being able to pull base images directly from the local Docker daemon.

[infa-rbliznet]

The same for us. We can't really start using Jib without this feature since we use a custom base image that is build before jibDockerBuild. The workaround with private registry is not well scalable.

[briandealwis]

How do you build your base image? What does your build process look like currently?

[infa-rbliznet]

Currently we don't use distroless images. We have a base image that shared across all microservices. The base image basically has just an installed java. On a service level we run a packer with chef solo that runs chef recipe to install the tomcat and other stuff. It also copies the war file as part of the process.
We are looking into way to optimize the process. We don't have a base image that would be suitable for all microservice but rather each of them do baking on their own. Currently we are looking into Jib to substitute the part of the process that copies war file into image. Later, I think, we would be able to migrate some service level customizations to Jib style. So that we could create a base 'a service' image that just war is missing from but it's far from now. I hope it makes sense.

[tdanylchuk]

I faced same issue, here are my steps:

1. build parent docker image withing same project but not pushing it to remote repository until all tests are run successfully.
2. run jib plugin with overridden parent - it fails since it tries to fetch base image from remote repository, although I use dockerBuild, not build goal.
3. run tests towards built image (result of jib plugin execution)
4. push all built images including parent and from jib execution (here I want to rebuild it with build goal).

It would be great at least look into local docker daemon cache in case of dockerBuild, since it interacts with it in any case.

[chanseokoh]

This feature will be in the next release.

For those who want to use a base image built by another Jib build, note that the new feature also allows specifying a tarball base image (which can either be the one built by Jib or from docker save): #1905.

Another related issue: #1807

[TadCordle]

@menya84 @NathanHowell @furyu-john @ehirsch @seanabraham @tedgine-ml @tellisnz-shift @sepe81 @mzagar @infa-rbliznet @tdanylchuk @freedev @xRomZak @Liu233w @PierreBesson @lostiniceland @m86194 (hopefully that's everyone who thumbs'd up/commented...)

v1.6.0 has been released with this feature; prefix your source image configuration with docker:// to use a base image stored in the Docker daemon.

Gradle: jib.from.image = 'docker://docker-image'
Maven: <from><image>docker://docker-image</image></from>

The first build may be a little slow, depending on how large your base image is, but subsequent builds should be faster once the layers are cached in a Jib-friendly format. We're still looking into ways to optimize this (#1912, #1913), but until then, if you find that using a docker daemon image is too slow and you have a base image that doesn't change often, you can consider first docker saveing the image, and then pointing to the saved tar using a tar:// base image in Jib. This lets Jib skip a step in the execution.

Gradle: jib.from.image = 'tar:///path/to/saved.tar'
Maven: <from><image>tar:///path/to/saved.tar</image></from>