Funzionalità del sito: Horizon, Reverb, Pulse e WordPress

Le funzionalità del sito sono configurazioni pronte per gli strumenti che usa il tuo framework, come Laravel Horizon, Reverb o il cron di WordPress. Le attivi dal menu del framework nell'intestazione del sito, e Vimonto Deploy configura sul server tutto ciò di cui lo strumento ha bisogno: processi Supervisor, cron job, direttive Nginx e valori nel .env. Il menu, e il pulsante Apri accanto, compaiono quando la prima configurazione del sito è finita e la sua prima versione è online.

La finestra di ogni funzionalità mostra esattamente cosa verrà configurato prima che tu la attivi, e le funzionalità vengono riavviate dopo ogni deploy quando serve.

Aprire il menu delle funzionalità#

Il menu si trova nell'intestazione del sito e porta il nome del framework del sito, per esempio Laravel o WordPress. Si apre con le funzionalità del framework, come Funzionalità Laravel, con un punto verde per quelle attive e un conteggio come 2 di 7 attive.

A ogni deploy Vimonto Deploy legge i pacchetti nei tuoi composer.json e package.json. Le funzionalità il cui pacchetto è usato dalla tua app sono contrassegnate con Nel tuo codice ed elencate per prime, insieme alle funzionalità già attive; le altre sono sotto Mostra tutto (altre … non trovate nel tuo codice). Fino al primo deploy vengono elencate tutte le funzionalità.

Attivare o disattivare una funzionalità#

1. Fai clic sulla funzionalità nel menu per aprirne la finestra.
2. Compila le sue impostazioni, se ne ha.
3. Controlla Cosa configuriamo e Impostiamo nel tuo .env. Le chiavi il cui valore cambia sono contrassegnate con cambia.
4. Fai clic su Attiva.

L'attivazione avviene come task in background che puoi seguire nell'intestazione del sito. Se non riesce, la funzionalità mostra Non riuscito nel menu e ricevi una notifica; aprila e fai clic su Salva per riprovare, oppure su Riprova per una funzionalità senza impostazioni, come lo Scheduler o Pulse. Entrambi applicano di nuovo le stesse impostazioni. Per modificare le impostazioni di una funzionalità attiva, aprila, modificale e fai clic su Salva. Per disattivarla, aprila e fai clic su Disattiva: i suoi processi, cron job e direttive Nginx vengono rimossi. I valori che ha impostato nel .env restano.

Le funzionalità richiedono un sito configurato e, per la maggior parte, già con un deploy: i loro comandi girano nella release attiva. Le funzionalità con direttive Nginx richiedono la configurazione Nginx generata del sito, oppure una configurazione personalizzata che mantenga la riga include per le direttive aggiuntive.

Quali funzionalità ci sono?#

I processi girano sotto Supervisor con l'utente del sito e compaiono nella pagina queue e scheduler con un badge Tramite …. I cron job girano con l'utente del sito.

Funzionalità Laravel#

Scheduler#

Esegue i tuoi comandi pianificati: una voce cron esegue php artisan schedule:run ogni minuto nella release attiva. È lo stesso interruttore di Attiva nella pagina queue e scheduler.

Horizon#

Esegue le tue queue Redis con Laravel Horizon: un programma Supervisor esegue php artisan horizon, che avvia tutti i worker descritti nel tuo config/horizon.php.

• Impostazione: Job più lungo (secondi), 3600 di default. A un deploy, i job in corso hanno questo tempo per terminare prima che il processo venga fermato.
• Dopo ogni deploy: php artisan horizon:terminate, così Horizon completa i suoi job e Supervisor lo riavvia sul nuovo codice.
• .env: QUEUE_CONNECTION=redis.
• Link: la Dashboard di Horizon su /horizon.

La finestra ti avvisa quando il sito ha anche queue worker propri (rimuovili, così i job non vengono presi in carico due volte) e quando il server non ha Redis (punta REDIS_HOST a un server di cache).

Reverb#

Esegue Laravel Reverb, il server WebSocket per il broadcasting, su un proprio indirizzo WebSocket.

• Indirizzo WebSocket: di default ws. più il dominio del sito, per esempio ws.shop.example.com.
• Porta locale: la porta su cui Reverb è in ascolto, solo sul server stesso, da 8080 in su. Ogni app sul server ne ha bisogno di una propria.

Quando la attivi, Vimonto Deploy:

• esegue php artisan reverb:start --host=127.0.0.1 --port=… sotto Supervisor;
• aggiunge l'indirizzo WebSocket ai nomi del sito e aggiunge regole Nginx che passano a Reverb /app/ (connessioni WebSocket) e /apps/ (l'API HTTP di Reverb);
• crea il record DNS quando l'indirizzo è su on-deploy.link, oppure quando il dominio del sito è gestito da un'integrazione DNS collegata; un record lì che punta altrove e che Vimonto Deploy non ha creato non viene toccato, e il task lo dice. Altrimenti la finestra indica il record A da creare, che punta all'indirizzo IP del server;
• richiede un nuovo certificato Let's Encrypt che include l'indirizzo WebSocket quando il sito ne ha già uno e il nome punta al server. Altrimenti richiedi un nuovo certificato in domini e SSL quando il record DNS è pronto;
• esegue php artisan reverb:restart dopo ogni deploy.

Imposta queste chiavi nel .env, riutilizzando l'app ID, la key e il secret di Reverb se il tuo .env li contiene già, e generandoli altrimenti:

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}"

Senza HTTPS sul sito, REVERB_PORT è 80 e REVERB_SCHEME è http. Dopo, fai di nuovo il deploy, così la build del frontend recepisce i valori VITE_. Quando Reverb è attivo, la finestra mostra l'Indirizzo WebSocket completo a cui si collegano i tuoi client.

