Apache schreef op woensdag 5 september 2018 @ 14:02:
[...]
Meer lightweight, je kan verschillende versies binnentrekken en parallel opspinnen binnen een beperktere footprint. Meestal worden ze ook gewoon aangeboden voor kant en klaar gebruik op docker hub, er zijn wel appliances die aangeboden worden, maar toch niet in een aanbod dat zo ruim is als containers?
Er werd vooral nagedacht over contracten naar usage toe, zoals env variables om bvb bij een database meteen een username/password/schema te configureren bij het opspinnen enz.
Zeker als je via een compose file of een kubernetes/helm deployment verschillende containers gaat composeren om zo een geintegreerde oplossing uit te werken. Ik denk dan aan bvb een wordpress en een mysqldb, eventueel nog met een nginx ervoor. Dat doe je niet met 3 vm appliances.
Inderdaad, dat doe je met een tool als ansible ;-)
Ik ben een voorstander van containers, maar het is op dit moment zo'n hype geworden, dat alles nu in containers wordt gegoten, waarbij het basis princiepe van een container overboord wordt gegooid. De genoemde domaincontroller is hiervan een goed voorbeeld. Een container hoort 1 proces te draaien, wanneer er meer processen nodig zijn, spawn je meer containers.
Wat ik veel zie is dat containers worden gebruikt als verijdelde VM's, ik heb zelfs voorbeelden gezien waarbij er configuratiemanagement IN een container wordt gebruikt. Dit kan natuurlijk prima werken, maar je mist dan zoveel van de potentie van containers.
Wanneer we het bij de genoemde applicaties van TS houden, (Gitlab, Owncloud en Apache), dan worden deze allemaal als VM appliance aangeboden:
https://bitnami.com/stack/gitlab/virtual-machine
https://github.com/ownCloud/vm
https://www.turnkeylinux.org/lamp
Hierbij heb je 0 ondersteunende VM's nodig om de infra draaiende te houden.
Wanneer we het op de
juiste manier in containers gaan gieten, dan kom ik met een beetje turven uit op 10 - 15 containers. (losse databases, statefull disks, applicaties en webservers containers). Daarnaast is er potentieel nog de nodige containers om de infra zelf in de lucht te houden. (wat doe je bijvoorbeeld met logging?)
Wanneer je dit voor elkaar hebt, heb je natuurlijk de bekende voordelen; je kan 1 container vervangen door bijvoorbeeld een nieuwere versie van apache, en de rest ongemoeid laten. Je kan relatief eenvoudig een (semi!)-redundant omgeving opbouwen. In ruil daarvoor zal je in plaats van 3 vm's nu 20 containers moeten "beheren", welke allemaal resources nodig hebben.
Netto bespaar je nu dus de 'overhead' van twee VM's, waar je buiten het nodige extra netwerkverkeer (wellicht binnen 1 host), vooral complexiteit voor terug krijgt.
Containers zijn ideaal in grotere omgevingen, waarbij je altijd redundant gaat (moet?) uitrollen, of bij een (grotere) OTAP omgeving, waar je dezelfde container door alle fasen van de otap straat kan laten lopen.
Het afhankelijk van de load per proces een container kunnen spawnen is ook een mooi principe. (al kan XEN / XCP dat ook op VM niveau ;-) ).
Dit alles betekend natuurlijk niet dat TS niet met containers aan de gang moet gaan, het is een fantastische techniek om mee te spelen en om kennis over op te doen.
Containers worden mijn inziens echter wel te veel als "het gouden ei" gezien.
