Skip to main content
Question Protected by 030
clarified terminology
Source Link
hawkeye
  • 1.2k
  • 1
  • 9
  • 14

I'm having a discussion with a friend about use cases for Docker. One guy in the team wants to use Docker for everything - like a kind of universal unix process wrapper. The other thinks that Docker should only be used for stateless applications like Microservices and AWS Lambda style apps.

We've engineered proof of concepts for both. On our docker cluster we have a shared drive that gets mounted when the Docker host is mounted, and if a Database in a container is mounted, it simply mounts a volume to the shared drive.

My friend still sticks to his position, despite being shown the contrary evidence. (He also argues that Docker adds unnecessary risk by adding complexity to the stack.)

I'm trying to listen and understand his point of view, both in an act of empathy, but also to better reason with him. (We all get on quite well - so this is a mix of in-jest and serious discussion).

Kind of the question behind the question is: are databases cattle? This comment suggests that a good automated backup and retrieval strategy for your database is indistinguishable from a cattle server.

My question is: What are the reasons Docker should not be used for databases?

EDIT: People have asked me to clarify my terminology. I was assuming that the database application was in the container, and the storage was in the volume. What I meant was, the RDBMS is in the container, and the database storage is in the volume.

Some commentators have suggested that the docker volume drivers aren't going to work with database writes very well. (Or something to that effect). Could you please expand on that?

I'm having a discussion with a friend about use cases for Docker. One guy in the team wants to use Docker for everything - like a kind of universal unix process wrapper. The other thinks that Docker should only be used for stateless applications like Microservices and AWS Lambda style apps.

We've engineered proof of concepts for both. On our docker cluster we have a shared drive that gets mounted when the Docker host is mounted, and if a Database in a container is mounted, it simply mounts a volume to the shared drive.

My friend still sticks to his position, despite being shown the contrary evidence. (He also argues that Docker adds unnecessary risk by adding complexity to the stack.)

I'm trying to listen and understand his point of view, both in an act of empathy, but also to better reason with him. (We all get on quite well - so this is a mix of in-jest and serious discussion).

Kind of the question behind the question is: are databases cattle? This comment suggests that a good automated backup and retrieval strategy for your database is indistinguishable from a cattle server.

My question is: What are the reasons Docker should not be used for databases?

I'm having a discussion with a friend about use cases for Docker. One guy in the team wants to use Docker for everything - like a kind of universal unix process wrapper. The other thinks that Docker should only be used for stateless applications like Microservices and AWS Lambda style apps.

We've engineered proof of concepts for both. On our docker cluster we have a shared drive that gets mounted when the Docker host is mounted, and if a Database in a container is mounted, it simply mounts a volume to the shared drive.

My friend still sticks to his position, despite being shown the contrary evidence. (He also argues that Docker adds unnecessary risk by adding complexity to the stack.)

I'm trying to listen and understand his point of view, both in an act of empathy, but also to better reason with him. (We all get on quite well - so this is a mix of in-jest and serious discussion).

Kind of the question behind the question is: are databases cattle? This comment suggests that a good automated backup and retrieval strategy for your database is indistinguishable from a cattle server.

My question is: What are the reasons Docker should not be used for databases?

EDIT: People have asked me to clarify my terminology. I was assuming that the database application was in the container, and the storage was in the volume. What I meant was, the RDBMS is in the container, and the database storage is in the volume.

Some commentators have suggested that the docker volume drivers aren't going to work with database writes very well. (Or something to that effect). Could you please expand on that?

Source Link
hawkeye
  • 1.2k
  • 1
  • 9
  • 14

What are the reasons Docker should not be used for databases?

I'm having a discussion with a friend about use cases for Docker. One guy in the team wants to use Docker for everything - like a kind of universal unix process wrapper. The other thinks that Docker should only be used for stateless applications like Microservices and AWS Lambda style apps.

We've engineered proof of concepts for both. On our docker cluster we have a shared drive that gets mounted when the Docker host is mounted, and if a Database in a container is mounted, it simply mounts a volume to the shared drive.

My friend still sticks to his position, despite being shown the contrary evidence. (He also argues that Docker adds unnecessary risk by adding complexity to the stack.)

I'm trying to listen and understand his point of view, both in an act of empathy, but also to better reason with him. (We all get on quite well - so this is a mix of in-jest and serious discussion).

Kind of the question behind the question is: are databases cattle? This comment suggests that a good automated backup and retrieval strategy for your database is indistinguishable from a cattle server.

My question is: What are the reasons Docker should not be used for databases?