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:
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.
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.
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.