Questo articolo descrive la migrazione dell’infrastruttura tecnica di WikiTrek, completata nel maggio 2026: le motivazioni che l’hanno resa necessaria, le scelte architetturali adottate, le difficoltà incontrate lungo il percorso e i risultati ottenuti.
Il problema: due server, il doppio della complessità
Fino alla primavera del 2026, WikiTrek era distribuito su due server virtuali privati (VPS) separati, entrambi ospitati presso il provider tedesco Hetzner.
Il primo — wikitrek143 — ospitava i componenti principali: i due wiki (wikitrek.org e data.wikitrek.org), i blog WordPress associati, e l’intero stack LAMP (Linux, Apache, MariaDB, PHP) su cui questi servizi si appoggiano.
Il secondo — containertrek — ospitava i servizi accessori ma indispensabili per il funzionamento di Wikibase: il motore di interrogazione SPARQL (WDQS/Blazegraph), il sistema di ricerca full-text (Elasticsearch) e QuickStatements, lo strumento per l’inserimento dati in batch. Questi servizi giravano in container Docker, una scelta tecnica motivata dalla loro complessità di installazione e dalla frequente necessità di aggiornamento.
Questa architettura distribuita presentava limiti concreti e crescenti. Ogni aggiornamento rilevante richiedeva interventi coordinati su entrambe le macchine. Le configurazioni dovevano essere mantenute coerenti tra due ambienti distinti. Il costo mensile era la somma dei due server. E ogni componente aggiuntivo aumentava la superficie di potenziali problemi.
La decisione di consolidare tutto su un’unica macchina è maturata gradualmente, ma è diventata urgente nel corso del 2025, quando la gestione del bot scraping aggressivo — un problema che descriveremo più avanti — ha evidenziato quanto fosse difficile applicare policy coerenti su un’infrastruttura frammentata.
La soluzione: architettura ibrida su server unico
Il nuovo server è un Hetzner CX33: 4 CPU virtuali, 8 GB di RAM, 80 GB di storage SSD. Il costo mensile è sostanzialmente equivalente alla somma dei due server precedenti. La differenza non è economica, ma architetturale: un’unica macchina, un’unica configurazione da mantenere, un’unica superficie da monitorare.
Il sistema operativo: Ubuntu 26.04 LTS
La scelta è ricaduta su Ubuntu 26.04 LTS, la versione con supporto a lungo termine rilasciata nell’aprile 2026, garantita fino al 2031. La motivazione è semplice: un’infrastruttura di questa complessità beneficia di una base stabile e prevedibile, con cinque anni di aggiornamenti di sicurezza garantiti senza necessità di migrare il sistema operativo.
L’architettura: LAMP nativo per i wiki, Docker per i servizi Wikibase
La scelta progettuale più rilevante è stata quella di adottare un’architettura ibrida, dove i due componenti principali del sistema vivono in ambienti distinti per ragioni precise e complementari.
MediaWiki e WordPress girano in modo nativo sul sistema operativo, su uno stack LAMP tradizionale (Apache, MariaDB, PHP 8.5). Questa scelta consente un controllo granulare su ogni aspetto della configurazione — ottimizzazione della cache, gestione della memoria, tuning delle query — e semplifica le operazioni di manutenzione ordinaria come gli aggiornamenti delle estensioni o le modifiche alle impostazioni.
I servizi Wikibase (WDQS/Blazegraph, Elasticsearch, QuickStatements) girano invece in container Docker, coordinati tramite Docker Compose. La ragione è opposta: questi componenti hanno dipendenze complesse, richiedono versioni specifiche di librerie Java e Python, e il loro aggiornamento manuale su un sistema nativo è un’operazione delicata e soggetta a errori. Docker isola queste dipendenze, garantisce la riproducibilità dell’ambiente e riduce drasticamente il rischio di conflitti tra componenti.
Il flusso del traffico in sintesi
Ogni richiesta in arrivo su WikiTrek segue questo percorso:Apache (porta 443, HTTPS) → Anubis (porta 8923, filtro antibot) → Apache (porta 8080, instradamento interno). Anubis — di cui parliamo nella sezione sulle sfide — si interpone tra il traffico pubblico e i wiki, analizzando ogni richiesta prima di lasciarla passare.
Le sfide: cosa ha reso la migrazione complessa
Il problema dei bot e la difesa a più livelli
Tra il 2024 e il 2025, wikitrek143 ha subito ripetuti episodi di scraping aggressivo da parte di bot automatizzati — in particolare crawler legati a sistemi di intelligenza artificiale — che generavano picchi di carico estremi. Il load average del server raggiungeva valori di 30–40, una condizione di stress severo per una macchina con 4 CPU, e i tempi di caricamento delle pagine arrivavano a superare il minuto.
La risposta è stata l’adozione di Anubis, un proxy antibot che pone una sfida crittografica (proof-of-work) a ogni visitatore non riconosciuto. I browser umani la risolvono in modo trasparente e automatico; i bot, che operano in modo massivo e non interattivo, vengono bloccati prima ancora di raggiungere il wiki. Dopo l’attivazione di Anubis, il carico del server è sceso stabilmente a valori di 1–2, con tempi di risposta tornati nell’ordine del secondo.
In occasione della migrazione, la protezione Anubis è stata estesa anche ai blog WordPress — anch’essi bersaglio di traffico automatizzato — e la policy di filtro è stata affinata: i bot delle grandi piattaforme AI come GPTBot e ClaudeBot, che rispettano le direttive del file robots.txt, sono ammessi con un livello di sfida moderato; i crawler più aggressivi come Bytespider vengono invece bloccati direttamente.
PHP 8.5 e la compatibilità con MediaWiki
Ubuntu 26.04 include PHP 8.5 come versione predefinita. La documentazione ufficiale di MediaWiki indicava che la versione 1.43 non fosse ancora certificata per PHP 8.5, il che avrebbe richiesto di installare una versione precedente di PHP da repository di terze parti — complicando la manutenzione e introducendo una dipendenza esterna da gestire nel tempo.
Piuttosto che accettare questo compromesso senza verifica, abbiamo condotto test diretti sull’ambiente di produzione. Il risultato è stato che MediaWiki 1.43 funziona correttamente con PHP 8.5, con un unico accorgimento necessario (la disattivazione del JIT PCRE, richiesta dal kernel di Ubuntu 26.04 per ragioni di sicurezza). Abbiamo potuto utilizzare la versione PHP nativa del sistema operativo, senza repository aggiuntivi.
La migrazione dei dati Wikibase
Il componente più delicato dell’intera operazione è stato il trasferimento di data.wikitrek.org, il repository Wikibase che contiene oltre 705.000 triple RDF. Questi dati non risiedono in un unico database: sono distribuiti tra MariaDB (per i dati strutturati), Blazegraph (per le query SPARQL) ed Elasticsearch (per la ricerca full-text). Ciascuno di questi sistemi richiede una procedura di import e ricostruzione distinta.
La strategia adottata ha previsto un primo ciclo completo di import sul nuovo server a scopo di verifica, seguito da un secondo import definitivo — effettuato con i wiki in modalità sola lettura — per garantire la coerenza dei dati al momento del passaggio. Blazegraph ed Elasticsearch sono stati poi ricostruiti a partire dai dati importati tramite le procedure di aggiornamento incrementale native di ciascun sistema.
I risultati
Stabilità e prestazioni
Il nuovo server è in produzione da alcune settimane e i parametri operativi sono confortanti. Il load average si mantiene stabilmente tra 1 e 2 anche sotto traffico sostenuto — lo stesso valore che su wikitrek143 si raggiungeva solo dopo l’ottimizzazione intensiva del 2025, e che allora richiedeva un monitoraggio costante. I tempi di risposta per le pagine già in cache si attestano nell’ordine di 1 secondo.
Anubis continua a filtrare in media oltre 100.000 richieste di bot al giorno, proteggendo il server da un carico che altrimenti sarebbe insostenibile per un’installazione di queste dimensioni.
Manutenzione semplificata
La riduzione da due server a uno ha un impatto diretto sulla gestione quotidiana. Gli aggiornamenti di sistema, le verifiche di sicurezza e i backup ora riguardano un’unica macchina. Il sistema di backup automatico — basato su uno script con rotazione grandfather-father-son — copre in un’unica operazione schedulata tutti i componenti: wiki, blog, database e volumi Docker. Il monitoraggio esterno è affidato a UptimeRobot, mentre phpSysInfo e GoAccess forniscono visibilità in tempo reale sulle metriche interne.
Effetti collaterali positivi
La migrazione ha offerto l’occasione per un lavoro di manutenzione più ampio, che andava rimandato da tempo. Tutte le estensioni MediaWiki sviluppate specificamente per WikiTrek — Wiki2Ban, RecentActivity, ParagraphLinks, PageToGitHub, MoreInfo, ActivityWiki — sono state riviste e aggiornate per garantire la piena compatibilità con PHP 8.5 e MediaWiki 1.43.
Parallelamente, il repository wikibase-data-services — che contiene l’intera configurazione Docker per i servizi Wikibase di WikiTrek — è stato reso pubblico su GitHub: github.com/lucamauri/wikibase-data-services. Il repository è rilasciato sotto licenza GPL v2 e può essere utilizzato come riferimento o punto di partenza da chiunque gestisca installazioni analoghe di Wikibase.
Conclusione
La migrazione a unitedwikitrek rappresenta un passo significativo nella maturazione dell’infrastruttura di WikiTrek. Il consolidamento su un’unica macchina non è solo una semplificazione operativa: è la precondizione per una gestione sostenibile nel lungo periodo, in cui ogni intervento — dagli aggiornamenti di sicurezza alle future evoluzioni del software — può essere pianificato e eseguito con maggiore controllo e minore rischio.
I vecchi server resteranno attivi in modalità sola lettura per alcune settimane come misura cautelativa, prima di essere dismessi definitivamente.
Per domande sulla configurazione o sulla migrazione, è possibile scrivere nei commenti o contattarci direttamente.
Sii il primo a commentare