Docker Community Forums

Share and learn in the Docker community.

Should I go "all in" on Docker?

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?

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.

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.

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