Door het automatisch bijwerken van je base images op je containerplatform is het mogelijk om de nieuwste versies op je OpenShift platform te hebben, zonder dat je hiervoor nog handmatig iets hoeft te doen!
In een eerdere blog heb ik al kort geschreven over wat Tekton is en wat je er precies mee kan doen. Heb je deze blog nog niet gezien? Bekijk hem hier! In deze blog ga ik wederom in op Tekton.
Nu heb je misschien vragen zoals: Wat is de HCS Base Updater? Hoe werkt de HCS Base Updater? Waarom zou ik HCS Base Updater gebruiken? Hoe gebruik ik de HCS Base Updater?
Na het lezen van deze blog zijn al die vragen beantwoord.
De HCS Base Updater is een stuk software waarmee je de base images op je containerplatform kan bijwerken zonder hier nog handmatig iets voor te hoeven doen. De HCS Base Updater maakt het dus mogelijk om volledig automatisch je base images bij te werken op je OpenShift platform.
Simpel gezegd is de HCS Base Updater een verzameling bestanden, waaronder:
Voordat we echt ‘onder de motorkap’ gaan kijken van de HCS Base Updater is het goed een aantal technieken die gebruikt worden verder toe te lichten.
De HCS Base Updater maakt gebruik van Knative en Tekton. Knative wordt gebruikt om objecten op het platform in de gaten te houden. In ons geval willen we dat de ImageStream objecten in de gaten gehouden moeten worden. Tekton wordt gebruikt voor het draaien van de pipelines, en daadwerkelijk de base images bouwen met een Tekton pipeline. In dit geval zal Tekton de juiste informatie vanuit Knative krijgen. Dus wanneer een ImageStream gewijzigd is, zal Knative dit merken, de gewijzigde ImageStream informatie naar Tekton sturen en vervolgens gaat Tekton een pipeline draaien. Deze Tekton pipeline zal een nieuwe base image bouwen, met de correcte informatie verkregen vanuit Knative. Wanneer de Tekton Pipeline de correcte informatie heeft verkregen, zal vervolgens een Git repository met configuratie, Dockerfiles en verschillende bestanden gecloned worden. Deze Git repository bevat alles wat nodig is voor het bouwen van de base images.
Knative werkt als volgt op het OpenShift platform.
Binnen de openshift namespace, de plek waar alle ImageStreams staan van het platform, is een Knative object aangemaakt.
Dit object is een ApiServerSource. Deze ApiServerSource beschrijft dat de ImageStream resources in die namespace in de gaten moeten worden gehouden.
Zodra er een wijziging plaatsvindt, zal dit doorgestuurd worden naar een sink welke een uri bevat.
Deze uri is een adres, de EventListener, van Tekton welke de wijzigingen van Knative binnenkrijgt.
Deze EventListener draait in een andere namespace op het platform, in ons geval de tooling namespace.
Dit betekent dat alle informatie van het ImageStream object nu is doorgestuurd door Knative naar Tekton.
Vervolgens zal Tekton het verder overnemen van Knative.
Wanneer Tekton de informatie van Knative heeft binnengekregen op de EventListener zal er een pipeline worden gestart.
Deze Tekton pipeline heeft 3 Tasks.
Thijs Gravestijn
git-clonecheck-imagestreambuild-base-imagesDe eerste stap, git-clone, is gebruikt voor het clonen van de configuratie voor de te bouwen images.
Vervolgens wordt gecontroleerd, door de check-imagestream Task, of hierin een configuratie aanwezig is voor de image dat getriggerd is door Knative.
Wanneer er geen configuratie van de ImageStream in Git staat, zal de pipeline vanzelf stoppen. Dit gebeurt omdat er geen configuratie aanwezig is voor de te bouwen image, er valt dus ook niets te bouwen. Wanneer er wel een configuratie aanwezig is zal de pipeline natuurlijk netjes verder gaan.
In de laatste stap, de build-base-images Task, worden de images daadwerkelijk gebouwd met Buildah. Na het bouwen worden ze in de interne image registry van OpenShift gezet.
Dit kan natuurlijk altijd gewijzigd worden wanneer dit naar een andere image registry gepushed moet worden.
De volgende screenshot vanuit Red Hat OpenShift laat zien hoe de weergave binnen OpenShift Pipelines eruitziet.
Dit stuk software geeft je de mogelijkheid om op een geautomatiseerde wijze de nieuwste versies van je base images op je platform beschikbaar te hebben. Hierdoor hoef je niet meer handmatig builds te starten en dit vervolgens in de gaten te houden.
Wanneer OpenShift wordt bijgewerkt, worden ook ImageStreams binnen de openshift namespace bijgewerkt.
Vervolgens gaat de HCS Base Updater lopen en worden de nieuwe versies van je base images op het platform neergezet.
Voordat je aan de slag gaat met de HCS Base Updater zijn er wel een paar vereisten.
Nu zou de HCS Base Updater moeten werken. Binnen de pipeline wordt een specifieke zelfgemaakte image gebruikt met Buildah, Python en een paar Python modules. Deze image kan zelf gebouwd worden met de meegeleverde BuildConfig voor OpenShift.
Last but not least, om het natuurlijk nog wat mooier te maken, deze software is volledig open source! Wanneer je na het lezen van deze blog graag een feature ziet, of na het testen nog ergens tegenaan loopt, maak dan vooral een issue of merge request aan. Ik zie graag feedback, features en bugfixes tegemoet.
Hier vind je de Git repository van de HCS Base Updater.
Tijdens het testen en in gebruik nemen van deze software in de praktijk kwam al snel een vraagstuk naar voren.
Het automatisch starten van pipelines wanneer een ImageStream wordt gewijzigd gebeurt netjes volgens plan. Alleen wanneer in Git een bestand gewijzigd wordt. Bijvoorbeeld een Dockerfile, een bestand voor in de container of zelfs het toevoegen van een nieuwe configuratie voor het bouwen van een image, dan wordt er niet automatisch een nieuwe pipeline gestart.
Dit is natuurlijk logisch, Knative detecteert geen wijziging op het ImageStream object. Dat maakt het soms wel lastig wanneer na een wijziging in Git een pipeline gestart moet worden.
Het meest simpele is een label toevoegen op het ImageStream object om zo het gewenste image te triggeren.
Tijdens het testen en debuggen heb ik zelf regelmatig gewoon een test=test label toegevoegd op een ImageStream object.
Om dit op te lossen is naast deze bestaande Tekton pipeline ook een on-demand pipeline opgezet om dit probleem op te lossen.
Ik vertel hier graag meer over in deel 2 van deze blog.
