Sitefuncties: Horizon, Reverb, Pulse, WordPress en meer

Sitefuncties zijn kant-en-klare set-ups voor de tools die je framework gebruikt, zoals Laravel Horizon, Reverb of de cron van WordPress. Je zet ze aan vanuit het frameworkmenu in de siteheader, en Vimonto Deploy richt alles in wat de tool op de server nodig heeft: Supervisor-processen, cronjobs, Nginx-directives en .env-waarden.

Het venster van elke functie laat precies zien wat er wordt ingericht voordat je de functie aanzet, en functies worden waar nodig na elke deploy herstart. Het menu, en de knop Openen ernaast, verschijnen zodra de eerste inrichting van de site klaar is en de eerste versie live staat.

Het functiemenu openen#

Het menu staat in de siteheader en heet naar het framework van de site, bijvoorbeeld Laravel of WordPress. Het opent met de functies van het framework, zoals Laravel-functies, met een groene stip bij de functies die aan staan en een telling zoals 2 van 7 aan.

Vimonto Deploy leest bij elke deploy de packages in je composer.json en package.json. Functies waarvan je app het package gebruikt, zijn gemarkeerd met In je code en staan bovenaan, samen met de functies die al aan staan; de andere staan achter Alles tonen (nog …, niet gevonden in je code). Tot de eerste deploy worden alle functies getoond.

Een functie aan- of uitzetten#

1. Klik op de functie in het menu om het venster te openen.
2. Vul de instellingen in, als die er zijn.
3. Controleer Wat we instellen en We zetten in je .env. Sleutels waarvan de waarde verandert, zijn gemarkeerd met verandert.
4. Klik op Aanzetten.

Aanzetten draait als achtergrondtaak die je in de siteheader kunt volgen. Mislukt het, dan toont de functie Mislukt in het menu en krijg je een melding; open haar en klik op Opslaan om het opnieuw te proberen, of op Opnieuw proberen bij een functie zonder instellingen, zoals de Planner of Pulse. Beide passen dezelfde instellingen opnieuw toe. Om de instellingen van een functie die aan staat te wijzigen, open je haar, pas je ze aan en klik je op Opslaan. Om haar uit te zetten, open je haar en klik je op Uitzetten: haar processen, cronjobs en Nginx-directives worden verwijderd. Waarden die ze in de .env heeft gezet, blijven staan.

Functies hebben een site nodig die is ingericht en, voor de meeste, gedeployed: hun commando's draaien in de live release. Functies met Nginx-directives hebben de gegenereerde Nginx-configuratie van de site nodig, of een eigen configuratie die de include-regel voor extra directives behoudt.

Welke functies zijn er?#

Processen draaien onder Supervisor als de gebruiker van de site en verschijnen op de pagina wachtrijen en scheduler met een badge Via …. Cronjobs draaien als de gebruiker van de site.

Laravel-functies#

Planner#

Draait je geplande commando's: een cron-regel voert elke minuut php artisan schedule:run uit in de live release. Dit is dezelfde schakelaar als Aanzetten op de pagina wachtrijen en scheduler.

Horizon#

Verwerkt je Redis-queues met Laravel Horizon: één Supervisor-programma draait php artisan horizon, dat elke worker start die je config/horizon.php beschrijft.

• Instelling: Langste job (seconden), standaard 3600. Bij een deploy krijgen lopende jobs zo lang de tijd om af te ronden voordat het proces wordt gestopt.
• Na elke deploy: php artisan horizon:terminate, zodat Horizon zijn jobs afmaakt en Supervisor het op de nieuwe code start.
• .env: QUEUE_CONNECTION=redis.
• Link: het Horizon-dashboard op /horizon.

Het venster waarschuwt je als de site ook eigen queue workers heeft (verwijder die, zodat jobs niet twee keer worden opgepakt), en als de server geen Redis heeft (laat REDIS_HOST dan wijzen naar een cacheserver).

Reverb#

Draait Laravel Reverb, de WebSocket-server voor broadcasting, op een eigen WebSocket-adres.

