Changes to Remote Docker Reporting & Pricing

Build Environment
1

CircleCI has significantly improved the execution speed and reliability of jobs that use the setup_remote_docker feature.

Our new implementation of the underlying architecture that powers jobs using setup_remote_docker gives you better flexibility, reliability, performance.

Before: All jobs that used setup_remote_docker used a primary container that was the size of the resource class specified in config.yml & a remote medium-sized Linux virtual machine to execute Docker commands, regardless of the resource class size specified in .circleci/config.yml. The number of compute credits/min for the job was dictated by the container size, the remote virtual machine was not charged for.

These jobs sent network traffic across the internet between the container and the virtual machine which would result in both transient network failures and slow job performance.

Now: You can rightsize the remote Docker engine to use as little or as much compute as you need as all remote docker jobs only run in one virtual machine. There is also no cross-internet network transfer which speeds up job performance and makes the jobs more reliable. The number of compute credits/min will be dictated by the size of the virtual machine (see “Pricing update” below).

Starting June 15, 2023, jobs that use setup_remote_docker will be identified with a “Remote Docker” executor in the CircleCI UI, instead of “Docker Executor” (see example below).

This will help you easily see which jobs use setup_remote_docker in the Plan Usage page, Insights, and other parts of the CircleCI web app, and compare their performance with non-remote Docker jobs:

1446Ă—260 61.3 KB

Pricing update, effective June 15, 2023
The pricing for jobs using the new remote Docker executor will be:

image

If a job defined in your .circleci/config.yml file uses a Small Docker resource class with the setup_remote_docker feature, starting June 15, 2023, the job will execute and appear in the CircleCI UI as Executor = Remote Docker, Resource Class = Medium.

If a job defined in your .circleci/config.yml file uses a Medium+ Docker resource class with the setup_remote_docker feature, starting June 15, 2023, the job will execute and appear in the CircleCI UI as Executor = Remote Docker, Resource Class = Large.

No action is required on your part. Adjust your resource class sizes to fit your team’s needs. If you have questions, comment below.

3 Likes
2

Hi,

Just to confirm my understanding, is the following correct?

  1. Previously, setup_remote_docker was always using Medium - 10 credits/min
  2. Now, it’s still using 10 credits/min, if you don’t override the resource class.
  3. If you have a resource_class: "medium+" and setup_remote_docker in the same job, previously it would use 10 credits/min, now it will use 20 credits/min since medium+ is shifted to large.
  4. If you have resource_class: "small" and setup_remote_docker in he same job, previously it would use 10 credits/min (medium); now it will still use 10 credits/min, since small is shifted to medium.

So essentially no cost increase unless you were previously specifying a larger resource class for the job that has setup_remote_docker.

Thanks,
Mike

1 Like
3

I’ve edited the original post for clarity, one clarification:

“All jobs that used setup_remote_docker used a primary container that was the size of the resource class specified in config.yml & a remote medium-sized Linux virtual machine to execute Docker commands, regardless of the resource class size specified in .circleci/config.yml.”

So for #1 in your list, previously all jobs would be charged for the Docker resource class that was specified in config.yml, and regardless of size specified, all jobs would use an additional remote medium-sized Linux VM to execute the remote docker commands. That means that if you specified xlarge, you would be charged 40 credits because your primary container was xlarge, but the remote Linux VM used to execute Docker commands would be a Medium. There was no additional charge for that remote Medium Linux VM.

For #2, if you do not override the resource class, you will continue to get the default size and there is no price change.

For #3 & #4, slight modifications given what I mentioned above. Previously medium+ would have used 15 credits, now it will use 20. Small would have used 5 and now it will use 10 credits.

3 Likes
4

So the small resource class is gone entirely? Not on Docker, and not on Linux either?

90% of my minutes are running on the small resource class, so this change doubles my credit usage. Not really happy about this, is there no way to keep using the small resource class?

2 Likes
5

