Normaal gesproken ziet een blog over containers er als volgt uit:
“Containerisatie kan een efficiënte manier zijn om DevOps te doen. Het is een praktische manier om met de DevOps-methodiek aan de slag te gaan binnen een organisatie. DevOps is binnen veel organisaties noodzakelijk vanwege de voordelen en de wendbaarheid om software sneller en beter vrij te geven en meer waarde te kunnen leveren. Een ander voordeel van containerisatie is dat het een praktische manier is om Cloud te adopteren. Niet zozeer vanuit een technologisch oogpunt maar omdat containerisatie het relatief eenvoudig maakt om Cloud en zaken als “As-a-Service” en “Elastic infrastructure” te omarmen. Verder is er nog het gerelateerde onderwerp Microservices…...”
En ga zo maar door. In deze blog echter een eerste kennismaking met containers en het is dan ook de bedoeling de basis uiteen te zetten.
Als applicatie-eigenaar heb je veel keuze waar je je applicatie kunt laten draaien; fysieke servers, virtuele servers of containers. Elk met zijn sterke en zwakke punten.
Trekken we een vergelijk tussen de applicatie en een huiseigenaar (een bewoner) dan worden de voor en nadelen snel duidelijk.
Een fysieke server is vergelijkbaar met een vrijstaand huis. Dit is “de veiligste” oplossing. Wordt er ingebroken in 1 huis dan blijft het andere huis veilig. Een apart huis en dus een apart systeem betekent echter veel onderhoud.
Bij virtuele servers denken we aan een 2-onder-1-kap woning. De hardware wordt gedeeld maar de toegang tot de applicatie is apart. Wanneer 1 applicatie, dan wel virtuele server een probleem heeft dan is dit niet van invloed op de andere. Beide woningen oftewel, beide virtuele servers, hebben echter wel individueel onderhoud nodig van onder andere besturingssysteem en applicatie. Daarnaast is het delen van resources slechts beperkt mogelijk.
Het 3e vergelijk is dat van de containers met de appartementen in een appartementengebouw. Voordelen zijn het delen van de services, de lage kosten wat betreft onderhoud en een goede scheiding van de applicaties (bewoners). Echter wanneer er problemen zijn met de kernel van het onderliggende besturingssysteem, in ons geval dus de centrale receptie van het appartementengebouw dan wel de gedeelde faciliteiten, dan hebben alle containers een probleem.
Om de voor- en nadelen kracht bij te zetten bekijken we ook het onderwerp isolatie; het scheiden van applicaties binnen 1 server. Wanneer je meerdere applicaties binnen hetzelfde systeem draait en 1 applicatie wordt geraakt door bijvoorbeeld een aanval is de kans groot dat ook de andere applicaties hier hinder van ondervinden. Het isoleren bijvoorbeeld door het gebruik van “SELinux” kan hierbij ondersteunen. Trekken we een vergelijk met de metafoor van het huis denk dan aan een Hostel waarbij je samen in 1 vertrek overnacht. Het gebruik van meerdere applicaties zonder een vorm van isolatie? Vergelijk dat gerust met het slapen in het park.
Containers, zoals beschreven door het appartementengebouw, zijn een oplossing die zowel de mogelijkheid biedt resources maximaal te gebruiken en waarbij je nog steeds de mogelijkheid hebt om meerdere applicaties veilig en snel naast elkaar te draaien. Door de kleine footprint van containers kennen ze een erg korte opstarttijd en de kosten van onderhoud zijn veel lager dan bij “de 2-onder-1-kap”.
In meer detail:
Zou je kiezen voor een woning van stro, een woning van hout of een woning van steen? Los van persoonlijke voorkeuren zou je kunnen zeggen dat de meest degelijke oplossing de keuze voor steen is. Dit kun je op zijn beurt weer vergelijken met de verschillende niveaus van support die de producten in de markt bieden. Ga je voor zelfbouw? Ga je voor community of kies je een product wat onderhouden en ondersteund wordt door een partner of leverancier?
Ok, leven in een stenen woning dus?
Wanneer we verder gaan met de metafoor van “het huis” en het appartementengebouw komen we op het onderdeel inrichting. Elke bewoner kiest zijn eigen inrichting en personaliseert zijn woning naar wens. Met containers doen we dit via zogenaamde Namespaces. Namespaces geven de container zijn eigen gepersonaliseerde omgeving. Elke container is een aparte “wereld”, ook al draaien ze naast elkaar op hetzelfde systeem.
Resource Groups en daarmee resource management voor containers richten we in via Cgroups. Een correcte configuratie van deze cgroups is belangrijk om vertragingen te voorkomen. De inrichting van de centrale faciliteiten van een appartementengebouw is belangrijk en deze dienen goed onderhouden te worden. Een extreem hete douche wanneer de buurman zijn toilet doortrekt is natuurlijk niet wenselijk. Ook hier willen we terugvallen op best practices uit geteste situaties.
Over het onderwerp security kan een blog op zichzelf geschreven worden; isolatie van containers, de juiste tools om beveiligingslekken en configuratiefouten naar boven te halen. Uiteraard een partner waar je op terug kunt vallen die je ondersteunt met de informatie over bekende fouten en lekken en de patches verzorgt. Zoals altijd is een inrichting volgens best practices belangrijk.
Het laatste onderdeel voor een complete inrichting zijn de Container images of templates. Je kunt (containers) images downloaden van een publieke repository, de kwaliteit van deze images is ongecontroleerd; malware? bugs? wat doet het? Een alternatief is natuurlijk het zelf bouwen van containers. Dit is echter tijdrovend en complex in initiële opzet maar ook onderhoud. Een veilig alternatief is een gecertificeerde repository. Een repository op locatie dan wel uit de cloud met gecertificeerde, gecontroleerde en veilige, up-to-date images.
Afgaande op bovenstaande punten kunnen we dus zeggen dat een containeroplossing een mooi compromis is. Wanneer we kiezen voor een containeroplossing die ondersteund wordt door een betrouwbare, klantgerichte organisatie zorgen we ervoor dat we beschikken over de juiste kwaliteit; snelheid, support, stabiliteit, beschikbaarheid.
Stefan van Oirschot, CTO Rhodix