• WebSocket-adres: standaard ws. plus het domein van de site, zoals ws.shop.example.com.
• Lokale poort: de poort waarop Reverb luistert, alleen op de server zelf, vanaf 8080. Elke app op de server heeft een eigen poort nodig.

Als je het aanzet, doet Vimonto Deploy het volgende:

• het draait php artisan reverb:start --host=127.0.0.1 --port=… onder Supervisor;
• het voegt het WebSocket-adres toe aan de namen van de site, en voegt Nginx-regels toe die /app/ (WebSocket-verbindingen) en /apps/ (de HTTP API van Reverb) doorgeven aan Reverb;
• het maakt het DNS-record aan als het adres op on-deploy.link staat, of als het domein van de site wordt beheerd door een gekoppelde DNS-integratie; een record daar dat ergens anders naartoe wijst en niet door Vimonto Deploy is gemaakt, blijft staan, en de taak meldt dat. Anders toont het venster het A-record dat je moet aanmaken, wijzend naar het IP-adres van de server;
• het vraagt een nieuw Let's Encrypt-certificaat aan met het WebSocket-adres erin als de site er al een heeft en de naam naar de server wijst. Anders vraag je een nieuw certificaat aan onder domeinen en SSL zodra het DNS-record er staat;
• het voert na elke deploy php artisan reverb:restart uit.

Het zet deze sleutels in de .env. De app-ID, key en secret van Reverb worden hergebruikt als je .env die al heeft, en anders gegenereerd:

BROADCAST_CONNECTION=reverb
REVERB_APP_ID=…
REVERB_APP_KEY=…
REVERB_APP_SECRET=…
REVERB_HOST=ws.shop.example.com
REVERB_PORT=443
REVERB_SCHEME=https
REVERB_SERVER_HOST=127.0.0.1
REVERB_SERVER_PORT=8080
VITE_REVERB_APP_KEY="${REVERB_APP_KEY}"
VITE_REVERB_HOST="${REVERB_HOST}"
VITE_REVERB_PORT="${REVERB_PORT}"
VITE_REVERB_SCHEME="${REVERB_SCHEME}"

Zonder HTTPS op de site is REVERB_PORT 80 en REVERB_SCHEME http. Deploy daarna opnieuw, zodat je frontend-build de VITE_-waarden oppikt. Zodra Reverb aan staat, toont het venster het volledige WebSocket-adres waarmee je clients verbinden.

Pulse#

Houdt php artisan pulse:check draaiende, zodat het dashboard van Laravel Pulse de CPU, het geheugen en de schijf van de server toont. Het voert na elke deploy pulse:restart uit en linkt naar het Pulse-dashboard op /pulse.

Inertia SSR#

Rendert Inertia-pagina's op de server, voor snellere eerste laadtijden en betere resultaten in zoekmachines. Het draait php artisan inertia:start-ssr onder Supervisor en na elke deploy inertia:stop-ssr, zodat de server-renderer op de nieuwe bundle herstart.

• Bouw de SSR-bundle ook in je deployscript, bijvoorbeeld npm run build && npx vite build --ssr. Het venster waarschuwt je als het daar geen --ssr vindt.
• De server heeft Node.js nodig (app- en webservers hebben het).
• De SSR-server luistert op de poort van Inertia, 13714, dus één site per server kan het gebruiken.

Nightwatch#

Houdt de agent van Laravel Nightwatch draaiende (php artisan nightwatch:agent), zodat je app rapporteert aan Nightwatch.

• Instelling: Nightwatch-token, van je applicatie op nightwatch.laravel.com. Laat het later leeg om het huidige token te houden.
• .env: NIGHTWATCH_TOKEN, gemaskeerd getoond in het venster.

Symfony-functies#

Messenger-workers#

Draait bin/console messenger:consume voor je transports van Symfony Messenger, met --time-limit=3600 --env=prod.

• Transports: gescheiden door spaties, op volgorde van prioriteit, zoals async scheduler_default. Standaard: async.
• Processen: hoeveel workers naast elkaar draaien (1 tot 20).
• Na elke deploy: messenger:stop-workers, zodat Supervisor ze op de nieuwe code start.

WordPress-functies#

