Cuando las personas hablan de ejecutar una base de datos en Docker, no tienen la intención de almacenar los datos en un contenedor; están hablando de tener una imagen acoplable con el software DB y montar los datos como un volumen (un volumen de enlace, no un volumen de contenedor).
Los volúmenes son una parte esencial en Docker, y no son algo escamoso o simplemente agregado. Docker no está hecho solo para servicios (micro) sin estado.
Por mucho que lo desee, no puedo encontrar una razón técnica para no ejecutar una base de datos en un Docker, así que desafortunadamente elegiré el otro lado del argumento y, por lo tanto, tal vez no le dé la respuesta que está buscando.
(Estoy usando Oracle como ejemplo porque estoy familiarizado con él, tanto de metal desnudo como dockerizado, y porque es una bestia bastante notoria por ser un poco no trivial de operar si pasa de la configuración predeterminada).
- Empaquetar el software DB en un contenedor le brinda los beneficios habituales: tener la misma versión en todas partes, evitar problemas de dependencia / biblioteca compartida, ser capaz de activar exactamente la misma DB en computadoras portátiles de desarrollador o donde sea que la necesite.
- Es muy fácil hacerlo funcionar en cualquier lugar; la actualización es trivial, y así sucesivamente. Se aplican todos los beneficios de Docker. Hay una imagen de Oracle en Dockerhub que le permite girar una base de datos en funcionamiento en un minuto o tres (y para los demás, por supuesto).
- Las personas hicieron pruebas de rendimiento y no encontraron diferencias de E / S entre volúmenes y metal desnudo ( https://www.percona.com/blog/2016/02/11/measuring-docker-io-overhead/ , https: // stackoverflow .com / preguntas / 21889053 / what-is-the-runtime-performance-cost-of-a-docker-container ).
- Debajo del capó, no es como Docker de alguna manera intercepta todas las E / S, de todos modos. Simplemente se vuelve creativo con las herramientas estándar de Linux (los montajes de enlace en este caso, la destrucción de las tablas internas del núcleo que hacen posible el Docker-fu).
- Obviamente, eso no significa que pueda ejecutar dos instancias de la base de datos y simplemente hacer que funcionen en los mismos archivos, pero nadie está implicando eso. Docker no le brinda acceso automático, simultáneo y mágicamente libre de carrera a los volúmenes, y nunca pretendió hacerlo. El resto de los beneficios aún se aplican. Si su DB no detecta conflictos como este, es mejor que proporcione un script CMD a la imagen que se niegue a girar un segundo contenedor cuando el volumen ya esté en uso.
- Debe ser un poco más cuidadoso al girar / apagar el contenedor (así como no simplemente apaga un servidor de base de datos), pero eso debería ser bastante manejable.
Ahora, dependiendo de las circunstancias, puede haber razones blandas para no hacerlo:
- Oracle (la compañía), por ejemplo, ciertamente no lo apoyará si ejecuta su RDBMS en un contenedor Docker. Pero tal vez esté utilizando imágenes dockizadas de Oracle RDBMS solo para sus desarrolladores y el entorno de prueba, donde no necesitaría su soporte en ningún caso, reservándolo para un servidor de producción simple. (Pero no olvides pagar tus licencias ...).
- Si los chicos de operaciones no están familiarizados con Docker, podría ser un poco más fácil matar accidentalmente todo, destruir sus archivos de datos, etc.
- Si usted tiene grandes máquinas de metal dedicada DB ya, con grandes cantidades de almacenamiento SAN dedicado muy rápido, y corriendo nada más de todos modos, entonces no solo habría ningún punto en el uso acoplable a containerize aquellos a medida que se nunca se acaba de girar otro servidor cuando hay son cientos de GB o incluso TB de datos. Después de todo, para la producción, un RDBMS como Oracle está muy, muy avanzado en todos los aspectos de replicación, integridad de datos, failover sin tiempo de inactividad, etc. Tenga en cuenta que este argumento solo dice "no es necesario que contenga su RDBMS en contenedores". No dice "no deberías hacerlo", tal vez quieras hacerlo porque deseas implementar actualizaciones de software de bases de datos a través de contenedores o por cualquier otra razón que puedas imaginar.
Ahí vas. Por supuesto , dockerice su base de datos, al menos para sus desarrolladores (que estarán eternamente agradecidos) y sus entornos de prueba. En la producción, que se reducirá a gusto, y hay por lo menos, yo también preferiría la solución que se sienta mejor con los DBA / OPS especializados - si tienen décadas de experiencia trabajando servidores metal desnudo DB, entonces por todos los medios que confiar para continuar así. Pero si de todas formas es una startup que tiene toda la TI en la nube, entonces un contenedor Docker sería una pieza más de cebolla en toda la imagen.