Cas d'utilisation de MariaDB et Docker, partie 1

Certaines des questions les plus fréquemment posées par nos utilisateurs concernent la prise en charge de MariaDB dans Docker, et en particulier comment elle peut être utilisée dans des déploiements de développement ou de production spécifiques. Cette série d'articles tentera de couvrir quelques cas d'utilisation de Docker et MariaDB.

Pourquoi choisir Docker pour MariaDB ?

• Les conteneurs Docker peuvent être utilisés pour tester, déployer et publier des applications dans n'importe quel environnement.
• Les déploiements Docker peuvent être automatisés facilement, en créant des environnements de déploiement et en les reproduisant facilement en préproduction et en production.
• Docker est une virtualisation légère. Les hyperviseurs ne sont pas nécessaires, et un conteneur MariaDB Docker devrait fonctionner aussi bien qu'une installation MariaDB normale sans surcharge notable.
• Docker est agnostique :une fois que vous avez installé Docker sur votre système d'exploitation, les instructions pour exécuter des conteneurs sont exactement les mêmes, que vous utilisiez CentOS, Debian ou Ubuntu, ou même Mac OS X et Windows.

Quelques points importants sur les conteneurs Docker

• Les conteneurs Docker sont immuables. Ils ne peuvent pas être facilement modifiés après le démarrage (sauf si vous vous y attachez et cassez tout).
• Par défaut et en raison de ce qui précède, les données ne sont pas persistantes. Docker utilise des volumes de données pour y remédier. Le conteneur MariaDB utilise un volume pour conserver les données (plus à ce sujet plus tard).

État de MariaDB dans Docker

MariaDB a toujours été très bien prise en charge dans Docker depuis quelques années, grâce aux nombreux efforts de l'équipe et de la communauté Docker. À ce jour, Docker prend en charge les trois versions de MariaDB :5.5, 10.0 et 10.1. Le conteneur docker MariaDB a les particularités suivantes :

• Le mot de passe root MariaDB peut être défini ou généré via des variables d'environnement.
• Un nouvel utilisateur et une base de données vide peuvent être créés via le même processus que ci-dessus.
• L'instance a un volume de données persistantes /var/lib/mysql par défaut, que vous pouvez laisser docker gérer en interne ou monter dans un répertoire de votre choix.
• L'instance de conteneur peut être montée sur un volume de données existant (par exemple une sauvegarde).
• Les ports réseau peuvent être liés à des ports arbitraires côté hôte.
• La base de connaissances MariaDB contient un article de documentation complet sur Docker. Lisez-le !

Cas d'utilisation de Docker n° 1 :Multi Tenancy

Un cas d'utilisation courant pour MariaDB et Docker consiste à exécuter plusieurs instances de MariaDB sur les mêmes hôtes physiques. Il existe déjà des solutions telles que MySQL Sandbox et d'autres, mais aucune d'entre elles n'offre la flexibilité, la facilité d'utilisation et la puissance offertes par Docker.

Pour illustrer notre propos, commençons par trois instances différentes de MariaDB, chacune exécutant une version majeure différente :

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 extraira automatiquement les images mariadb officielles du référentiel et les lancera. Maintenant, nous pouvons simplement nous connecter à n'importe laquelle de ces instances en utilisant le port et le mot de passe fournis :

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

Notez que chacune de nos instances utilisera un volume de données persistant situé sous le ~/mdbdata répertoire – Docker créera automatiquement cette arborescence de répertoires pour nous.

Maintenant que nous avons fait cela, explorons les fonctionnalités avancées de Docker. Docker prend en charge les groupes de contrôle Linux (cgroups), qui peuvent être utilisés pour limiter, comptabiliser ou isoler l'utilisation des ressources. Disons que nous voulons notre instance MariaDB 10.1 (nommée mdb11 ) pour avoir une priorité CPU plus élevée que les deux autres instances. Dans ce cas, nous pouvons réduire les parts de CPU de mdb10 et mdb55 . Chaque instance a 1024 partages CPU maximum par défaut, alors recréons notre mdb55 et mdb10 conteneurs avec 512 partages de CPU chacun.

Dans le préambule, nous avons dit que les conteneurs Docker sont immuables. Si nous voulons modifier les paramètres de nos conteneurs, nous devons les supprimer. Ce n'est pas un problème car nous avons défini des volumes de données persistants dans ~/mdbdata, de sorte que le contenu réel de notre base de données persistera lorsque nous recréons les conteneurs.

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

Nous avons recréé les deux instances MariaDB avec 512 partages CPU chacune. Il s'agit cependant d'une limite souple, qui n'est appliquée que lorsque les processus sont en concurrence pour les cycles CPU. Si les autres instances sont inactives, n'importe quelle instance peut utiliser jusqu'à 100 % de tous les processeurs. En pratique, cela signifie que si les trois instances utilisent le CPU simultanément, chacun des deux premiers conteneurs, qui ont chacun 512 partages, (mdb55 et mdb10 ) pourra utiliser jusqu'à 25 % de tous les processeurs, tandis que le troisième conteneur, qui compte 1 024 partages, pourra utiliser jusqu'à 50 % de tous les processeurs.

Une autre option consiste à lier l'instance à un cœur de processeur spécifique, alors recréons les conteneurs et faisons cela :

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

Dans l'exemple ci-dessus, étant donné un système à 4 cœurs de processeur, mes conteneurs mdb55 et mdb10 s'exécuteront chacun sur un seul cœur de processeur distinct, tandis que mdb11 les deux cœurs restants.

Nous pouvons également contrôler la façon dont nos conteneurs accèdent aux ressources de disque et de mémoire, ce qui est certainement utile sur un système occupé - vous ne voulez pas qu'une requête de développement galopante utilise tout le disque de vos instances de test de charge, par exemple. Alors que les limites de mémoire sont simples, les partages d'E/S de bloc fonctionnent de la même manière que les partages de CPU, sauf que le partage d'E/S de bloc par défaut est de 500 dans une plage de 10 à 1 000.

Limitons nos deux premiers conteneurs à 512 Mo de mémoire et 250 partages d'E/S de bloc :

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 la même manière que ce que nous avons vu dans l'exemple des partages de CPU, si les trois instances se disputent les E/S, chacun des deux premiers conteneurs sera limité à 25 % de la capacité d'E/S disponible, le troisième conteneur étant limité à la capacité restante, par ex. 50 %.

Il y a beaucoup plus de contraintes d'exécution Docker que ce dont nous avons parlé ici dans cet article. Veuillez lire la référence détaillée de l'exécution de Docker pour connaître toutes les options possibles.