Containers (only) based Development Environment

It was kind of a great feeling to me when I had to reinstall my computer last time. I was even looking forward to it. It was this shiver in a back whether all the things, I was preparing for, work out. Because you know how it usually goes when you have to reinstall the machine…

Download your favourite new version of Linux distribution ISO image, burn to USB key, boot, install, finish installing and then it takes another day or two downloading your real tools and stuff you like in order to develop fluently. And that is just the most simplest scenario. What if you have a bunch of new developers coming on board?

… and there it was, my procedure went through download, burn, finish installation and then? That’s almost it. Because you know — everything is a container!

So when I want to open Eclipse or IntelliJ I fire up a container like this:

mug eclipse

or

mug idea

I don’t have to care where to download it. In case I don’t have the container image, I gladly wait with a mug of coffee and I can be rest assured I get my favourite IDE.

But IDE is just a top of the iceberg. I have to switch among different environments — Java, JavaScript, Scala, Clojure — and each has different set of libraries and tools I like to have at hand. And with those tools I like to build it locally but also for production so the environment is still the same. Therefore I just hit (in best case):

mug

and it downloads appropriate development container for me where I just jump in to my mounted project and start working. Without the need to configure a thing. The beauty of it is in two aspects:

  • having containers for everything apart my project files (although that is also very possible :) )
  • separating data, configuration containers and application containers

Imagine the situation below. You run software company and you have some developers.

What a newcomer needs to install is Docker on fresh machine, some version control system (e.g. Git) and potentially some helper scripts like mug. Everything else is the responsibility of e.g. Competence centre in the company to prepare common container images. Developer downloads them and the environment is consistent across whole team.

In order to support this philosophy I have created the mug project which contains some basis for running development environment from containers. There are some ready-made images for Java, JavaScript, Eclipse, etc. which I use on real projects.

So far working in containerized development environment is convenient and brings a lot of order and consistency. I encourage you to try living inside of them and share your experience.

P.S. in next post I will describe the whole infrastructure covered by mug from the Docker containers point of view. In the meantime you can take a look into one of the real images or investigate the content of its Dockerfile.

A single golf clap? Or a long standing ovation?

By clapping more or less, you can signal to us which stories really stand out.