WSO2 heeft een nieuwe manier van updaten geïntroduceerd. Het heet Updates 2.0, en maakt de dingen net even anders dan we gewend waren. Maar, waarom zou je überhaupt updaten?
Software is zoals sommigen zeggen ‘nooit af’. Nee, ik heb het niet over de ellende van projectmanagement, maar ik heb het over het feit dat software zoals WSO2 aangepast wordt aan nieuwe functies en, net zo belangrijk, vaak componenten gebruikt die door anderen ontwikkeld worden. Dit houdt in dat er veel ‘bewegende onderdelen’ zijn, die allemaal hun eigen bijwerkingen en reparaties nodig hebben waarvoor de code geüpdate moet worden.
Enfin, updates zijn noodzakelijk om alles zo goed mogelijk te laten werken en je zult er dus op moeten rekenen dat ze geregeld uitgevoerd moeten worden. Het is niet altijd vooraf duidelijk wanneer er een update beschikbaar komt en daarom is het belangrijk dat er een werkend proces bekend is op het moment dat het tijd is om er één uit te rollen.
WSO2 producten updaten of niet?
Voor sommigen is dat een ‘no brainer’. Ik heb immers net zelf onderbouwd dat updates noodzakelijk zijn. Ja, dat heb ik net inderdaad beweerd, maar WSO2 updates zijn alleen beschikbaar voor betalende klanten. De abonnementskosten zijn een inkomstenbron voor WSO2 en geeft hen de mogelijkheid om hun producten te ontwikkelen, zodat wij ze kunnen gebruiken.
WSO2 updates bevatten verbeteringen bovenop de laatste productversie van WSO2 die door WSO2 zelf vrijgegeven worden. Door de updates hoef je niet te wachten tot er een volgende versie van een product op de markt komt, maar kun je al veel eerder profiteren van de verbeteringen en beveiligingspatches. Wat mij betreft is het een must-have als je WSO2 zakelijk gebruikt. Het is geen sluikreclame voor de productondersteuning die wij bieden, maar serieuze noodzaak.
We creëren en beheren software en systemen niet als hobby, maar met een zakelijk belang. Voor zaken die op deze systemen vertrouwen kan een onderbreking tamelijk prijzig zijn. Bovendien liggen organisaties onder een vergrootglas. De media is happig op verhalen over ondernemingen en instanties die zwakheden in hun systemen hebben en openstaan voor allerlei bedreigingen. Waar het gaat om persoonsgegevens is er zelfs de plicht onder de AVG om de toezichthoudende autoriteiten binnen 72 uur na een inbraak op systemen hiervan op de hoogte te stellen. Dat zijn alles bij elkaar dingen die je heel graag zult willen voorkomen.
WUM of Update 2.0
Tot op heden was er WUM (WSO2 Update Manager). Het werkte als commandoregel om een repository aan te maken en de beschikbare updates op de basisversie uit te voeren, waardoor er een nieuwe versie van het product ontstond met een timestamp als achtervoegsel. Het is belangrijk om te beseffen dat de WUM met een kant-en-klare versie van WSO2 werkt, waarin GEEN van je wijzigingen, parameters en settings toegepast zijn. Dus, bij iedere geüpdatete versie moest alles opnieuw ingesteld en vervolgens getest worden.
Wat echter minder bekend is, is dat in recente versies van WSO2 producten commando’s gevonden kunnen worden om in-place updates mee uit te voeren. Deze tools, zoals update_linux, die gevonden kunnen worden in de bin bestandsmap (bijv. in de WUM-versie van WSO2 API Manager 3.2.0) voert de update uit op die specifieke versie.
WSO2 Updates 2.0 werkt vanuit de bestandsmap waar het geïnstalleerd staat. Een speciaal commando, bijv. wso2update_linux, zal ervoor zorgen dat voor klanten met geldige productondersteuning de uploads gedownload en toegepast worden. Het mechanisme is vergelijkbaar met de WUM (patches downloaden en toepassen) zoals we kunnen zien als we de update uitvoeren met -v (verbose) als extra parameter.
Updates en hotfixes
Updates kunnen onder andere veiligheidspatches, nieuwe functies of verbeteringen bevatten, maar ook bug fixes voor bestaande producten. Als er een update uitgevoerd wordt, dan wordt het update-niveau verhoogd. In ons voorbeeld staat het niveau van de WSO2 API Manager op 26.
Zoals je op de afbeelding kunt zien, update een fictief bedrijf genaamd Acme het WSO2-product maar krijgt ook hotfixes voor problemen doorgevoerd. Een hotfix is een zipbestand dat lokaal toegevoegd wordt. ‘Other Corp’ krijgt hotfixes als reguliere updates.
Aan de slag met Updates 2.0
Er zijn drie afzonderlijke versies voor de drie ondersteunde besturingssystemen waar WSO2 op kan draaien:
- Windows: wso2update_windows.exe
- Linux: wso2update_linux
- Mac: wso2update_darwin
Dit zijn geen scripts, zoals het start script voor WSO2 (wso2server.sh), maar het zijn uitvoerbare bestanden.
Als je een WSO2 product wilt updaten zul je eerst de tool zelf moeten updaten. Dit scherm laat je de gang van zaken op Windows zien. Linux en Mac gaan nagenoeg op dezelfde wijze wat betreft de stappen en de functionaliteit. Een klein verschil is dat voor Windows de mogelijkheid om een update terug te draaien bijvoorbeeld ontbreekt. Dus het maakt wel degelijk uit welk platform je gebruikt. Ik laat de gang van zaken hieronder voor Windows zien, maar over het algemeen is het aan te raden om het in een Linux-omgeving te draaien.
Welke functies heeft de tool?
Als we willen weten wat we met de tool kunnen, laten de parameters ons enkele opties zien. Commando’s en zogenaamde ‘flags’ kunnen gecombineerd worden. Dat is goed te zien in de voorbeelden in de screenshot.
Het is belangrijk om te realiseren dat we commando’s en flags hebben, wat nogmaals duidelijk wordt uit bovenstaande screenshot. Sommige van deze flags hebben een shortcut, zoals ‘-p’ voor ‘–password’.
Het eerder genoemde –revert is geen commando maar een flag. Er bestaat wel een revert-hotfix commando, maar dat werkt specifiek voor updates die als hotfixes aangeboden worden. In andere woorden: updates die als zip-bestand lokaal aan het WSO2-product toegevoegd moet worden.
In tegenstelling tot de WUM hebben we geen update commando. De update wordt uitgevoerd als we de tool starten. We kunnen ook een gebruikersnaam- en wachtwoord aan de tool meegeven als extra parameters. Hierdoor kan het proces geautomatiseerd worden, alhoewel dit vraagt om een gebruikersnaam en wachtwoord als platte tekst op te slaan. Een snelle check met betrekking tot het wachtwoord laat zien dat het soms met tussen enkele aanhalingstekens ingevoerd moet worden: -p ‘myPa55!word’. In Linux, worden tekens zoals ! door bash gebruikt voor speciale doeleinden. In dat geval kun je enkele aanhalingstekens om je wachtwoord zetten, wat een indicatie is dat dit gedeelte niet als code geïnterpreteerd dient te worden.
‘Dry run’ biedt de mogelijkheid om de procedure te testen. Een ‘dry run’ voert alle stappen uit om de distributie te updaten, maar maakt geen blijvende veranderingen. Hierdoor kunnen we testen of we kunnen verwachten dat het uitvoeren van de update zal slagen.
‘Current state’ laat het huidige niveau zien, in dit geval 25.
Met ‘apply-hotfix’ kun je een hotfix aan het product toevoegen. ‘remove-hotfix’ (niet zichtbaar) zal deze vervolgens weer kunnen verwijderen.
Wat is de status
Online kun je het Update Overzicht van dit product vinden (inloggen verplicht). Je kunt het preciezer bekijken door op de turquoise button (136 UPDATES) te klikken voor details over de afzonderlijke updates.
Conflicten oplossen
Er kunnen situaties voorkomen waarbij er conflicten ontstaan tussen de huidige versie en de aankomende update. Dit zou in een configuratiebestand of een artifact dat je zelf hebt aangepast kunnen zitten. Als een bestand of een artifact conflicten veroorzaakt, probeert de update tool ze niet samen te voegen. In een dergelijke situatie zul je handmatig de aanpassingen aan de geüpdatete bestanden uit moeten voeren.
Vooral als je het updateproces geautomatiseerd hebt, kan het optreden van conflicten voor problemen zorgen. Je zou in dat geval kunnen overwegen om het updateproces op een standaard productversie te runnen en tools als Ansible, Chef, Puppet enz. te gebruiken om de aanpassingen door te voeren nadat de update via de WSO2 Updates tool geïmplementeerd zijn.
Je kunt conflicten minimaliseren door best practices te volgen. Eén van deze methoden is om geen Jar-, War- of Car-bestanden die bij het product horen aan te passen. Een update zal deze bestanden overschrijven en al je wijzigingen gaan daardoor verloren. War-bestanden (Web Application Resource file) zullen volgens WSO geüpdate worden door het bestand te dearchiveren en de updates er bovenop uit te voeren. Er is een goede kans dat aanpassingen aan de War teruggehaald kunnen worden na de update, maar het is aan te raden op safe te gaan en het controleren!
Car-bestanden die je zelf aanbiedt worden door het updaten niet gewijzigd, dus daar hoef je je geen zorgen over te maken. Voor .jag/js en json-bestanden is het belangrijk om de originele inspringingen aan te houden. Houdt ook de volgorde van parameters in json-bestanden zo veel mogelijk gelijk door nieuwe key / value paren aan het einde toe te voegen.
Mocht een probleem zich voordoen, dan zijn dit de drie eenvoudige stappen. Waar we *.original noemen, staat het * voor één of meerdere bestanden.
- Vind de bestanden die conflicteren en door de tool gerapporteerd worden;
- Vind de *.original bestanden (in je huidige setup) en de *.new bestanden (in de update);
- Verhelp de problemen en sla het resultaat op als *.final. Run de update nog een keer met –continue en controleer de uitkomst. Alle conflicterende bestanden zouden nu weg moeten zijn (alle: dus original, new en final).
Werken met Docker
Een van de functies die ik gaaf vind is de mogelijkheid om een docker image te maken van het geüpdatete product dat we zojuist gecreëerd hebben. De image wordt lokaal in docker opgeslagen en je kunt het gebruiken als je nieuwe product base image.
Zoals je kunt zien hebben we een geüpdatete versie aan de docker repo toegevoegd.
Doorlopend updaten van WSO2 producten
Deze blog geeft een overzicht van de WSO2 Updates 2.0 tool. Deze informatie kan gebruikt worden om een proces van doorlopend updaten in te regelen, hoewel dat meer vraagt dan de informatie hier. Hiermee bedoel ik het scripten (ansible), testen, uitrollen en de automatisering van het geheel.
De WSO2 Updates 2.0 tool geeft gebruikers de mogelijkheid om een bestaande WSO2 configuratie te updaten. De vorige tool, WUM, kon alleen productversies die door WSO2 zelf uitgebracht werden updaten. Maar, zoals we zagen, was er wel een mogelijkheid om een in-place update uit te voeren met een update commando (bijv. update_windows.exe). Beide benaderingen hebben zo hun voor- en nadelen.
Het uitvoeren van updates op een door WSO2 aangeboden installatie, dus zonder je eigen persoonlijke aanpassingen, voorkomt dat er conflicten optreden tussen de update en de bestaande installatie. Hierdoor kun je zulke problemen al vroeg in het proces oplossen, eigenlijk al voordat je ze uitvoert in een live-omgeving. Deze benadering houdt echter wel in dat het sterk aan te raden is om de installatie en configuratie van je omgeving te automatiseren, omdat je bij iedere update het hele WSO2 product opnieuw moet uitrollen in de werkomgeving.
Met de benadering van de WSO2 Updates 2.0 is dit herhaald uitrollen niet langer nodig. Je kunt er nu voor kiezen om de updates in een live omgeving te laten uitvoeren, of je past ze toe op de standaard door WSO2 aangeboden installatie en rolt de update uit via een geautomatiseerd proces.
In beide gevallen is een testronde van de update zeker aan te raden. Test of de update naar verwachting uitgevoerd wordt en of er niets stuk gaat.
Als je jouw WSO2 installatie zelf moet beheren, dan raden we aan om de installatie en configuratie van je WSO2 producten te automatiseren. Hiermee zal de reproduceerbaarheid en het gemak van de installatie vergroten en het zal minder moeite kosten om de updates toe te passen en uit te rollen in je omgeving.
Als al het bovenstaande naar jouw smaak té complex klinkt, neem dan een kijkje naar het Connext product dat wij aanbieden. Hierin doen wij de installatie en configuratie van de WSO2 producten voor je. Op die manier kun jij je richten op de zaken waar jouw bedrijf aan verdient en nemen wij voor jou het API Management, de Integratie en het Identity & Access Management met WSO2 voor onze rekening!