De WordPress-functies gebruiken WP-CLI, dat Vimonto Deploy op de server installeert (als /usr/local/bin/wp) zodra een functie het voor het eerst nodig heeft.

Echte cron voor WordPress#

WordPress draait zijn geplande taken normaal gesproken wanneer iemand een pagina bezoekt. Op rustige sites worden ze dan overgeslagen en drukke sites worden er trager van. Echte cron zet DISABLE_WP_CRON in wp-config.php en voert in plaats daarvan elke minuut wp cron event run --due-now uit vanuit een echte cronjob. Uitzetten verwijdert de constante weer.

Redis-objectcache voor WordPress#

Installeert en activeert de plugin Redis Object Cache en zet hem aan, zodat WordPress de database niet bij elk request dezelfde vragen stelt. Er is Redis op de server voor nodig; op servers zonder Redis is de functie niet beschikbaar. Uitzetten schakelt de cache uit en deactiveert de plugin.

Beveiliging voor WordPress#

Sluit de deuren waardoor aanvallen op WordPress meestal binnenkomen:

• Nginx weigert xmlrpc.php;
• Nginx weigert PHP-bestanden in wp-content/uploads uit te voeren;
• DISALLOW_FILE_EDIT zet de bestandseditor voor thema's en plugins in het dashboard uit.

Onderhoud en toegang#

Onderhoudsmodus#

Toont bezoekers een onderhoudspagina tot je hem uitzet. Zolang hij aan staat, toont de siteheader Onderhoudsmodus; klik erop om het venster te openen.

• Laravel en Statamic: voert php artisan down uit met een secret en --retry=60. Het venster toont een Omzeillink (zet een cookie) waarmee je de site gewoon kunt bekijken. Elke keer dat je hem aanzet, is het secret nieuw, dus een oude link werkt dan niet meer. De status staat in storage/, dat tussen releases wordt gedeeld, dus hij blijft bij deploys behouden.
• WordPress: voert wp maintenance-mode activate uit.

Wachtwoordbeveiliging#

Vraagt om een gebruikersnaam en wachtwoord (HTTP basic authentication) voordat iemand de site ziet: handig voor stagingsites en previews op het adres op on-deploy.link.

• Gebruikersnaam: standaard preview; letters, cijfers, ., _ en -.
• Wachtwoord: minstens 8 tekens. Alleen een bcrypt-hash wordt opgeslagen. Laat het later leeg om het huidige wachtwoord te houden.

Let's Encrypt kan de site nog steeds bereiken om certificaten uit te geven en te vernieuwen terwijl ze beveiligd is. Op een load-balanced site is wachtwoordbeveiliging de enige functie, en beveiligt ze alle app-servers achter de balancer in één keer.

Wil je alleen een pad beveiligen, zoals /admin, of meerdere mensen een eigen login geven, gebruik dan beveiligingsregels. Een beveiligingsregel voor de hele site en wachtwoordbeveiliging kunnen niet tegelijk aanstaan.

Veelgestelde vragen#

Wat betekent "In je code"?#

Het package van de functie staat sinds de laatste deploy in je composer.json of package.json, bijvoorbeeld laravel/horizon voor Horizon. Je kunt ook functies aanzetten die niet zijn gevonden; open Alles tonen om ze te zien.

Verwijdert het uitzetten van een functie haar .env-waarden?#

Nee. Processen, cronjobs en Nginx-directives worden verwijderd, maar waarden die de functie in de .env heeft gezet, blijven staan. Pas ze aan op de pagina omgeving als je ze niet meer nodig hebt.

Waarom is een functie niet beschikbaar?#

Het venster zegt waarom, bijvoorbeeld Er draait geen Redis op deze server., Deze server heeft geen Node.js., of dat de site een eigen Nginx-configuratie heeft zonder de include voor extra directives.

Kan ik het proces van een functie zelf aanpassen?#

Niet rechtstreeks. Processen en cronjobs die een functie maakt, worden alleen via de functie gewijzigd en verwijderd, zodat ze altijd overeenkomen met haar instellingen. Voeg voor al het andere je eigen queue workers of serverprocessen toe.