Pulse#

Mantiene in esecuzione php artisan pulse:check, così la dashboard di Laravel Pulse mostra CPU, memoria e disco del server. Esegue pulse:restart dopo ogni deploy e rimanda alla Dashboard di Pulse su /pulse.

Inertia SSR#

Esegue il rendering delle pagine Inertia sul server, per un primo caricamento più veloce e risultati migliori nei motori di ricerca. Esegue php artisan inertia:start-ssr sotto Supervisor e inertia:stop-ssr dopo ogni deploy, così il renderer lato server si riavvia sul nuovo bundle.

• Genera il bundle SSR anche nel tuo script di deploy, per esempio npm run build && npx vite build --ssr. La finestra ti avvisa quando non vi trova --ssr.
• Il server ha bisogno di Node.js (gli app server e i web server lo hanno).
• Il server SSR è in ascolto sulla porta di Inertia, 13714, quindi può usarlo un solo sito per server.

Nightwatch#

Mantiene in esecuzione l'agent di Laravel Nightwatch (php artisan nightwatch:agent), così la tua app invia i dati a Nightwatch.

• Impostazione: Token di Nightwatch, dalla tua applicazione su nightwatch.laravel.com. In seguito lascialo vuoto per mantenere il token attuale.
• .env: NIGHTWATCH_TOKEN, mostrato mascherato nella finestra.

Funzionalità Symfony#

Worker di Messenger#

Esegue bin/console messenger:consume per i tuoi transport di Symfony Messenger, con --time-limit=3600 --env=prod.

• Transport: separati da spazi, in ordine di priorità, per esempio async scheduler_default. Default: async.
• Processi: quanti worker girano in parallelo (da 1 a 20).
• Dopo ogni deploy: messenger:stop-workers, così Supervisor li riavvia sul nuovo codice.

Funzionalità WordPress#

Le funzionalità WordPress usano WP-CLI, che Vimonto Deploy installa sul server (come /usr/local/bin/wp) la prima volta che una funzionalità ne ha bisogno.

Cron reale per WordPress#

Normalmente WordPress esegue i suoi task pianificati quando qualcuno visita una pagina, il che li salta sui siti poco visitati e rallenta quelli molto trafficati. Cron reale imposta DISABLE_WP_CRON in wp-config.php ed esegue invece wp cron event run --due-now ogni minuto da un vero cron job. Disattivandolo, la costante viene rimossa.

Cache degli oggetti Redis per WordPress#

Installa e attiva il plugin Redis Object Cache e abilita la cache, così WordPress smette di porre al database le stesse domande a ogni richiesta. Richiede Redis sul server; la funzionalità non è disponibile sui server che non lo hanno. Disattivandola, la cache viene disabilitata e il plugin disattivato.

Hardening per WordPress#

Chiude le porte da cui di solito arrivano gli attacchi a WordPress:

• Nginx blocca xmlrpc.php;
• Nginx si rifiuta di eseguire file PHP in wp-content/uploads;
• DISALLOW_FILE_EDIT disattiva l'editor dei file di temi e plugin nella dashboard.

Manutenzione e accesso#

Modalità manutenzione#

Mostra ai visitatori una pagina di manutenzione finché non la disattivi. Mentre è attiva, l'intestazione del sito mostra Modalità manutenzione; fai clic per aprire la finestra.

• Laravel e Statamic: esegue php artisan down con un secret e --retry=60. La finestra mostra un Link di bypass (imposta un cookie) che ti permette di vedere il sito come al solito. Ogni volta che la attivi il secret è nuovo, quindi un vecchio link smette di funzionare. Lo stato è conservato in storage/, condiviso tra le release, quindi sopravvive ai deploy.
• WordPress: esegue wp maintenance-mode activate.

Protezione con password#

Chiede un nome utente e una password (autenticazione HTTP basic) prima che chiunque veda il sito: utile per i siti di staging e le anteprime sull'indirizzo on-deploy.link.

• Nome utente: preview di default; lettere, numeri, ., _ e -.
• Password: almeno 8 caratteri. Viene salvato solo un hash bcrypt. In seguito lasciala vuota per mantenere la password attuale.

Let's Encrypt può comunque raggiungere il sito per emettere e rinnovare i certificati mentre è protetto. Su un sito con bilanciamento del carico, la protezione con password è l'unica funzionalità, e protegge in un colpo solo tutti gli app server dietro il load balancer.

Per proteggere solo un percorso, come /admin, o dare a più persone un proprio accesso, usa invece le regole di sicurezza. Una regola di sicurezza per tutto il sito e la protezione con password non possono essere attive insieme.

Domande frequenti#

Cosa significa "Nel tuo codice"?#

Il pacchetto della funzionalità è presente nel tuo composer.json o package.json all'ultimo deploy, per esempio laravel/horizon per Horizon. Puoi comunque attivare funzionalità non trovate; apri Mostra tutto per vederle.

Disattivare una funzionalità rimuove i suoi valori dal .env?#

No. Processi, cron job e direttive Nginx vengono rimossi, ma i valori che la funzionalità ha impostato nel .env restano. Modificali nella pagina ambiente se non ti servono più.

Perché una funzionalità non è disponibile?#

La finestra spiega il motivo, per esempio Su questo server non c'è Redis., Questo server non ha Node.js., oppure che il sito ha una configurazione Nginx propria senza l'include per le direttive aggiuntive.

Posso modificare io il processo di una funzionalità?#

Non direttamente. I processi e i cron job creati da una funzionalità si modificano e si rimuovono solo tramite la funzionalità, così corrispondono sempre alle sue impostazioni. Per tutto il resto aggiungi i tuoi queue worker o i tuoi processi del server.