Het is ondertussen alweer een flink aantal jaren geleden dat de geluiden rondom Docker verschenen. Wat Docker precies is en wat de voordelen zijn lees je in dit blog.
Mijn eerste kennismaking met Docker was tijdens een Red Hat Summit in Boston. Ik ben nooit zo goed met jaartallen maar ik meende dat dit de Summit van 2013 was. Red Hat bood vanaf dat moment Docker aan in de RHEL releases en daarmee dus ook support voor Docker containers. De 1.0 versie was er nog niet van Docker, die kwam uit op 16 oktober 2014.
Op dat moment waren we voor een klant bezig met de implementatie van een nieuw backend systeem. Microservice architecturen waren ook in opkomst op dat moment. Verschillende leveranciers leverde delen van de omgeving op als kleine services en kozen voor hun eigen favoriete implementaties. Java, PHP en Kafka waren verschillende talen waarin de componenten werden opgeleverd.
Per service werd een Virtual Machine ingericht. Naast de hoeveelheid benodigde resources werd al snel duidelijk dat het beheren van al deze verschillende componenten een grote uitdaging zou gaan worden. Want wat moet je doen als een component herstart moet worden? En waar in de applicatie configuratie moet je zijn als er wijzigingen aangebracht moeten worden voor bijvoorbeeld JVM settings of PHP instellingen?
Bij het horen van het Docker concept zoals dat op de Red Hat Summit werd uitgelegd was het voor mij direct duidelijk dat ik hier de oplossing van bovenstaande vraagstukken op een presenteerblaadje kreeg aangeboden.
Docker is toch een soort van Virtual Machine?
Als een eerste uitleg aan iemand zonder noemenswaardige ICT kennis zou dit een geldige uitleg kunnen zijn. Echter Docker is veel meer dan dat. Of eigenlijk beter gezegd, veel minder dan dat.
Een computer of een server is eenvoudig uit te leggen. Er is de hardware, cpu, memory, hdd etc. Hier draait een besturingssysteem op en dat zorgt ervoor dat verschillende applicaties gebruik kunnen maken van deze hardware. Een nadeel hierbij is dat alle applicaties dezelfde ondersteunende software moeten gebruiken, denk aan dezelfde java en python versies.
Hier komt de Virtual Machine om de hoek kijken. Hierbij wordt de hardware als het ware in stukjes verdeeld en kan je op elk stukje een eigen besturingssysteem zetten en een eigen versie van java en wat er nog meer nodig is.
Wat blijkt echter, vaak is het besturingssysteem in alle Virtual Machines toch linux. Dus wat als we de middleman kunnen overslaan? En de resources die hiervoor nodig zijn kunnen gebruiken om meer applicaties te draaien?
Dan hebben we het over Docker. Of een andere container technologie, in basis werken ze allemaal hetzelfde. Een besturingssysteem zoals linux bestaat uit meerdere stukken en de kernel is het deel dat communicatie met de hardware mogelijk maakt. En laten nu de meeste linux varianten op dezelfde kernel draaien.
Wat doet Docker?
Wat Docker doet is het verpakken van je applicatie samen met nog een klein beetje randsoftware zoals java of python en wat hulpprogramma’s om met de kernel te communiceren in een pakketje. Dit pakketje noemen we een image. En wanneer dit image gestart wordt, noemen we het een container, en zal de kernel er voor zorgen dat de hardware in afgeschermde stukjes wordt verdeeld er aan wordt toebedeeld.
Waarom kiezen we binnen ilionx voor Docker?
Omdat het grote voordelen heeft omtrent testbaarheid. Want op de testmachine draait het hetzelfde als op de pc van de ontwikkelaar, als op de uiteindelijke productie machine.
Er zijn belangrijke afspraken rondom het gebruik van Docker: Immutable. Geen persistent storage, tenzij network storage. Kleine specifieke applicaties met duidelijk gedefinieerd doel. Deze afspraken zijn continu in beweging om het gebruik van Docker veiliger en stabieler te maken.
Gevolg van immutable images en data op externe locaties is dat applicaties als wegwerpartikelen gezien kunnen worden. Misdraagt het zich, dan stop je de container en gooi je deze weg. En start je een nieuwe. Dit is het Pets vs Cattle principe.
Docker
Containers starten erg snel op: seconden in plaats van minuten voor Virtual Machines. Het is daarom dus ook niet erg om ‘even’ een nieuwe container op te starten. Sterker nog, het is zelfs gebruikelijk om een container te maken die alleen één klein taakje uitvoert en vervolgens weer weg is.
Bij voorkeur is het horizontaal schaalbaar en draai je er meerdere instanties van. Dus als er één herstart wordt, dan merkt niemand daar iets van. Dit is goed voor de beschikbaarheid. En mocht er een piek-load zijn, dan start je er gewoon nog een paar bij.
Pas N-1 versie beheer toe. En upgraden van versies kan on-the-fly zonder dat de beschikbaarheid onderbroken wordt. Canary deployments zijn eenvoudig in te richten. En bij problemen rol je terug naar de laatste stabiele versie.
Houd je aan de afspraken!
Dit is allemaal mogelijk door wat werken met containers bied, maar zeker ook door de afspraken die we met zijn allen hebben gemaakt. Wanneer we ons niet aan deze afspraken houden, vervliegen de voordelen van Docker als sneeuw voor de zon.
Ga dus niet inloggen in een Docker container, configuratie bestanden of environment variabelen aanpassen en de processen herstarten. Sla geen belangrijke informatie op de lokale disk van de server waar de container op draait. Zorg ervoor dat je applicatie in de container draait onder een willekeurige user en met als groep root. Dit maakt je leven makkelijker als je later overgaat op Kubernetes of OpenShift.
