Hoe zorgt een hostingpartij dat klanten van de nieuwste features gebruik kunnen maken, zonder dat updates leiden tot onverwachte downtime? Bij Hostnet, een van de grootste hostingproviders van Nederland, vinden wijzigingen aan de infrastructuur plaats volgens vaste regels: op schaal, in principe automatisch, en alles wordt uitvoerig getest.
Met meer dan 280.000 klanten is Hostnet een van de grootste hostingproviders van Nederland. Het bedrijf biedt diensten aan uiteenlopende doelgroepen: van de kleine ondernemer en small/home-officegebruik tot developers en digitale dienstverleners. Daarvoor biedt het onder meer domeinregistratie, webhosting, online werken, Managed Services en Virtual Private Servers (vps’en).
In het team dat bij Hostnet verantwoordelijk is voor Managed Services zijn drie dev/ops-engineers actief die zich richten op het testen en uitrollen van updates en features op schaal. Zij zijn verantwoordelijk voor de managed en vps-infrastructuur en worden ondersteund door nog eens twee software-developers. Een uitdaging bij het uitrollen van veranderingen op grote schaal, binnen een uitgebreid portfolio aan producten en een complexe infrastructuur, is dat wijzigingen die je op de ene plek doorvoert, op een andere plek onbedoelde (en potentieel nadelige) gevolgen kunnen hebben. “Dat is de essentie van change management”, zegt Jerry Wiersma, dev/ops-engineer bij Hostnet. “Het gaat om de vraag hoe je op een redelijk snelle manier updates en features uitrolt en bijblijft bij de markt, en tegelijkertijd een bepaalde mate van zekerheid hebt dat alles blijft werken zoals het zou moeten.”
Generiek en uitvoerig getest
Om de kans op fouten zoveel mogelijk te beperken, gelden binnen Hostnet bepaalde regels. “We werken in principe niet handmatig, maar geautomatiseerd, en alles gaat op schaal”, zegt Jeroen de Boer, ook dev/ops-engineer bij Hostnet. “Alles dat we maken is generiek, elke klant heeft er profijt van. We voeren dus geen maatwerk uit voor een enkele klant. En wat we maken, testen we uitvoerig. Zelfs als we superzeker zijn van onze zaak, herinneren we ons eraan dat ieder mens fouten kan maken en dat we voorzichtig moeten uitrollen.” Een voorbeeld is het beschikbaar maken van een nieuwe technology stack, namelijk Node.js-hosting. “Omdat we dat graag willen aanbieden, zijn we gaan onderzoeken of de feature een impact heeft op de traditionele tech stack - PHP-hosting - en hoeveel resources hij gebruikt.”
Calamiteiten en r&d uitgezonderd voert men bij Hostnet per regel geen handmatige acties uit bij het doorvoeren van wijzigingen. De volledige configuratie en staat van elk systeem wordt beheerd in code, middels Puppet. Deze software op basis van Ruby kan op een groot aantal uiteenlopende systemen (van Linux tot Windows en Solaris) wijzigingen doorvoeren. Jeroen: “Het geeft ons de zekerheid dat elk systeem de juiste configuratie heeft en biedt de mogelijkheid om gemakkelijk soortgelijke systemen op te leveren.” Met een groot aantal vps’en is dit geen overbodige luxe. “Dat zijn allemaal individuele systemen van klanten waar Plesk op draait en waar meestal weer meerdere domeinen op draaien. Wij gaan niet op al die systemen afzonderlijk wijzigingen doorvoeren. We gebruiken daar een stukje automatisering voor dat voor elke vps elk half uur checked op veranderende code en deze zelf doorvoert.”
Testen kan handmatig
Het team van Jerry en Jeroen werkt in sprints van telkens twee weken, waarin doorgaans meerdere features tegelijk worden opgepakt. Wijzigingen worden in die periode in eerste instantie op een ontwikkelomgeving getest, om te kijken of de beoogde implementatie het gewenste effect heeft. “Dit kan handmatig op een test-vm, bijvoorbeeld in Vagrant”, zegt Jerry. “Ook de implementatie in de Puppet-code testen we op acceptatiesystemen, voordat we een merge request indienen.” Wijzigingen aan software en configuratie worden bij Hostnet doorgevoerd middels merge requests in GitLab. “Deze moeten relateren aan openstaande verzoeken, projecten of verbeteringen. Dit doen wij, omdat dit zorgt voor traceability en auditability van elke wijziging.”
Elke merge request maakt automatisch een ci/cd-pipeline waarin verschillende Docker-containers de kwaliteit en functionaliteit van de code testen op basis van code linters en unit tests. Daarnaast is het zo dat het projectteam de codewijzigingen nakijkt. Zodra alle automatische tests slagen, de code voldoet aan de door Hostnet gestelde standaarden en de maintainers het groene licht hebben gegeven, is het tijd om de code te mergen. “En zo niet, dan krijgt de developer feedback”, zegt Jeroen. “Wanneer de code eenmaal gemerged is, komen er opnieuw ci/cd-pipelines om het merge-result nogmaals te testen alvorens automatisch de laatste versie van de code naar acceptatie te deployen, en later naar productie.”
Node.js zonder regressie in PHP
Een voorbeeld van een recente wijziging op deze manier is het doorvoeren van Node.js-hosting. Jeroen: “Ons platform bood nog geen ondersteuning voor het server-side gebruikmaken van JavaScript. Onze klanten konden alleen nog maar met PHP backend-applicaties maken. Omdat er veel interesse was in Node.js, hebben wij onderzocht of en hoe we dit konden aanbieden. Moesten wij bijvoorbeeld configuratiewijzigingen doorvoeren, was er een negatief effect op de door de klant gebruikte resources en was er geen sprake van regressie in de bestaande stack die met PHP werkte?” Na het testen werd onder meer duidelijk dat er sprake was van positieve impact voor concurrency bij Node.js-applicaties en dat bestaande PHP-applicaties hier geen last van zouden hebben. “De conclusie was dat we dit veilig voor onze klanten konden aanbieden. Op dat punt ben je dan klaar met het testen en start het opbouwen van de automatisering, om de feature daarna automatisch uit te rollen, te zorgen dat hij bij iedereen terechtkomt en stabiel blijft.”
Het meten van de impact van codewijzigingen op customer workloads gebeurt via canary deployments. Met een rundeck job zorgt Hostnet ervoor dat alle systemen tijdelijk stoppen met automatische Puppet-runs, zodat de wijziging niet direct op alle systemen wordt doorgevoerd. Na de rundeck-job schakelt Puppet gefaseerd weer in. Eerst op vijftig systemen, dan op honderd, enzovoort.” Het inbouwen van extra zekerheden is altijd nodig, vindt Jeroen. “Zodra alle tests slagen en iedereen denkt ‘Dit gaat goed komen’, gaat de code naar de productiestraat. En dat is toch het eerste moment dat er daadwerkelijk iets met nieuwe code op klantsystemen gebeurt. Dat blijft een spannend moment. Je kunt nog zoveel zekerheden inbouwen, we maken helaas allemaal weleens een fout. Daar moet je altijd rekening mee houden.”
Wat als er dan toch problemen ontstaan?
Jerry: “Mochten er ondanks alle automatische tests en peer reviews toch nog problemen ontstaan, dan komen we hier altijd vroeg achter, voordat het een impact heeft op alle workloads van onze klanten. In dit geval stoppen we de canary deployments, en afhankelijk van de impact lossen we het op met een roll-forward. Dat wil zeggen dat we het probleem direct oplossen door ervoor te zorgen dat het werkt zoals we het voor ogen hebben. Pas als dit niet mogelijk is, bijvoorbeeld omdat het te complex is of te veel impact heeft, voeren we alsnog een rollback uit.” Een voorbeeld van zo’n scenario was een update in PHP, enige tijd geleden. Jeroen: “Al onze tests wezen uit dat onze update een performanceverbetering zou betekenen, maar al snel na de rollout begonnen bij onze servicedesk meldingen van incidenten bij klanten binnen te komen. We onderzochten deze meldingen, achterhaalden de oorzaak en hebben de update direct uit productie gehaald. Vervolgens hebben we met Puppet overal de oude configuratie teruggezet, allemaal in een tijdsbestek van ongeveer drie kwartier, inclusief het onderzoek. Zo’n gebeurtenis laat wel zien dat je nooit zeker kunt weten wat het effect is van een update. Maar ook dat onze procedure hier prima werkte en onze klanten zo min mogelijk last hebben gehad van downtime.”
Dit artikel is geen redactioneel artikel, maar een advertorial en tot stand gekomen dankzij Hostnet en Tweakers Partners. Dit is de afdeling binnen Tweakers die verantwoordelijk is voor commerciële samenwerkingen, winacties en Tweakers-events zoals Meet-ups, Developers Summit, Testfest en meer. Kijk hier voor een overzicht van alle acties en events. Mocht je ideeën met ons willen delen over deze vorm van adverteren, dan horen wij dat graag. Hierover kun je met ons in gesprek via [Discussie] Reclame algemeen].
/i/1386259508.png?f=fpa)
:strip_icc():strip_exif()/u/10337/crop5814ad4bebe9a_cropped.jpeg?f=community){kind=small}
:strip_exif()/u/220446/crop5dd40a798c9ae.gif?f=community){kind=small}
/u/57387/claimedavatar-70.png?f=community){kind=avatar}
/u/1460960/crop5f730e5da03af_cropped.png?f=community){kind=small}
:strip_exif()/u/47900/baph.gif?f=community){kind=small}
/u/30977/crop654a08a5866a6_cropped.png?f=community){kind=small}
:strip_icc():strip_exif()/u/409953/crop560b87de9a531_cropped.jpeg?f=community){kind=small}