Vorige week gaf onze collega Menno Pot een interessante presentatie over de mogelijkheden van OpenShift, e.e.a. na een training die hij daartoe bij Redhat (bedenker van OpenShift) gevolgd had. OpenShift als deployment platform kan complementair zijn aan Docker en zorgt er voor dat je met Docker images een echte OTAP op kunt zetten welke makkelijk te redeployen is.

Verschil tussen OpenShift en Virtual machines is dat de Pod’s (systemen) binnen OpenShift op unix kernel niveau gescheiden zijn van elkaar. Dit resulteert in betere security onderling en betere performance. Kleine kanttekening is dat oa memory wel direct toegekend worden en dus niet gedeeld worden. Derhalve zul je in de praktijk meer geheugen in je cluster moeten hebben om al je systemen mee te draaien.

OpenShift is gratis te gebruiken, maar dan met zeer beperkte ondersteuning. Het is ook als service direct bij RedHat of bijv. by T-systems af te nemen, hier zitten dan wel kosten aan verbonden maar dan heb je ook ondersteuning en zij leveren dan de hardware.

Meer info is te vinden op :https://blog.openshift.com/openshift-container-platform-reference-architecture-implementation-guides/

Waarom überhaupt steeds opnieuw deployen?

We kennen het allemaal wel, een test faalt terwijl hij gister nog slaagde. En voor je gevoel is er niets veranderd. Je SUT (System Under Test) veranderd continu. Door aanpassingen door ontwikkelaars een testers, maar ook door het uitvoeren van testen op het systeem.

Dit alles kun je wel herstellen, maar dat kost tijd en vaak ook irritatie. Als je mazzel hebt vindt je de oorzaak en is het ook iets wat je moet aanpassen in de code dan wel de test code, maar zo niet dan heb je geen voordeel en zit je uiteindelijk alleen met een systeem waarop de testen wel weer slagen, maar welke toch niet gegarandeerd 100% gelijk is aan hoe het in productie geïnstalleerd zal worden.

Kortom, deploy een SUT en draai de testen. Als je nieuwe testen wil draaien, deploy dan opnieuw.

Voordelen van Openshift

Ook na een re-deploy is het systeem nog steeds beschikbaar op dezelfde URL. Je kunt zelfs re-deployen waarbij het oude systeem pas down gaat als het nieuwe volledig opgestart is. Dus geen downtime!

Indien er meer capaciteit nodig is, schakel je met 1 druk op de knop een extra systeem bij. Loadbalancing wordt door openshift geregeld. Loadbalancing kan zelfs geo-redundant uitgevoerd worden.

In een landschap van microservices kan OpenShift heel makkelijk melden welke service waar bereikbaar is. Zo kunnen de services elkaar onderling bereiken, zelfs als ze “over gaan” van de test omgeving naar de acceptatie omgeving zonder dat je alle endpoints aan hoeft te passen. Indien er bijv. toch problemen zijn op acceptatie dan kun je snel een nieuw systeem deployen (roll-back of roll-forward) maar het oude systeem wel in tact laten om later te debuggen.

Je kunt gemakkelijk een nieuw project opstarten. Dit kun je zien als een omgeving zoals een test omgeving. Deze deployen allemaal identiek. Hierdoor zou het eigenlijk niet meer moeten kunnen dat iets wel werkt op de test omgeving en niet op de acceptatieomgeving.

Stoppen we dan met OTAP?

Je kunt simpelweg een omgeving opstarten voor wat je nodig hebt. Je zult vaak nog een ontwikkel omgeving gebruiken, maar dit kan ook een omgeving zijn per story die je ontwikkeld. Daarnaast is het heel makkelijk vergelijkbare omgevingen op te starten voor bijv. security testen, performance testen, trainingsdoeleinden etc. etc.

Alles bij elkaar een mooie tool waarmee Docker images nog meer waarde krijgen en het (test) landschap heel wat kan veranderen.