Remote Docker and IP Ranges (Suggested Solutions)

solutions.md

Brief

This shows the decision tree on which solutions is possible, for customers facing the known limitation of IP ranges not working with Remote Docker on CircleCI.

This document assumes you want to

flowchart TD
    job[Your Job using Remote Docker & IP Ranges] --> only_docker{Is job only about building and/or pushing Docker images?}
    only_docker -- "NO (e.g., run E2E tests with built images)" --> ip_ranges_needed_when_docker{Is IP ranges required when building and pushing the Docker image?}
    only_docker -- YES --> solution_kaniko((See solution #2))
    ip_ranges_needed_when_docker -- YES --> solution_combine((See solution #3))
    ip_ranges_needed_when_docker -- "NO (i.e., IP ranges only required for other steps)" --> solution_split((See Solution #1))

Loading

Solution 1

Split job

Your job may look something like this:

(case A)

1. Download some private packages (IP ranges needed)
2. Build and push Docker image (IP ranges not needed)

Or, something like this:

(case B)

1. Build Docker image (IP ranges not needed)
2. Run some E2E tests with the built image (IP ranges needed)

In these scenarios, the building (and pushing) of Docker images do not require IP ranges.

Hence, the solution would be to split the Docker builds from the rest of the steps (i.e., into 2 jobs).

For case A, you can passs the required files to the 2nd job (that builds the Docker image) via workspaces.

For case B, there are 2 approaches.

If your Docker image is pushed to a accessible registry (e.g., Docker Hub), your 2nd job can then just pull the Docker image as normal then.

If you are not pushing the built Docker image, you can use [workspaces] to save and load the Docker images (as .tar files) then.

This requires using the docker image save and docker image load commands:

• https://docs.docker.com/engine/reference/commandline/image_save/
• https://docs.docker.com/engine/reference/commandline/image_load/

Here is a sample project using Docker's image load and save commands, and CircleCI's workspace: https://github.com/kelvintaywl/whale-of-a-time/tree/docker-save-load-strategy

Solution 2

Build Docker images without a Docker daemon

Tools like Buildah and Kaniko can help developers build Docker images without a Docker daemon. In other words, you can build and push Docker images on CircleCI using just a Docker executor job and Kaniko/Buildah without the remote Docker.

By doing so, you can continue to use IP ranges with your Docker executor job then.

For documentation on how to use Buildah, please see our documentation: https://circleci.com/docs/container-runner/#building-container-images

For examples on how to build Docker images on CircleCI with Kaniko, please check this Discuss article: https://discuss.circleci.com/t/how-to-build-and-push-docker-images-with-kaniko/44923

Solution 3

Combine solutions 1 and 2

This approach combines both solutions 1 and 2, since you need IP ranges for all steps within your job.

It means that you will:

• split the Docker-build step and other steps into separate jobs themselves
• use Kaniko or Buildah to build your Docker image without a Docker daemon