Casos de uso MariaDB e Docker, Parte 1

Algumas das perguntas mais comuns feitas por nossos usuários são sobre o suporte ao MariaDB no Docker e, em particular, como ele pode ser usado em implantações específicas de desenvolvimento ou produção. Esta série de artigos tentará cobrir alguns casos de uso do Docker e do MariaDB.

Por que escolher o Docker para MariaDB?

Os contêineres do Docker podem ser usados para testar, implantar e liberar aplicativos em qualquer ambiente.
As implantações do Docker podem ser automatizadas facilmente, criando ambientes de implantação e reproduzindo-os facilmente na preparação e na produção.
O Docker é uma virtualização leve. Os hipervisores não são necessários, e um contêiner do MariaDB Docker deve funcionar tão bem quanto uma instalação normal do MariaDB sem nenhuma sobrecarga perceptível.
O Docker é agnóstico – depois de instalar o Docker em seu sistema operacional, as instruções para executar contêineres são exatamente as mesmas, esteja você executando CentOS, Debian ou Ubuntu, ou mesmo Mac OS X e Windows.

Alguns pontos importantes sobre contêineres do Docker

Os contêineres do Docker são imutáveis. Eles não podem ser modificados facilmente após o início (a menos que você os anexe e quebre tudo).
Por padrão e devido ao acima, os dados não são persistentes. O Docker usa volumes de dados para remediar isso. O contêiner MariaDB usa um volume para preservar dados (mais sobre isso posteriormente).

Estado do MariaDB no Docker

O MariaDB sempre foi muito bem suportado no Docker por alguns anos, graças a muitos esforços da equipe e da comunidade do Docker. Até hoje, o Docker oferece suporte a todas as três versões do MariaDB:5.5, 10.0 e 10.1. O contêiner docker MariaDB possui as seguintes particularidades:

A senha de root do MariaDB pode ser definida ou gerada por meio de variáveis de ambiente.
Um novo usuário e um banco de dados vazio podem ser criados pelo mesmo processo acima.
A instância tem um volume de dados persistente padrão /var/lib/mysql, que você pode permitir que o docker gerencie internamente ou monte em um diretório de sua escolha.
A instância de contêiner pode ser montada em um volume de dados existente (por exemplo, um backup).
As portas de rede podem ser vinculadas a portas arbitrárias no lado do host.
A base de conhecimento do MariaDB tem um extenso artigo de documentação sobre o docker. Leia!

Caso de uso do Docker nº 1:multilocação

Um caso de uso comum para MariaDB e Docker é executar várias instâncias do MariaDB nos mesmos hosts físicos. Já existem soluções como MySQL Sandbox e outras, porém nenhuma delas oferece a flexibilidade, facilidade de uso e potência que o Docker oferece.

Para ilustrar nosso ponto, vamos iniciar três instâncias diferentes do MariaDB, cada uma delas executando uma versão 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

O Docker puxará automaticamente as imagens oficiais do mariadb do repositório e as iniciará. Agora podemos simplesmente nos conectar a qualquer uma dessas instâncias usando a porta e a senha fornecidas:

$ 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.

Observe que cada uma de nossas instâncias usará um volume de dados persistente localizado em ~/mdbdata diretório – o Docker criará automaticamente essa árvore de diretórios para nós.

Agora que fizemos isso, vamos nos aprofundar nos recursos avançados do Docker. O Docker oferece suporte a grupos de controle do Linux (cgroups), que podem ser usados para limitar, contabilizar ou isolar o uso de recursos. Digamos que queremos nossa instância MariaDB 10.1 (chamada mdb11 ) para ter uma prioridade de CPU mais alta do que as outras duas instâncias. Neste caso podemos diminuir os compartilhamentos de CPU de mdb10 e mdb55 . Cada instância tem 1.024 compartilhamentos máximos de CPU por padrão, então vamos recriar nosso mdb55 e mdb10 contêineres com 512 compartilhamentos de CPU cada.

No preâmbulo, dissemos que os contêineres do Docker são imutáveis. Se quisermos alterar os parâmetros de nossos contêineres, precisamos removê-los. Isso não é um problema porque definimos volumes de dados persistentes em ~/mdbdata, portanto, o conteúdo real de nosso banco de dados persistirá quando recriarmos os contêineres.

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

Recriamos as duas instâncias do MariaDB com 512 compartilhamentos de CPU cada. Este é um limite flexível, porém, e só é aplicado quando os processos competem por ciclos de CPU. Se as outras instâncias estiverem ociosas, qualquer instância poderá usar até 100% de todas as CPUs. Na prática, isso significa que se todas as três instâncias usarem a CPU simultaneamente, cada um dos dois primeiros contêineres, que possuem 512 compartilhamentos cada, (mdb55 e mdb10 ) poderá usar até 25% de todas as CPUs, enquanto o terceiro contêiner, que possui 1024 compartilhamentos, poderá usar até 50% de todas as CPUs.

Outra opção é vincular a instância a um núcleo de CPU específico, então vamos recriar os contêineres e fazer isso:

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

No exemplo acima, dado um sistema de 4 CPU Core, meus contêineres mdb55 e mdb10 cada um será executado em um único núcleo de CPU separado, enquanto mdb11 ambos os núcleos restantes.

Também podemos controlar a maneira como nossos contêineres acessam recursos de disco e memória, o que é definitivamente útil em um sistema ocupado – você não deseja uma consulta de desenvolvimento descontrolada usando todo o disco de suas instâncias de teste de carga, por exemplo. Enquanto os limites de memória são diretos, os compartilhamentos de E/S de bloco funcionam de maneira semelhante aos compartilhamentos de CPU, exceto que o compartilhamento de E/S de bloco padrão é de 500 em um intervalo de 10 a 1000.

Vamos limitar nossos dois primeiros contêineres a 512 M de memória e 250 compartilhamentos de E/S de bloco:

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

Da mesma forma que vimos no exemplo de compartilhamentos de CPU, se as três instâncias competirem por E/S, cada um dos dois primeiros contêineres será limitado a 25% da capacidade de E/S disponível, sendo o terceiro contêiner limitado à capacidade restante, por exemplo 50%.

Há muito mais nas restrições de tempo de execução do Docker do que falamos aqui neste artigo. Leia a extensa referência de execução do Docker para conhecer todas as opções possíveis.