Enkele van de meest gestelde vragen van onze gebruikers hebben betrekking op MariaDB-ondersteuning in Docker, en met name hoe deze kan worden gebruikt in specifieke ontwikkelings- of productie-implementaties. Deze serie artikelen zal proberen een paar Docker- en MariaDB-gebruiksgevallen te behandelen.
Waarom kiezen voor Docker voor MariaDB?
- Docker-containers kunnen worden gebruikt voor het testen, implementeren en vrijgeven van applicaties binnen elke omgeving.
- Docker-implementaties kunnen eenvoudig worden geautomatiseerd, waardoor implementatie-omgevingen worden gecreëerd en deze gemakkelijk kunnen worden gereproduceerd in fasering en productie.
- Docker is lichtgewicht virtualisatie. Hypervisors zijn niet nodig en een MariaDB Docker-container zou net zo goed moeten presteren als een normale MariaDB-installatie zonder merkbare overhead.
- Docker is agnostisch:als je Docker eenmaal op je besturingssysteem hebt geïnstalleerd, zijn de instructies voor het uitvoeren van containers precies hetzelfde, of je nu CentOS, Debian of Ubuntu gebruikt, of zelfs Mac OS X en Windows.
Een paar belangrijke punten over Docker-containers
- Docker-containers zijn onveranderlijk. Ze kunnen niet gemakkelijk worden gewijzigd na het starten (tenzij je eraan vastmaakt en alles breekt).
- Standaard en vanwege het bovenstaande zijn gegevens niet persistent. Docker gebruikt datavolumes om dit te verhelpen. De MariaDB-container gebruikt een volume om gegevens te bewaren (hierover later meer).
Staat van MariaDB in Docker
MariaDB wordt al een paar jaar altijd zeer goed ondersteund in Docker, dankzij de vele inspanningen van het Docker-team en de community. Tot op de dag van vandaag ondersteunt Docker alle drie MariaDB-releases:5.5, 10.0 en 10.1. De MariaDB docker container heeft de volgende bijzonderheden:
- Het MariaDB-rootwachtwoord kan worden ingesteld of gegenereerd via omgevingsvariabelen.
- Een nieuwe gebruiker en een lege database kunnen worden aangemaakt via hetzelfde proces als hierboven.
- De instantie heeft een standaard /var/lib/mysql persistent datavolume, dat u door Docker intern kunt laten beheren of aan een directory naar keuze kunt koppelen.
- De containerinstantie kan worden gekoppeld aan een bestaand gegevensvolume (bijvoorbeeld een back-up).
- Netwerkpoorten kunnen worden gekoppeld aan willekeurige poorten aan de hostzijde.
- De kennisbank van MariaDB bevat een uitgebreid artikel met documentatie over docker. Lees het!
Docker use case #1:Multi Tenancy
Een veelvoorkomend gebruik voor MariaDB en Docker is het uitvoeren van meerdere instanties van MariaDB op dezelfde fysieke hosts. Er zijn al bestaande oplossingen zoals MySQL Sandbox en andere, maar geen van hen biedt de flexibiliteit, het gebruiksgemak en de kracht die Docker biedt.
Om ons punt te illustreren, laten we beginnen met drie verschillende instanties van MariaDB, elk met een andere hoofdversie:
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 haalt automatisch de officiële mariadb-afbeeldingen uit de repository en start ze. Nu kunnen we eenvoudig verbinding maken met een van die instanties met behulp van de opgegeven poort en wachtwoord:
$ 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.
Houd er rekening mee dat al onze instanties een permanent gegevensvolume gebruiken dat zich onder de ~/mdbdata bevindt directory – Docker zal deze directorystructuur automatisch voor ons aanmaken.
Nu we dat hebben gedaan, gaan we dieper in op de geavanceerde functies van Docker. Docker ondersteunt Linux-stuurgroepen (cgroups), die kunnen worden gebruikt om het gebruik van bronnen te beperken, te verantwoorden of te isoleren. Laten we zeggen dat we onze MariaDB 10.1-instantie (met de naam mdb11 ) om een hogere CPU-prioriteit te hebben dan de twee andere instanties. In dit geval kunnen we de CPU-shares van mdb10 . verlagen en mdb55 . Elke instantie heeft standaard 1024 maximale CPU-shares, dus laten we onze mdb55 opnieuw maken en mdb10 containers met elk 512 CPU-shares.
In de preambule zeiden we dat Docker-containers onveranderlijk zijn. Als we de parameters van onze containers willen wijzigen, moeten we ze verwijderen. Dit is geen probleem omdat we persistente datavolumes hebben gedefinieerd in ~/mdbdata, dus de feitelijke inhoud van onze database blijft behouden wanneer we de containers opnieuw maken.
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.0We hebben de twee MariaDB-instanties opnieuw gemaakt met elk 512 CPU-shares. Dit is echter een zachte limiet en wordt alleen afgedwongen wanneer processen strijden om CPU-cycli. Als de andere instanties inactief zijn, kan elke instantie tot 100% van alle CPU's gebruiken. In de praktijk betekent dit dat als alle drie de instances de CPU gelijktijdig gebruiken, elk van de twee eerste containers, die elk 512 shares hebben, (mdb55 en mdb10 ) tot 25% van alle CPU's kunnen gebruiken, terwijl de derde container, die 1024 shares heeft, tot 50% van alle CPU's kan gebruiken.
Een andere optie is om de instantie aan een specifieke CPU-kern te binden, dus laten we de containers opnieuw maken en dat doen:
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.1In het bovenstaande voorbeeld, gegeven een 4 CPU Core-systeem, mijn containers mdb55 en mdb10 zullen elk op een afzonderlijke, enkele CPU-kern draaien, terwijl mdb11 zullen beide resterende kernen.
We kunnen ook bepalen hoe onze containers toegang krijgen tot schijf- en geheugenbronnen, wat zeker handig is op een druk systeem - u wilt bijvoorbeeld geen op hol geslagen ontwikkelingsquery waarbij de hele schijf van uw load-testinstanties wordt gebruikt. Terwijl geheugenlimieten eenvoudig zijn, werken blok-IO-shares op dezelfde manier als de CPU-shares, behalve dat de standaard block-IO-share 500 is in een bereik van 10 tot 1000.
Laten we onze twee eerste containers beperken tot 512M geheugen en 250 block 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.0Vergelijkbaar met wat we hebben gezien in het voorbeeld van CPU-aandelen, als de drie instanties strijden om IO, wordt elk van de twee eerste containers beperkt tot 25% van de beschikbare IO-capaciteit, terwijl de derde container beperkt is tot de resterende capaciteit, b.v. 50%.
Er is veel meer aan de runtime-beperkingen van Docker dan waar we het hier in dit artikel over hebben gehad. Lees de uitgebreide referentie voor Docker-runs om meer te weten te komen over alle mogelijke opties.