Supporting Docker builds is one hack over the other with 2.0


supporting docker builds is one hack over the other with 2.0. Literally everything is a major PITA:

We have been happy customers of Circle except for the crappy docker support in 1.0, and it seems like 2.0 is just making things even worse. If this is really the suggested approach for building docker images, how are you planning to retain all your customers that require docker builds?

Support Docker versions newer than v1.9.1

Hi, I split this post off as this is really it’s own post as opposed to what the original post was meant for.

Specifics on what you are having trouble with or what specifically you feel isn’t working for you will provide us with the best chance to improve documentation and CircleCI 2.0 itself.


@itajaja Try the machine executor


The machine executor, as far as I understand, will not receive updates to docker, becuase it’s basically circle 1. see Support Docker versions newer than v1.9.1

The problem with Circle 2 overall is that it doesn’t seem to offer any overall advantage to Circle 1. All the juicy features of the docker executor are not really applicable when you have to set up the remote docker engine (composabiliy, shared folders, caching)


Hi @itajaja

Thank you for using CircleCI 2.0 and providing feedback.

Machine executor will continue to receive updates.

We are looking at ways to simplify setting up remote docker engine and additionally add more functionality to our machine executor. Multiple options are being considered and we will have more updates as we move along in this Beta milestone.

We will be updating our documentation to address specific use cases and provide clearer guidance for different executor types.

I would suggest using machine executor to see if it serves your needs.

Stay tuned for more updates.


Hi @anon30319619, unless machine executor receives an update to docker engine, that’s really not an option. People have been asking to update from docker 1.9 for a very long time, and the recent answer was to switch to Circle 2 docker executor. It doesn’t really look there is a timeline or an statement of intention to update the docker engine in circle1/machine executor


This is not true because we have been pushing updates (some of that linked thread are from 2016), but the versions are the same when using the remote environment. The machine is where your containers are run.


Where did you get this information? As dhaval wrote, the Docker version available within the machine executor has and will get updated. For example, I just ran a test build now and when running docker version, the fairly recent version of 17.03.0-ce was returned.


My mistake to jump the gun. It looked like machine executor was just a porting of circle 1 (which in some way is: similar syntax, features, etc). Moreover, comments like:

Seemed to hint at the docker executor, not the machine one. Overall, it seems that’s what you guys are pushing more, since it’s the biggest novelty of v2.

As usual, frustration in a specific moment didn’t help my reasoning, I apologize for that. On your end probably additional documentation about the machine executor would be helpful, since the info is very sparse, but I am sure you are already working for now. Also, the “using docker” section of the documentation only speaks about docker executor, so it seems that that is the suggested way, which to go back to my first comment seem a little bit haphazard (that is, docker executor with remote docker environment cannot make use of many of the features of the docker executor). In the end of course is up to us to decide what better fits our needs individually, but I am not sure what you guys suggest is better suited for this. docker executor w/ remote docker engine, vs machine executor? I understand the lack of documentation since this is still beta, probably this is a good opportunity to clarify this?


@anon30319619 if you have the chance, I would most appreciate documentation updates for networking within the docker executor – specifically between the job space and the remote docker engine. Currently I’m unable to find an answer or a solution and have resorted to annoying @rohara multiple times a day (thanks for your help).


Hi Reedflinch,


Assuming you have seen this:

Can you please describe your usecase so that I can give a more appropriate and targetted answer.


Love 2.0, just needs to be a bit more reliable

I would add the use of private images to this list. I understand how building docker images requires the extra effort as it is a limitation of docker. However, we shouldn’t have to rely on the remote docker environment only to use a private image for out test environment. Especially when your documentation explicitly recommends to build our own image and add our build tools to make builds quicker (which is reasonable).

At the time when I add together the time (allocation remote docker environment, pulling alpine image, cping repository into data container) together I get to about the same amount of time as it would take to spin up a machine executor and simply avoid the docker executor altogether - which would result in a much cleaner build setup as well. I’d even be okay with it, if the machine executor didn’t have a warning on it that it may become a premium feature in the future (which I see as a degradation of service for existing customers at the moment).

It would be helpful if you could publish some sort of timeline or at least an intent on what issues are things that you will fix/rework and which ones are things you see as not changing for a longer period of time (say 6+ months).


Hi @mitom,

Thank you for your feedback.

The issues that you bring up about the remote docker environment are valid. We are working on addressing this and improving our executor offerings.

I understand your concerns and we would have liked our pricing plans to be released sooner. On a positive note, we are nearing the end of our research and should be releasing more details in coming weeks.


I just wanted to chime in that this 2.0 documentation and way of doing things is so convoluted compared to 1.0, we’ll most likely be leaving the service unless things get drastically easier to work with. Things are so different and the documentation is so unhelpful (at this point), I can’t even give constructive criticism yet. I’d almost need to hop on a call with someone and explain what I’m trying to do and see if it’s at all possible ,and if so, how I’d approach it.

Also, I want to explicitly say, my post may read more negative then I mean it to be. I’m just trying to call out that 2.0 seems like a major regression in usability compared to 1.0, to the point where we couldn’t possibly move to 2.0 if it’s in this state when it goes live.

Let me know if you want to chat directly, I’d love to give further thoughts.


@erichmond thank you for the feedback - it’s really appreciated.

I’m currently working on ‘round two’ of the CircleCI 2.0 docs. We’ve just appointed a full-time technical writer and we’re working hard to make big improvements.

Regarding CircleCI 2.0 configuration, our engineering team is working to make that easier too. We’re about to launch a new feature which paves the way for making configuration options more powerful, flexible and easier to use.

I’d be very happy to hop on a call so you can share your experience and let me know what you’d like to do with CircleCI 2.0 (I’m in Ireland so timezones may be a factor). Feel free to send me a DM on this message board, or email and mention ‘Tom’ and this thread.


@Tom, how do I DM you? I’d love to chat and explain what I’m trying to do.



Click on his profile picture and select Message


As a newcomer to circle I bypassed 1.0 and skipped directly to 2.0 with docker. While I agree the documentation could better I didn’t find working with the configuration that obscure. Everything seems to make sense, sort of. Once I understood remote docker, things clicked. Just wanted to offer some positive feedback. I think this is a great service and I wished I discovered it sooner.