5 ms·

Database servers, whether MySQL or PostgreSQL or NoSQL ones like CouchDB should never be dockerized. This is a use case where it is inappropriate to use Docker

Database servers, whether MySQL or PostgreSQL or NoSQL ones like CouchDB should never be dockerized. This is a use case where it is inappropriate to use Docker at all. This is a case where the db server should use the entire resources of a single server and for managing that server (and its replicas or other cluster members) you use a tool like Ansible or Chef or Puppet. And you need to learn that management tool well, because you will be pushing the limits of server automation with a database server. If you think that a database server is where you put your "application's database" then I question why you have a db server at all. That is the use case SQLITE is for. Database servers are for the use case of storing the business's mission critical data so that all the applications of the business can access needed data. I love Docker and use it a lot, but not for everything.

aeharding 10y ago
Eh. For small scale, running a DB in a container and linking the DB storage to a directory on the host's filesystem works well enough. I can't talk about large scale since I don't have first hand experience managing a setup like that.
marcc 10y ago
Could you expand on why "database servers... should never be dockerized"? You mention that database servers should have access to all of the resources of the server, but Docker doesn't prevent that. What other reasons would you give someone when they are considering Docker vs Ansible/Chef/Puppet to deploy a database server or cluster?
UK-AL 10y ago
There are other benefits to docker than just being able to run multiple processes on the same machine. Putting everything you need to build an image using a dockerfile(Then to version control that) is useful. Developers can also grab docker images for databases for their localmachines without any setup. Also consistency with the rest of the stack.
- iamatworknow 10y ago
  If you don't need containerization and still want those features you mention why not just use Vagrant?
  - UK-AL 10y ago
    I often use vagrant + docker. It isn't a replacement for docker. Vagrant isn't designed for servers. I want be using the exact same dockerfiles + images on dev machine, as i'm using on production. I usually use vagrant + docker images running inside the vm. Sometimes however since I often have all my microservices on my machine, which can consume a lot of ram. I don't want be splitting my RAM between a VM.
otterley 10y ago
I wouldn't go so far as to say they should "never be containerized," but doing so doesn't solve any of your problems other than a packaging problem, and it arguably creates problems you might not have had before. It's my experience that most of the impetus behind Docker is driven by developers who need it on their Mac/Windows workstations to run Linux processes, and who (for good reason) want to ensure that their development environment is as similar to the production environment as possible. In other words, the developers are driving the production environment, instead of the production engineers driving the development environment. This leads to friction when the production environment has its own unique set of constraints and needs that Docker and containers aren't quite yet a match for.
- memracom 10y ago
  I also develop on OSX or Windows systems, targeting Linux as the deployment system. And I also want to test the code in an environment as close to production as possible. That is why I install Virtualbox and set up virtual Linux servers using the exact same server management scripts (in my case Ansible) as are used to configure production servers. It works great with no Docker. But I do use Docker as well for servers that are more cookie cutter than a db. For instance a JVM app server that has two Docker images, one with 3 layers culminating in the JVM app, and one with 2 layers culminating in an NGINX SSL proxy. And I don't run Docker on OSX at all because it is just a wrapper for running Virtualbox with a Linux server inside. It is simplicity to just set up Virtualbox directly and just use Linux virtual servers directly.
user5994461 10y ago
> This is a case where the db server should use the entire resources of a single server They have thousands of clusters. They didn't design/architect anything. They're likely just trying to regroup databases because they are heavily underutilized and noone knows WTF they are running. And the organization will keep growing like that, adding new databases every day.
UK-AL 10y ago
Why? There are tons of advantages of using docker that's not just for running multiple processes on a single machine. You can still gain advantages from just installing a single database container on a big server + docker volumes. Being able to version control image creation scripts, being able to pull a identical image for both dev/production is useful and quicker than trying to use puppet on dev machines, the fact you can now use your docker deployment infrastructure for all services, and not have exceptions for things. Whats the disadvantage? No one has explained this to me.
- memracom 10y ago
  I don't understand your puppet comment, but then I have never used it. I had some experience with Chef, lots of experience with shell scripts to config servers from scratch. But now I use Ansible instead. Technically I still run a shell script to call AWS CLI and launch an instance, but then I do everything else with an Ansible playbook that configures the server, installs a specific version of PostgreSQL, adds some extras like server extensions and a performance reporting tool. This is what set up our current production and dev servers, and from time to time I use it to set up yet another server to test something like adding a language extension, before running it against the dev server. And as I mentioned, I also use Docker for other servers. My experience is that using Docker to set up a server is usually the same amount of work as Ansible. But Ansible is more amenable to refactoring into reusable components, i.e. components of the build/config process.

