Caching Docker images in Workflows


A few of the following threads raise similar issues. I’d like to group discussion from those into this one.

To summarize, users want images from jobs quickly available to downstream jobs in the same workflow. The most common case seems to be for a build-test-deploy strategy.

Which engine setup to use for passing images between workflow jobs

If you build your own Docker images for testing in most of your builds, the current best route is likely using the Docker executor with a reusable engine. This is still a preview feature, but we provide it to our paid customers. To enable it, you just need to open up a support ticket to request it.

Reusable engines are shared between jobs of the same project (one repo on Github). An engine will be used by only 1 job at a time, unless you configure your job with exclusive: false. In that case, an engine may be shared between 2 jobs at most. When your project requires more jobs than engines available, we’ll allocate a new reusable engine for the new job and future jobs in that project.

We currently aren’t in a position to guarantee how long a given engine will be persisted and available. We expect to only bring them down for critical updates to Docker engine, and when we encounter infrastructure failures. For reference, thus far, a few customers had to clean up months-old images in their reusable engines to free up disk space.

Which job gets which reusable engine?
Reusable engines are shared within a project, but you should expect to get a random engine from your pool of reusable engines. A job should be configured to fetch an image if it isn’t already available in the engine.

How should I pass docker images between jobs?
In my experience, pushing and pulling from a Docker registry has been magnitudes faster than using CircleCI caching or workspaces to transfer Docker images. For build-test-deploy workflows with fan-out from the build step, this will mean some reusable engines download images from Dockerhub.

Is this as good as it can get for a build-test-deploy workflow?
This is how I would use the features available to streamline a build-test-deploy workflow. However, we still have a lot of work planned and underway on CircleCI 2.0. I expect the image sharing between jobs to get better over time.


This is great, thanks so much for summarizing.