Docker 18.09 support for setup_remote_docker?

We would really like to begin using Buildkit to mount our project’s ssh key during build time in order to build docker images with private github repo dependencies, but this requires a remote Docker Engine with at least API version 1.39.

Is there an ETA for setup_remote_docker Docker 18.09 support?

7 Likes

Great question. Right now we’re doing several Docker related updates however I wasn’t able to get an ETA for this specific request at this time.

Any workaround until circle support this?

Can you make the key available in your (outer) build container, and then use Docker ARG to inject it into the (inner) building container? I’ve not used ARG before, but I understand it makes environment values available at build-time only.

In the docs at https://circleci.com/docs/2.0/building-docker-images/#docker-version it says:

CircleCI supports multiple versions of Docker and defaults to using 17.03.0-ce . Consult the Stable releases or Edge releases for the full list of supported versions.

Note that those two links (Stable releases and Edge releases) contain 18.09 as docker-18.09.0.tgz. The name has changed since 18.06 - it no longer has the -ce suffix.

At any rate, neither version: "18.09" nor version: "18.09-ce" work. This contradicts what the docs suggest, which is that the full list of released docker CE versions are supported…

Is this simply something broken due to the naming change? Or are the docs a little too optimistic?

Thanks!

Same issue, “18.09”, “18.09.0”, and “18.09.0-ce” all fail with error: “failed to create host: rpc error: code = Unknown desc = image docker- is not supported”

We’re really looking forward to buildkit support, can you share a timetable for 18.09 support? Would also be great to see a docs update, as CircleCI’s list of supported versions does not seem to be the same as the list of Docker Stable/Edge versions linked by @hairyhenderson .

I know this isnt a full solution buy until they do, i think we can use github actions with api calls to build (i’ve managed to do a successful build and push on GitHub actions)

@AmiM Are you saying the Docker 18.09 is supported as a remote Docker backend via the API but not via config.yml?

No, im saying that maybe there’s a GitHub API to launch a GitHub Action that will build the docker image on GitHub instead of circle

any update?

Weighing just just to say I have the same need here. Specifically, when I specify 18.09 as the docker version to use, I get this message in the logs:

Allocating a remote Docker Engine
failed to create host: rpc error: code = Unknown desc = image docker-18.09.0 is not supported

@FellcianoTech Any ETA on this update? Thanks!

This feature is become slightly more important for my team and I. I tried using a machine executor instead to avoid the need for an updated setup_remote_docker, but it seems that the version of Ubuntu that the machine executors use (14.04) isn’t supported by Docker 18.09, with no plans of supporting it in the future: https://github.com/docker/for-linux/issues/440

It looks like my team will need to wait for either an update to setup_remote_docker or an update to the base image that circleci machine executors use before we can build docker images on CircleCI.

Has anyone else found another way to build images that use Buildkit?

Thanks in advance for the help!

Indeed very important to be able to use latest docker engines. Needed for the use of BuildKit.
Latest version I am able to provision is 18.05, very strange newer versions does not work

Looks like this has been solved here. Often, if there is only one dependency, you can upgrade that thing in isolation, as long as you do the appropriate testing to ensure the OS still works.

Hi.

Could someone tell us which version of Docker currently is supported, please?

I’ve tried 18.09.1-ce, 18.09.0-ce and now 18.06.1-ce. It is quite annoying having to use trial-and-error only to get to see something like this:

image docker-18.06.1-ce is not supported

HI

Any chance you can get us un update on this?

I’ve twice added contributions to this thread, with a view to encouraging thread participants to consider workarounds, with no responses so far. You’re the most active poster here, so I wonder if you could tackle that question head-on, for the benefit of all readers/users?

What is a good and pragmatic solution to this problem now that users can do immediately?

I am also trying to use setup_remote_docker with version >=18.09.0. I am trying to leverage buildkit because I am using multi-stage builds to optimize the image size of my production builds. Buildkit drastically reduces my build time.

I’d like to avoid switching to the machine executor.

I think hairyhenderson may have been on the right track when he asked if something was broken due to the version naming change. I found an issue in the CircleCI base Dockerfile for pre-built images that had an issue with the version naming change: https://github.com/circleci/circleci-images/issues/324

But I think that specific bug is only affecting pre-built images. I’m not sure what environment the ‘remote’ docker is running in, but its build could be affected by a similar bug (or they just haven’t upgraded it yet).

Either way it’d be great to know if an issue has been logged for this and if there are any plans to address it.

Can we get an update on this from any CircleCI employee?
This is quite a blocker for many use cases

Hi all, thanks for your patience here. We are definitely interested in making Docker 18.09 support available on setup_remote_docker as soon as possible.

Before we get to Docker 18.09 in setup_remote_docker we need to make a series of upgrades in other parts of our infrastructure that are essential for the stability of the entire system. We are actively working on these upgrades, and once we finish them we will be able to tackle the upgrade for setup_remote_docker.

The current timeline for the Docker 18.09 availability in setup_remote_docker is Q2 2019. We will do our best to get there sooner but can’t guarantee that it’s going to happen sooner than that.

Again, thanks a lot for your patience and understanding.

5 Likes