Meerdere NFS mounts met Docker?

[Lethalis]

Mijn vraag
Sinds kort ben ik bezig met het implementeren van Docker op mijn werk. Zo heb ik gisteren een SQL Server 2017 Express container geconfigureerd. Daarbij was de voornaamste uitdaging (voor mij) om makkelijk te kunnen backuppen naar en restoren van een externe bron.

De manier die ik daarvoor heb gebruikt, is het maken van een Docker volume dat een NFS share kan mounten:

code:

sudo docker volume create \
    --driver local \
    --opt type=nfs \
    --opt o=addr=192.168.168.50,rw \
    --opt device=:/volume1/backup \
    nasbackup

En dan de SQL Server 2017 Express container:

code:

sudo docker run \
    -e 'ACCEPT_EULA=Y' \
    -e 'SA_PASSWORD=************' \
    -e 'MSSQL_PID=Express' \
    --mount type=bind,source=/srv/sql2017,destination=/var/opt/mssql \
    --mount type=volume,source=nasbackup,destination=/backups \
    -p 1433:1433 \
    --hostname app1 \
    --name sql2017 \
    -d mcr.microsoft.com/mssql/server:2017-latest

Het voordeel van het gebruiken van een Docker volume, is dat de NFS share door Docker gemount wordt zodra de container gestart wordt. Docker zorgt er dus voor dat de share beschikbaar is voor SQL Server.

Dit werkt allemaal prima, maar wat ik mij nu afvraag, is het volgende:

Wat is de beste manier om hiermee door te gaan zodra ik meerdere containers heb die toegang hebben tot dezelfde server?

Daarmee bedoel ik niet per se dat ze in elkaars vaarwater komen en dezelfde bestanden bewerken op hetzelfde moment, maar dat bijvoorbeeld 30 containers allemaal een NFS mount hebben naar bijvoorbeeld dezelfde backup directory op een NAS.

Geeft dit problemen? Zijn er dingen waar ik rekening mee moet houden?

Of nog beter: wat zijn de best practices hiervoor?

Er zijn namelijk ook mensen die bijvoorbeeld op de host een NFS share mounten en die simpelweg binden aan hun containers. Een Docker volume lijkt mij echter netter werken.

Dus ik hoop dat hier ervaringsdeskundigen zitten die mij tips kunnen geven over wat de beste manier is om hiermee om te gaan.

Want in principe zal ik meer containers aanmaken in de toekomst (voor SQL Server 2017, 2019, Postgres, enzovoorts) en voor veel van die dingen zal gelden dat er op een eenvoudige manier - op applicatieniveau - gegevens ingelezen en geëxporteerd kunnen worden.

Zoals bij SQL Server dus ook. Even snel een backup maken van een database voordat je een potentieel gevaarlijke query uitvoert, of bijvoorbeeld makkelijk een klantdatabase kunnen inlezen om te kijken wat ermee aan de hand is. Die kan ik nu eenvoudig op de NAS parkeren en vervolgens restoren. Dat soort dingen.

Relevante software en hardware die ik gebruik
Meestal (virtuele) Ubuntu of Debian Linux met Docker er op.

Wat ik al gevonden of geprobeerd heb
Ik vind allerlei manieren om het op te lossen, maar ik vind het lastig te beoordelen wat nou het verstandigste is.

Kortom:
1. Volume mounts gebruiken per container naar dezelfde directory
2. Volume mounts gebruiken per container naar elk hun eigen directory (klinkt goed)
3. Bind mounts gebruiken naar een enkele NFS mount op de Docker host
4. Containers extra rechten geven zodat ze zelf NFS kunnen mounten (slecht idee)

Optie 2 lijkt me eigenlijk de beste. Maar door mijn onervarenheid met de materie (eigenlijk NFS), vraag ik om advies

Niet dat ik straks op mijn werk 30 containers heb draaien met NFS mounts naar dezelfde netwerk storage en er onverwachte dingen gaan gebeuren.

Wat zijn jullie ervaringen (en uitdagingen geweest) en wat zijn de best practices?

Docker documentatie is daar wat vaag in (of ik lees erover heen). Ze leggen vaak uit hoe iets kan, maar niet per se of dat ook verstandig is.

Alvast bedankt.

[CAPSLOCK2000]

Ik denk ook dat optie 2 de beste is.
Ik ben met ongeveer dezelfde uitdaging bezig maar dan met Ceph in plaats van NFS.

