Menu
I can understand the benfits behind dockerizing stateless services, such as web servers, appservers, load balancers, etc... If you are running these services on a cluster of machines, it is very easy to move these containers around with low overhead. What I don't understand though is the purpose behind containerizing databases? databases are connected to a data volume that is persistent in a specific hard disk. Because of state, it is not easy, and not efficient to actually move the database container around. So can anyone see why dockerizing a database can be useful at all?
263
Docker is great for running databases in a development environment! You can even use it for databases of small, non-critical projects which run on a single server. Just make sure to have regular backups (as you should in any case), and you'll be fine.
So, one example of when not to use containers is if a high level of security is critical. They can require more work upfront: If you're using containers right, you will have decomposed your application into its various constituent services, which, while beneficial, isn't necessary if you are using VMs.
Containers enable rapid deployment, patching and scaling of applications. The efficiency derived from containers is unmatched. Containers consume less system requirements than traditional hardware or a VM type of setup.
You can run the application through a container regardless of the operating system and the software inside your computer. Therefore, you can focus on developing your applications and deploy them straightly.
"So can anyone see why dockerizing a database can be useful at all?"
Good question Keeto. One of the main reasons for containerizing your databases is so that you can have the same consistent environment for your entire app, not just the stateless parts, across dev, staging and production. A consistent environment is one of the promises of docker, but when your database lives outside this model, there is a big difference that can't be accounted for in your testing. Also, by containerizing your database as well as the rest of your app, you are more likely to be able to move your entire app between hosting providers (say from AWS to Google Compute). If you use Amazon RDS, for example, even if you can move your web nodes to Google, you won't be able to move your database, meaning that you are heavily dependent on your cloud provider.
Another reason for containerizing data services is performance. This is particularly true for service providers (all the database as a service offerings- e.g. rackspace cloud databases- run in containers), because containers allow you to provide service guarantees that aren't possible using virtualization, and running one database per physical machine is not financially viable. Chances are you aren't running a databases hosting service, but this analogy makes similar sense if you are running on bare metal and want to use containers for process isolation, instead of VMs. You'll get better performance for your databases because of the well-known i/o hit you take when running a db in a VM.
I'm not saying that you should containerize your database, but these are some of the reasons why it would make sense.
Full disclosure, I work for clusterhq, that new project that Mark O'connor mentioned in his answer. We have an opensource project called Flocker that makes it much easier to migrate databases and their volumes between hosts so that the benefits I mentioned above aren't completely outweighed by the negatives that you raised in your question.
81
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
