Indice dei contenuti
Se utilizzi una macchina virtuale su Microsoft Azure, saprai che la maggior parte di queste VM vengono fornite con un cosiddetto disco temporaneo (solitamente montato in /mnt/). Si tratta di uno storage velocissimo, basato su SSD o NVMe, con IOPS elevatissimi e latenze bassissime... ma con un limite importante: i suoi contenuti sono effimeri. Al riavvio, o in caso di deallocazione della VM, tutto quello che contiene viene perso.
Potrebbe sembrare un problema, ma in realtà è un’opportunità perfetta: quel disco è ideale per cache, file temporanei, sessioni PHP, directory di upload e altro ancora. In altre parole, tutto ciò che deve essere scritto e/o letto con la maggiore efficienza possibile e che, nel contempo, può essere eliminato senza problemi ad ogni reboot. È proprio partendo da questa importante premessa che ho deciso di realizzare azure-tempdisk-bootstrap.
/mnt
Cos’è e a cosa serve
azure-tempdisk-bootstrap è uno script open source (con relativa unit di systemd) che ricrea in automatico, a ogni avvio della VM, le directory necessarie su /mnt, impostando i permessi corretti e assicurandosi che siano sempre pronte all’uso.
Ecco le cartelle che prepara:
/mnt/nginx/fastcgi/– cache FastCGI di Nginx/mnt/nginx/proxy/– cache reverse proxy di Nginx/mnt/nginx/temp/– file temporanei Nginx/mnt/php/sessions/– file di sessione PHP/mnt/php/uploads/– directory temporanea per gli upload PHP/mnt/dotnet/temp/– directory temporanea per ASP.NET Core/mnt/wordpress/– cache ed esportazioni di WordPress
In questo modo non dovrai più creare manualmente queste directory a ogni riavvio, né rischiare che Nginx o PHP vadano in errore per mancanza di path.
Perché è importante
Spostare le cache e i file temporanei sul disco temporaneo di Azure significa sfruttare la memoria più veloce disponibile sulla VM, senza consumare il disco di sistema o i dischi gestiti.
Il risultato è:
- Caricamenti più rapidi per le pagine servite da cache
- Meno stress sul disco OS o dati (meno rischio di colli di bottiglia sugli IOPS)
- Prestazioni migliori a costo zero
Ovviamente, il disco non è persistente: non va usato per database o log critici, ma per dati effimeri è perfetto.
Come scaricarlo e installarlo
Il progetto può essere scaricato gratuitamente da GitHub. All’interno troverai lo script e i file di configurazione. Ecco i passi rapidi per installarlo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
# 1) Installare lo script sudo install -m 0755 scripts/azure-tempdisk-bootstrap.sh \ /usr/local/sbin/azure-tempdisk-bootstrap.sh # 2) Installare il servizio systemd sudo install -m 0644 systemd/azure-tempdisk-bootstrap.service \ /etc/systemd/system/azure-tempdisk-bootstrap.service # 3) Ricaricare systemd ed abilitare il servizio sudo systemctl daemon-reload sudo systemctl enable azure-tempdisk-bootstrap.service sudo systemctl start azure-tempdisk-bootstrap.service # 4) Verificare che le cartelle siano state create ls -ld /mnt/nginx/* /mnt/php/* /mnt/dotnet/temp /mnt/wordpress |
Da questo momento in poi, a ogni reboot della VM le directory verranno ricreate in automatico, sempre pronte all’uso.
Nginx: configurazione manuale o semi-automatica
Hai due possibilità per configurare Nginx a usare il disco temporaneo:
Configurazione manuale (per ambienti complessi)
Se gestisci molti siti con esigenze diverse, ti conviene modificare direttamente i file server { }, definendo proxy_cache_path e fastcgi_cache_path
in base alle necessità di ciascun sito. Avrai così il massimo controllo.
Configurazione semi-automatica (più semplice)
Se invece ospiti pochi siti o vuoi un setup rapido, nel pacchetto troverai il file conf/nginx/azure-tempdisk-cache.conf. Basta copiarlo in /etc/nginx/conf.d/ e avrai subito cache e temp path su /mnt.
PHP e .NET
Per PHP ti basta modificare il php.ini così:
|
1 2 3 4 |
session.save_path = "/mnt/php/sessions" upload_tmp_dir = "/mnt/php/uploads" |
Per .NET, invece, basta impostare la variabile d’ambiente TMPDIR su /mnt/dotnet/temp all’interno della systemd unit.
Perché un servizio systemd invece di un semplice script all’avvio?
Una delle domande più frequenti è: perché abbiamo scelto di fornire un servizio systemd dedicato invece di aggiungere lo script di bootstrap a rc.local, cron @reboot o meccanismi simili?
La risposta riguarda principalmente affidabilità e tempistica:
- Tempistica del mount
Su Azure, il disco effimero (/mnt) viene montato dall’Azure Linux Agent (waagent) o da cloud-init dopo l’inizializzazione di base del sistema.
Se lo script parte troppo presto,/mntpotrebbe essere ancora vuoto (o una semplice directory), e tutta la configurazione fallirebbe silenziosamente. - Gestione esplicita delle dipendenze
Consystemdpossiamo dichiarareRequiresMountsFor=/mnteAfter=local-fs.target, assicurando che il servizio venga eseguito solo quando il disco effimero è correttamente montato e disponibile. - Idempotenza e sicurezza
Il servizio gira in modalitàoneshoted esce dopo aver creato directory e permessi.systemdgarantisce che venga eseguito esattamente una volta per boot e nell’ordine corretto. - Integrazione con altri servizi
DichiarandoBefore=nginx.service(o altri servizi), ci assicuriamo che Nginx, PHP-FPM o le app .NET non vengano mai avviate senza che le loro directory temporanee/cache siano già presenti. - Manutenibilità
Usaresystemdmantiene tutto nello stesso contesto degli altri servizi di sistema, rendendo semplice controllare i log conjournalctl, abilitare/disabilitare il bootstrap o aggiornare lo script.
In sintesi: uno script lanciato all’avvio è fragile perché può essere eseguito prima che /mnt sia pronto. Un’unità systemd dedicata rende la configurazione prevedibile, affidabile e integrata nel ciclo di vita dei servizi Linux.
Conclusione
Ho creato azure-tempdisk-bootstrap perché volevo un modo semplice e sicuro per sfruttare al meglio il disco temporaneo di Azure con i miei web server. Funziona così bene che ho deciso di condividerlo in open source: se usi Nginx, PHP, WordPress o .NET su Azure, sono certo che ti tornerà utile.