aeharding 10y ago

Eh. For small scale, running a DB in a container and linking the DB storage to a directory on the host's filesystem works well enough. I can't talk about large scale since I don't have first hand experience managing a setup like that.

marcc 10y ago

Could you expand on why "database servers... should never be dockerized"? You mention that database servers should have access to all of the resources of the server, but Docker doesn't prevent that. What other reasons would you give someone when they are considering Docker vs Ansible/Chef/Puppet to deploy a database server or cluster?

UK-AL 10y ago

There are other benefits to docker than just being able to run multiple processes on the same machine. Putting everything you need to build an image using a dockerfile(Then to version control that) is useful. Developers can also grab docker images for databases for their localmachines without any setup. Also consistency with the rest of the stack.

iamatworknow 10y ago
If you don't need containerization and still want those features you mention why not just use Vagrant?
- UK-AL 10y ago
  I often use vagrant + docker. It isn't a replacement for docker. Vagrant isn't designed for servers. I want be using the exact same dockerfiles + images on dev machine, as i'm using on production. I usually use vagrant + docker images running inside the vm. Sometimes however since I often have all my microservices on my machine, which can consume a lot of ram. I don't want be splitting my RAM between a VM.

otterley 10y ago

I wouldn't go so far as to say they should "never be containerized," but doing so doesn't solve any of your problems other than a packaging problem, and it arguably creates problems you might not have had before. It's my experience that most of the impetus behind Docker is driven by developers who need it on their Mac/Windows workstations to run Linux processes, and who (for good reason) want to ensure that their development environment is as similar to the production environment as possible. In other words, the developers are driving the production environment, instead of the production engineers driving the development environment. This leads to friction when the production environment has its own unique set of constraints and needs that Docker and containers aren't quite yet a match for.

memracom 10y ago
I also develop on OSX or Windows systems, targeting Linux as the deployment system. And I also want to test the code in an environment as close to production as possible. That is why I install Virtualbox and set up virtual Linux servers using the exact same server management scripts (in my case Ansible) as are used to configure production servers. It works great with no Docker. But I do use Docker as well for servers that are more cookie cutter than a db. For instance a JVM app server that has two Docker images, one with 3 layers culminating in the JVM app, and one with 2 layers culminating in an NGINX SSL proxy. And I don't run Docker on OSX at all because it is just a wrapper for running Virtualbox with a Linux server inside. It is simplicity to just set up Virtualbox directly and just use Linux virtual servers directly.

user5994461 10y ago

> This is a case where the db server should use the entire resources of a single server They have thousands of clusters. They didn't design/architect anything. They're likely just trying to regroup databases because they are heavily underutilized and noone knows WTF they are running. And the organization will keep growing like that, adding new databases every day.

UK-AL 10y ago

Why? There are tons of advantages of using docker that's not just for running multiple processes on a single machine. You can still gain advantages from just installing a single database container on a big server + docker volumes. Being able to version control image creation scripts, being able to pull a identical image for both dev/production is useful and quicker than trying to use puppet on dev machines, the fact you can now use your docker deployment infrastructure for all services, and not have exceptions for things. Whats the disadvantage? No one has explained this to me.

memracom 10y ago
I don't understand your puppet comment, but then I have never used it. I had some experience with Chef, lots of experience with shell scripts to config servers from scratch. But now I use Ansible instead. Technically I still run a shell script to call AWS CLI and launch an instance, but then I do everything else with an Ansible playbook that configures the server, installs a specific version of PostgreSQL, adds some extras like server extensions and a performance reporting tool. This is what set up our current production and dev servers, and from time to time I use it to set up yet another server to test something like adding a language extension, before running it against the dev server. And as I mentioned, I also use Docker for other servers. My experience is that using Docker to set up a server is usually the same amount of work as Ansible. But Ansible is more amenable to refactoring into reusable components, i.e. components of the build/config process.