Skip to content

Instantly share code, notes, and snippets.

@duijf
Last active January 3, 2016 18:49
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save duijf/8504682 to your computer and use it in GitHub Desktop.
Save duijf/8504682 to your computer and use it in GitHub Desktop.
Dutch description of my working knowledge of docker

Docker concepts

Linux file systems

Een Linux systeem heeft twee filesystems nodig om te functioneren:

  • Een boot file system (bootfs)
  • Een root file system (rootfs)

Het bootfs bevat de bootloader en kernel. Tijdens system boot wordt de kernel in het geheugen geladen en het bootfs wordt gedismount.

Het rootfs bevat de bekende directory structuur met mappen als /dev, /var, /etc en /home. Hierin staan de diverse binaries en libraries die worden gebruikt om userland-applicaties te draaien.

Linux boot and mounts

In een traditionele system boot van een Linux systeem wordt het rootfs als read-only gemount, de integriteit gewaarborgd en vervolgens als read-write gemount.

Er is nog een soort mount. Een union mount. Hier is sprake van wanneer het ene filesystem bovenop een ander wordt gemount, terwijl ze één lijken te zijn.

Docker concepten

Layers

Docker verschilt van een traditionele Linux omgeving in het mounten van het rootfs. In plaats van dit na de integriteitscheck als read-write te mounten, wordt er middels een union-mount een read-write laag bovenop het gewone filesystem gemount. Deze filesystems heten layers. Er kunnen verschillende layers bovenop elkaar worden gemount voordat de read-write layer gemount wordt.

Images

Read-only layers heten images. Ze worden geidentificeerd met een unieke 64-character hexademicale string, maar hebben ook vaak een naam, zoals ubuntu. Elk image kan naar een parent verwijzen, en het filesystem van een image verandert nooit. Images hebben geen state.

Bij het initialiseren van een container (de precieze definitie volgt nog, het verschilt van een image), is de bovenste read-write layer leeg, maar gaandeweg wordt deze gevuld wanneer processen uitgevoerd worden. Als één van deze processen een file uit een onderliggende layer aan wil passen, dan wordt eigenlijk maar wordt een nieuwe file op dezelfe locatie in het filesystem in de read-write layer aangemaakt. De file lijkt door de union-mount weg te zijn uit de onderliggende laag, maar deze is gewoon aanwezig, maar niet toegankelijk. Deze eigenschap van layers is transparant voor processen/applicaties.

Containers

Een container is net iets anders dan een image. Het is de collectie van layers van base tot aan de read-write layer plus metadata. Containers hebben net zoals images een hexadecimale string van 64 tekens die de container uniek identificeerd.

Containers en state

Containers kunnen processen draaien en deze wijzigingen die door processen worden uitgevoerd leiden tot state: de state van het filesystem (ookwel de state van read-write layer die bovenop een aantal images wordt bevestigd door middel van een union mount) en de state van operatie. De status van het filesystem wordt bewaard ongeacht de status van operatie.

De status van operatie kan één van twee opties zijn: running en exited.

Wanneer een container zich in de running state bevindt, bevat de notie van een container niet alleen de graaf van layers, maar ook een tree van processen die (in isolatie van de processen op de host) draaien. In de exited state hebben containers slechts de staat van het filesystem. Deze kan tot een image worden gemaakt door middel van docker commit. De state van het werkgeheugen van containerswordt niet tussen restarts bewaard.

Waarom Docker voor Sticky?

Zorgen dat je configuratie van een server/VPS gedocumenteerd en repeatable is, is geen makkelijke taak. Er zijn voldoende configuration managment tools beschikbaar, maar de meeste van deze opereren op het niveau van een server. Meerdere servers voor je database needs, meerdere voor email etc.

Het probleem waar Sticky mee zit, is dat het bestuur elk jaar wisselt, en dus is er de grote kans dat serverbeheer elk jaar bij iemand anders terecht komt. Het gevolg is niet mooi. De server die Sticky bij de universiteit Utrecht heeft staan, is een voorbeeld van een configuration mess. Niemand weet precies wat aangepast is ten opzichte van een stock install, settings zijn niet gedocumenteerd, en ik zou niet durven om dat apparaat te herstarten. Ik ga het niet eens hebben over het controleren van updates en zorgen dat er geen beveiligingslekken in de server zitten.

We bevinden ons nu in de positie dat we opnieuw kunnen beginnen. Er is een nieuwe VPS aangeschaft en we bevinden ons in een positie om alle serverconfiguratie te documenteren en zo in te stellen dat een servermigratie in de toekomst een weekend werk moet zijn. De keuze voor configuratiemanagement is een beetje onorthodox. We kiezen voor docker om de volgende redenen:

Eén VPS heeft meerdere doeleinden

Chef, Salt en Puppet gaan uit van 1 doel per server. Een server is een database server of een mailserver of iets dergelijks. Sticky heeft 1 VPS voor alle hosting needs. De website staat er op samen met de intro site, het adminsysteem komt er op te staan, evenals sites voor activiteiten zoals Indievelopment, de wintersportreis en de studiereis waar inschrijvingen digitaal worden afgehandeld.

Deze sites/applicaties worden in een varieteit van verschillende talen/frameworks geschreven en hebben allemaal hun eigen needs. Het ene wordt geschreven in Rails, en het andere is een mashup van eigen PHP en Wordpress. Het andere is weer een statische site die door jekyll wordt gegenereerd. Sommige praten met de centrale Sticky DB, en andere mogen hier juist helemaal niet in de buurt komen.

De dependencies voor dit alles managen en documenteren is een stuk eenvoudiger wanneer je kan doen alsof alles geisoleerd van elkaar werkt en op een standaard manier met elkaar communiceert. Docker is gemaakt voor precies deze oplossing: virtualisatie/containing op het applicatieniveau, niet het serverniveau.

Keep it Simple Stupid

Omdat Sticky andere needs heeft dan enterprises met hun serverclusters voor alleen databases zijn tools als Chef, Puppet en Salt overkill. Granted, ze hebben allemaal iets als chef-solo, waarbij configuratie voor een enkele server te regelen is, maar dit alles is te complex. De talen/manieren om relaties mee uit te drukken zijn nou eenmaal belachelijk complex.

Docker heeft dan meer conceptuele complexiteit (in ieder geval voor enkele servers), maar wanneer deze eenmaal overwonnen is is de manier van configureren niet veel lastiger dan het schrijven van een imperatief programma.

Meer gaat volgen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment