These days, Docker is a frequent friend of many developers. Some developers even turn to Docker to run their database systems – applications are safe in containers, containers usually are lightweight, and generally containers allow devs to bundle all the software they use into “boxes” called Docker containers.
Running Databases in Containers
Running software in containers is generally a mainstream thing, but what about databases or database servers (for example, SQL Server, MySQL, Oracle, PostgreSQL, MariaDB)? Have you ever heard of a dev running his databases in containers as well? Most likely not, because doing so requires extra resources and dedication towards the craft of containers. To run your databases in a containerized environment and utilize database monitoring properly, here’s what you must know:
- - Containers let you approach your databases as an on-demand utility (each application can have its own database.)
- - Containers let you have less “mess” on your machines – you always know what’s where.
- - Multiple containers can run on the same OS.
Running databases in containers is not very easy, though: if we think of containers as a lightweight alternative to VMs, we will quickly realize that containers in this case would let us “engulf” our applications in containers that each might run different operating systems. In case of databases, that most likely would look like each DBMS is “encapsulated” into its own container image. Don’t forget that when dealing with Docker, we’d usually need .yml files that would define the services our containers run, etc.
Everything looks pretty complex, doesn’t it? How do we decide whether we need that in regards to databases? It might help to look at alternatives before answering this question.
Alternatives to Containerization
The most frequent alternative to containerization is simply running a database on a standalone server. This process is quite a lot easier than running databases on containers and it can easily be accomplished both locally and in a live environment. On a local server, you just need to spin up WAMP or its alternative if you’re using Linux, and when you’re in a live environment, buy access to shared hosting, a VPS, or a dedicated server if you’re building services requiring more hardware resources, and you should be good to go. In many cases, databases will even come pre-installed to the services you use.
If you ask a developer or even a database administrator which option is better – should you run your databases on Docker or on a more “natural” environment involving servers – you will probably hear an answer like “Don’t bother with Docker.” Want to know why? Running databases in a containerized environment (using Docker) isn’t a very smart choice due to complexity – Docker might bring less clutter, but it will certainly bring more headaches just by the way it’s structured.
Running your databases on Linux is the traditional and straightforward way to get on the web – when monitoring is concerned, everything can be set up in a more “traditional” fashion when containers don’t get in the way as well. Look at dbWatch: define your connection details and you’re done! Isn’t that awesome?
After your database instances (of whatever database management system flavor you’re using) would be imported into dbWatch, they then could be monitored, and in a span of minutes, a bunch of expert-made database jobs could be run:
With a wide variety of database jobs, dbWatch proves to be a perfect choice for many business owners and database administrators alike – just a couple of clicks, and your database issues will be solved. There’s no need to reinvent the wheel and run databases in a containerized environment using Docker: in fact, not many people run their databases on Docker at all – there’s a good reason for that: doing so is pretty complex, even to advanced database administrators. In many cases, database administrators are not sysadmins, so the traditional way is preferred here. Did we talk about junior developers and DBAs? Docker is not a good choice for them either: in fact, it might steer them away from development altogether, not even talking about choices
As far as containers are concerned, they certainly have their own upsides, but running databases inside of them isn’t one of them.
Running your databases in a traditional, non-containerized way lets you develop and roll out features faster, and you will be able to solve issues faster as well: for example, post a problem you’re having with your databases on Stack Overflow. Chances are, you will instantly be bombarded with questions like “Why are you using Docker?” “Isn’t the traditional way – a good way for you?” etc., so go with the traditional path instead.
Whatever path you choose, bear in mind that there are a bunch of database monitoring tools – and that dbWatch is one of them. dbWatch comes with many of its own unique features that help your databases exceed your wildest expectations, and the experts in the northern part of Europe behind it are always at your service. Try it and you won’t regret it, but before doing that, make sure to take a deeper look at our blog – we have many more things in store for you.
About the Author:
Lukas Vileikis is an ethical hacker and a frequent conference speaker.
Since 2014, Lukas has found and responsibly disclosed security flaws in some of the most visited websites in Lithuania.
He runs one of the biggest & fastest data breach search engines in the world - BreachDirectory.com, frequently speaks at conferences and blogs in multiple places including his blog over at lukasvileikis.com.