@ravenouschicken If your job is not using Remote Docker (setup_remote_docker), you can still use the Docker Small resource class. That is not going away.

There has never been a small Linux VM resource class: CircleCI Resource Classes - CircleCI

If you were using a Small resource class with a job that uses Remote Docker, that job will now start to use a medium resource class.

2 Likes
6

In preparation for these upcoming pricing changes to jobs that use the setup_remote_docker feature (aka Remote Docker), we have updated the Job Details UI to enable users to distinguish between Docker jobs that use the Remote Docker feature and jobs that do not. Previously, this distinction was not obvious in the UI.

Screen Shot 2023-05-03 at 11.57.48 AM

As of today, the UI will now show “Remote Docker” as the Executor on the Job Details page. As a follow-up, we will start sending this new executor name to other parts of the UI including the Plan Usage page and Insights. No changes are needed from the user’s end for this to take effect.

Please also note that the following API will now report executor = remote-docker instead of docker in their response for jobs that use Remote Docker:

/api/v1/project/:user/:prj/:num
/api/v1.1/project/:vcs/:user/:prj/:num
/api/v2/project/:vcs/:user/:prj/job/:num
1 Like
7

This forum post and associated emails are completely unclear. You are planning a 150% price increase for xlarge! WIthout any justification of the increase, especially compared to the price of medium and large. How on earth can xlarge be 5 times the price of large for twice the compute? And you appear to be providing no mitigation or alternative to avoid the massive price hike?

Saying “No action is required on your part” is utterly inaccurate.

You can rightsize the remote Docker engine to use as little or as much compute as you need as all remote docker jobs only run in one virtual machine.

What does this actually mean? Are you implying there is some new config that needs setting so that the docker part can run on a smaller resource class than the main build? Note that splitting the build into separate jobs would be incredibly painful. The first link goes to a documentation page that provides very little info before linking back to this forum post.

Please explain what on earth is going on here.

8

All jobs that use Remote Docker now run as a Linux VM “under the hood”. The new price for the Remote Docker xlarge resource class is the same as the price of our Linux VM xlarge resource class. The new prices for Remote Docker jobs match the equivalently-sized Linux VM resource class prices.

Previously, an xlarge using Remote Docker would run with an xlarge primary container and Docker commands would be run in a remote, medium-sized Linux VM. Now, the entire job runs in an xlarge Linux VM.

The alternative is to use a smaller resource class for jobs that run Docker commands. You can view CPU/RAM usage in the “Resources” tab for each job as well as historical trends with “Resource Class Insights” to see whether the job is possibly over-provisioned on resources.

9

Can we switch back to the older architecture? AFAIK we never had any problem with it.

(Our docker access is fully integrated with our main build. We can’t just spin up a separate job for the docker part. And anyway using multiple jobs in one script is a huge PITA that slows the build down massively)

Can you see how this just looks like price gouging? Where is the justification for xlarge costing 5 times large?

1 Like
10

@jodastephen

There is unfortunately no way to switch to the old architecture. Totally fair feedback on the messaging, I should have made it more clear. I’ll ensure that future messaging is crisper.

The 5x increase is a product of the new Remote Docker prices being changed to match the prices of Linux VM resource classes and that is how our Linux VM resource classes are priced. The Linux VM resource class prices have several factors that go into them, not exclusively the CPU/RAM specs, which is one of the reasons why there is that discrepancy between Large & Xlarge.

1 Like
11

One answer for this issue is to look at self-hosted runners. Their value is very dependent on your exact needs and you may need to refactor your process to get full value from them, but in the right situation, they can be very useful.

As a simple example, I use self-hosted runners that are just instances defined within a VMWARE stack I built on services from a hosting company called ScaleWay. As I already have the resources I just do my builds on a VMWARE instance and let VMWARE handle the resource allocation. The advantage is that the job can take as long as I (or it) likes and I’m not paying per-minute fees.

2 Likes
12

FYI, the pricing change is effective as of today, June 15.

1 Like