Elke server komtuit hetzelfdescript.
Wij hosten de winkels die we bouwen zelf. Dat is een keuze: een Magento-winkel die traag is of omvalt komt uiteindelijk bij ons terug, en dan wil je erbij kunnen. Het platform is een Ansible-repository die een lege Ubuntu-machine omzet in een server waar Magento-winkels op draaien, met daarnaast een uitrolstraat die code van een commit naar de winkel brengt. Deze case laat zien wat daarin zit en wat het verschil maakt.
- Voor
- Disrex
- Discipline
- Hosting · Uitrolstraat
- Jaar
- 2026
- basis en gebruikers
- firewall en toegang
- webserver
- PHP met de juiste extensies
- database
- cache en sessies
- zoekmachine
- wachtrijen
- certificaten
- cron en taken
- back-ups
- meten en waarschuwen
Meerdere winkels op één machine, die elkaar nergens raken
Elke winkel krijgt een eigen Linux-account, een eigen database met eigen inloggegevens, eigen PHP-processen met een eigen versie en een eigen webserverconfiguratie met eigen certificaat. Loopt de ene winkel vast, dan blijven de andere gewoon draaien.
- De randlanden- en netwerkherkenning
- Webservereigen configuratie per winkel
- PHPeigen processen, eigen versie
- Databaseeigen gebruiker, eigen wachtwoord
Elke winkel loopt door alle vier de lagen, en nergens delen ze een account, een database of een proces.
Magento past niet in de standaardinstellingen
PHP bewaart gecompileerde code in het geheugen zodat hij die niet bij elk bezoek opnieuw hoeft te vertalen. Hoeveel bestanden daarin passen staat standaard op tienduizend. Een Magento-winkel met Hyvä bestaat uit vijfendertig- tot vijfenvijftigduizend bestanden.
Wat er niet in past wordt bij elk bezoek opnieuw vertaald, en dat kost tijd bij elke paginaweergave van elke bezoeker. Hetzelfde geldt voor het geheugen dat die cache mag gebruiken en voor de ruimte voor hergebruikte teksten. De fabrieksinstellingen zijn gemaakt voor een gemiddelde website.
Richt je een server met de hand in, dan richt je hem elke keer net iets anders in. Op de ene machine staat een instelling wel goed, op de andere niet, en dat merk je pas als er iets misgaat. Wie er dan bijspringt moet eerst uitzoeken hoe deze machine in elkaar zit.
Een nieuwe server is dat script draaien
De hele server staat in een Ansible-repository. Wat erin zit is voor elke machine gelijk, en een wijziging voeren we door in de repository en niet op één server. Er is dus geen machine die alleen iemand van ons nog begrijpt.
De eerste stap is een poort
Onze gedeelde onderdelen zitten als submodule in het project van de klant, vastgezet op een commit. Die poort bouwt de schone basis na op precies die versies en compileert hem. Verwijst een van die onderdelen naar iets dat er niet meer is, dan valt de pijplijn daar om en komt er niets op een server.
- 01
Compileren op deze versies
de poortDe poort leest per gedeelde module de vastgezette commit, bouwt de schone basis na op precies die versies en compileert. Faalt dit, dan stopt alles.
- 02
Statische bestanden vooraf
Alle thema's en talen in één keer, in een vaste bouwomgeving. Het resultaat wordt bewaard als pakket.
- 03
Naar staging
Automatisch bij elke push. Database bijwerken als het nodig is, pakket erover, cache leeg.
- 04
Naar acceptatie
Dezelfde route, andere omgeving. Hier kijkt de klant mee. Twee pogingen bij een hapering.
- 05
Naar productie
Nooit vanzelf. Iemand drukt op de knop, en het is hetzelfde pakket dat op acceptatie stond.
- 06
Het onderhoudsvenster
winkel even dichtTijdens het wisselen van de bestanden zien bezoekers een onderhoudspagina. Kort, omdat de server niets hoeft te bouwen: hij pakt uit.
Wat er standaard aanstaat
Dit zit erin zonder dat iemand het aanvraagt. Het staat hier voluit omdat het samen het verschil is tussen een server waar Magento op staat en een server die voor Magento is ingericht.
Afgeschermd
- Eigen Linux-account per winkel
- Eigen database en inloggegevens
- Eigen PHP-processen en PHP-versie
- Eigen webserverconfiguratie
Afgeweerd
- Landen- en netwerkherkenning aan de rand
- Dagelijks bijgewerkte lijst met misbruikende netwerken
- Automatisch blokkeren na herhaald mislukt inloggen
- Certificaat automatisch aangevraagd en verlengd
Gescand
- Twee keer per dag op skimmers en achterdeurtjes
- Bevindingen buiten de server bewaard
- Aparte controle op bekende Magento-lekken
In de gaten gehouden
- Gezondheid van de machine
- Live beeld per server
- Trage pagina's in de winkel zelf
- Losse controles op wachtrijen en foutcodes
Terug te zetten
- Database om de paar uur
- Bestanden elke nacht
- Naar een aparte back-upserver
- Terugzetscript naast het back-upscript
Afgesteld op Magento
- Code-cache berekend op het aantal winkels
- PHP-processen geschaald op de machine
- Eigen paginacache per winkel waar dat helpt
- PHP 5.6 tot en met 8.4 naast elkaar
Ruim binnen de grens, op alle drie
Voor de winkelier zit de winst ergens anders: hij belt over iets wat traag is en wij kunnen erbij. De server is van ons, de inrichting staat in code, en we hoeven niet eerst een hoster te overtuigen dat er iets aan de hand is.
Dezelfde winkel, twee servers
Twee dingen eerlijk. Een uitrol naar productie kent een kort onderhoudsvenster; bezoekers zien dan een onderhoudspagina terwijl de bestanden gewisseld worden. Dat is geen uitrol zonder onderbreking en we noemen het ook niet zo. En we laten hier bewust niet zien welke poorten, paden en versies waar staan: dat is precies de informatie die een aanvaller zoekt. De metingen zijn van 2 augustus 2026, op onze demowinkel, met Chrome vanaf een verbinding in Nederland.
Dit zetten we ook onder jouw winkel.
Vertel waar het nu traag is of waar je op je hoster wacht, dan kijken we of het hier beter uitpakt.