Docker on Development Workstations

Question

I recently had an interesting discussion with a colleague. We have different perspectives on what is required to develop Docker containers. I won't say who believes what, to keep from prejudicing the responses. Here are two competing assertions:

Assertion 1:
It is not necessary to install Docker on development workstations. Container build is a CI task that can be performed by a CI tool, then containers can be troubleshot/debugged in a DEV environent.

Assertion 2
It is critical for developers to run Docker locally so they can smoke test and execute containerized processes before they are committed to SCM or CI. Containerization is a core developer skill, which is specialized by development platform.

Is it critical, nice-to-have, or not necessary for Docker to be installed on developer workstations where containerized workloads are developed?

Answer 1

Someone said that to each question, there are always three answers. So here's your third answer.

Install docker on the dev machine, and build images with it.

But:

The images should not contain your source code or anything that changes during the usual edit-build-test-run cycle. The images only need to contain the basic stuff that does the build/test/run parts.

That is, if you were to develop a Maven application, your image/container would contain the mvn command with all its depdendencies. A second image/container would contain your wildfly or whatever you are using as an application server.

If you were to develop in ruby on rails, you would have one image/container which contains everything to be able to run bundle exec rake cucumber, another image/container which contains everything to be able to run rails s or rails c.

The images will be recreated seldomly, for example if you want to upgrade the application server, and they will certainly not be docker build't on each run by the dev. Both images would not contain anything that belongs to your application. No source code, no .war file, no precompiled assets or application-specific gems for the ruby application. These would be mounted as volume when starting the containers, and point directly to whatever local directory the dev is currently working with.

This way, it is guaranteed that your dev uses the exact same base environment as your CI or production. New devs can start building/testing/running instantly and never need to install anything to their host machine. They can use the editor of their choice (if they wish to use something like Eclipse which has lots of magic and wants to compile the stuff itself, then they are free to do so of course - as long as they do at least a cursory check whether everything still works in the docker variant, before pushing).

And if you wish to deploy your application as a fully self-contained docker image, finally, then you are free to do so. Your CI server can build those images. It should use the smaller images used by your devs as base image, obviously.

This gives you a nice medium ground which should cover everything.

Answer 2

Being a fan of The Twelve-Factor App, I'll recommend installing Docker on every workstation, following rule X. "Dev/prod parity: Keep development, staging, and production as similar as possible".

I encourage that every developer is responsible to produce production-ready software, so you need to test it locally before pushing it. CI is for integration as its name suggests, not to check any individual contribution, but to check any conflict between the contribution of several developers.

Answer 3

Assertion 1:

• Pro: The build environment is guaranteed to be what's expected
• Cons: It slow down validation of patches.

Assertion 2: Exactly the opposites pro and cons.

I'd advocate to let developers have docker on their system to iterate quickly on fixes or advancement and keeping regression and integration tests in the CI pipeline. That's not required, every dev should be able to choose if they just code and never run anything locally or if they want to run whole test suite on their workstation.

So both assertions are valid, I see no valid reasons to enforce one or the other

Answer 4

IMHO it is at least a nice-to-have if not critical. But if critical it's not for the reason stated in assertion #2.

The ability to exactly replicate the containerized build from the CI can be critical to reproduce and debug some issues found in the CI verifications, then develop and test fixes for them.

Such ability can also be useful to optionally run parts of or the entire CI verification prior to committing the code for potentially high-risk changes.

And, in general, docker on the dev workstations can contribute overall to reducing the differences between the development and QA/staging/production environments.

But running CI-class verifications prior to commit can also be done on shared resources or on resources temporarily borrowed from the CI system, not necessarily on the developer's workstation, which in some cases can even be prohibitive - some CI builds can require much more resources than those available on the typical developer workstations.

But when having such ability it can be very tempting to actually require developers to perform such verifications in an attempt to completely eliminate regressions in the real CI executions, which is, I believe, implied in assertion #2. But that would IMHO be sub-optimal - such verifications are still done in isolation and thus cannot completely eliminate CI failures (see How can successfully pre-verified changes cause regressions which should have been caught?), while being expensive and chewing developer time for stuff that can be entirely automated.

If eliminating regressions in the real CI executions is desired then the precommit verifications have to be coordinated, ideally centralized, automated and immediately followed by automated commits.