sql >> Base de Datos >  >> RDS >> MariaDB

Casos de uso de MariaDB y Docker, Parte 1

Algunas de las preguntas más comunes que hacen nuestros usuarios se refieren a la compatibilidad con MariaDB en Docker y, en particular, cómo se puede usar en implementaciones específicas de desarrollo o producción. Esta serie de artículos tratará de cubrir algunos casos de uso de Docker y MariaDB.

¿Por qué elegir Docker para MariaDB?

  • Los contenedores Docker se pueden usar para probar, implementar y lanzar aplicaciones en cualquier entorno.
  • Las implementaciones de Docker se pueden automatizar fácilmente, creando entornos de implementación y reproduciéndolos fácilmente en la preparación y producción.
  • Docker es una virtualización ligera. No se necesitan hipervisores, y un contenedor MariaDB Docker debería funcionar tan bien como una instalación normal de MariaDB sin ninguna sobrecarga notable.
  • Docker es agnóstico:una vez que haya instalado Docker en su sistema operativo, las instrucciones para ejecutar contenedores son exactamente las mismas, ya sea que esté ejecutando CentOS, Debian o Ubuntu, o incluso Mac OS X y Windows.

Algunos puntos importantes sobre los contenedores Docker

  • Los contenedores Docker son inmutables. No se pueden modificar fácilmente después del inicio (a menos que los adjunte y rompa todo).
  • De forma predeterminada y debido a lo anterior, los datos no son persistentes. Docker usa volúmenes de datos para remediar esto. El contenedor de MariaDB usa un volumen para conservar los datos (más sobre esto más adelante).

Estado de MariaDB en Docker

MariaDB siempre ha tenido un buen soporte en Docker durante un par de años, gracias a los muchos esfuerzos del equipo y la comunidad de Docker. Hasta el día de hoy, Docker es compatible con las tres versiones de MariaDB:5.5, 10.0 y 10.1. El docker container de MariaDB tiene las siguientes particularidades:

  • La contraseña raíz de MariaDB se puede establecer o generar a través de variables de entorno.
  • Se puede crear un nuevo usuario y una base de datos vacía mediante el mismo proceso que el anterior.
  • La instancia tiene un volumen de datos persistente /var/lib/mysql predeterminado, que puede permitir que Docker administre internamente o que se monte en un directorio de su elección.
  • La instancia del contenedor se puede montar en un volumen de datos existente (por ejemplo, una copia de seguridad).
  • Los puertos de red se pueden vincular a puertos arbitrarios en el lado del host.
  • La base de conocimiento de MariaDB tiene un extenso artículo de documentación sobre Docker. ¡Léalo!

Caso de uso n.º 1 de Docker:Multiusuario

Un caso de uso común para MariaDB y Docker es ejecutar varias instancias de MariaDB en los mismos hosts físicos. Ya existen soluciones como MySQL Sandbox y otras, sin embargo, ninguna proporciona la flexibilidad, la facilidad de uso y la potencia que ofrece Docker.

Para ilustrar nuestro punto, comencemos tres instancias diferentes de MariaDB, cada una de las cuales ejecuta una versión principal diferente:

docker run -d -p 3301:3306 -v ~/mdbdata/mdb55:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=admin --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 -v ~/mdbdata/mdb10:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=admin --name mdb10 mariadb:10.0
docker run -d -p 3303:3306 -v ~/mdbdata/mdb11:/var/lib/mysql -e MYSQL_ROOT_PASSWORD=admin --name mdb11 mariadb:10.1

Docker extraerá automáticamente las imágenes oficiales de mariadb del repositorio y las ejecutará. Ahora simplemente podemos conectarnos a cualquiera de esas instancias utilizando el puerto y la contraseña proporcionados:

$ mysql -u root -padmin -h 127.0.0.1 -P3302
Welcome to the MariaDB monitor.  Commands end with ; or g.
Your MariaDB connection id is 2
Server version: 10.0.22-MariaDB-1~jessie mariadb.org binary distribution Copyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others. Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.

Tenga en cuenta que cada una de nuestras instancias utilizará un volumen de datos persistente ubicado en ~/mdbdata directorio:Docker creará automáticamente este árbol de directorios para nosotros.

