Unhappy with Docker build-test-deploy scenarios

docker
caching
workflow
feedback

#1

We’re seeing some serious hoop after hoop requirements in order to maintain our docker build workflow on CircleCI 2.0. Quite unhappy at this point. All we have is a simple build-test-deploy cycle but:

  • The Docker executor doesn’t seem to work with build-test-deploy Workflows at all. The Docker layer context is swapped out so whatever you just built isn’t available in the next job without tarball shuffling.
  • If we did get workflows to work, some of our “build 10 base images and deploy them” workflows in order to achieve parallelism would require back-breaking levels of copy-pasting throughout the YML file.
  • Volume mounts, which we still need in some cases, are not at all supported on the Docker executor.
  • The Machine executor has a ??? on its price tag right now even with CircleCI 2.0 in GA.
  • The Machine executor doesn’t seem to support any level of Docker layer caching except DIY.
  • If I use the Machine executor with Workflows, am I guaranteed to get the same machine for every job? There aren’t any docs for Machine+Workflows, but they seem to imply that I need to specify my machine: image: circleci/classic:edge in every job like I would the Docker executor which makes me concerned about getting hot-swapped to a different machine.

I know Circle is working furiously to improve the experience for their users and I appreciate that greatly, but there seem to be some Docker-unfriendly ingrained architectural decisions having been made in the early development of this product that really give a bad first impression. I really hope you guys get it worked out and the documentation brought up to speed.


Docker images between jobs in Workflows
Caching Docker images in Workflows
#2

Thank you for providing comprehensive feedback. We will look into addressing these in our future releases.

You can consider using https://circleci.com/docs/2.0/workflows/#using-workspaces-to-share-data-among-jobs for sharing data between jobs.

Our general and machine pricing details are being finalized and will be available in coming weeks. These details will be available on circleci.com

We are considering adding docker layer caching support to our machine executor which will give you the reusable option https://circleci.com/docs/2.0/docker-layer-caching/#reusable.


#3

@taiidani - I’m curious if you figured out a way to make the container persistence an better per your first bullet point. Using workspaces to share data is useful in some cases, but you still have to deal with export/save and import (or push/pull from DockerHub) to get it running in the next job, right?

For Circle: It would be fantastic if we could mark a build/run job as complete/successful, but let it continue to run while we run tests against it with dependent jobs.


#4

@aayore Unfortunately not. My company is in a holding pattern on CircleCI 1.0 while we wait for 2.0’s offering to improve. We’d love to switch to it but it doesn’t appear to be ready for the build-test-push use case we have for all of our services.

We have gotten a few extremely simple use cases (our base images) through where we didn’t need workflows and CircleCI 2.0 has been able to handle them. I haven’t tried lately with an actual service that involves testing & complex deployments.

Circle: Have there been any platform updates that would address the problems listed above?


#5

We’re in the same boat. I need to switch to Circle CI 2.0 to be able to run an elasticsearch container for our integration tests, but our previous workflow was to build a deployable app container, then run that with docker-compose to do our integration testing. With 2.0 I would have liked to build the app container in a build step, then in a test step use that as our root docker with the dependency dockers running alongside it.

Really I would have preferred to specify a Dockerfile in my build job, how to tag it, then be able to use that image in another job to run tests, and finally in a push step push the image. That would be truly docker oriented CI. Is there a way to specify an image from a private repository as the root docker in a test step? If so I could at least push the container to a private registry and then use it in the next step, as frustrating as it is to pull several hundred megabytes (yes our images are rather large).


#6

I wonder if that could be fixed with YAML references? I have not tried that myself, but if CircleCI are using a full YAML parser, I’d expect it to. Depends on whether you’re able to post parts of the tree verbatim (that will work) rather than with per-section tweaks (references don’t support that AFAIK).


How to repeat workflow config in multiple trigger types without excessive duplication?
How can steps in YAML config be reused?
#7

References work, see e.g. https://raw.githubusercontent.com/retorquere/zotero-better-bibtex/master/.circleci/config.yml


#8

I gave some wrong advice here. You can reference a predefined tree section in YAML, and then overwrite individual keys. See here.


#9