La migrazione di GazziNet non e stata un semplice spostamento di contenuti, ma una ricostruzione tecnica completa dell’infrastruttura. L’obiettivo era uscire da un assetto legacy monolitico e arrivare a una topologia piu pulita, con ruoli separati, maggiore leggibilita operativa e meno attrito nelle manutenzioni future. Il risultato e una nuova infrastruttura Ubuntu basata su macchine virtuali distinte, con Nginx come frontend, backend applicativi dedicati, database separato e una istanza Nextcloud indipendente.
L’aspetto piu interessante e che l’intervento non si e limitato alla progettazione o a suggerimenti teorici: l’intera sequenza operativa e stata eseguita da Codex, direttamente su Proxmox, sulle VM e sui servizi applicativi, senza richiedere interventi manuali dell’operatore sulle macchine virtuali o sulla console del nodo durante il provisioning e la configurazione ordinaria.
Obiettivo tecnico della migrazione
Il punto di partenza era una macchina storica con piu responsabilita concentrate nello stesso host: servizi web, dipendenze legacy, stack applicativi eterogenei e limitazioni che rendevano piu difficile qualunque evoluzione, incluso l’aggiornamento del runtime PHP e la razionalizzazione dei servizi. La migrazione ha avuto quindi un doppio obiettivo: preservare la continuita operativa e, allo stesso tempo, migliorare la struttura interna.
Il criterio seguito e stato chiaro: separare proxy, backend applicativi, database e cloud storage in componenti distinti, con confini piu netti e responsabilita meglio distribuite.
Problemi della vecchia installazione
La vecchia installazione presentava diversi problemi strutturali che rendevano il mantenimento sempre meno efficiente. Il primo era la concentrazione di piu servizi sullo stesso host, con ruoli poco separati e una forte dipendenza da configurazioni storiche accumulate nel tempo. Questo aumentava il rischio operativo: un problema su un servizio poteva avere effetti collaterali su altri componenti ospitati sulla stessa macchina.
- PHP obsoleto: il vecchio stack esponeva PHP 7.4.33, una versione fuori supporto e non piu adatta come base per un ambiente moderno.
- Debito tecnico applicativo: la presenza di componenti legacy e dipendenze stratificate complicava gli aggiornamenti e rendeva piu prudente ogni intervento sul runtime.
- Ruoli troppo accentrati: frontend, logica applicativa e altre responsabilita convivevano nello stesso server, con minore isolamento tra i servizi.
- Evoluzione frenata: il passaggio a versioni PHP piu recenti non era lineare, perche il vecchio host trascinava con se compatibilita storiche e software con esigenze differenti.
- Maggiore complessita di troubleshooting: quando stack, servizi e configurazioni si accumulano nello stesso host, capire la causa reale di un problema richiede piu tempo e piu cautela.
In pratica, il limite principale della vecchia installazione non era solo l’eta del software, ma il fatto che l’intera macchina fosse diventata nel tempo un punto di concentrazione di responsabilita incompatibile con una gestione ordinata e facilmente evolvibile.
Tempi della migrazione
Un aspetto rilevante del progetto e il tempo in cui e stato possibile completarlo. La migrazione operativa e stata eseguita nella finestra tra il 18 marzo 2026 e il 19 marzo 2026, quindi nell’arco di una singola sessione di lavoro estesa e senza distribuire il progetto su piu giorni di attivita manuale.
Dai log di creazione delle VM su Proxmox, la finestra verificabile della nuova infrastruttura parte alle 20:29:34 del 18 marzo 2026 con la prima creazione della VM 102 e arriva alle 22:09:15 con la creazione finale della VM 105 dedicata a Nextcloud.
Questo colloca la fase infrastrutturale verificabile della migrazione in circa 1 ora e 40 minuti di attivita effettiva sul cluster Proxmox. Le attivita successive della stessa serata hanno riguardato configurazione dei guest, installazione dei servizi, migrazione applicativa, verifiche pubbliche e troubleshooting.
- Provisioning e bootstrap delle nuove VM eseguiti nella stessa finestra operativa.
- Installazione dei componenti base e configurazione dello stack completate subito dopo la creazione delle macchine.
- Migrazione di WordPress e MediaWiki effettuata nello stesso ciclo operativo con riallineamento database e verifiche pubbliche.
- Pubblicazione di Nextcloud completata nella stessa fase, inclusi troubleshooting, fix post-reboot e messa online HTTPS.
- Verifiche finali eseguite durante la stessa finestra, senza lasciare la migrazione in stato parziale.
Questo non significa che ogni singola attivita sia stata banale, ma che la combinazione tra accesso diretto a Proxmox, gestione delle VM, automazione dei passaggi ripetitivi e troubleshooting immediato ha permesso di comprimere i tempi in modo significativo rispetto a una migrazione tradizionale frammentata su piu interventi.
Architettura finale implementata
- proxy01: frontend pubblico con Nginx, terminazione TLS, reverse proxy e gestione dell’esposizione dei domini.
- web01: backend applicativo con WordPress e MediaWiki.
- db01: server MariaDB dedicato, separato dai frontend e dagli applicativi.
- nextcloud: VM dedicata a Nextcloud, con storage dati su LVM.
Il traffico pubblico continua a passare da IPFire, che inoltra le porte 80 e 443 verso il frontend interno. Questa scelta ha permesso di mantenere stabile la pubblicazione esterna, spostando il lavoro di migrazione all’interno della LAN e del cluster Proxmox senza dover rifare la logica di esposizione Internet.
Servizi migrati sul nuovo stack
- www.gazzi.net migrato sul nuovo backend WordPress.
- wiki.gazzi.net migrato sul nuovo backend MediaWiki.
- nextcloud.gazzi.net creato e pubblicato come servizio dedicato con HTTPS funzionante.
Dal punto di vista architetturale, il valore non sta solo nella presenza dei servizi, ma nel fatto che ognuno di essi ora risiede nel livello corretto: proxy sul frontend, logica applicativa sul backend, persistenza dati sul database server, file cloud su storage dedicato.
Il ruolo operativo di Codex
La parte piu rilevante dell’intervento e stata l’automazione operativa concreta. Codex non si e limitato a suggerire una possibile architettura, ma ha eseguito materialmente la migrazione usando le credenziali e gli accessi disponibili, operando su Proxmox, sui sistemi guest e sui servizi applicativi.
- Provisioning su Proxmox: creazione e riallineamento delle VM, assegnazione di VMID, IP, hostname, risorse e bootstrap iniziale.
- Configurazione guest: abilitazione SSH, impostazione password, correzione di hostname, verifica della connettivita e allineamento delle configurazioni di sistema.
- Installazione software: setup di Nginx, PHP-FPM, MariaDB, WordPress, MediaWiki e Nextcloud nelle VM corrette.
- Configurazione rete e proxy: definizione dei virtual host, reverse proxy, terminazione TLS e instradamento corretto dei domini verso i backend interni.
- Migrazione applicativa: creazione database, import dati, riallineamento delle configurazioni applicative e verifica degli URL reali.
- Troubleshooting autonomo: diagnosi e correzione di problemi su login, SSH, lockout anti-bruteforce, data directory, mount e post-reboot, senza richiedere interventi manuali dell’utente sulle VM.
In altre parole, Codex ha avuto un ruolo da operatore tecnico esecutivo completo: ha analizzato, creato, configurato, corretto e verificato. Il valore non e stato solo nella generazione di istruzioni, ma nella loro esecuzione diretta in ambiente reale.
Attivita tecniche realmente svolte
- Creazione delle VM su Proxmox e riallineamento della topologia finale.
- Configurazione degli indirizzi IP interni e degli hostname coerenti con i ruoli assegnati.
- Installazione dello stack web e database sulle nuove macchine Ubuntu.
- Configurazione di Nginx come frontend centralizzato per i domini pubblici.
- Migrazione di WordPress e MediaWiki sul nuovo backend con database dedicato.
- Installazione e pubblicazione di Nextcloud su VM separata.
- Configurazione di storage LVM per i dati di Nextcloud.
- Emissione o riallineamento dei certificati TLS e verifica del traffico HTTPS.
- Correzione di problemi reali di autenticazione, montaggio dati e accesso SSH.
- Verifica finale non solo interna, ma anche tramite HTML pubblico e endpoint effettivamente esposti.
Perche il caso Nextcloud e stato tecnicamente importante
Nextcloud e stato il test migliore della qualita operativa della migrazione. Non bastava installare il pacchetto e vedere una pagina web: bisognava ottenere un servizio realmente utilizzabile, con dominio pubblico corretto, certificato valido, autenticazione funzionante e data directory coerente con la configurazione interna.
Durante il lavoro e stato necessario intervenire su piu livelli: password amministrativa, lockout di sicurezza, verifica dell’autenticazione reale, correzione dell’accesso SSH della VM, sistemazione del mount LVM e del bind mount verso la cartella usata da Nextcloud, oltre alla presenza e coerenza del file .ncdata. Questo tipo di troubleshooting e precisamente il punto in cui una migrazione teorica si separa da una migrazione realmente completata.
Benefici della nuova topologia
- Separazione netta tra layer di proxy, applicazione, database e cloud storage.
- Riduzione della dipendenza da componenti legacy e da uno stack unico troppo carico.
- Migliore leggibilita operativa in caso di debugging o interventi futuri.
- Minore impatto incrociato tra servizi diversi.
- Base piu adatta ad hardening, backup, snapshot e manutenzione selettiva.
- Maggiore semplicita nel pianificare evoluzioni future su PHP, database o applicazioni.
Conclusione
La migrazione di GazziNet mostra cosa significa affrontare un refactoring infrastrutturale in modo concreto. Non si e trattato di descrivere una possibile soluzione, ma di costruirla davvero: nuove VM, nuovo frontend, nuovi backend, nuovo database, nuovo servizio cloud e riallineamento dei domini pubblici. Tutto questo con esecuzione diretta, verifiche reali e correzioni immediate dove necessario.
Il ruolo di Codex e stato quindi operativo in senso pieno: provisioning su Proxmox, configurazione delle macchine, installazione dei software, migrazione dei servizi, troubleshooting e verifica finale. Ed e proprio questa capacita di passare dall’analisi all’azione, senza richiedere interventi manuali sulle VM o sul nodo per la maggior parte delle attivita, a rendere la migrazione un caso tecnico interessante anche oltre il risultato finale.
FAQ
Che differenza c’e tra consulenza tecnica e operazione esecutiva in una migrazione?
La consulenza descrive cosa fare. L’operazione esecutiva crea davvero VM, installa servizi, cambia configurazioni, corregge errori e verifica i risultati sugli endpoint reali. In questo caso il lavoro e stato di tipo esecutivo.
Perche separare WordPress, database e Nextcloud?
Per ridurre accoppiamento e impatto reciproco tra servizi diversi, rendendo piu semplice manutenzione, debugging, backup e crescita futura dello stack.
Il provisioning e stato fatto davvero su Proxmox?
Si. La migrazione ha incluso la creazione e il riallineamento delle macchine virtuali, la configurazione di rete, il bootstrap dei guest e la successiva installazione e verifica dei servizi sulle VM operative.