Should I go "all in" on Docker?

General
1

Short version, outside of a short tutorial to get Docker up and running, I really have not used it. I have read about it quite a bit, and see why it’s got very nice value. But, I have not really dived all in.

Here is my use case: I have 2-3 servers where I run many different web applications: email (postfix/dovecot/spamassassin/etc) + nextcloud + gitlab + a static home page + a little shopping list app) all with LE and behind Apache.

It has been up and running without significant issue for 2+ years.

The one problem with this setup is, it’s not very modular AT ALL. As time as gone on, I have become afraid of doing much to it, for fearing of breaking something. For example, slowly I am finding myself in a situation where I need to upgrade the database (couple year old version of mysql), but all the applications share the same one! This is bad design, I know. But, it was my first stab.

Now, that I feel a bit more mature, I see my errors.

Docker seems like it could help. I could basically put all these apps in their own containers, all behind a common web server that handles LE, and maybe (I will have to decide) a common DB or each with their own.

Also, should I ever want to, I could move these systems of my local home servers, onto a cloud server without major issue.

I guess I just gotta figure out (after I figure out Docker basics), how to manage the interaction between containers (if I share a db, probably will just eat the overhead, and not do that), and networking between the web host and the various containers. Then, I should be good to go.

Is my thinking sound? Should I take the leap?

2

Well, years ago, before Docker I wanted to upgrade Gitlab at my workplace and something went wrong. I could not fix it so we lost everything except the git repositories. Then I had to create a custom git shell where I could handle permissions with a PHP script similar to the way GitLab did it. So I know how risky could an upgrade be. Later I used Docker containers so it is a really good way to avoid a lot of mistakes but do not think that this could solve everything. In fact, you will have other problems to deal with like the one you mentioned (communication). I always say Docker is a good choice if you have time to learn. For small projects where there is not much risk or complication I would switch to Docker. In your case I recommend to start working with Docker in a test environment (clone of your production) and when you feel confident enough and see everything works as it should, then you can finally use it in production.

3

Thanks for the reply! I will do that. I guess that has been why I have not started with Docker already, since the ramp up time to make good use of it, for my use case, since so far (and probably still) I can still just patch everything up. However, as a responsible engineer, I feel exposed and irresponsible by not having the maximum amount of modularity.

4

Make sure to leverage docker compose from the beginning, as it will allow a better re-usability later on and you will be able to store the configuration in git repositores.

Identify the low haning fruits and migrate them one at a time. With every service you migrate, you gain experience and confidence in the approach. Once you migrated all services of your testing environment, you can re-use and adopt the docker compose files for your productive setup.

If you feel that you lack knowledge to takle the task at hand, I can highly recommend to do this free self-paced training: Introduction to Containers. It should give you a solid foundation, as long as you don’t skip the hands-on exercises :slight_smile:

2 Likes