Daarbij kwam ik ongeveer tot dezelfde conclusies als jij, zoals dat ik storage buiten de container om wil regelen en dus geen NFS in docker containers wil mounten (optie 4 dus niet).

Het verschil tussen optie 1 en optie 2 is minimaal, maar optie 2 geeft iets meer flexibiliteit naar de toekomst toe.

Ik zou me geen zorgen maken om 30 NFS-mounts, dat is nog een overzichtelijk aantal.
(Hou er wel rekening mee dat NFS niet veilig is en op netwerkniveau eenvoudig gesniffed kan worden. Als beveiliging belangrijk is moet je even nadenken wie er allemaal bij het netwerk kan).

Helaas heb ik problemen met de ceph-driver voor docker en ben dus uitgekomen bij optie 3, dat is in ieder geval een hele makkelijke oplossing.

[Lethalis]

CAPSLOCK2000 schreef op woensdag 30 januari 2019 @ 16:18:
Ik denk ook dat optie 2 de beste is.
Ik ben met ongeveer dezelfde uitdaging bezig maar dan met Ceph in plaats van NFS.

Daarbij kwam ik ongeveer tot dezelfde conclusies als jij, zoals dat ik storage buiten de container om wil regelen en dus geen NFS in docker containers wil mounten (optie 4 dus niet).

(Hou er wel rekening mee dat NFS niet veilig is en op netwerkniveau eenvoudig gesniffed kan worden. Als beveiliging belangrijk is moet je even nadenken wie er allemaal bij het netwerk kan).

Helaas heb ik problemen met de ceph-driver voor docker en ben dus uitgekomen bij optie 3, dat is in ieder geval een hele makkelijke oplossing.

Ja, het probleem is denk ik ook minder groot dan ik in eerste instantie dacht.

Om het voor mij overzichtelijk te maken heb ik ten eerste een scheiding aangebracht in het type container voor mezelf:

1. Server containers
Een server container heeft persistent data nodig en zal eventueel een NFS mount hebben voor backup en restore. Te denken valt hierbij aan database servers voor de databases, reverse proxies voor hun configuratie, gitea server voor de database en git repositories enzovoorts.

2. Application containers
Een application container heeft meestal geen persistent data nodig, omdat hij meestal via web services praat met iets anders, of gebruik maakt van een database server. Hier heb ik niks met NFS te maken.

Qua backups hebben we ook met 2 type backups te maken:

1. File level backups
Backups die op file niveau werken in situaties waar ik niet bang hoef te zijn voor data corruptie. Dit zijn backups met rsync en eventueel tar van gegevens die niet vaak wijzigen. Van een nginx configuratie kan ik prima een file level backup maken bijvoorbeeld.

