Rolling updates voor SURFconext

Huidige releaseproces SURFconext

In de loop van de jaren is het test- en releaseproces van SURFconext steeds beter geworden. Dit komt omdat we het proces steeds verder aanscherpen en regelmatig releases uitvoeren. Het afgelopen collegejaar hebben we bijvoorbeeld al 18 keer gereleased.

Voordat de software in productie is genomen, is er al heel wat gebeurd:
 

• Alle software wordt getest via vaste protocollen, zowel geautomatiseerd als handmatig.
• Vervolgens worden de software en configuraties uitgerold. Dit is voor alle omgevingen (test, acceptatie en productie) volledig geautomatiseerd met behulp van Ansible.
• Om er zeker van te zijn dat de nieuwe software ook goed met productiedata overweg kan, zetten we als laatste controle de nieuwe software eerst een korte periode op 1 server op productie. Deze is alleen toegankelijk voor het SURFconext-team.
• Bij akkoord wordt de nieuwe software tijdens het onderhoudsvenster uitgerold voor alle gebruikers. Ook tijdens het onderhoudsvenster doen we dit zonder downtime.

Nieuwe releases worden altijd een week van tevoren aangekondigd, zodat bij eventuele problemen instellingen en dienstaanbieders weten dat er aan onze zijde iets veranderd is

Nadelen huidig releaseproces

Dit proces loopt goed, maar toch zijn er een aantal nadelen aan deze methode:

• Er zijn veel instellingen en diensten gekoppeld aan SURFconext. Instellingen en diensten gebruiken veel verschillende SAML-producten en configuraties: er zijn in principe een kleine 200.000 mogelijke combinaties van IdP en SP. We kunnen dus niet alle mogelijke combinaties van tevoren testen.
• Als er na een release toch een fout ontdekt wordt en we de oude software terug moeten zetten, dan brengt dit risico’s met zich mee: dit moeten we dan namelijk vaak op het drukste moment van de dag doen.
• Het releaseproces vraagt redelijk veel van het team en onze beheerpartij. De beheerder en technisch productmanagers van SURFconext moeten om 5.00 uur op om de release uit te voeren en te testen. Dit zorgt ervoor dat we minder vaak releasen dan we zouden willen. Bij voorkeur doen we dit namelijk nog vaker, zodat de wijzigingen per keer nog kleiner blijven.

We willen deze nadelen graag wegnemen en hiervoor is een andere manier van releasen nodig: rolling updates.

Wat is een rolling update?

Bij een rolling update gebruikt eerst een klein percentage van de gebruikers de nieuwe software en als de monitoring aangeeft dat er geen problemen zijn, wordt dit percentage opgeschroefd. Als dit succesvol verloopt – geen afwijkingen in de monitoring en geen klachten van gebruikers – dan gaan steeds meer gebruikers de nieuwe software gebruiken. Dit is een voorspelbaar en geautomatiseerd proces.

Als de nieuwe software niet succesvol blijkt, dan kan direct naar de oude versie teruggeschakeld worden. Beide versies zijn naast elkaar beschikbaar en kunnen de volledige belasting aan. Het terugzetten van oude software is dan niet meer nodig. Zo zorgen rolling updates ervoor dat de nadelen van de huidige releasemethode worden weggenomen.

Uitdagingen

In juni zijn we begonnen met rolling updates voor een aantal niet-kritische applicaties. Dit is goed verlopen en het plan is om na september deze manier van updaten ook toe te passen voor de rest van het platform. Voordat we dit gaan doen, zijn er nog een aantal uitdagingen waarmee we aan de slag gaan:

• Onze monitoring is vrij uitgebreid, maar vooral gericht op het detecteren van grotere verstoringen. Om ook de kleinere problemen te kunnen detecteren (bijvoorbeeld een specifieke instelling-dienstcombinatie), moeten we onze monitoring verder verbeteren.
• Niet alle releases zijn uit te voeren met rolling updates, omdat er bijvoorbeeld grotere databasewijzigingen nodig zijn. We moeten hier rekening mee houden bij de ontwikkeling van nieuwe software. En grote wijzigingen of aanpassingen die niet zonder downtime gedaan kunnen worden, voeren we nog steeds tijdens een maintance window uit.
• Een gebruiker of instelling weet niet of hij/zij op de huidige of nieuwe softwareversie zit. Bij problemen willen we graag weten welke versie er gebruikt wordt zonder dat de gebruiker zelf ingewikkelde dingen hoeft te doen. Niet alleen het SURFconext-team wil dit graag weten, maar ook de instellingen en dienstaanbieders.

We hebben nog een aantal vragen die we graag samen de aangesloten instellingen willen beantwoorden. Wat is bijvoorbeeld het beste moment om een rolling update uit te voeren? Hoe lang moet een rolling update duren? Hoe zorg ik dat mijn supportdesk op de hoogte is? Ben jij een ICT-manager, service manager of supportdesk medewerker en wil je met ons meedenken over hoe het rolling update proces er uit zou kunnen zien? Stuur een mail naar femke.morsch@surfnet.nl