1.10.4 Container Placement

Each step in a build is executed inside a container. The web node distributes containers across the worker cluster depending on the configured strategy.

The volume-locality strategy

When using volume-locality, the web node places task step and put step containers on workers where a majority of their inputs are already present. This is the default strategy.

The advantage of this approach is that it reduces the likelihood that large artifacts will have to be streamed from one worker node, through the web node, and to the target worker node. For large artifacts, this can result in quite a bit of overhead.

The disadvantage of this approach is that it can sometimes result in builds "gravitating" to a particular worker and overloading it, at least until the resource caches warm across the worker pool.

If your builds tend to be light on artifacts and heavy on task execution, you may want to try the fewest-build-containers strategy instead.

The fewest-build-containers strategy

When using the fewest-build-containers strategy, step containers are placed on the worker that has the fewest build containers (i.e. containers for other steps of other builds).

To use this strategy, set the following env var on the web node:

CONCOURSE_CONTAINER_PLACEMENT_STRATEGY=fewest-build-containers

The random strategy

With the random strategy, the web node places get, put and task containers on any worker, ignoring any affinity.

As this is truly random, this will be fine until one day it's not fine.

To use this strategy, set the following env var on the web node:

CONCOURSE_CONTAINER_PLACEMENT_STRATEGY=random