Il tipo di server è il ruolo che assegni a un server quando lo crei. Il tipo determina cosa installa Vimonto Deploy durante il provisioning, quali porte apre il firewall e quali pagine ha il server in Vimonto Deploy. Non sai quale ti serve? Scegli un App server: esegue tutto su una sola macchina ed è adatto alla maggior parte delle applicazioni.
Gli altri tipi ti permettono di suddividere un'applicazione su più server man mano che cresce: web server dietro un load balancer, worker separati per le queue e server dedicati per database, cache e ricerca, collegati tramite una rete privata.
Quale tipo di server scegliere?
| Tipo | Usalo per | Installa |
|---|---|---|
| App server | Tutto su un solo server. Adatto alla maggior parte delle applicazioni. | Nginx, PHP, un database (facoltativo), Redis, Memcached, Node.js, Supervisor |
| Web server | Servire la tua applicazione, con database e cache su altri server. | Nginx, PHP, Node.js, Supervisor |
| Worker server | Queue worker e altri processi PHP di lunga durata. Non raggiungibile via HTTP. | PHP, Supervisor |
| Server database | Un database per i tuoi app server, web server e worker server. | MySQL, MariaDB o PostgreSQL |
| Server di cache | Redis e Memcached per i tuoi app server, web server e worker server. | Redis, Memcached |
| Server Meilisearch | Un motore di ricerca veloce per la tua applicazione, raggiungibile tramite la rete privata. | Meilisearch |
| Load balancer | Distribuire il traffico di un dominio tra i tuoi app server e web server. | Nginx |
Ogni tipo riceve anche la stessa base: aggiornamenti di Ubuntu, l'utente del server, hardening di SSH, il firewall ufw, fail2ban, aggiornamenti di sicurezza automatici, swap, job pianificati standard e l'agente di monitoring.
Quali pagine ha ciascun tipo?
Un server mostra solo le pagine che hanno senso per ciò che vi è installato.
| Pagina | App | Web | Worker | Database | Cache | Meilisearch | Load balancer |
|---|---|---|---|---|---|---|---|
| Panoramica | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Siti | ✓ | ✓ | – | – | – | – | ✓ |
| Database | ✓¹ | – | – | ✓ | – | – | – |
| Backup | ✓¹ | – | – | ✓ | – | – | – |
| PHP | ✓ | ✓ | ✓ | – | – | – | – |
| Processi | ✓ | ✓ | ✓ | – | – | – | – |
| Scheduler | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Monitoring | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Terminale | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Rete | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Chiavi SSH | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Servizi | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
| Impostazioni | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ | ✓ |
¹ Solo se l'app server è stato creato con un database, non con Nessuno.
App server
L'app server ha tutto: Nginx, PHP (la versione che scegli, con Composer), Node.js e npm, un database, Redis, Memcached e Supervisor per i queue worker. Le porte 80 e 443 sono aperte per i tuoi siti. Database, Redis e Memcached sono in ascolto solo sul server stesso (localhost), quindi non sono raggiungibili dall'esterno.
Puoi creare un app server senza database scegliendo Nessuno in Database, ad esempio quando usi un server database separato. In quel caso non ha le pagine Database e Backup.
Web server
Un web server esegue i tuoi siti come un app server, con Nginx, PHP, Node.js e Supervisor, ma senza database né cache. Collegalo a un server database e a un server di cache tramite una rete privata. Usa più web server dietro un load balancer per gestire più traffico.
Worker server
Un worker server ha PHP e Supervisor per i queue worker e altri processi, e niente Nginx. Il firewall consente solo SSH, quindi non è raggiungibile via HTTP. Usalo per togliere il lavoro pesante delle queue ai tuoi web server.
Server database
Un server database esegue solo MySQL (8.4 LTS o 8.0), MariaDB (11.4 LTS o 10.11 LTS) o PostgreSQL (18, 17 o 16); per questo tipo un database è obbligatorio. A differenza di un app server, il database è in ascolto su tutti gli indirizzi, così gli altri tuoi server possono connettersi. Se il server è in una rete privata, il provisioning consente la porta 3306 (MySQL e MariaDB) o 5432 (PostgreSQL) solo da quella rete. Senza rete privata, il firewall blocca tutto il traffico in entrata verso il database finché non aggiungi una regola per gli indirizzi degli altri tuoi server nella pagina Rete del server.
Il provisioning crea un utente del database con il nome dell'utente del server (vimonto per impostazione predefinita), con tutti i permessi e la password del database mostrata una sola volta, e un database con lo stesso nome. Gestisci database e utenti nella pagina Database e pianifica i backup sul tuo storage.
Server di cache
Un server di cache esegue solo Redis e Memcached. Sono in ascolto su tutti gli indirizzi così gli altri tuoi server possono usarli. Qui Redis funziona senza password, quindi solo il firewall lo tiene chiuso verso internet. Se il server è in una rete privata, il provisioning consente le porte 6379 (Redis) e 11211 (Memcached) solo da quella rete. Senza rete privata nulla può raggiungerli finché non aggiungi una regola per gli indirizzi degli altri tuoi server nella pagina Rete.
Server Meilisearch
Un server Meilisearch esegue il motore di ricerca Meilisearch come servizio di sistema sulla porta 7700, in modalità production. La sua master key viene generata alla creazione del server e mostrata una sola volta, insieme alla password sudo, come Meilisearch master key. Se il server è in una rete privata, il provisioning consente la porta 7700 solo da quella rete; altrimenti aggiungi una regola nella pagina Rete. Imposta l'indirizzo privato del server e la chiave nella tua applicazione (per Laravel Scout: MEILISEARCH_HOST e MEILISEARCH_KEY).
Server in una rete privata
I server database, di cache e Meilisearch che crei in una rete privata ricevono subito le regole del firewall per i loro servizi. I tuoi app server, web server e worker server nella stessa rete possono così connettersi senza altre impostazioni:
| Tipo | Porte consentite dalla rete privata |
|---|---|
| Server database | 3306 (MySQL, MariaDB) o 5432 (PostgreSQL) |
| Server di cache | 6379 (Redis), 11211 (Memcached) |
| Server Meilisearch | 7700 |
Le regole consentono l'intervallo di indirizzi della rete, per esempio 10.0.0.0/16. Se Vimonto Deploy non conosce l'intervallo, usa il /16 attorno all'indirizzo IP privato del server. Trovi le regole nella pagina Rete del server, contrassegnate come Predefinito; puoi rimuoverle o aggiungerne di tue. Internet resta fuori: il firewall blocca tutto l'altro traffico in entrata.
I server senza rete privata, compresa una VPS personale, non ricevono queste regole: aggiungi tu una regola per ogni server che deve accedervi.
Load balancer
Un load balancer esegue solo Nginx, con le porte 80 e 443 aperte, e distribuisce il traffico di un dominio tra i tuoi app server e web server. Non ha PHP. L'unico tipo di sito che puoi crearci è un sito Load balancer (sotto Nuovo sito), e questo tipo di sito può stare solo su un server load balancer.
Nella pagina Bilanciamento del carico del sito scegli:
- il Metodo: Round robin (ogni server a turno, in base al peso), Meno connessioni (il server con meno connessioni aperte) o Hash IP (ogni visitatore resta su un solo server, in base al suo indirizzo IP);
- i server a cui inoltra il traffico: con Aggiungi server scegli un app server o web server attivo della tua organizzazione, con una Porta, un Peso (più alto riceve più traffico) e, se vuoi, come Server di riserva, che riceve traffico solo quando gli altri server non rispondono (non con Hash IP, che Nginx non combina con i server di riserva). Modifica cambia in seguito porta, peso e impostazione di riserva. Il traffico passa dalla rete privata quando entrambi i server sono nella stessa.
Ogni app server ha bisogno di un sito per lo stesso dominio. Il load balancer passa agli app server l'indirizzo IP del visitatore e l'informazione se è arrivato in HTTPS, e i siti su quei server si fidano di queste informazioni solo se arrivano da questo load balancer. Il sito con bilanciamento del carico ha bisogno di un tuo dominio prima che tu aggiunga gli app server, perché questi non possono rispondere per il suo indirizzo on-deploy.link. Finché non hai aggiunto nessun app server, i visitatori ricevono un errore 503. Trovi tutta la configurazione in bilanciamento del carico.
Domande frequenti
Conviene iniziare con un solo app server o con server separati?
Inizia con un solo app server. È la configurazione più semplice ed economica e regge molto traffico. Separa un server database, un server di cache o dei worker server quando un solo server non basta più, o quando vuoi scalare i web server separatamente.
Come comunicano tra loro i server separati?
Mettili nella stessa rete privata quando li crei. I server database, di cache e Meilisearch consentono allora già le loro porte da quella rete (vedi server in una rete privata); per il resto, consenti la porta dall'intervallo di indirizzi della rete nella pagina Rete del server che riceve le connessioni. Nelle impostazioni della tua applicazione usa l'indirizzo IP privato mostrato nella panoramica di ciascun server.
Posso aggiungere un database a un web server in seguito?
Il provisioning installa ciò che serve al tipo quando il server viene creato. Scegli un app server se vuoi un database sulla stessa macchina, oppure crea un server database e collegati a esso.