Sinds deze week is het officieel; Red Hat OpenShift 4.2 is gereleased en voor het grote publiek beschikbaar. Waarschijnlijk kun je niet wachten om er mee aan de slag te gaan, maar wat is er nu precies nieuw? Als Red Hat Accelerator vind ik het altijd leuk om met de nieuwste technieken bezig te zijn en deze te onderzoeken. In dit blog neem ik jullie mee in een paar mooie nieuwe features die mij persoonlijk zijn opgevallen in OpenShift 4.2.
Bij mijn eerste OpenShift blog hoort uiteraard een korte introductie. Mijn naam is Jan Kappert, Dev/Ops Engineer bij HCS Company, en ik vind het gaaf om me bezig te houden met Red Hat technologie. Zo gaaf zelfs dat ik mezelf Red Hat Evangelist mag noemen en ook ben toegelaten tot het Red Hat Accellerator programma. Mijn passie is het delen van kennis over Red Hat technologie, dit doe ik dan ook graag met jullie!
De afgelopen periode heb ik grondig gekeken naar de nieuwste features van Red Hat OpenShift, waarvan ik er graag een paar met jullie wil delen. De lijst is natuurlijk niet uitputtend, daarvoor is er te veel nieuws bijgekomen. Zie het als een start van mijn reeks aan blogs en mogelijk zelfs vlogs in de toekomst.
Onderstaande opsomming is dus niet omvattend, maar dit zijn features die mij direct op zijn gevallen in OpenShift 4.2 .
In OpenShift Container Platform 4.1 introduceerde Red Hat het concept van upgrade kanalen om de juiste upgrade versies aan te bevelen voor je cluster. In het kort: upgrade kanalen scheiden upgrade-strategieën en worden ook gebruikt om de trapfrequentie van updates te regelen. In OpenShift 4.2 kun je nu daadwerkelijk upgraden door te switchen van channel.
Deze upgrade kanalen zijn gekoppeld aan een secundaire versie van OpenShift Container Platform. OpenShift Container Platform 4.2-kanalen bevatten bijvoorbeeld nooit een upgrade naar een 4.3-release. Dit zorgt ervoor dat beheerders een expliciete beslissing moeten nemen om te upgraden naar de volgende secundaire versie van het OpenShift Container Platform.
Kanalen beheren alleen updates en hebben geen invloed op de versie van het cluster dat je installeert. De versie die je installeert wordt bepaald door de OpenShift-installer. Na de installatie is het mogelijk om een update te draaien, mits deze aanwezig is. Het grote voordeel van deze manier van updaten is dat er ook een rollback gedaan kan worden van de upgrade. Ook is het update proces hierdoor een stuk eenvoudiger geworden.
OpenShift Container Platform 4.2 introduceert een ondersteuning voor installatie en het bijwerken van OpenShift Container Platform-clusters in beperkte netwerkomgevingen. Het is ontworpen om te werken met elke docker 2.2 container registry. Via deze oplossing is het dus mogelijk om OpenShift te deployen binnen een afgeschermd netwerk.
Eerst moet je de content repliceren van Quay.io naar de lokale container registry. Nadat de content is gerepliceerd, kan OpenShift-install worden geconfigureerd om Ignition-configs te genereren die de content van de locale registry haalt in plaats vanuit Quay.io. Dit kan alleen gebruikt worden met de UPI-implementaties (User-provisioned Infrastructure).
Ook is het nu mogelijk om Operators uit de OLM-catalogus te gebruiken in een beperkte netwerkomgeving. Echter, de operatorbronnen moeten nog wel handmatig opgehaald worden om de offline catalogus te vullen. Dit handmatige proces is slechts een tijdelijke oplossing voor OpenShift Container Platform 4.2. Een geautomatiseerde oplossing staat gepland voor een toekomstige release.
OpenShift Container Platform 4.2 ondersteunt vanaf nu ook proxy’s. Mocht je dit eerder in OpenShift 4.1 willen doen, dan moest je aanpassingen maken in je huidige netwerk en transparante proxy’s gebruiken. Iets wat vaak geen gewenste situatie is, aangezien je als organisatie zeker wil weten of de servers geautoriseerd zijn om gebruik te mogen maken van het internet.
Als je nu OpenShift Container Platform 4.2 gaat installeren, dan kan je de proxy informatie kwijt in de install-config.yaml die je genereert met de openshift-install tool. Het is dus vanaf nu niet meer nodig om in je eigen netwerk aparte proxy‘s te bouwen om een installatie mogelijk te maken.
Tijdens de installatie moet je een install-config.yaml aanmaken waar je de proxy informatie in kwijt kunt. Deze informatie wordt gebruikt tijdens de installatie en binnen OpenShift cluster proxy object.
Let op: Deze proxy settings kunnen alleen gebruikt worden als je gebruik maakt van de user- provisioned infrastructure installatie (UPI).
Daarnaast is er nu ook ondersteuning voor eigen CA-bundels, waardoor de proxy MITM HTTPS kan gebruiken.
In OpenShift Container Platform 4.2 is er, naast de al bestaande geautomatiseerde full stack deployments (IPI, AWS, GCP en Azure), nu ook Red Hat Openstack Platform bijgekomen. Gaaf om te zien dat de cloud deployments nu goed ondersteund worden!
Wat nog wel anders is, is het on-premise verhaal. In OpenShift 4.3 komt er nog een platform bij (waarschijnlijk RHV?), en gaan we zien dat meer ondersteuning gaat komen voor geautomatiseerde full stack deployments. Voor een snelle start kan een IPI deployment prettig zijn. Mocht je echter toch gebruik maken van een corporate proxy of een netwerk waar geen internet beschikbaar is, dan moet je gebruik gaan maken van een UPI installatie.
Op bestaande omgevingen, waar automation niet mogelijk is, zijn er in OpenShift Container Platform 4.2 twee installatie mogelijkheden: IPI = Full stack automated en UPI = installatie.
De IPI installatie maakt gebruik van de volledige installatie procedure, inclusief infrastructuur provisioning. Dit allemaal volgens de best practice van Red Hat. Met de UPI installatie ben je zelf verantwoordelijk voor het provisionen van de infrastructuur en machines, maar dit biedt je wel veel meer flexibiliteit. Op deze manier van deployen heb je dus meer controle over je machines.
Je zou ervoor kunnen kiezen om, net als in OpenShift 3, infra nodes te installeren waar je bijvoorbeeld de OpenShift-monitoring, OpenShift-logging en routers in plaatst. Een andere mogelijkheid is om speciale nodes toe te wijzen voor het afhandelen van de Container Native Storage oplossing van Red Hat. Hier zal ik binnenkort meer over schrijven.
Zelf ben ik geen Developer, maar om mij heen hoor ik al veel Developers die maar al te graag gebruik willen gaan maken van onderstaande nieuwe tools :)
Webconsole met een ontwikkelaarsperspectief.
Hiermee kunnen ontwikkelaars zich concentreren op wat er voor hen belangrijk is. Handig: zo is alleen de informatie en configuratie zichtbaar die je als ontwikkelaar nodig hebt.
Odo , een speciale cli ontworpen voor ontwikkelaars.
Hiermee kan een Developer op een eenvoudige wijze een applicatie ontwikkelen op OpenShift. De style lijkt een beetje op git push. Deze CLI helpt Developers die nog niet echt bekend zijn met Kubernetes en het ontwikkelen van applicaties op OpenShift.
De naam zegt het al: er is een Connector gemaakt voor Microsoft Visual Studio Code, JetBrains IDE, IntelliJ en Eclipse Desktop IDE. Met deze connector is het mogelijk om makkelijker in te haken op bestaande pipelines. Wanneer er gebruik gemaakt wordt van de connector kan de Developer, zonder de IDE te verlaten, de software builden, debuggen en deployen op OpenShift.
Red Hat OpenShift Deployment Extension voor Microsoft Azure DevOps.
Gebruikers van deze DevOps tool kunnen nu, direct via Microsoft Azure DevOps, hun applicaties bouwen en deployen op Azure Red Hat OpenShift en elk ander OpenShift cluster.
Service Mesh
OpenShift Service Mesh is gebaseerd op Istio-, Kiali- en Jaeger-projecten en worden geïnstalleerd via Operator. OpenShift Service Mesh biedt traffic monitoring, toegangscontrole, detectie, security, veerkracht, tracering en rapporteert aan een groep services door te draaien als een sidecar container. Je krijgt die functies zonder aangepaste code; er zijn geen wijzigingen nodig in de code van je services.
Met de nieuwe release van OpenShift 4.2 heeft Red Hat en de community het gebruik voor ontwikkelaars en beheerders een stuk eenvoudiger gemaakt. Voor de Developers is het Developer console een stuk overzichtelijker geworden. Je kunt snel bij bepaalde functies komen en snel doorklikken naar de zaken die je echt nodig hebt. Ook zijn er veel nieuwe cloud-native tools bijgekomen. Dit stelt Developers in staat om zich beter te focussen op de zaken die echt belangrijk zijn in OpenShift. Hierdoor kan beter geconcentreerd worden op het bouwen van de volgende generatie bedrijfstoepassingen zonder dat er een uitgebreide expertise van Kubernetes nodig is.
Voor de platform engineers is er ook veel veranderd, zo is er een andere installatie procedure. Handig! Mocht je namelijk snel een OpenShift cluster willen opzetten in public cloud, dan kun je een installatie al in 30 minuten uitvoeren. Wil je meer flexibiliteit? Dan kun je de baremetal methode aanhouden.
Het update proces is ook een stuk eenvoudiger geworden. Dit gaat nu automatisch en je hebt ook de beschikking over een rollback oplossing. Ook wordt er veel configuratie werk uit handen genomen door Cluster Operators.
Zo, de teerling is geworpen: ik heb mijn eerste blog afgeleverd. Ik heb hier in het kort mijn persoonlijke selectie van diverse nieuwe features in OpenShift 4.2 besproken. Wat vonden jullie ervan? Wat is goed en wat kan er beter?
In mijn aankomende blogs wil ik dieper in op nog meer nieuwe features. Welke vinden jullie dat ik als eerste moet oppakken? Ik zie jullie reacties graag tegemoet!
Jan Kappert