¿Tiene sentido dockerize (containerize) bases de datos?
Puedo entender los beneficios detrás de la dockerización de servicios sin estado, como servidores web, appservers, balanceadores de carga, etc... Si está ejecutando estos servicios en un clúster de máquinas, es muy fácil mover estos contenedores con una sobrecarga baja. Lo que no entiendo, sin embargo, es el propósito detrás de la contenedorización de bases de datos? las bases de datos están conectadas a un volumen de datos que es persistente en un disco duro específico. Debido al estado, no es fácil, y no eficiente para mover realmente el contenedor de base de datos alrededor. Entonces, ¿alguien puede ver por qué dockerizar una base de datos puede ser útil?
3 answers
"Entonces, ¿alguien puede ver por qué dockerizar una base de datos puede ser útil?"
Buena pregunta Keeto. Una de las principales razones para contener sus bases de datos es para que pueda tener el mismo entorno consistente para toda su aplicación, no solo las partes sin estado, en desarrollo, preparación y producción. Un entorno consistente es una de las promesas de docker, pero cuando su base de datos vive fuera de este modelo, hay una gran diferencia que no se puede tener en cuenta en su prueba. Además, al contener su base de datos y el resto de su aplicación, es más probable que pueda mover toda su aplicación entre proveedores de alojamiento (por ejemplo, de AWS a Google Compute). Si utiliza Amazon RDS, por ejemplo, incluso si puede mover sus nodos web a Google, no podrá mover su base de datos, lo que significa que depende en gran medida de su proveedor de nube.
Otra razón para contener servicios de datos es el rendimiento. Esto es particularmente cierto para el servicio proveedores (todas las ofertas de base de datos como servicio-por ejemplo, bases de datos en la nube de rackspace - se ejecutan en contenedores), porque los contenedores le permiten proporcionar garantías de servicio que no son posibles utilizando la virtualización, y ejecutar una base de datos por máquina física no es económicamente viable. Lo más probable es que no esté ejecutando un servicio de alojamiento de bases de datos, pero esta analogía tiene un sentido similar si se está ejecutando en bare metal y desea usar contenedores para el aislamiento del proceso, en lugar de máquinas virtuales. Conseguirás mejor rendimiento para sus bases de datos debido al conocido golpe de e/s que recibe al ejecutar una base de datos en una máquina virtual.
No estoy diciendo que debas contener tu base de datos, pero estas son algunas de las razones por las que tendría sentido.
Divulgación completa, trabajo para clusterhq, ese nuevo proyecto que Mark O'Connor mencionó en su respuesta. Tenemos un proyecto de código abierto llamado Flocker que hace que sea mucho más fácil migrar bases de datos y sus volúmenes entre hosts para que los beneficios I mencionados anteriormente no son completamente superados por los aspectos negativos que planteó en su pregunta.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2014-08-07 08:17:49
No estoy seguro de estar de acuerdo con su comentario sobre la eficiencia... Es mucho más fácil descargar y ejecutar un contenedor de base de datos, en comparación con instalarlo de forma nativa. La documentación de docker describe cómo implementar una separación lógica limpia entre un contenedor con estado y sus datos:
Pero... está en lo correcto que un contenedor con estado estaría vinculado a su servidor host, a menos que haya algún mecanismo para portar el datos alrededor también.
Una solución obvia es montar un volumen de almacenamiento compartido en todos los hosts que podrían estar ejecutando su base de datos.
El siguiente artículo discute una solución muy innovadora donde se usa un cliente tipo bittorrent para replicar un contenedor de datos entre hosts.
Finalmente un nuevo proyecto llamado flocker está intentando resuelva este problema administrando los contenedores con estado y sus volúmenes ZFS asociados:
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2015-04-15 14:52:28
Este es un buen hilo, y el progreso reciente en la clonación de SQL Server agregaría capacidades adicionales para el uso de Contenedores con clones. Esto aborda algunos de los problemas de workign con grandes conjuntos de datos. Divulgación completa, trabajo para Windocks, donde hemos lanzado 2.0 con contenedores SQL Server con clonación de bases de datos integradas.
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/ajaxhispano.com/template/agent.layouts/content.php on line 61
2017-04-14 00:08:33