Before we conclude this series, let us recapitulate what we learned over the last weeks on dev containers.
What can run on Linux can run in a dev container
This may sound very simplified, but it is a good rule of thumb: When your dependency can run on Linux you can put it into a dev container without much effort. You often get oven-ready images that do all the work for you, and if not, you find a tutorial or script where someone else went through all the steps.
If it is Windows-only: run away!
Docker runs on Windows, but that is something entirely different from Windows containers. You belong to an absolute minority that runs Docker this way and all the work is up to you. Forget documentation or help, you will need to figure out everything by yourself. And with the next release of Docker, you probably need to start from scratch.
I strongly advise against dev containers with the Windows container format. Instead, create a virtual machine somewhere in the cloud and run your dependencies there. This cost a little amount of money but it is by far cheaper than weeks of tracking down problems with the Windows container format.
Start small, add more later
Start with your dev container and then add your dependencies one by one. That way you get something that works early on that you can build on top of that. Put your database in a container and connect from your machine to check if everything works as expected. Only then put your code in a dev container and connect it to the database in the container. Those baby steps look boring, but with only one moving part you can pinpoint errors fast and accurate.
If you try everything at once you may miss a tiny configuration details and nothing works. It is no fun to debug a connection issue between 3 or 4 containers. Go slow to go fast.
Start with a Dockerfile – if you must
While a Dockerfile seems to be the natural starting point, you may not need it for your dev container. If you can get a good image that someone else maintains, you can leverage their work without investing too much time into creating your own image. Therefore, try an existing image first before you spend time in setting up everything in a specific way. More often than not a small change in your environment makes your own Dockerfile obsolete.
It is a big step from a dev container to production
It may not look that way, but from a dev container where you need all the access rights and your dev tools to a container that runs in production is a long way. In production you need to care about restricted access rights, minimalistic images and how you harden your image to prevent security problems – all things you do not need in your dev container. If you want to go ahead and run your app in a container in production, you need time to make it secure. There are many great tutorials that can help you, but please do not put your dev container into production. It will not take long and someone else runs it.
Conclusion
If you put a few applications into a dev container you see a repeating pattern. You can reuse your own configuration files and quickly add more dependencies if needed. I can recommend dev containers for applications with multiple dependencies or incompatible versions. However, dev containers are no silver bullet that will clean-up your application. They are a first step to clean things up but you will need to do the work yourself.