HiveBrain v1.2.0
Get Started
← Back to all entries
patterndockerMinor

Docker on Development Workstations

Submitted by: @import:stackexchange-devops··
0
Viewed 0 times
dockerdevelopmentworkstations

Problem

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?

Solution

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.

Context

StackExchange DevOps Q#3118, answer score: 3

Revisions (0)

No revisions yet.