Nogle af de mest almindelige spørgsmål stillet af vores brugere er vedrørende MariaDB-support i Docker, og især hvordan det kan bruges i specifikke udviklings- eller produktionsimplementeringer. Denne serie af artikler vil forsøge at dække nogle få Docker- og MariaDB-brugssager.
Hvorfor vælge Docker til MariaDB?
- Docker-containere kan bruges til at teste, implementere og frigive applikationer i ethvert miljø.
- Docker-implementeringer kan nemt automatiseres, skabe implementeringsmiljøer og reproducere dem nemt i iscenesættelse og produktion.
- Docker er letvægtsvirtualisering. Hypervisorer er ikke nødvendige, og en MariaDB Docker-container skal fungere lige så godt som en normal MariaDB-installation uden nogen mærkbar overhead.
- Docker er agnostisk – når du først har installeret Docker på dit OS, er instruktionerne til at køre containere nøjagtig de samme, uanset om du kører CentOS, Debian eller Ubuntu, eller endda Mac OS X og Windows.
Et par vigtige punkter om Docker-containere
- Docker-beholdere er uforanderlige. De kan ikke nemt ændres efter start (medmindre du sætter den på og ødelægger alt).
- Som standard og på grund af ovenstående er data ikke persistente. Docker bruger datamængder til at afhjælpe dette. MariaDB-beholderen bruger en volumen til at bevare data (mere om dette senere).
State of MariaDB in Docker
MariaDB har altid været meget godt støttet i Docker i et par år, takket være mange anstrengelser fra Docker-teamet og samfundet. Den dag i dag understøtter Docker alle tre MariaDB-udgivelser:5.5, 10.0 og 10.1. MariaDB docker-containeren har følgende egenskaber:
- MariaDB root-adgangskoden kan indstilles eller genereres gennem miljøvariabler.
- En ny bruger og en tom database kan oprettes gennem samme proces som ovenfor.
- Forekomsten har en standard /var/lib/mysql vedvarende datavolumen, som du kan lade docker administrere internt eller montere til en mappe efter eget valg.
- Beholderforekomsten kan monteres på en eksisterende datavolumen (for eksempel en sikkerhedskopi).
- Netværksporte kan være bundet til vilkårlige porte på værtssiden.
- MariaDB-vidensbasen har en omfattende dokumentationsartikel om docker. Læs det!
Docker use case #1:Multi Tenancy
Et almindeligt brugstilfælde for MariaDB og Docker kører flere forekomster af MariaDB på de samme fysiske værter. Der findes allerede eksisterende løsninger såsom MySQL Sandbox og andre, men ingen af dem giver den fleksibilitet, brugervenlighed og kraft, som Docker tilbyder.
For at illustrere vores pointe, lad os starte tre forskellige forekomster af MariaDB, hver af dem, der kører en anden hovedversion:
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.1Docker trækker automatisk de officielle mariadb-billeder fra lageret og starter dem. Nu kan vi simpelthen oprette forbindelse til enhver af disse forekomster ved hjælp af den medfølgende port og adgangskode:
$ 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 distributionCopyright (c) 2000, 2016, Oracle, MariaDB Corporation Ab and others.Type 'help;' or 'h' for help. Type 'c' to clear the current input statement.
Bemærk, at hver af vores forekomster vil bruge en vedvarende datavolumen placeret under ~/mdbdata bibliotek – Docker vil automatisk oprette dette bibliotekstræ for os.
Nu hvor vi har gjort det, lad os dykke ned i avancerede funktioner i Docker. Docker understøtter Linux-kontrolgrupper (cgroups), som kan bruges til at begrænse, tage højde for eller isolere ressourceforbrug. Lad os sige, at vi vil have vores MariaDB 10.1-instans (navngivet mdb11 ) for at have en højere CPU-prioritet end de to andre forekomster. I dette tilfælde kan vi sænke CPU-andele af mdb10 og mdb55 . Hver forekomst har 1024 maks. CPU-shares som standard, så lad os genskabe vores mdb55 og mdb10 containere med 512 CPU-dele hver.
I præamblen sagde vi, at Docker-containere er uforanderlige. Hvis vi vil ændre vores containeres parametre, skal vi fjerne dem. Dette er ikke et problem, fordi vi har defineret vedvarende datamængder i ~/mdbdata, så det faktiske indhold af vores database vil bestå, når vi genskaber containerne.
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.0Vi har genskabt de to MariaDB-instanser med hver 512 CPU-shares. Dette er dog en blød grænse og håndhæves kun, når processer konkurrerer om CPU-cyklusser. Hvis de andre instanser er inaktive, er enhver instans i stand til at bruge op til 100 % af alle CPU'er. I praksis betyder det, at hvis alle tre instanser bruger CPU'en samtidigt, vil hver af de to første containere, som hver har 512 shares, (mdb55 og mdb10 ) vil være i stand til at bruge op til 25 % af alle CPU'er, hvorimod den tredje container, som har 1024 delinger, vil kunne bruge op til 50 % af alle CPU'er.
En anden mulighed er at binde instansen til en specifik CPU-kerne, så lad os genskabe beholderne og gøre det:
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.1I eksemplet ovenfor, givet et 4 CPU Core system, mine containere mdb55 og mdb10 vil hver køre på en separat, enkelt CPU-kerne, hvorimod mdb11 vil begge resterende kerner.
Vi kan også kontrollere, hvordan vores containere får adgang til disk- og hukommelsesressourcer, hvilket helt sikkert er nyttigt på et travlt system - du ønsker for eksempel ikke en løbsk udviklingsforespørgsel, der bruger hele disken i dine belastningstestinstanser. Mens hukommelsesgrænser er ligetil, fungerer blok-IO-shares på samme måde som CPU-shares, bortset fra at standardblok IO-share er på 500 i et 10 til 1000-interval.
Lad os begrænse vores to første containere til 512 M hukommelse og 250 blok IO-shares:
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.0I lighed med hvad vi har set i CPU shares-eksemplet, hvis de tre instanser konkurrerer om IO, vil hver af de to første containere være begrænset til 25% af tilgængelig IO-kapacitet, hvor den tredje container er begrænset til den resterende kapacitet, f.eks. 50 %
Der er meget mere i Docker runtime-begrænsninger end det, vi har talt om her i denne artikel. Læs venligst den omfattende Docker-reference for at vide om alle mulige muligheder.