@@PRODUCT@@

Serverprofielen

Een profiel is de vorm van een machine, één keer opgeschreven in plaats van per server ingetypt: welke rollen hij draait, welke tools hij draagt, hoe zijn database en zijn cache afgesteld staan, en waarmee een nieuwe WordPress-site erop beg

Geschreven voor: Beheerder

Een profiel is de vorm van een machine, één keer opgeschreven in plaats van per server ingetypt: welke rollen hij draait, welke tools hij draagt, hoe zijn database en zijn cache afgesteld staan, en waarmee een nieuwe WordPress-site erop begint.

Je zet er een machine mee op:

root@new:~# corectl setup --profile wordpress

en je kunt een bestaande machine erheen verhuizen — daar zitten de interessante regels.

Wat een profiel bepaalt

Rollenprecies deze set — web, db, mail, dns, ftp, backup
Webserverwelke provider, en of LSCache aanstaat
Toolsgit, Composer, WP-CLI, imapsync, Valkey, een Node- of Python-serie
Instellingende eigen serverinstellingen die het meebrengt, op maat van deze machine
PHP-plafondsde directives waarvan dit soort machine de grens verlegt
WordPressde plugins en de object-cache die een nieuwe site erft
Website-updatesof deze machine de websites erop 's nachts vanzelf bijwerkt, en in welke uren

De lijsten zijn exact, geen minimum. Dat telt het zwaarst voor wat een profiel weglaat: het WordPress-profiel heeft geen mailrol, en die afwezigheid is een besluit, geen vergissing.

Website-updates: alleen de twee profielen die klantwebsites draaien

Sinds deze uitgave zetten Gedeelde hosting en WordPress-hosting het venster voor automatische website-updates aan: 05:00–07:00, en wat elke installatie daarin meeneemt blijft de keuze van de klant zelf.

Elk ander profiel zegt er niets over, en dat is het verschil dat telt: een profiel dat er niets over zegt, verandert er ook niets aan. Zet je een draaiende hostingserver over naar het databaseprofiel, dan gaat zijn updatevenster daar niet van uit — alleen een profiel dat het noemt, verzet het.

Het is bewust een ánder venster dan het onderhoudsvenster van het besturingssysteem. Dat laatste mag de machine herstarten, en een herstart midden in een databasemigratie is precies wat een website-update nooit mag tegenkomen. Daarom staat het er standaard ná.

Op het applicatiescherm van een account zie je het venster van de machine waarop dat account staat, met de schakelaar, het tijdstip van de eerstvolgende ronde en hoeveel installaties elk beleid dekt.

De zes profielen

root@web1:~# corectl profile list
Profiles:
     backup-target   Backup node — restic and its timers, tuned for large sequential transfers
     db-dedicated    Database server — MariaDB alone, InnoDB sized for a machine that runs nothing else
     dns-edge        Nameserver — PowerDNS authoritative alone, tuned for UDP bursts
     mail-dedicated  Mail server — Postfix, Dovecot and Rspamd alone, with the IP reputation to itself
     shared          Shared hosting — websites, databases, mail, DNS and FTP on one machine
  on wordpress       WordPress hosting — LiteSpeed with LSCache, Valkey object cache, MariaDB tuned for InnoDB

This node carries wordpress. `corectl profile status` shows how far it has drifted.
Own presets go in /etc/corecp/profiles/<name>.yaml and win over the built-in one.

Twee daarvan zijn machines die álles doen; vier zijn machines die één ding doen.

shared — de alles-in-één machine

Websites, hun databases, hun e-mail, hun DNS en FTP, op één server. Dit profiel stelde vroeger bewust niets af. Dat is herzien: het stelt nu wél dingen af, maar alleen dingen die een feit over de machine zijn en geen gok over wat je klanten draaien.

WatWaarom het niets over de werkbelasting aanneemt
Grootte van de PHP-bytecodecache (OPcache), afgeleid van het geheugenWat die cache vult is het aantal PHP-bestanden van een site, niet wat die bestanden doen. Elke applicatie heeft er evenveel baat bij. PHP's eigen standaard is 128 MB per proces, en op een gedeelde node draait elk account zijn eigen PHP — bij veertig accounts belooft die standaard vijf gigabyte
Meer plek voor het aantal bestanden in de cacheOok een aantal, geen aanname. Als de teller vol zit stopt PHP stilletjes met cachen van nieuwe bestanden — je merkt er niets van behalve traagheid
Het bijhouden van bestandsdatums blíjft aanDit is de énige OPcache-instelling waarvan de "snellere" stand wél iets aanneemt: uitzetten hoort bij een server waar een deploy PHP herstart. Bij gedeelde hosting is de deploy een klant met een FTP-programma, en die verwacht dat zijn wijziging meteen te zien is
Een plafond op het aantal PHP-werkprocessen, afgeleid van het geheugenDit is niet de werkerslimiet van een pakket — die blijft per account staan. Dit is wat de máchine aankan als alle processen tegelijk hun geheugengrens zouden raken. De eerlijke uitkomst is een verzoek dat even wacht in plaats van een proces dat door de kernel wordt afgeschoten
Terughoudender omgaan met swap en met wegschrijven naar schijfDe standaardwaarden laten één grote upload elke andere klant op de machine laten wachten. Op een gedeelde machine hoort niemand op andermans schrijfactie te wachten

Wat het profiel nog steeds niet aanraakt: de PHP-plafonds waar je klanten binnen werken en de standaardinstellingen van MariaDB. Een plafond gaat over wat een klant mag vragen, en de database van een gedeelde node bedient werk dat niemand heeft gezien.

De vier machines-met-één-taak

Rollen zijn de bouwstenen, een profiel is de vorm van een machine, en een servergroep koppelt ze aan elkaar. Zo bouw je een vloot: de plaatsing kiest per rol de machine die die rol draagt, dus de websites van een klant kunnen op de ene server staan en zijn databases op de andere, zonder dat een van beide dat hoeft te weten.

Wat deze profielen afstellen wordt betaald door wat ze weglaten. Een bufferpool mag tweederde van het geheugen nemen op een machine waar niemand anders dat geheugen wilde — en dat is meteen de reden dat het wisselen van een drukke server naar zo'n profiel geweigerd wordt in plaats van kleiner gemaakt.

ProfielRolWat het doet
db-dedicateddbInnoDB-bufferpool op 65% in plaats van de 30% van een gedeelde machine, schrijfgedrag en redo-log afgestemd op SSD, en per databasegebruiker een standaardlimiet op het aantal gelijktijdige verbindingen
mail-dedicatedmail (plus een interne database en webserver)Alleen e-mail, met het IP-adres — en dus de reputatie — voor zich. Rspamd's opslag krijgt een geheugenplafond dat wél tijdelijke gegevens weggooit en níét wat de spamfilter heeft geleerd. De kernel wordt afgestemd op veel korte verbindingen, wat een eigenschap van e-mail is en niet van jouw e-mail
dns-edgednsEen nameserver en verder niets. Alles wat het afstelt is een wachtrij of een buffer die de kernel anders stilletjes laat overlopen — het zegt niets over hoeveel zones je hebt
backup-targetbackupDe machine die de kopieën bewaart. Hij loopt door miljoenen paden en schrijft lange stromen, en daar is het bestandssysteem- en netwerkgedrag op afgestemd. Hij configureert de opslagbestemming níét: de bestemming en het wachtwoord van de repository zijn het enige wat geen enkel profiel kan meedragen

De losse mailserver heeft twee interne hulpjes. mail-dedicated installeert naast mail ook een database (daar staan de mailtabellen in) en een webserver (voor webmail en het certificaat van de server). Beide zijn intern: je ziet ze op de pagina van de server als interne rollen, het paneel plaatst er nooit websites of databases van klanten op, en een klantdatabase aanmaken op die server wordt geweigerd. Daardoor slaagt het profiel ook op een schone server. Meer daarover in Gedeelde dienstservers en uitgaande mail.

backup-target toepassen installeert restic en zijn timers; die draaien en falen zichtbaar tot je ze ergens op richt:

root@bk1:~# corectl profile apply backup-target
root@bk1:~# corectl role add backup --target sftp \
    --endpoint backup@storage.example.net --repo /srv/restic/bk1
root@bk1:~# corectl backup init

Profiel of Releem?

Kort: een profiel is de vloer waarmee een machine opstart, Releem is het bijstellen van een database die al draait. Een profiel rekent met het geheugen van de machine en met wat de rolset veilig maakt, vóórdat er één verzoek is beantwoord. Releem kijkt naar de draaiende server en stelt getallen voor die geen enkel profiel kan weten.

Ze bijten elkaar niet. Pas je een aanbeveling van Releem toe, dan verschijnt dat als een afwijking van het profiel — gemeld, nooit teruggedraaid. Wil je dat die waarde voortaan de vloer ís, kopieer het profiel dan naar /etc/corecp/profiles/ en zet het getal erin.

wordpress — een machine voor één soort applicatie

Draait de machine maar één soort applicatie, dan kun je haar daarvoor afstellen:

  • LiteSpeed met LSCache, zodat de cache in de webserver zit, vóór PHP;
  • Valkey met een geheugenplafond en een opruimregel, zodat een plugin die elke query cachet de machine niet kan omleggen;
  • een InnoDB-bufferpool op maat van deze machine in plaats van MariaDB's standaard 128 MB — dat is het grootste verschil tussen een trage en een snelle WordPress;
  • geen mailrol. Een WordPress-host is geen mailhost. Sites versturen via een relay en poort 25 blijft dicht.

Een nieuwe WordPress-site op zo'n machine krijgt de plugins LiteSpeed Cache en Redis Object Cache, en de object-cache wordt voor je aangezet. Paginacaching zet CoreCP bewust aan bij de site en niet bij de server: de server weet niet welke cookie "ingelogd" betekent en de cacheplugin wel, en een servicebrede één-seconde-cache is één plugin-update verwijderd van de pagina van een ingelogde bezoeker aan iemand anders tonen.

Een profiel helemaal lezen, inclusief waarom het kiest wat het kiest:

root@web1:~# corectl profile show wordpress
wordpress — WordPress hosting — LiteSpeed with LSCache, Valkey object cache, MariaDB tuned for InnoDB
  source     built into corectl
  roles      web, db
  webserver  litespeed (lscache on)
  tools      composer, git, valkey, wp-cli
  drop-in    mariadb (406 bytes, as rendered for this machine)
  drop-in    valkey (39 bytes, as rendered for this machine)
  php policy max_input_vars max 30000
  wordpress  object cache redis, new sites get litespeed-cache, redis-cache
  note       Page caching is turned on at the *site*, not at the node. …

corectl profile show wordpress --yaml drukt het profiel af precies zoals het geschreven staat — dat is wat je kopieert om er zelf een te maken.

De maten komen van de machine

De database- en cache-instellingen zijn geen vaste getallen maar een percentage van het geheugen dat de server écht heeft, afgerond op iets wat een mens zou intypen:

