MariaDB
 sql >> Database >  >> RDS >> MariaDB

Casi d'uso MariaDB e Docker, parte 1

Alcune delle domande più comuni poste dai nostri utenti riguardano il supporto di MariaDB in Docker e, in particolare, come può essere utilizzato in specifiche implementazioni di sviluppo o produzione. Questa serie di articoli cercherà di coprire alcuni casi d'uso Docker e MariaDB.

Perché scegliere Docker per MariaDB?

  • I container Docker possono essere utilizzati per testare, distribuire e rilasciare applicazioni in qualsiasi ambiente.
  • Le implementazioni Docker possono essere automatizzate facilmente, creando ambienti di distribuzione e riproducendoli facilmente in fase di staging e produzione.
  • Docker è una virtualizzazione leggera. Gli hypervisor non sono necessari e un contenitore Docker di MariaDB dovrebbe funzionare esattamente come una normale installazione di MariaDB senza alcun sovraccarico evidente.
  • Docker è agnostico:una volta installato Docker sul tuo sistema operativo, le istruzioni per l'esecuzione dei container sono esattamente le stesse, indipendentemente dal fatto che tu stia utilizzando CentOS, Debian o Ubuntu, o anche Mac OS X e Windows.

Alcuni punti importanti sui container Docker

  • I contenitori Docker sono immutabili. Non possono essere facilmente modificati dopo l'avvio (a meno che non ti alleghi e rompi tutto).
  • Per impostazione predefinita ea causa di quanto sopra, i dati non sono persistenti. Docker utilizza i volumi di dati per rimediare a questo. Il contenitore MariaDB utilizza un volume per conservare i dati (ne parleremo più avanti).

Stato di MariaDB in Docker

MariaDB è sempre stata molto ben supportata in Docker per un paio d'anni, grazie ai molti sforzi del team e della community di Docker. Ad oggi, Docker supporta tutte e tre le versioni di MariaDB:5.5, 10.0 e 10.1. Il contenitore docker MariaDB presenta le seguenti particolarità:

  • La password di root di MariaDB può essere impostata o generata tramite variabili di ambiente.
  • È possibile creare un nuovo utente e un database vuoto tramite la stessa procedura di cui sopra.
  • L'istanza ha un volume di dati persistente /var/lib/mysql predefinito, che puoi lasciare che docker gestisca internamente o monti in una directory a tua scelta.
  • L'istanza del contenitore può essere montata su un volume di dati esistente (ad esempio un backup).
  • Le porte di rete possono essere associate a porte arbitrarie sul lato host.
  • La knowledge base di MariaDB contiene un ampio articolo di documentazione sulla finestra mobile. Leggilo!

Caso d'uso Docker n. 1:Multi Tenancy

Un caso d'uso comune per MariaDB e Docker è l'esecuzione di diverse istanze di MariaDB sugli stessi host fisici. Esistono già soluzioni esistenti come MySQL Sandbox e altre, tuttavia nessuna offre la flessibilità, la facilità d'uso e la potenza offerte da Docker.

Per illustrare il nostro punto, iniziamo tre diverse istanze di MariaDB, ognuna delle quali esegue una versione principale diversa:

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 estrarrà automaticamente le immagini ufficiali di mariadb dal repository e le avvierà. Ora possiamo semplicemente connetterci a una qualsiasi di queste istanze utilizzando la porta e la password fornite:

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

Tieni presente che ciascuna delle nostre istanze utilizzerà un volume di dati persistente situato sotto ~/mdbdata directory:Docker creerà automaticamente questo albero di directory per noi.

Ora che l'abbiamo fatto, analizziamo le funzionalità avanzate di Docker. Docker supporta i gruppi di controllo Linux (cgroup), che possono essere utilizzati per limitare, contabilizzare o isolare l'utilizzo delle risorse. Diciamo che vogliamo la nostra istanza MariaDB 10.1 (denominata mdb11 ) per avere una priorità CPU maggiore rispetto alle altre due istanze. In questo caso possiamo abbassare le condivisioni della CPU di mdb10 e mdb55 . Ogni istanza ha un massimo di 1024 condivisioni CPU per impostazione predefinita, quindi ricreiamo il nostro mdb55 e mdb10 contenitori con 512 condivisioni CPU ciascuno.

Nel preambolo abbiamo detto che i container Docker sono immutabili. Se vogliamo modificare i parametri dei nostri contenitori, dobbiamo rimuoverli. Questo non è un problema perché abbiamo definito i volumi di dati persistenti in ~/mdbdata, quindi il contenuto effettivo del nostro database persisterà quando ricreeremo i contenitori.

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

Abbiamo ricreato le due istanze MariaDB con 512 condivisioni CPU ciascuna. Questo è un limite morbido, tuttavia, e viene applicato solo quando i processi competono per i cicli della CPU. Se le altre istanze sono inattive, qualsiasi istanza è in grado di utilizzare fino al 100% di tutte le CPU. In pratica, ciò significa che se tutte e tre le istanze utilizzano la CPU contemporaneamente, ciascuno dei primi due container, che hanno 512 condivisioni ciascuno, (mdb55 e mdb10 ) sarà in grado di utilizzare fino al 25% di tutte le CPU, mentre il terzo container, che ha 1024 condivisioni, sarà in grado di utilizzare fino al 50% di tutte le CPU.

Un'altra opzione è associare l'istanza a un core della CPU specifico, quindi ricreiamo i contenitori e procediamo così:

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

Nell'esempio sopra, dato un sistema a 4 CPU Core, i miei container mdb55 e mdb10 ciascuno verrà eseguito su un singolo core CPU separato mentre mdb11 saranno entrambi i core rimanenti.

Possiamo anche controllare il modo in cui i nostri contenitori accedono al disco e alle risorse di memoria, il che è sicuramente utile su un sistema occupato:non vuoi che una query di sviluppo incontrollata utilizzi tutto il disco delle tue istanze di test di carico, ad esempio. Mentre i limiti di memoria sono semplici, le condivisioni I/O a blocchi funzionano in modo simile alle condivisioni della CPU, tranne per il fatto che la condivisione I/O a blocchi predefinita è di 500 in un intervallo da 10 a 1000.

Limitiamo i nostri primi due contenitori a 512 milioni di memoria e 250 condivisioni di I/O a blocchi:

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

Analogamente a quanto visto nell'esempio delle condivisioni della CPU, se le tre istanze competono per l'IO, ciascuno dei primi due container sarà limitato al 25% della capacità IO disponibile, mentre il terzo container sarà limitato alla capacità rimanente, ad es. 50%.

C'è molto di più nei vincoli di runtime Docker rispetto a quello di cui abbiamo parlato qui in questo articolo. Leggi l'ampio riferimento all'esecuzione di Docker per conoscere tutte le opzioni possibili.