2. Application level backups
Backups die op applicatie niveau werken in situaties waar gegevens veel veranderen. Te denken valt hierbij aan database backups (SQL Server's BACKUP DATABASE, of pg_dump voor Postgres).

Door dit zo te categoriseren, valt op dat eigenlijk een hoop dingen eenvoudig kunnen met simpele file level backups en dat ik de NFS shares eigenlijk maar in beperkte situaties zal gebruiken (voor database containers).

De rest zal normaliter bind mounts gebruiken, waarvan ik vanaf de host een file level backup kan maken (omdat de gegevens niet vaak wijzigen).

Kijk ik dan naar het volledige scenario, dan is het belangrijkste wat ik nog niet goed in beeld heb, het maken van backups van container images. Dit zal vooral bij application containers spelen, maar in beperkte mate ook bij server containers.

Daarmee bedoel ik dat als ik meerdere versies van een container in productie heb, dat ik deze ook altijd weer op een andere host moet kunnen restoren. Je moet dus een bepaalde garantie hebben dat dit ook mogelijk is en je over alle versies kunt beschikken.

Ik zal dus misschien nog een script moeten maken / vinden dat alle container images kopieert naar een backup locatie.

Uiteindelijke conclusie: ik zal helemaal niet zoveel NFS mounts nodig hebben

PS
Dat NFS niet veilig is, weet ik (je hebt standaard alleen op ip gebaseerde access controle en geen encryptie). Eventueel wil ik hiervoor nog SSHFS gebruiken (met de vieux docker volume plugin). Wel betekent dit waarschijnlijk een lagere performance. Dit zal ik in de praktijk moeten testen.

[ Voor 3% gewijzigd door Lethalis op 02-02-2019 10:22 ]

[ppl]

Op werk gebruiken we helaas ook NFS. Dat klinkt op papier heel mooi maar de praktijk is dat we daar aardig wat problemen mee hebben die een hele grote impact op de applicatie zelf hebben. Wanneer bijv. de docker daemon later start dan NFS beschikbaar is dan is er geen NFS share beschikbaar in de containers. De enige oplossing is dan een herstart van de docker daemon met alle gevolgen van dien. Dit is iets wat je ook niet in de gaten hebt wanneer je daar niet actief op monitort (al is het maar een mailtje die zegt dat je backup is gefaald).

Wat we hebben gezien is dat anderen gebruik maken van cloud-opslagdiensten of iets anders wat gewoon via https werkt. Dat werkt betrouwbaarder en ook veiliger. Er zijn ook andere manieren om data van a naar b te krijgen. Dat betekent dat er dus ook naar de werking van de applicatie zelf gekeken moet worden (lees: moet je wel iets op een filesystem gaan opslaan?). Voor PostgreSQL kun je bijv. gebruikmaken van iets als Barman waarmee je streaming backups hebt die op eenzelfde manier werken als een slave.

Overigens lijkt het mij zeer onnodig en onwenselijk om een script te maken om je container images te kopiëren naar een backuplocatie. Je docker images haal je uit een registry. Dan heeft het meer zin om je registry te backuppen. Je kunt met dingen als Saltstack, Ansible, etc. wel iets maken wat dan een deploy van zo'n container doet (incl. alle opties die nodig zijn om het ding te draaien). Hierbij kun je aparte scripts maken voor productie en niet-productie. Bij productie kun je bijv. specifieke versies gebruiken terwijl je bij niet-productie gewoon "latest & greatest" kunt toepassen.

[Lethalis]

@ppl Wat vind jij eigenlijk van het draaien van database services in Docker voor productie?

https://vsupalov.com/database-in-docker/

Ik lees namelijk diverse artikelen waarin ze het afraden om zoiets belangrijks als een database server in een container te draaien en ik weet niet zo goed wat ik daarvan moet denken. Het is natuurlijk ook een optie om SQL Server en Postgres in dedicated VM's te installeren en er geen Docker voor te gebruiken. Wat is het verstandigste?

Het gebruiken van bestaande cloud diensten is helaas iets waar mijn werkgever niet erg positief tegenover staat. Kosten moeten voorspelbaar zijn, dus alles dat "pay as you go" is, wordt meteen afgekeurd. Hij snapt wel dat het ook in ons voordeel kan zijn, maar wil graag alles in eigen beheer houden en niet voor verrassingen komen te staan (torenhoge rekeningen omdat wij ergens een inschattingsfoutje hebben gemaakt).

Wat NFS betreft, wat vind je van een bind mount voor de backuplocatie naar de host, maar dat deze locatie simpelweg door de host wordt gedeeld?

Dus stel SQL Server of Postgres maakt in de container een backup naar /backups en dit eindigt op de host op /srv/backups en deze wordt weer met Samba gedeeld door de host?

Dan kunnen we vrij eenvoudig backups van en naar die share kopiëren en kan SQL Server erbij. Dan heb je dus geen NFS meer nodig. Enige nadeel is dat je genoeg storage op de server moet hebben, maar dat is vaak geen probleem.

Wat betreft de container images, je hebt helemaal gelijk! Ik zal binnenkort eens een test registry draaien

PS
https://blog.newrelic.com...containerizing-databases/

Mocht ik toch per se een database server willen draaien in een container, dan moet ik iig volumes gebruiken ipv bind mounts. Rookie mistake

[ Voor 11% gewijzigd door Lethalis op 03-02-2019 11:45 ]

[ppl]

Lethalis schreef op zondag 3 februari 2019 @ 10:04:
@ppl Wat vind jij eigenlijk van het draaien van database services in Docker voor productie?

https://vsupalov.com/database-in-docker/

Ik lees namelijk diverse artikelen waarin ze het afraden om zoiets belangrijks als een database server in een container te draaien en ik weet niet zo goed wat ik daarvan moet denken. Het is natuurlijk ook een optie om SQL Server en Postgres in dedicated VM's te installeren en er geen Docker voor te gebruiken. Wat is het verstandigste?

Het ligt eraan wat je met databases wilt doen en ook welke database software je gebruikt. Docker images wil je het liefst zo klein mogelijk houden ivm het pushen/pullen e.d. Als je kijkt naar de Oracle database dan zie je dat zo'n image al snel 6~8GB groot is. De images zijn ook bedoeld voor maar 1 database, niet meerdere. Oracle adviseert bij gebruik van meerdere databases dan ook om een losse installatie te doen (baremetal of in een vm). Iets anders om in dit geval ook rekening mee te houden is de I/O. Databases en virtualisatie zijn omwille van I/O lang niet altijd een goede combinatie.

Een ander punt is het principe van containers. Die dingen moeten immutable zijn: als er iets mis is moet je ze af kunnen schieten en weer opnieuw kunnen uitrollen. Bij gebruik van dingen als docker swarm of kubernetes is dat extra belangrijk. Je definieert daar namelijk hoeveel instances je van zo'n container wil hebben en dat wordt dan voor je geregeld. Gooi je er eentje weg, dan wordt er dus automatisch weer een nieuwe voor aangemaakt. Je had immers gespecificeerd dat je er x aantal wilde hebben. Dat soort zaken zijn lastig bij databases.

Overigens kun je prima tijdens het ontwikkelen gebruikmaken van databases in een container, je hebt toch amper data. Sterker nog, dat heeft min of meer de voorkeur omdat je daarmee een omgeving kunt bouwen die een ander ook kan gebruiken. Dat laatste is een van de gedachten achter docker.
Voor productie zou het prima kunnen als het een kleine database is (je kunt je afvragen of je het dan niet bij de betreffende component in de container kunt stoppen), voor de rest lijkt het me geen handige of verstandige optie. Sommige dingen moet je niet in een vm of container stoppen.

Het gebruiken van bestaande cloud diensten is helaas iets waar mijn werkgever niet erg positief tegenover staat.

Het punt van die cloud diensten was niet om die te gebruiken maar om te doen zoals zij ook doen en vooral naar iets anders dan NFS moet kijken. Veel cloud diensten gebruiken namelijk geen NFS om data uit te wisselen, die doen dat op een andere wijze.

Kosten moeten voorspelbaar zijn, dus alles dat "pay as you go" is, wordt meteen afgekeurd. Hij snapt wel dat het ook in ons voordeel kan zijn, maar wil graag alles in eigen beheer houden en niet voor verrassingen komen te staan (torenhoge rekeningen omdat wij ergens een inschattingsfoutje hebben gemaakt).

Voorspelbaarheid van kosten is een heel leuk punt. Het argument wat naar voren wordt gebracht laat heel duidelijk zien dat die persoon eigenlijk niet weet hoe het werkt. Die torenhoge rekeningen door een inschattingsfout heb je altijd. Het verschil is alleen dat wanneer je alles in-house doet je de gevolgen van die inschattingsfout altijd zal blijven dragen, bij pay-as-you-go niet. Bij die dingen herstel je de fout en vanaf dat moment betaal je minder (heeft te maken met het kunnen op- en afschalen; ideaal wanneer je klanten hebt die nog wel eens een actie houden waarbij er tijdelijk ineens meer traffic is). Bovendien zorgen pay-as-you-go diensten voor een heel goed overzicht waar je precies voor betaald en hoeveel. Wanneer je meerdere klanten bedient heb je dan ook een heel wat beter overzicht waar de financiën naartoe gaan wat je de mogelijkheid geeft om daar op te sturen (ook qua development). Veel van die diensten hebben ook de mogelijkheden om kosten in te perken en als je de boel standaardiseert weet je ook hoeveel het toevoegen van een nieuwe omgeving je gaat kosten. Bovendien heeft men vaak prijsopgaven beschikbaar voor de instances die ze aanbieden en valt er dus vooraf een hele goede inschatting van de kosten te maken.

Wij hebben klanten in verschillende groottes en moeten vooraf (soms samen met de klant) een inschatting maken wat ze precies nodig hebben. Dat gaat soms goed, soms fout. Wat vaak gebeurd is dat we een overschatting maken van wat er daadwerkelijk nodig is. Gevolg: hoge kosten. Dit lossen we eenvoudig op door terug te schalen. Hadden we alles in-house gehost dan was dat een stukje moeilijker geweest omdat we dan met hardware zitten dat niet gebruikt wordt. Voor ons niet heel erg omdat het weer ingezet kan worden voor een nieuwe klant maar tot die tijd betaal je wel te veel.
Het mooie van het overzicht is dat we de kosten niet alleen per klant maar ook per onderdeel kunnen zien. Zodoende weten we ook beter waar we aanpassingen kunnen maken die in ons voordeel zijn.

Met andere woorden, dit is iets waar je goed naar moet kijken en waarbij je een aantal zaken naast elkaar moet leggen. Het kan namelijk zomaar zijn dat juist de pay-as-you-go diensten een veel voorspelbaarder en beheersbaarder zijn op gebied van kosten dan wanneer je alles zelf gaat doen.

Wat NFS betreft, wat vind je van een bind mount voor de backuplocatie naar de host, maar dat deze locatie simpelweg door de host wordt gedeeld?

Dat is hoe wij het doen en waar we dus grote problemen mee hebben. Je bent en blijft afhankelijk van het online zijn van die NFS share. Docker zelf raadt het gebruik van bind mounts af ten faveure van volumes omdat deze laatste door docker zelf worden gemanaged (er is dus geen afhankelijkheid van het OS e.d.). Zeker wanneer je dingen met docker swarm of kubernetes gaat draaien worden dat soort zaken belangrijk.

Dus stel SQL Server of Postgres maakt in de container een backup naar /backups en dit eindigt op de host op /srv/backups en deze wordt weer met Samba gedeeld door de host?

Dezelfde map voor NFS en Samba gebruiken is ook niet iets wat men aanraadt, die twee konden elkaar nog wel eens in de weg gaan zitten. Anderzijds, is het ook nodig om het via Samba te doen? Je hebt al een NFS share...

Wat betreft de container images, je hebt helemaal gelijk! Ik zal binnenkort eens een test registry draaien

Docker biedt een vrij simpele maar er zijn ook diverse anderen. VMware biedt bijv. Harbor aan. Heb je ook meteen security scanning van je images (iets wat ook belangrijk is).

https://blog.newrelic.com...containerizing-databases/

Mocht ik toch per se een database server willen draaien in een container, dan moet ik iig volumes gebruiken ipv bind mounts. Rookie mistake

Zoals eerder gezegd geldt dat eigenlijk altijd. Volumes worden namelijk volledig gemanaged door docker terwijl een bind mount weer afhankelijk is van het OS e.d.

[Lethalis]

ppl schreef op zondag 3 februari 2019 @ 17:44:
[...]
Iets anders om in dit geval ook rekening mee te houden is de I/O. Databases en virtualisatie zijn omwille van I/O lang niet altijd een goede combinatie.

Virtualisatie biedt echter wel erg veel voordelen qua beheerbaarheid.

Ik voel me toch wat geruster als ik een VM herstart op afstand dan een bare metal machine

Zo woon en werk ik in de regio Rotterdam, maar staan onze eigen servers in een colocatie in de regio Amsterdam. Moet er niet aan denken dat ik daarheen moet rijden om op een knopje te drukken.

Ook kan ik momenteel erg eenvoudig complete machines backuppen. We gebruiken Windows machines die op ESXi draaien en met Veeam Backup en Replication worden deze in hun geheel met configuratie en alles gebackupt. De backup software is daarbij application aware, wat betekent dat middels VSS writers SQL Server een seintje krijgt dat hij de pending I/O operation moet syncen.

Allemaal erg leuk, maar ook kostbaar en op een gegeven moment aan vervanging toe.

Op het moment dat je met containers een voorspelbare setup hebt van een SQL Server instantie, en met SQL Server zelf backups maakt, kun je het vrij eenvoudig weer online krijgen.

Een ander punt is het principe van containers. Die dingen moeten immutable zijn: als er iets mis is moet je ze af kunnen schieten en weer opnieuw kunnen uitrollen. Bij gebruik van dingen als docker swarm of kubernetes is dat extra belangrijk. Je definieert daar namelijk hoeveel instances je van zo'n container wil hebben en dat wordt dan voor je geregeld. Gooi je er eentje weg, dan wordt er dus automatisch weer een nieuwe voor aangemaakt. Je had immers gespecificeerd dat je er x aantal wilde hebben. Dat soort zaken zijn lastig bij databases.

Ja dat klopt. Ik lees inderdaad overal dat het daar niet voor werkt. Een database server moet in principe gewoon 1 instantie van zijn, met daarbij een voorspelbare I/O (simpelweg ext4 bestandssysteem gebruiken bijvoorbeeld en dus geen COW, of vage volume plugin die er nog tussen zit).

Overigens kun je prima tijdens het ontwikkelen gebruikmaken van databases in een container, je hebt toch amper data. Sterker nog, dat heeft min of meer de voorkeur omdat je daarmee een omgeving kunt bouwen die een ander ook kan gebruiken.

Daarvoor is het idd erg handig

Voor productie zou het prima kunnen als het een kleine database is (je kunt je afvragen of je het dan niet bij de betreffende component in de container kunt stoppen), voor de rest lijkt het me geen handige of verstandige optie. Sommige dingen moet je niet in een vm of container stoppen.

Tsja, het belangrijkste wat je probeert te bereiken is die database service weer snel online te krijgen.

Even terug naar de ouderwetste situatie van SQL Server op een kale Windows installeren, daar ben je gewoon rustig een uur mee bezig. Op Ubuntu / Debian Linux kun je een PPA toevoegen en sudo apt install doen, maar ook dan wil je garanties over de versie die je krijgt, moeten er nog users aangemaakt worden, enzovoorts.

Tot nu toe gebruik ik daar dus virtuele machines voor.

In principe is mijn keuze dan ook beperkt tot:
- SQL Server / Postgres in een container gebruiken
- Of SQL Server / Postgres in een virtuele machine gebruiken

Het punt van die cloud diensten was niet om die te gebruiken maar om te doen zoals zij ook doen en vooral naar iets anders dan NFS moet kijken. Veel cloud diensten gebruiken namelijk geen NFS om data uit te wisselen, die doen dat op een andere wijze.

Alleen is dat vaak closed source en commercieel.

Ik zou best graag mijn eigen Amazon S3 buckets hosten, maar dat gaat niet

Voorspelbaarheid van kosten is een heel leuk punt. Het argument wat naar voren wordt gebracht laat heel duidelijk zien dat die persoon eigenlijk niet weet hoe het werkt. Die torenhoge rekeningen door een inschattingsfout heb je altijd. Het verschil is alleen dat wanneer je alles in-house doet je de gevolgen van die inschattingsfout altijd zal blijven dragen, bij pay-as-you-go niet. Bij die dingen herstel je de fout en vanaf dat moment betaal je minder.

Ja, dat begrijp ik allemaal, maar het verkopen aan / overtuigen van iemand anders ben ik niet zo goed in.

Ik heb zelf een tijd terug een testaccount bij AWS aangemaakt en er tijdje mee gespeeld. Ook geprobeerd om daar limieten in te stellen voor de billing, maar je kunt alleen alerts instellen. En dat vond ik persoonlijk een beetje eng.

Daar kun je ook leuke horrorverhalen over vinden op het internet. Al is het in bijna alle gevallen zo dat iemand zijn keys rond heeft laten slingeren ergens op github, waar dan een ander mee aan de haal is gegaan en 1000 instanties van het e.e.a. aan heeft gezet.

Tegen de tijd dat jij die billing alert krijgt, ben je al duizenden euro's armer.

Veel mooier - voor de klant, niet voor Amazon - zou zijn als het rate limited zou zijn. Zo van "dit is de maximale capaciteit die is ingesteld, meer krijg je ook niet en kost het ook niet".

Op het moment dat je zulk soort harde limieten kunt instellen, is het veel makkelijker te verkopen.

Een beetje net zoals Google AdSense, daar hebben we ook een maximaal budget van X euro per maand en klaar.

Ik geloof dat Azure wel bezig is zoiets in te bouwen, maar dat het nog niet helemaal functioneel is. Het zou een unique selling point kunnen zijn.

*voordelen van de cloud voor klanten*

Een deel van het probleem is dat wij veel klanten hebben met een brakke internetverbinding. Echt van die VDSL lijntjes van 8mbit, terwijl ze wel met 30 man ingelogd willen zijn op hun server. Om die reden leveren we nog heel vaak simpelweg on premises hardware aan klanten.

Je ziet vaak dat ze panden kiezen op basis van hun logistieke voordelen (makkelijk aan te rijden buiten de stad, goedkope grond voor grote magazijnen, etc). Snel internet is er vaak niet te krijgen.

Dat is hoe wij het doen en waar we dus grote problemen mee hebben. Je bent en blijft afhankelijk van het online zijn van die NFS share. Docker zelf raadt het gebruik van bind mounts af ten faveure van volumes omdat deze laatste door docker zelf worden gemanaged (er is dus geen afhankelijkheid van het OS e.d.). Zeker wanneer je dingen met docker swarm of kubernetes gaat draaien worden dat soort zaken belangrijk.

Als je naar mijn TS kijkt, zie je dat ik al een Docker volume gebruik voor NFS.

Jij schreef dat een complete herstart van de Docker daemon nodig kan zijn als de NFS share er niet is, maar geldt dat ook voor Docker managed volumes?

PS
Momenteel is het zo:

code:

sudo docker volume create sql2017_data

sudo docker volume create \
    --driver local \
    --opt type=nfs \
    --opt o=addr=192.168.168.52,rw \
    --opt device=:/volume1/sqltest \
    sql2017_backup

sudo docker run \
    -e 'ACCEPT_EULA=Y' \
    -e 'SA_PASSWORD=*********' \
    -e 'MSSQL_PID=Express' \
    --mount type=volume,source=sql2017_data,destination=/var/opt/mssql \
    --mount type=volume,source=sql2017_backup,destination=/backups \
    -p 1433:1433 \
    --hostname sql2017 \
    --name sql2017 \
    -d mcr.microsoft.com/mssql/server:2017-latest

Ik gebruik nu overal named Docker volumes voor.

[ Voor 4% gewijzigd door Lethalis op 04-02-2019 12:24 ]

[ppl]

Lethalis schreef op maandag 4 februari 2019 @ 12:21:
[...]

Virtualisatie biedt echter wel erg veel voordelen qua beheerbaarheid.

Ik voel me toch wat geruster als ik een VM herstart op afstand dan een bare metal machine

Dat klopt maar in bepaalde toepassingen heb je nou eenmaal geen andere keuze. Wij hebben ook geen enkele bare metal server, is ook 1 virtueel park. Database servers horen daar ook bij en dat is in ons geval ook geen enkel probleem.

Zo woon en werk ik in de regio Rotterdam, maar staan onze eigen servers in een colocatie in de regio Amsterdam. Moet er niet aan denken dat ik daarheen moet rijden om op een knopje te drukken.

Daarvoor heb je out of band management of een servicecontract met het DC (die dus iemand naar je kast kan sturen om dat knopje in te drukken)

Even terug naar de ouderwetste situatie van SQL Server op een kale Windows installeren, daar ben je gewoon rustig een uur mee bezig. Op Ubuntu / Debian Linux kun je een PPA toevoegen en sudo apt install doen, maar ook dan wil je garanties over de versie die je krijgt, moeten er nog users aangemaakt worden, enzovoorts.

Tot nu toe gebruik ik daar dus virtuele machines voor.

In principe is mijn keuze dan ook beperkt tot:
- SQL Server / Postgres in een container gebruiken
- Of SQL Server / Postgres in een virtuele machine gebruiken

Het is belangrijk om je hier te realiseren dat bepaalde zaken nou eenmaal een bepaalde hoeveelheid tijd kosten. Bij een complete restore ben je, ook met een container, gewoon een tijd zoet. Afhankelijk van de grootte van de database e.d. kan dat gerust een halve dag zijn. Daar gaat een container je niet heel erg bij helpen. Bij een vm heb je als voordeel dat je dan dingen als een snapshot of een complete backup van de betreffende vm kunt terugzetten waardoor je dat hele installatieproces niet hebt. Een handmatige installatie doe je wanneer ook zo'n restore niet werkt.

Btw, zo'n handmatige installatie zoals je die hier beschrijft kun je prima automatiseren met tools als Ansible, Puppet, etc. Scheelt wat tijd en voorkomt ook fouten omdat het feitelijk een checklist is die afgewerkt wordt (en dan eentje die je, als het goed is, voor ingebruikname hebt getest en dus weet dat het werkt).

Alleen is dat vaak closed source en commercieel.

Kleine disclaimer: wij bouwen applicaties dus in ons geval is het een aanpassing in onze eigen applicatie waarbij we desnoods een extra component toevoegen om zoiets te realiseren.

Daar kun je ook leuke horrorverhalen over vinden op het internet. Al is het in bijna alle gevallen zo dat iemand zijn keys rond heeft laten slingeren ergens op github, waar dan een ander mee aan de haal is gegaan en 1000 instanties van het e.e.a. aan heeft gezet.

Ik snap wat je bedoelt maar dit is daar geen goed voorbeeld voor, dit is namelijk gewoon een security breach. Keys, wachtwoorden e.d. behoor je eigenlijk helemaal niet in een repository op te nemen. Als je echt geen andere keus hebt dan doe je zoiets versleutelt. Als het om publieke repositories gaat doe je het gewoon niet of gebruik je dummy gegevens. Die Amazon facturatie is dan wel het minste van je zorgen, dit is namelijk ook iets wat je hier wettelijk verplicht bent om te melden. Dat gaat je dus heel wat meer kosten.

Veel mooier - voor de klant, niet voor Amazon - zou zijn als het rate limited zou zijn. Zo van "dit is de maximale capaciteit die is ingesteld, meer krijg je ook niet en kost het ook niet".

Daar valt natuurlijk zelf ook behoorlijk wat aan te doen. Je eigen applicatie valt ook in te stellen met zaken als rate limiting en er valt ook gewoon actief te monitoren op werking van de systemen en diens kosten (iets wat je sowieso moet doen).
Je moet hier niet vergeten dat dit soort systemen en ook containerisatie heel erg gericht is op het wereldje dat gebruik maakt van dingen als microservices en devops. Dat werkt op een andere wijze en dat is ook 1 van de redenen waarom ik zeg dat je dit soort zaken echt moet gaan uitzoeken. Het is namelijk lang niet voor iedereen en alles de oplossing.

Een deel van het probleem is dat wij veel klanten hebben met een brakke internetverbinding. Echt van die VDSL lijntjes van 8mbit, terwijl ze wel met 30 man ingelogd willen zijn op hun server. Om die reden leveren we nog heel vaak simpelweg on premises hardware aan klanten.

Dat is bij onze klanten niet van toepassing. Zij gebruiken onze software om hun services aan hun klanten aan te bieden. In dit geval gaat het om het aantal bezoeker die de software en infrastructuur aan kan. Wat je met dat autoscaling kunt doen is hetzelfde als wat een hedendaagse cpu met energiegebruik doet: zo weinig mogelijk gebruiken en wanneer het moet, opschalen in performance (met als gevolg een hoger energiegebruik) en direct weer afschalen als het kan. Het is een manier om goed te kunnen schipperen tussen kosten en performance (een trage website kost je namelijk klanten).

Jij schreef dat een complete herstart van de Docker daemon nodig kan zijn als de NFS share er niet is, maar geldt dat ook voor Docker managed volumes?

Dat weet ik niet zeker, ik heb nog niet gespeeld met die opzet. Het enige verschil is dat je de NFS niet door het OS maar nu door docker laat afhandelen en ik weet niet hoe docker omgaat met een NFS server/share/link die pleitos is. Als ik de laatste comment in het volgende draadje moet geloven is dat NFS issue met zo'n volume opgelost: NFS volume: same service but inconsistent storage between replicas in different nodes. Daar valt vast wel wat mee te testen.

[CAPSLOCK2000]

Of je bind-mounts of volumes gebruikt staat volgens mij los van de vraag of je NFS gebruikt of een ander storage systeem. In beide gevallen zal je storage online moeten zijn voor je containers kan starten. Op een modern Linux-systeem voeg je daarvoor een dependency toe aan de systemd unit-file.
Of Docker daar goed mee omgaat of niet vind ik eigenlijk niet zo'n issue, die situatie moet gewoon niet voorkomen, je hebt juist een init-systeem om te zorgen dat alle afhankelijkheden in de juiste volgorde gestart worden.
Overigens probeer ik niet te zeggen dat bind-mounts beter zijn dan volume, ook ik geef de voorkeur aan volumes.

[ppl]

In dit geval niet. De docker daemon heeft geen controle over die bind mounts, wel over die volume mounts. Dat is waar die laatste comment in de laatste link op inspringt. De docker daemon heeft met een volume mount controle over die NFS connectie waardoor de garantie dat het goed gaat hoger zou moeten zijn (sterker nog, die gast geeft aan dat het probleem er niet meer zou moeten zijn). De vraag in deze is in hoeverre dat dus echt zo is. Als er geen NFS is, start de container dan wel? Zo ja, is de NFS share dan wel te bereiken in de container zodra deze weer beschikbaar komt? Wat als de boel al draait en NFS ineens wegvalt?

Het gaat hier dus niet zozeer om bind vs volume mount maar meer of NFS en docker wel zo'n goede combinatie is. Andere zaken, zoals het eerder genoemde security, spelen dus ook een rol.

Bovendien is het soms ook gewoon een kwestie van testomgeving opzetten en er zelf meespelen. Er is geen betere manier om te bepalen of dat NFS lekker gaat werken dan het domweg eens te proberen. Geef de NFS server eens een shutdown, rommel met de opstart volgorde van de daemons, trek je netwerkverbinding eruit, etc. en kijk wat er gebeurd