root@web1:~# corectl profile status
profile   wordpress — WordPress hosting — LiteSpeed with LSCache, Valkey object cache, MariaDB tuned for InnoDB
memory    3398 MB (what the profile's drop-ins are sized from)
drift     none — this node matches its profile

3398 MB levert een bufferpool van 960 MB en een objectcache-plafond van 320 MB. Geef je de machine meer geheugen, dan past hij zichzelf niet aan — draai corectl profile apply wordpress opnieuw en de instellingen worden met de nieuwe getallen herschreven.

In het paneel: een profiel kiezen bij het toevoegen van een server

De wizard Server toevoegen begint bij het profiel. Kies je er een, dan vult hij de rollen en de webserver hieronder alvast in — en verder niets: elk vinkje blijft gewoon van jou.

Verander je daarna iets aan de rollen of de webserver, dan zegt het scherm dat, en wordt de server gekoppeld met precies de keuzes die op het scherm staan. Hij krijgt dan géén profielnaam. Dat is met opzet: een machine met de naam van een profiel waar hij niet aan voldoet zou vanaf de eerste minuut een afwijking melden, en dan waarschuwt hij ergens voor wat jij bewust hebt gedaan. Je kunt het profiel later alsnog toepassen op het tabblad Configuratie.

Kies je "Aangepast", dan werkt de wizard precies zoals je gewend was.

Heeft je installatie nog geen enkele server, of is er even geen server bereikbaar? Dan kan het paneel de profielenlijst niet ophalen en zegt het dat. Vink de rollen zelf aan; het profiel geef je later.

In het paneel: het profiel van een draaiende server wisselen

Op de serverpagina, tabblad Configuratie, staat het huidige profiel met een badge die zegt of de machine er nog aan voldoet. Profiel wisselen opent een paneel met drie dingen, in deze volgorde:

  1. Wat het profiel ís — de samenvatting van het gekozen profiel, zijn rollen en de afwegingen die het zelf heeft opgeschreven. Kom je db-dedicated voor het eerst tegen, dan wil je die lezen en niet alleen een verschillenlijst.
  2. Wat het zou veranderen — druk op Wat verandert er?. Deze knop verandert niets op de server; hij vraagt de machine wat er zou gebeuren.
  3. Wat er in de weg staat, als er iets in de weg staat. Zie hieronder.

Pas als je gekeken hebt, wordt Profiel toepassen actief. Bij het toepassen vraagt het paneel je om je identiteit opnieuw te bevestigen — één druk op die knop kan een rol van een server met klanten halen. Het bekijken vraagt daar bewust niet om: een bevestiging die je voor elke blik moet geven, leer je wegklikken.

Die bevestiging gaat sinds deze ronde overal hetzelfde: je vult je code in en de toepassing gaat daarna vanzelf door — je hoeft het paneel niet opnieuw te openen en niets opnieuw te kiezen. Klik je het venster weg, dan is er niets gebeurd en blijft je keuze staan; er verschijnt dan ook geen foutmelding.

Het profiel van een machine wisselen

Kijk altijd eerst. --dry-run verandert niets en vertelt alles:

root@web1:~# corectl profile apply shared --dry-run

Erbij zetten is gratis. Een wissel die alleen een rol of een tool toevoegt gaat zonder vragen door.

Weghalen niet. Een rol weghalen betekent breken wat hem nodig heeft — mailboxen, DNS-zones, databases, FTP-logins — en een profielwissel is geen migratie. CoreCP weigert dus, en de weigering zegt precies wat in de weg staat en hoe je elk daarvan vrijmaakt:

root@web1:~# corectl profile apply wordpress
corectl: switching to profile wordpress would take the mail role(s) off this node, and 33 binding(s) still need it:
  mail      domain   voorbeeld.nl (account acme)            corectl mail disable voorbeeld.nl
  mail      mailbox  info@voorbeeld.nl (account acme)       corectl mailbox delete info@voorbeeld.nl
  mail      … and 27 more (19 domain, 14 mailbox in total)

Move them to another node first — that is what the panel's service bindings are for, and it keeps the data — or free them with the commands above, or pick a profile that keeps the role. Nothing on this node was changed.

In het paneel zie je diezelfde lijst: elke mailbox, zone, database en FTP-login die zijn machine zou verliezen, met het commando dat hem vrijmaakt eronder. Zolang er iets in de lijst staat, blijft Profiel toepassen uit. Het aantal tonen en de lijst weglaten zou precies de "rol is in gebruik"-melding zijn die deze motor moet vervangen.

Forceren kan niet, en dat is opzet. De weg langs een binding is hem verhuizen — daar is de serverplaatsing in het paneel voor, en dat behoudt de gegevens van de klant. Een geweigerde wissel raakt niets aan: de server staat er precies bij zoals hij stond.

Zit er niets vast, dan mag een rol er gewoon af. De regel gaat over bindingen, niet over de richting.

Een profiel is een startpunt, geen keurslijf

Je mag een machine aanpassen nadat je hem een profiel hebt gegeven. Niets draait dat terug. Wat CoreCP wél doet, is melden dat de machine en zijn profiel uit elkaar zijn gelopen:

root@web1:~# corectl tool add node@24
root@web1:~# corectl profile status
profile   wordpress — WordPress hosting — LiteSpeed with LSCache, Valkey object cache, MariaDB tuned for InnoDB
memory    3398 MB (what the profile's drop-ins are sized from)
drift     1 difference(s). A profile is a starting point: these are
          reported, never undone.

  tool        node@24                added    installed here, not part of the profile

Put the node back on its profile with: corectl profile apply wordpress

Hetzelfde staat in de gezondheidscontrole als waarschuwing, nooit als fout — een machine waaraan je bewust een extra tool hebt gegeven is niet ziek:

root@web1:~# corectl doctor | grep profile
[warn] profile            wordpress — 1 difference(s): tool node@24 added — installed here, not part of the profile

En in het paneel, op de pagina van de server: de profielnaam met een badge die óf geen afwijkingen zegt óf hoeveel het er zijn, met de lijst eronder.

Een machine terugzetten op zijn profiel vraag je zelf, en alleen dan: corectl profile apply wordpress.

Zelf een profiel schrijven

Je eigen profielen staan in /etc/corecp/profiles/ en winnen van het ingebouwde profiel met dezelfde naam — je kunt dus veranderen wat "shared" op jouw vloot betekent zonder op ons te wachten. Begin bij een bestaand profiel:

root@web1:~# mkdir -p /etc/corecp/profiles
root@web1:~# corectl profile show shared --yaml > /etc/corecp/profiles/shared-nl.yaml
root@web1:~# nano /etc/corecp/profiles/shared-nl.yaml

Zet het veld name: gelijk aan de bestandsnaam — die twee moeten kloppen. De rest is een lijst die je bewerkt:

name: shared-nl
summary: Ons gedeelde platform, met Node voor de deploy-pipelines
roles: [web, db, mail, dns, ftp]
webserver: nginx_apache
tools: [composer, git, imapsync, node@24, valkey, wp-cli]

Alles wat een profiel noemt wordt gecontroleerd vóórdat er één pakket geïnstalleerd wordt, en je krijgt het in één keer te horen in plaats van één fout per poging:

root@web1:~# corectl profile apply shared-nl --dry-run
corectl: profile shared-nl cannot be applied:
  role "mailserver" does not exist (backup, db, dns, ftp, mail, web)
  tool "kubernetes": unknown tool "kubernetes" — `corectl tool list` names the catalogue

Verder lezen

  • Tools op een server — wat een tool is en hoe de lijst werkt.
  • Eigen serverinstellingen — de instellingen die een profiel meebrengt, en hoe je er later met de hand een verandert. Sinds deze ronde horen daar ook de PHP-FPM-werkprocessen en de kernelinstellingen bij.
  • Een server toevoegen — de wizard waarin het profiel de eerste vraag is.
  • Koppelingen op een server — waar een rol van een klant terechtkomt, en hoe je hem verhuist in plaats van hem in de weg te laten staan.