As a Success Engineer, I often see a lot of confusion around using Docker on CircleCI. Before the release of CircleCI 2.0, it was possible to build and test applications without ever having to think about Docker: all our builds ran in LXC containers, configured by our inference engine to include any necessary tools and dependencies in an oftentimes fairly automatic way.
With the release of CircleCI 2.0, however, we’ve placed Docker front-and-center in our build process: any Docker image, public or private (we now support private images hosted on Amazon’s EC2 Container Registry, too!), can be the primary container for a build. This adds power and customization to the build process, especially when combined with Workflows, which allows for sets of jobs (build, test, deploy, etc.) to be strung together, sometimes running in parallel, each with its own base Docker image. To aid the transition from CircleCI 1.0 to 2.0, we’ve even provided a wide range of convenience images to meet common language and dependency needs, tweaked to maximize compatibility with the CircleCI platform.
However, as they say, with great power comes great responsibility. Using Docker can be intimidating. For some developers, it may seem to have a high learning curve. Others worry about maintenance or upkeep for any images they’ve created. And then there are privacy concerns—after all, many of the images on the main Docker registry, Docker Hub, are completely public.