Cosa installa e configura il provisioning del server

Il provisioning è il lavoro che trasforma un server Ubuntu appena creato in un server pronto per le tue applicazioni. Vimonto Deploy lo esegue subito dopo aver creato un server presso il tuo provider, oppure dopo che hai collegato il tuo VPS. Aggiorna il sistema, crea l'utente del server, mette in sicurezza SSH, attiva il firewall e gli aggiornamenti di sicurezza automatici, e installa il software richiesto dal tipo di server.

Il provisioning gira come un unico task, passo dopo passo, via SSH. Ogni passaggio è uno script bash che gira come root, si ferma al primo errore e si può eseguire di nuovo senza rischi, quindi un provisioning non riuscito si può semplicemente riavviare. Di solito richiede da 5 a 15 minuti.

Come si svolge il provisioning#

Il task raggruppa i suoi passaggi in quattro fasi: Avvio, Protezione in corso, Installazione del software e Completamento.

Un VPS personalizzato salta i passaggi del provider e parte da Attendi che il server accetti SSH. Vedi l'avanzamento nella pagina del server e nella pagina attività, con l'output completo di ogni comando in Dettagli e log. Non devi tenere la pagina aperta.

Mentre il server viene configurato (in creazione, in attesa del suo comando di connessione, in provisioning, o non riuscito in questa fase), la sua panoramica con l'avanzamento è la sua unica pagina: non c'è la barra laterale, e ogni altra pagina del server e dei suoi siti riporta alla panoramica. Le sue Impostazioni si aprono comunque dalla panoramica, così puoi eliminare un server la cui configurazione non è riuscita. La barra laterale torna da sola appena il server è attivo.

Preparare il sistema#

• Verifica che il server usi Ubuntu 24.04 o 26.04, altrimenti si ferma.
• Attende che cloud-init termini, se il provider lo usa.
• Imposta l'hostname sul nome del server (a meno che l'ambiente non gestisca l'hostname da sé) e il fuso orario su UTC.
• Esegue apt-get update e apt-get upgrade.
• Installa i pacchetti di base: software-properties-common, ca-certificates, curl, gnupg, lsb-release, unzip, zip, git, jq, acl, rsync, ufw, fail2ban, unattended-upgrades, cron, logrotate e htop.
• Crea lo swap se il server non ne ha: metà della memoria, almeno 1 GB e al massimo 4 GB, in /swapfile. Gli host che non consentono lo swap (alcuni container) proseguono senza.
• Ottimizza il kernel: vm.swappiness = 10, fs.inotify.max_user_watches = 524288 e net.core.somaxconn = 65535.

L'utente del server e SSH#

Ogni server ha un utente di sistema, vimonto per impostazione predefinita. I tuoi siti, i deploy, i queue worker e i job pianificati girano con questo utente (un sito che crei come isolato riceve un utente Linux proprio; vedi creare un sito).

• L'utente viene creato con una home directory in /home/vimonto ed entra nei gruppi sudo e www-data.
• La sua password sudo viene generata per questo server: 24 lettere e numeri casuali. Viene mostrata una sola volta quando il server viene creato (vedi conservare le password del server).
• ~/.ssh/authorized_keys riceve la chiave di Vimonto Deploy per questo server, le chiavi dell'account scelte alla creazione del server, le chiavi dell'organizzazione e le chiavi che la pagina Chiavi SSH del server mostra già per questo utente. Root accetta le stesse chiavi.
• L'utente riceve una propria chiave Ed25519 (~/.ssh/id_ed25519), la chiave pubblica del server mostrata nella sua panoramica, che può usare per clonare i repository. Le chiavi host SSH di GitHub, GitLab e Bitbucket vengono aggiunte al suo known_hosts.
• SSH viene irrobustito: gli accessi con password e keyboard-interactive sono disattivati, e root può accedere solo con una chiave (PermitRootLogin prohibit-password).

I deploy possono ricaricare PHP-FPM e Nginx e controllare Supervisor senza password; per tutto il resto l'utente ha bisogno di sudo con la password sudo.

La chiave SSH del server in Vimonto Deploy#

