Blog

Mijn serverkast draait deze site — wat een homelab me leert over jouw hosting

Onder mijn bureau staat een kast met een paar servers. Geen datacenter, geen indrukwekkende ledverlichting — gewoon wat computers die zachtjes zoemen. Op die kast draait onder andere de site die je nu leest. Dat klinkt misschien als een hobby die uit de hand is gelopen, en dat is het deels ook. Maar het is vooral een proeftuin: alles wat ik daar leer over betrouwbaar hosten, gebruik ik voor het werk dat ik voor klanten doe. Dit stukje gaat niet over de techniek om de techniek. Het gaat over wat één principe — “alles staat in code, niets is handwerk” — betekent voor jouw website.

Wat er in de kast staat

De kast draait een eigen Kubernetes-cluster. Kubernetes (een systeem dat servers en applicaties beheert) verdeelt het werk over de machines, herstart iets dat vastloopt, en zorgt dat de juiste dingen op de juiste plek draaien. Voor een grote webwinkel is dat onmisbaar; voor mijn thuisopstelling is het vooral een oefenterrein waar ik dezelfde gereedschappen gebruik als in productie.

Het aardige is: ik kan die hele kast niet “met de hand” bedienen. Ik log niet in om even een instelling te wijzigen. Alles wat de cluster doet — welke applicaties draaien, hoeveel geheugen ze krijgen, welke domeinnaam waarheen wijst — staat beschreven in tekstbestanden. Die bestanden staan publiek op GitHub, zodat een meelezende techneut precies kan narekenen hoe het in elkaar zit: github.com/webgrip.

Als het niet in git staat, bestaat het niet

git is versiebeheer: het houdt elke wijziging bij — wie, wanneer, en waarom. Voor mij is het de enige bron van waarheid. De regel in mijn hoofd is simpel: staat het niet in git, dan bestaat het niet. Wil ik iets veranderen, dan verander ik een bestand, niet de server.

Dat klinkt streng, maar het lost het grootste hostingprobleem op dat ik ken. In veel opstellingen is er ooit iemand ingelogd om “even snel” iets aan te passen. Een half jaar later weet niemand meer wat er is gewijzigd of waarom. Verhuist de site, dan mist die ene vergeten instelling en werkt de helft niet meer. Bij mij kan dat niet: er is geen verborgen handwerk. Wat de server doet, kun je teruglezen. En kan ik het teruglezen, dan kan ik het ook terugdraaien als een wijziging niet uitpakt zoals bedoeld.

De reis van een wijziging naar live

Stel, ik pas een tekst op deze site aan. De reis van die wijziging naar de live site ziet er zo uit.

  • Ik wijzig het bestand op mijn eigen computer en leg de verandering vast in git, met een korte uitleg erbij.
  • Ik stuur die wijziging naar GitHub. Dat is meteen het startsein.
  • Automatisch draaien er controles: bouwt de site nog, kloppen de instellingen, zijn er geen fouten geslopen.
  • Slagen die controles, dan wordt de nieuwe versie automatisch live gezet — de deployment (het live zetten). Geen knop die ik met de hand indruk, geen bestand dat ik ergens naartoe sleep.

De hele route is bewijsbaar. Voor elke live versie kan ik aanwijzen welke wijziging erachter zit en welke controles zijn geslaagd. Gaat er onverhoopt iets mis, dan zet ik de vorige versie terug — niet door te sleutelen, maar door dezelfde route andersom te lopen.

Dezelfde manier van werken gebruik ik voor klantprojecten. Een deel daarvan kun je bekijken bij mijn werk, en de meeste opzet is publiek terug te lezen in de broncode.

Wat jij daar als klant van merkt (spoiler: niets, en dat is de bedoeling)

Hier komt de anticlimax: als het goed is, merk je van dit alles helemaal niets. Je site staat er gewoon. Wijzigingen verschijnen zonder gedoe. Er is geen avond waarop “de hosting eruit lag omdat iemand iets verkeerd had gezet”.

En dat is precies de bedoeling. Goede hosting is saai. Het werk zit niet in het brandjes blussen, maar in de opzet die brandjes voorkomt: geen handwerk dat vergeten wordt, geen configuratie die alleen in iemands hoofd bestaat, een route van code naar live die je kunt controleren. Wat mij thuis rustig laat slapen, doet voor jouw site precies hetzelfde.

Ben je benieuwd hoe dat er voor jouw situatie uitziet? Lees dan verder over hosting en onderhoud. En wil je het gewoon eens rustig bespreken, dan plan je via contact een vrijblijvende kennismaking van drie kwartier — dan kijk ik met je mee of dit bij je past.

← Terug naar alle stukken

Klinkt dit als jouw soort aanpak?

Plan een gratis kennismaking van drie kwartier. Liever eerst mailen? Kan ook.

Gratis en vrijblijvend · 45 minuten · reactie binnen één werkdag

Geen verkooppraatje, en ik ga niet nabellen.