Team H&S raadt aan om een aantal punten in acht te nemen bij het draaien van websites of applicaties in CHP. Deze vallen onder te verdelen in technisch en procedureel:
CHP is gebouwd op Redhat Openshift, wat weer gebouwd is op Kubernetes, wat geinspireerd is op Docker, wat een containerplatform is.
Op dockerhub zijn vele vele containers te vinden voor allerhande runtimes (php, java, node.js, enz enz). Vanwege de vereiste van Openshift dat containers rootless draaien kunnen niet alle docker hub containers 1-op-1 draaien in Openshift, maar het geeft wel een idee van wat er allemaal beschikbaar is.
De volgende runtimes worden veel gebruikt:
Ondersteunend daaraan zijn onderstaande componenten:
Ook andere programmeertalen en databases kunnen gebruikt worden, maar zijn wel wat minder alomtegenwoordig.
Static assets zijn alle onderdelen van een website of applicatie die niet on-the-fly door de code gegenereerd worden. Denk hierbij aan plaatjes, css en javascript.
Wij adviseren om deze assets onder te brengen bij het image CDN (Scalia) en niet om ze in een “persistent volume” (PVC) in een pod op te slaan. De redenen hiervoor zijn:
Het “afsplitsbaar zijn” houdt in dat de assets vanaf een andere URL geserveerd moeten kunnen worden. Stel de site in CHP draait op www.xrtv.nl, dan
Het is technisch heel goed mogelijk om binnen Openshift een database pod te draaien. En voor test en acceptatie doeleinden is dat ook prima. Maar voor productieomgevingen raden weaan om dit soort stateful componenten (denk bv ook aan elasticsearch) als managed service binnen AWS af te nemen. De redenen hiervoor zijn:
Voor een schaalbare website is caching vaak heel belangrijk. Maar in CHP
is er niets dat uit zichzelf caching doet. Wij adviseren om altijd
RFC2616 http caching te
gebruiken (dwz: genereren van Cache-Control en Expires headers
in de applicatie, zodat de webserver kan weten wat en hoelang er
gecached kan worden).
Maar, ook als de applicatie de juiste headers genereert betekent dat nog
niet dat die data gecached wordt. Daar is een webserver voor nodig om
dat te doen. Hiervoor zijn 2 mogelijkheden:
Voor high-volume websites is Cloudfront een goede keuze. Voor de rest adviseren we om een nginx container te gebruiken.
Persistent volumes zijn bedoeld om state op te slaan die niet zomaar weg mag (vandaar “persistent”). Maar denk vantevoren goed na over wat voor state dat dan kan zijn. Idealiter is er niet zoveel van dat soort state namelijk:
Dus er zijn wel use cases voor persistent storage, maar veel andere use cases zijn beter gediend bij andere oplossingen. Als je applicatie toch persistent storage nodig heeft, denk dan na over de volgende zaken:
Concluderend:
Applicaties die draaien in openshift moeten er rekening mee houden dat elke pod die onderdeel maakt van de applicatie op elk moment gestopt kan worden door het systeem en eventueel elders weer opgestart kan worden. Dit is namelijk een gevolg van de automatische schaling (als het druk is worden er pods bijgemaakt, wordt het daarna weer rustiger dan worden deze pods weer gestopt) en de self-healing in het cluster (als een stuk onderliggende hardware een probleem heeft kan het systeem besluiten alle pods die daar draaien te verhuizen naar een andere node. De pod in kwestie zal dan dus gestopt worden en ergens anders weer opgestart worden).
Dit betekent dat een HA applicatie niet exclusief kan leunen op het altijd bestaan van 1 pod. Die pod zou namelijk zomaar eventjes weg kunnen zijn. Het meest sprekende voorbeeld zijn applicaties die gebruik maken van redis. Redis is een key-value store. Als er maar 1 redis container draait, dan zal de applicatie waarschijnlijk stuk gaan op het moment dat die container even verhuisd wordt naar een andere node.
Het is dus zaak om ervoor te zorgen dat er geen single points of faillure in de applicatie zijn, zoals in het voorbeeld hierboven de enkele redis pod. De oplossing hiervoor is om gebruik te maken van clustering oplossingen. Bijvoorbeeld bij redis is het mogelijk om een dit zodanig te draaien dat er altijd meerdere pods zijn die elkaar onderling in de gaten houden en data onderling kunnen repliceren, zodat als er 1 pod down gaat, de dienst als geheel onverstoord door kan draaien.
Dit kan uitsluitend via Simple Email Service (SES)
Taken die traditioneel meer aan de operationele kant zaten, zoals het configureren van een webserver, vallen in een DevOps platform als Openshift opeens onder de verantwoordelijkheid van het team dat de applicatie maakt (“dev”) en niet meer onder het team dat het platform als geheel in de lucht houdt (“ops”). Dat betekent dat er in ontwikkelteams meer kennis moet zijn van operationele zaken. Houd daar bij de samenstelling van ontwikkelteams rekening mee.
Een taak die hier ook onder valt is het bijhouden van software versies. Als de gebruikte software in een pod verouderd is en mogelijk security problemen heeft, dan is het de verantwoordelijkheid van het ontwikkelteam op deze weer up-to-date te krijgen.
Wij raden sterk aan om een CI/CD straat in te richten om op deze manier de development en deployment van applicaties gestroomlijnd te hebben. Hierdoor wordt het makkelijker om wijzigingen in de codebase door te voeren en deze door te zetten naar de productie omgevingen.
Het is mogelijk dat het platform als geheel het prima doet, maar dat applicaties die erin draaien het niet meer doen. Voorbeelden hiervan kunnen zijn dat er wordt geleund op een single instance pod en dat die pod ermee opgehouden is. In zo'n geval werkt het platform prima (je zou tenslotte zo weer een nieuwe pod kunnen starten als je wilt) maar is de applicatie wel down.
Omdat het platform het goed doet gaan er bij de platformbeheerders (de medewerkers van team H&S) geen alarmbellen af. Het is dus zaak je eigen alarmbellen in te bouwen die monitoring op applicatieniveau doen. En mocht er een alarmbel afgaan (b.v. buiten kantoortijd) procedures te hebben om ervoor te zorgen dat hier ook opvolging aan wordt gegeven.