Why you should run one service per container

In my last post I described how I set up a single Docker image that runs several services using runit. I also said right from the start that I do not recommend to do so. Now I’ll describe why I think multiple containers is the way to go. This is probably mostly preaching to the choir, but here we go. I’ll make the assumption that the single-container solution we’re criticizing it build around runit. Read On →

How to use a Docker container like a fancy VM

Before we start I do not generally recommend this approach. It can, however, be a valid one in some particular cases. For example, it can be a useful approach if you want to move an existing server setup with multiple applications running on the server over to Docker. It is then sometimes easier to not go “Docker all the way” at first, but to keep the new dockerized setup pretty close to what you had running on your server in the first place. Read On →

Why and how we converted 89 git repositories to one monorepo

I work at Impossible Software, where we offer realtime video personalization as SaaS. Two years ago we switched from manually setting up Git repositories on a server to using Gitlab for managing Git repositories. The number of Git repositories grew rapidly, mostly because of a 1:1:1 mapping of Git repository → Jenkins job → Debian package. Skip to the last section if you’re only interested in the how and not so much in the why. Read On →