Ahora que lo hemos hecho, profundicemos en las funciones avanzadas de Docker. Docker admite grupos de control de Linux (cgroups), que se pueden usar para limitar, contabilizar o aislar el uso de recursos. Digamos que queremos que nuestra instancia de MariaDB 10.1 (llamada mdb11 ) para tener una prioridad de CPU más alta que las otras dos instancias. En este caso, podemos reducir las cuotas de CPU de mdb10 y mdb55 . Cada instancia tiene un máximo de 1024 recursos compartidos de CPU de forma predeterminada, así que vamos a recrear nuestro mdb55 y mdb10 contenedores con 512 recursos compartidos de CPU cada uno.

En el preámbulo dijimos que los contenedores Docker son inmutables. Si queremos cambiar los parámetros de nuestros contenedores, debemos eliminarlos. Esto no es un problema porque hemos definido volúmenes de datos persistentes en ~/mdbdata, por lo que el contenido real de nuestra base de datos persistirá cuando volvamos a crear los contenedores.

docker rm -f mdb55 mdb10
docker run -d -p 3301:3306 --cpu-shares=512 -v ~/mdbdata/mdb55:/var/lib/mysql --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 --cpu-shares=512 -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb10 mariadb:10.0

Hemos recreado las dos instancias de MariaDB con 512 recursos compartidos de CPU cada una. Sin embargo, este es un límite suave y solo se aplica cuando los procesos compiten por ciclos de CPU. Si las otras instancias están inactivas, cualquier instancia puede usar hasta el 100 % de todas las CPU. En la práctica, esto significa que si las tres instancias usan la CPU al mismo tiempo, cada uno de los dos primeros contenedores, que tienen 512 recursos compartidos cada uno, (mdb55 y mdb10 ) podrá usar hasta el 25 % de todas las CPU, mientras que el tercer contenedor, que tiene 1024 recursos compartidos, podrá usar hasta el 50 % de todas las CPU.

Otra opción es vincular la instancia a un núcleo de CPU específico, así que volvamos a crear los contenedores y hagamos eso:

docker rm -f mdb55 mdb10 mdb11
docker run -d -p 3301:3306 --cpuset-cpus=0 -v ~/mdbdata/mdb55:/var/lib/mysql --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 --cpuset-cpus=1 -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb10 mariadb:10.0
docker run -d -p 3303:3306 --cpuset-cpus=2-3 -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb11 mariadb:10.1

En el ejemplo anterior, dado un sistema de 4 CPU Core, mis contenedores mdb55 y mdb10 cada uno se ejecutará en un núcleo de CPU único e independiente, mientras que mdb11 serán los dos núcleos restantes.

También podemos controlar la forma en que nuestros contenedores acceden al disco y a los recursos de memoria, lo que definitivamente es útil en un sistema ocupado; por ejemplo, no desea una consulta de desarrollo fuera de control utilizando todo el disco de sus instancias de prueba de carga. Mientras que los límites de memoria son sencillos, los recursos compartidos de E/S en bloque funcionan de manera similar a los recursos compartidos de CPU, excepto que el recurso compartido de E/S en bloque predeterminado es de 500 en un rango de 10 a 1000.

Limitemos nuestros dos primeros contenedores a 512 MB de memoria y 250 bloques compartidos de E/S:

docker rm -f mdb55 mdb10
docker run -d -p 3301:3306 --blkio-weight=250 --memory=512M -v ~/mdbdata/mdb55:/var/lib/mysql --name mdb55 mariadb:5.5
docker run -d -p 3302:3306 --blkio-weight=250 --memory=512M  -v ~/mdbdata/mdb10:/var/lib/mysql --name mdb10 mariadb:10.0

De manera similar a lo que hemos visto en el ejemplo de uso compartido de CPU, si las tres instancias compiten por IO, cada uno de los dos primeros contenedores se limitará al 25 % de la capacidad de IO disponible, y el tercer contenedor se limitará a la capacidad restante, p. 50%.

Hay mucho más en las restricciones de tiempo de ejecución de Docker de lo que hemos estado hablando aquí en este artículo. Lea la extensa referencia de ejecución de Docker para conocer todas las opciones posibles.