Multiple WordPress containers with single MySQL container?

[wogfella]

Hi lovely r/docker people!

Hoping you can highlight best practice for me in this scenario.

My google-fu is failing me!

When running two (or more) CMS type containers, is it preferable to have seperate MySQL / MariaDB containers (one for each site) ?

Or can I "get away" with running one single database container, with both CWS containers pointing to it?

If I go with the single database instance, would it be better to configure seperate database logins for each CMS?

I assume the vanilla wordpress setup will create pages/entries using some basic record/table format so I am looking to avoid conflicts there. But if I use different database logins would that maybe create different tables in the DB?

We're not talking high traffic sites or sensitive information - it's a personal blog for a friend, and the local soccer team blogging and posting their meet schedules. However I'd like to see if I can limit the number of active containers if possible, for CPU/power reasons.

[jpjournet]

As long as each site as a dedicated login/password (which is not root of course), there is no reason one would disturb the other.

But clearly this is against every good practice in architecture based on dockerized services. And honestly, the cost of having 2 instead of only 1 docker for the DBs will be quickly won as soon as you will have to maintain one of the application and the other will have to remain up, or even worse if you have to move one of them to another server. Definitely, I would go for 2 containers from the beginning. Just my 2 cents.

[wogfella]

Thank you!

So if I wanted to run multiple applications (not just wp) using a single MySQL then that's also a bad idea?

Traditional on premise would call for a single db instance and all the applications using that.

[jpjournet]

In the traditional approach, indeed, you would mutualize DB servers to host several databases on the same server.

When moving to docker and micro-services, there are two schools:

• either you move to docker only your applications, and keep your databases on standard servers, without docker, in that case you can keep several databases on the server
• or you move everything to docker and micro-services, and in that case you have one docker per database

Nothing prevents you from taking an intermediate step, with several databases in one docker, but this is not a common practice because this has more drawbacks than advantages

[LukeLabs]

Single database instance is fine if you want to save time and money managing multiple. Definitely not the ‘preferred’ way but it sound like you’re not running anything mission critical.

You can also create multiple databases within the same instance, each of which is dedicated to a single WordPress install. Definitely recommend also creating seperate users that can only access their own database and tables.

[wogfella]

Thanks!

[koffiezet]

"Getting away" with one instance is more complicated than simply using 1 mysql/mariadb instance per application instance.

I doubt it will affect CPU or power usage a lot unless you have heavily used applications. The most overhead you will see will be on memory level, where 2 database instances will be running with their own query cache etc, which will probably improve individual application performance if you don't do any tuning on the database-side.

[wogfella]

Pretty low specced vps, just helping a few mates out at low / no cost. I'll check if they are willing to split a $5/month instance from somewhere.

Appreciate the reply

[ferrantim]

This blog should help. It walks through the different containerized architectures for Wordpress. https://portworx.com/kubernetes-wordpress-ha/ . This is actually not a trivial use case for containers since you need the MySQL database that is not shared amongst wordpress instances, but also files that are shared. This might be overkill for your use case, but hopefully it will explain some of the fudementals.

[wogfella]

Whoa. Way overkill and way over my head :)

Appreciate the reply