Under the premise “containerize all the things” I’m working a lot with Docker building more and more container images. A few days ago I had a conversation about the need for Docker. Well, actually it was more about why Docker doesn’t make anything better.

I reflected on that and came to the conclusion: With Docker software gets better. But it takes some time…

Docker as lightweight virtualization

A lot of people think that Docker contains powerful basic images which can be used like a distribution itself. Their look and feel is very similar to an installed version besides the interactive stuff. That’s why a lot of people use Docker containers the wrong way. They install their whole application setup in a single container. Including database daemon, the application itself, a reverse proxy, additional scripts, configuration management, sshd and more. (Sounds like headache? Unfortunately, one can find a lot of those images in the wild)

They use containers the same way like they use VMs. This is not only wrong, it just breaks the whole idea of Docker. If you want to run such a setup you should checkout cloud-init instead of Docker. Cloud-init is created for bootstrapping operating systems. With a full OS you have internal service management like systemd or the old-school SysVinit. Docker therefore doesn’t need them inside a container.

The advantage of this wrong usage “problem” of Docker is: There are people like me out there who notice such grievances and start writing Dockerfiles and create repositories to split all the things up and bring it in a convenient state considering the Docker best practices.

It’s a good thing to search for projects which need a good “dockerization” and fix their setup.

Simplify setup and testing

Docker is also loved by many developers. The setup of a local environment is pretty easy. It makes building, testing and verifying your product before commit or push to a repository for integration tests a breeze. To put it simple: It saves lot of time and money.

Docker is also liked by many Ops. Updating a good containerized application takes only a few seconds instead of minutes or hours. And it scales. Update 1 instance, 5 instances or 100? It does not matter.

Changing the way of development

As Docker simplifies setups and scaling of applications developers more and more start thinking about and working on the scalability of their products. And by scaling I talk about scaling out not up.

Docker changes the way developers think. It minimizes applications and let them provide common usable APIs like a Rest-API instead of implementing all features into a single application.

It also changes the way your application handles configuration. Starting with scripts to generate/modify the configuration inside your Docker container until there is native application support. All Docker projects I worked on the last few weeks are now configurable by environment variables instead of exposing large configuration directories. Especially HackMD (I love this project for being so awesome) has implemented new configuration parameters for environment variables spontaneously! Just because I started changing the configuration handling inside their Docker image and opened a Pull Request.

Getting images ready

As a developer of good, scalable software you should definitely think about providing a repository for an official Docker image. This provides trusty containers to your users and allows them to provide patches which may then be used officially. Contribution made simple.

As a good point to start with search your own application on docker hub. A lot of applications are already up there and have some useful images. This is a good starting point to an official image.

On top of that you can try to provide your image over the official Docker library and make it an official Docker base image that way. That’s almost the best place where your application container image can be provided as there are a lot of Docker professionals improving these images all day long.

Conclusion

Writing a Dockerfile is pretty easy. You already know how your distribution works and the Docker basics are straightforward. Placing your application inside an image helps getting your application ready for cloud-based setups.

Your first image has not to be perfect. Contributions to your container environment are most likely to happen anyway and may even improve your software in general.

Think about your way of handling configuration and config-options and try to find an easy way to replace big configuration files with light key-value-store-like setups.

As a rule of thumb:

Your docker run statement should stay in a single, easy-readable line for a simple test setup

Pulling all the strings together: Providing a Docker image makes it easy for me to get your application running. Provide it. Make me happy. And your other users of course. ;)

Hope you enjoyed this little article about my ideas about Docker and it’s influence on the way of software development. May leave a comment or checkout my Twitter account. And finally don’t forget to share this article with your friends and co-workers using the buttons down below.

Further information about Dockerization:

• Setup Docker on your machine
• Basics for writing Dockerfiles
• Using docker-compose to bring up all your applications components

Additional information:

• Basics about VMs and containers
• Official Docker Webinars
• Scaling and orchestrate containers using Swarm, Rancher or Kubernetes