Separatamente, ogni server riceve in Vimonto Deploy una propria coppia di chiavi Ed25519 quando viene creato. Vimonto Deploy la usa per connettersi per il provisioning, i deploy e tutto il resto; la chiave privata è conservata cifrata e non viene mai condivisa tra server. La prima connessione registra la chiave host SSH del server, e Vimonto Deploy rifiuta di connettersi se quella chiave cambia.

Firewall e fail2ban#

Il firewall ufw viene azzerato e configurato per bloccare tutto il traffico in entrata e consentire tutto il traffico in uscita. Consente:

• la porta SSH (22, o la porta che hai inserito per un VPS personalizzato), e la porta su cui sshd è effettivamente in ascolto se è diversa (per i server dietro NAT);
• le porte 80 e 443 su app server, web server e load balancer;
• sui server database, di cache e Meilisearch in una rete privata, le loro porte di servizio, solo dall'intervallo di indirizzi di quella rete: 3306 (MySQL, MariaDB) o 5432 (PostgreSQL) su un server database, 6379 (Redis) e 11211 (Memcached) su un server di cache, e 7700 su un server Meilisearch. Senza rete privata non viene aggiunta nessuna regola del genere e queste porte restano chiuse.

fail2ban viene attivato per bloccare gli indirizzi che continuano a fallire l'accesso via SSH. In seguito gestisci le regole firewall nella pagina rete del server, dove sono elencate le regole del provisioning. Per spostare SSH su un'altra porta in seguito, cambia la Porta SSH nelle impostazioni del server: la regola firewall e fail2ban la seguono.

Aggiornamenti di sicurezza automatici#

unattended-upgrades viene attivato: gli elenchi dei pacchetti vengono aggiornati e gli aggiornamenti di sicurezza installati ogni giorno, e i pacchetti vecchi vengono rimossi ogni settimana.

Nginx#

Su app server, web server e load balancer:

• Nginx gira con l'utente del server e nasconde la sua versione (server_tokens off).
• Sono consentite richieste fino a 64 MB (client_max_body_size 64M), e la compressione gzip è attiva per testo, CSS, JavaScript, JSON, XML e SVG.
• Il sito predefinito viene rimosso. Un server catch-all risponde alle richieste per hostname sconosciuti senza restituire nulla (stato 444), invece di mostrare il primo sito.
• La configurazione viene verificata con nginx -t prima di riavviare Nginx.

In seguito ogni sito riceve una propria configurazione; vedi Nginx.

PHP#

Su app, web e worker server, la versione PHP che hai scelto (da 8.1 a 8.5) viene installata dal repository ondrej/php, con PHP-FPM e queste estensioni: bcmath, cli, curl, fpm, gd, igbinary, imagick, intl, mbstring, memcached, msgpack, mysql, pgsql, readline, redis, soap, sqlite3, xml e zip.

• PHP-FPM gira con l'utente del server, con un massimo di 5 processi.
• Impostazioni PHP-FPM: memory_limit 512 MB, upload fino a 64 MB, max_execution_time 60 secondi, max_input_vars 1000, OPcache attivo, expose_php disattivato, fuso orario UTC.
• La riga di comando riceve memory_limit = 1G.
• Composer viene installato in /usr/local/bin/composer, dopo aver verificato la firma del suo installer.

Modifica queste impostazioni e installa altre versioni nella pagina PHP.

Node.js#

App server e web server ricevono Node.js 22 con npm, da NodeSource, per compilare gli asset front-end durante i deploy.

Database#

Gli app server (a meno che tu non abbia scelto Nessuno) e i server database ricevono il database che hai scelto:

Per ogni database:

• Viene creato un utente del database con il nome dell'utente del server (vimonto), con tutti i diritti e la password del database: 32 lettere e numeri casuali, mostrata una sola volta. Viene creato anche un database con lo stesso nome.
• MySQL e MariaDB usano utf8mb4 con utf8mb4_unicode_ci, UTC, e fino a 300 connessioni. L'utente root non ha password e può accedere solo dal server stesso.
• PostgreSQL usa UTC e fino a 300 connessioni, e accetta l'accesso con password (scram-sha-256); è il firewall a decidere chi può connettersi.
• Su un app server il database è in ascolto solo sul server stesso. Su un server database è in ascolto su tutti gli indirizzi, così gli altri tuoi server possono connettersi: in una rete privata il firewall li consente già (vedi sopra), altrimenti una volta che aggiungi una regola per loro.

