Mongo Container in production environment

I’ve been exploring options to containerize my project in attempt to understand Docker better. I also found out that you can containerize your Mongodb server as well and you can spin it up with the rest of your project using docker-compose

This is awesome but after speaking with another dev, they mentioned that this is considered to be bad practice to containerize in production? Why though?

I’m still new at Docker and the hope is that I can create a CICD pipeline from my local instances to my remote production server.

Hello!

That’s weird. It may be just me, but I’ve never read something like that. I think his claim is just wrong, since containers are just a way to deploy apps (there are app servers, VPS, managed servers, etc.), each with different complexity.

Read about Kubernetes and, more generally, what container orchestration is :slight_smile:.

I was thinking the same thing. It’s just a way to deploy applications to your server.

I’m assuming they mean Mongo specifically. You can run databases in containers. The issue is that containers can be spun up, killed or restarted at will – that’s one of the great benefits of them. In development, a database does benefit from that, that’s normally a useful thing (spin up, seed with pretend data, connect, off you go). In production, it is not – if there’s an issue with it, wiping it out and starting it afresh is not normally a good option because it’s not the database that’s important, it’s the data that lives on it, and you really don’t want that to vanish. There are methods of allowing safe usage, but it’s probably better to avoid putting Mongo in a container unless it’s for data you don’t care about – there are several ways around this, but you have to decide whether you gain anything by adding the extra layers of complexity.

2 Likes

I got a response back the dev that advised not containerizing your production database:

full post here: https://forum.strapi.io/t/docker-compose-error-connecting-to-the-mongo-database/301/7

Most of the reasons involve crashing/instability and management/scaling properly. Resources also becomes a concern especially with the added latency of docker itself, Red Hat’s Podman has solved a lot of the network latency issues but you are still injecting another level of virtualization and the added latency.

Most databases are designed to be extremely latency sensitive (both network and Disk/Memory I/O) and where possible Dedicated hardware with a private LAN (Don’t expose your database to the public internet, looking at you Atlas).

The goal of containers is to provide a stable and repeatable environment to run a scalable application (typically dynamically) and you would not be dynamically scaling your Database cluster.

2 Likes

In that case, I agree… though, honestly, I skipped the part where you spoke about containerize your MongoDB server, so I clearly didn’t understand the context correctly.

In any case, thanks for the update, it’s very useful :slight_smile:.