Några av de vanligaste frågorna som ställs av våra användare är angående MariaDB-stöd i Docker, och i synnerhet hur det kan användas i specifika utvecklings- eller produktionsinstallationer. Den här serien av artiklar kommer att försöka täcka några Docker- och MariaDB-användningsfall.
Varför välja Docker för MariaDB?
- Docker-behållare kan användas för att testa, distribuera och släppa applikationer i alla miljöer.
- Docker-distributioner kan enkelt automatiseras, skapa distributionsmiljöer och reproducera dem enkelt i iscensättning och produktion.
- Docker är lätt virtualisering. Hypervisorer behövs inte, och en MariaDB Docker-container bör fungera lika bra som en vanlig MariaDB-installation utan några märkbara overhead.
- Docker är agnostiker – när du väl har installerat Docker på ditt operativsystem är instruktionerna för att köra behållare exakt desamma, oavsett om du kör CentOS, Debian eller Ubuntu, eller till och med Mac OS X och Windows.
Några viktiga punkter om Docker-containrar
- Docker-behållare är oföränderliga. De kan inte lätt modifieras efter start (såvida du inte fäster den och bryter allt).
- Som standard och på grund av ovanstående är data inte beständiga. Docker använder datavolymer för att åtgärda detta. MariaDB-behållaren använder en volym för att bevara data (mer om detta senare).
State of MariaDB in Docker
MariaDB har alltid fått mycket bra stöd i Docker under ett par år, tack vare många ansträngningar från Docker-teamet och communityn. Än idag stöder Docker alla tre MariaDB-versioner:5.5, 10.0 och 10.1. MariaDB docker-behållaren har följande egenskaper:
- MariaDB root-lösenordet kan ställas in eller genereras genom miljövariabler.
- En ny användare och en tom databas kan skapas genom samma process som ovan.
- Förekomsten har en standard /var/lib/mysql beständig datavolym, som du kan låta docker hantera internt eller montera till en valfri katalog.
- Behållarinstansen kan monteras på en befintlig datavolym (till exempel en säkerhetskopia).
- Nätverksportar kan bindas till godtyckliga portar på värdsidan.
- MariaDBs kunskapsbas har en omfattande dokumentationsartikel om docker. Läs den!
Docker användningsfall #1:Multi Tenancy
Ett vanligt användningsfall för MariaDB och Docker kör flera instanser av MariaDB på samma fysiska värdar. Det finns redan befintliga lösningar som MySQL Sandbox och andra, men ingen av dem ger den flexibilitet, användarvänlighet och kraft som Docker erbjuder.
För att illustrera vår poäng, låt oss börja med tre olika instanser av MariaDB, var och en av de som kör en annan huvudversion:
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 kommer automatiskt att hämta de officiella mariadb-bilderna från förvaret och starta dem. Nu kan vi helt enkelt ansluta till någon av dessa instanser med den medföljande porten och lösenordet:
$ 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.
Observera att var och en av våra instanser kommer att använda en beständig datavolym som finns under ~/mdbdata katalog – Docker skapar automatiskt detta katalogträd åt oss.
Nu när vi har gjort det, låt oss fördjupa oss i avancerade funktioner i Docker. Docker stöder Linux-kontrollgrupper (cgroups), som kan användas för att begränsa, ta hänsyn till eller isolera resursanvändning. Låt oss säga att vi vill ha vår MariaDB 10.1-instans (som heter mdb11 ) för att ha en högre CPU-prioritet än de två andra instanserna. I det här fallet kan vi sänka CPU-andelar för mdb10 och mdb55 . Varje instans har 1024 maximala CPU-andelar som standard, så låt oss återskapa vår mdb55 och mdb10 behållare med 512 CPU-andelar vardera.
I ingressen sa vi att Docker-containrar är oföränderliga. Om vi vill ändra våra containrars parametrar måste vi ta bort dem. Detta är inte ett problem eftersom vi har definierat beständiga datavolymer i ~/mdbdata, så det faktiska innehållet i vår databas kommer att finnas kvar när vi återskapar behållarna.
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 återskapat de två MariaDB-instanserna med 512 CPU-andelar vardera. Detta är dock en mjuk gräns och tillämpas endast när processer konkurrerar om CPU-cykler. Om de andra instanserna är inaktiva kan alla instanser använda upp till 100 % av alla processorer. I praktiken betyder detta att om alla tre instanserna använder CPU samtidigt, var och en av de två första behållarna, som har 512 delningar var, (mdb55 och mdb10 ) kommer att kunna använda upp till 25 % av alla processorer, medan den tredje behållaren, som har 1024 delningar, kommer att kunna använda upp till 50 % av alla processorer.
Ett annat alternativ är att binda instansen till en specifik CPU-kärna, så låt oss återskapa behållarna och göra 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 exemplet ovan, givet ett 4 CPU-kärnsystem, mina behållare mdb55 och mdb10 kommer var och en att köras på en separat, enda CPU-kärna medan mdb11 kommer båda kvarvarande kärnor.
Vi kan också kontrollera hur våra containrar får tillgång till disk- och minnesresurser, vilket definitivt är användbart i ett upptaget system – du vill till exempel inte ha en skenande utvecklingsfråga som använder alla diskar i dina belastningstestningsinstanser. Medan minnesgränserna är enkla, fungerar block-IO-andelar på ett liknande sätt som CPU-resurserna, förutom att standardblockets IO-andel är 500 i ett intervall från 10 till 1000.
Låt oss begränsa våra två första behållare till 512 miljoner minne och 250 block-IO-resurser:
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 likhet med vad vi har sett i CPU-andelsexemplet, om de tre instanserna konkurrerar om IO, kommer var och en av de två första behållarna att begränsas till 25 % av tillgänglig IO-kapacitet, den tredje behållaren är begränsad till den återstående kapaciteten, t.ex. 50 %
Det finns mycket mer i Docker runtime-begränsningar än vad vi har pratat om här i den här artikeln. Läs den omfattande referensen för Docker-körning för att veta mer om alla möjliga alternativ.