Il provisioning verifica anche che la versione installata sia quella che hai scelto. Gestisci database e utenti nella pagina database.

Redis e Memcached#

App server e server cache ricevono Redis e Memcached. Su un app server sono in ascolto solo sul server stesso. Su un server cache sono in ascolto su tutti gli indirizzi e Redis gira senza protected mode, per gli altri tuoi server; in una rete privata il firewall consente le loro porte solo da quella rete.

Meilisearch#

Un server Meilisearch riceve l'ultimo binario di Meilisearch, che gira con un proprio utente di sistema meilisearch sotto systemd, in modalità production sulla porta 7700, con i dati in /var/lib/meilisearch. La master key è la password generata mostrata una sola volta come Meilisearch master key.

Supervisor#

App, web e worker server ricevono Supervisor, che mantiene in esecuzione i tuoi queue worker e gli altri processi.

Completamento e agent di monitoring#

Gli ultimi passaggi:

• aggiungono due job pianificati standard che girano come root: Aggiorna Composer (ogni notte) e Rimuovi i pacchetti inutilizzati (ogni settimana);
• rimuovono i pacchetti non più necessari e puliscono la cache dei pacchetti;
• registrano la versione di Ubuntu e la chiave pubblica del server;
• installano l'agent di monitoring: un piccolo script bash che cron esegue ogni minuto. Misura CPU, carico, memoria, disco e rete, e li invia a Vimonto Deploy. Sul server non c'è nulla in ascolto per questo. Vedi monitoring.

Se fallisce solo l'installazione dell'agent, il server è comunque attivo; puoi installare di nuovo l'agent nella pagina Monitoring.

Quando tutto è finito, il server diventa Attivo e ciò che è stato installato compare nelle sue pagine: le regole firewall, la versione PHP, il database e il suo utente, le chiavi SSH e i job pianificati.

I membri che vedono il server ricevono la notifica Server pronto, oppure Configurazione di un server non riuscita se il provisioning si interrompe con un errore, tramite i canali scelti nelle notifiche.

Cosa succede se il provisioning non riesce?#

Quando un passaggio non riesce, il task si ferma, il server riceve lo stato Non riuscito e la sua pagina mostra Configurazione non riuscita con il passaggio e il relativo exit code. L'output in Dettagli e log mostra cosa è andato storto.

1. Leggi l'output del passaggio non riuscito. Cause comuni: un mirror dei pacchetti temporaneamente irraggiungibile, un server che non si avvia o non accetta SSH entro 15 minuti, un firewall del provider che blocca SSH, o un sistema che non è Ubuntu 24.04 o 26.04.
2. Risolvi la causa, se dipende da te.
3. Scegli Riprova nella pagina del server. Ti serve il permesso di creare server.

Il provisioning riparte allora dall'inizio. È sicuro: un server già creato presso il provider non viene creato di nuovo, ogni passaggio controlla cosa è già stato fatto, e apt-get attende e riprova quando i lock sono tenuti dagli aggiornamenti automatici. Se avevi già confermato le password, vengono generate nuove password sudo e del database, mostrate di nuovo una sola volta. Vengono installate le stesse chiavi SSH del primo tentativo, anche se nel frattempo una chiave dell'account è stata eliminata.

Domande frequenti#

Quanto dura il provisioning?#

Di solito da 5 a 15 minuti in tutto. L'aggiornamento di Ubuntu e l'installazione del database richiedono la maggior parte del tempo; un server cache o un load balancer è più veloce di un app server.

Posso vedere i comandi eseguiti?#

Sì. L'output di ogni passaggio è nel task, in Dettagli e log nella pagina del server o nella pagina attività.

Come si chiama l'utente di sistema?#

vimonto per impostazione predefinita. Il nome viene salvato per ogni server al momento della creazione.

Il provisioning modifica il mio server dopo che è terminato?#

No. Dopo il provisioning, le modifiche avvengono solo quando le fai tu o un deploy, oltre agli aggiornamenti di sicurezza automatici di Ubuntu e ai job pianificati standard.