Theory
Firstly, some theory of Congress (at least according to version 3.3.3):
People often say that "Congress" has a "cache", but misunderstands what that means. Each hub worker has a set of volumes on disk that remain around, forming a volume cache. This volume volume contains volumes that were populated with get and put resources and the outputs task.
People also often misunderstand how docker-image-resource uses Docker. The global docker server works with your Concourse installation, because Concourse containers are not Docker containers, they are runC containers. Each docker-image-resource ( check , get , put ) process is launched inside its own runC container, inside which the local docker server runs. This means that there is no global docker server that pulls out docker images and caches layers for future reference.
This implies that when we talk about caching with a docker-image resource, it means uploading or pre-pulling images to the local docker server.
Practice
Now, to optimize the build time:
load_base
Background
The load_base parameter in your docker-image-resource put tells the resource first the docker load image (obtained via get ) to the local docker load server before creating the image specified via put Titles.
This is useful when you need to pre-populate an image in your docker cache. In your case, you want to preload the image used in the FROM directive. This is more efficient because it uses its own Concourse cache to only pull out the “base” once, making it available to the docker server during the execution of the FROM command.
Using
You can use load_base as follows:
Suppose you want to create a custom python image, and you have a git repository with a ci/Dockerfile like this:
FROM ubuntu RUN apt-get update RUN apt-get install -y python python-pip
If you want to automate the creation / clicking of this image, using volume caching as well as docker level caching :
resources: - name: ubuntu type: docker-image source: repository: ubuntu - name: python-image type: docker-image source: repository: mydocker/python - name: repo type: git source: uri: ... jobs: - name: build-image-from-base plan: - get: repo - get: ubuntu - put: python-image params: load_base: ubuntu dockerfile: repo/ci/Dockerfile
cache and cache_tag
Background
The cache and cache_tag in your docker-image-resource put tell the resource to first pull a specific image tag + from your remote source before creating the image specified with your put parameters.
This is useful when it is easier to pull out an image than to create it from scratch, for example. you have a very long build process, such as expensive compilations
This DOES NOT use Concourse volume caching and uses the Docker --cache-from function (which runs the risk of docker pull ) during each put .
Using
You can use cache and cache_tag as follows:
Suppose you want to create a custom ruby image in which you compile ruby from source code, and you have a git repository with a ci/Dockerfile as follows:
FROM ubuntu
If you want to automate the creation / clicking of this image using only the caching of the Docker layer :
resources: - name: compiled-ruby-image type: docker-image source: repository: mydocker/ruby tag: 2.0.0-compiled - name: repo type: git source: uri: ... jobs: - name: build-image-from-cache plan: - get: repo - put: compiled-ruby-image params: dockerfile: repo/ci/Dockerfile cache: mydocker/ruby cache_tag: 2.0.0-compiled
Recommendation
If you want to increase the efficiency of load_base imaging, I suggest load_base should be used in most cases. Since it uses the get resource, it uses Concourse volume caching and avoids the need to do additional docker pull s.