L’idillio iniziale: perché Cloudflare Pages sembrava la scelta perfetta

25 luglio 2022, questo è stato il primo commit sul repo Github del mio blog. In precedenza usavo Wordpress con soddisfazione, ma mi sono accorto che usavo meno del 10% delle funzionalità del CMS per il mio blog, che richiedeva manutenzione continua per evitare rischi di sicurezza. Ho cominciato a vagliare diversi strumenti che mi potessero dare la possibilità di scrivere un blog in formato semplice (Markdown), senza necessità di un backend e di un database e con una manutenzione minima.

Fu durante quella ricerca che scoprii Hugo e ne fui subito molto soddisfatto sotto diversi punti di vista e decisi quindi di salvere i miei articoli su Github e fare l’hosting del sito su Cloudflare Pages, visto che il mio dominio era gia’ configurato li'.

L’integrazione era perfetta: un push di un nuovo articolo sul branch master (allora il branch di default aveva ancora quel nome, poi sostituito con main) dava il segnale a Cloudflare Pages (ora chiamato Workers & Pages) che era il momento di usare Hugo per rigenerare il contenuto statico del sito e pubblicarlo.

Perfetto, non sbagliava mai un colpo e una volta sistemato, era la cosa piu’ comoda e semplice del mondo.

Leggera deviazione: unificare i domini per attrarre piu’ traffico sul portfolio

Passano gli anni, arriviamo nel 2026 e inizio la mia carriera da freelancer in ambito networking e devops e ho bisogno di portare piu’ traffico sul mio sito portfolio lazzarotto.dev per attrarre potenziali clienti.

Uno dei suggerimenti migliori che ho ricevuto, è quello di spostare il blog da mlazzarotto.it (che ha portato 1000 visite negli ultimi 90 giorni) e unirlo al dominio lazzarotto.dev per uniformare i domini.

Il motivo era piuttosto semplice: agli occhi di Google avevo due siti web distinti e in competizione tra loro:

• mlazzarotto.it (il blog)
• lazzarotto.dev (il portfolio)

Qui avevo due strade:

• spostare il blog nel sottodominio blog.lazzarotto.dev
• spostare il blog nel path lazzarotto.dev/blog

Facendo qualche ricerca online, ho capito che la seconda opzioni era quella consigliata da tutti i “pro” del campo web design e SEO.

L’ostacolo inaspettato: il problema del miodominio.dev/blog

Cloudflare Workers & Pages funziona benissimo quando il sito statico da pubblicare viene esposto nella root del dominio (o sottodominio) come https://mlazzarotto.it/, ma diventa velocemente un inferno cercare di pubblicare il sito web sul subpath https://lazzarotto.dev/blog per via della logica di Cloudflare.

Non nego di aver speso diverse ore a cercare di far funzionare i workers per pubblicare il sito nel modo giusto, e ci sono anche arrivato vicino, ma c’era sempre qualche problema di alcune risorse (CSS e JS) che non venivano referenziate correttamente da Hugo. E quindi il sito era visibile, ma senza styling e senza componenti dinamici.

Il momento della decisione: valutare le alternative

Anche se il mio focus professionale non è primariamente sui servizi di hosting per siti statici, ho esplorato le alternative più comuni per il mio caso d’uso.

Una delle prime alternative che ho scartato è stata GitHub Pages, principalmente per via di un uptime non sempre impeccabile per i miei standard. A questo si aggiunge una mia preferenza personale a distanziarmi dall’ecosistema Microsoft e dalla sua attuale direzione.

L’immagine qui sotto e’ stata presa da https://mrshu.github.io/github-statuses/ il giorno 11 aprile 2026 e oggettivamente non mi fa impazzire, per quanto il mio blog non necessiti di di uptime al 99.9999%.

Esistono poi altre soluzioni come Netlify e Vercel ma rimaneva comunque il problema dell’uso di una subpath per rendere disponibile questo blog su https://lazzarotto.dev/blog. Pertanto, visto che sto gia’ facendo hosting del mio portfolio su Kubernetes usando Traefik come reverse proxy, ho deciso di tenere anche il blog nel mio homelab.

La nuova architettura: un’occhiata al nuovo setup

La nuova architettura prevede l’uso di Gitea come repository e per la parte di Continuos Integration, Kubernetes per il deployment del blog e ArgoCD per la parte di Continuos Delivery.

Con questi 3 strumenti sono riuscito a replicare in maniera soddisfacente la combinazione che usavo precedentemente, ovvero Github + Cloudflare Pages, in modo piuttosto semplice (relativamente) e che mi permette comunque di avere la pubblicazione di un nuovo post in meno di 5 minuti.

Di seguito illustrero’ come funziona la pipeline.

Gitea: il controllo del mio codice

Utilizzo Gitea gia’ da un po’ di tempo per tenere in locale i miei progetti personali, tra i quali anche il codice del mio sito portfolio, e lo uso anche come software di Continuous Integration grazie alla funzionalita’ Gitea Actions che e’ praticamente una copia di Github Actions.

Nel repo del blog ho create quindi un workflow che crea un’immagine Docker, la carica sul registry Docker (sempre su Gitea) e poi modifica il manifest di Kubernetes in modo che ArgoCD aggiorni il deployment.

La configurazione del workflow e’ piuttosto semplice e usa alcuni packages esterni da Github.

Kubernetes: l’orchestratore di tutto

Mentre Gitea si occupa di gestire il codice sorgente, Kubernetes ha il compito di orchestrate i pod (2 repliche) ed assicurarsi che l’applicazione sia sempre funzionante grazie all’implementazione di healt-check.

Il deploy avviene automaticamente grazie all’integrazione di ArgoCD che fa il deploy del nuovo replicaSet appena Gitea modifica il manifest.

Il tutto avviene mantenendo un’alta affidabilita’ e senza downtime.

Il quadro generale

Di seguito potete vedere lo schema di come funziona il mio workflow e la pipeline tra Gitea, ArgoCD e Kubernetes.

Riflessioni finali: era la mossa giusta?

Quindi, era la mossa giusta? Assolutamente sì. Ho barattato la semplicità di un servizio gestito con la totale flessibilità di una soluzione mia, risolvendo il mio problema specifico e costruendo una piattaforma su cui potrò sperimentare ancora a lungo. Per me, è una vittoria su tutti i fronti.

Ora confrontiamo i pro e i contro di questa soluzione.

Pro

• Controllo completo del workflow
• Codice sorgente privato nel mio homelab, cio’ significa che non verra’ usato da Github per il training di Copilot
• Nessun costo (ovviamente, in questo calcolo non considero il costo più grande: il mio tempo; ma dato che l’obiettivo era anche fare pratica con nuovi strumenti, lo considero un investimento formativo a tutti gli effetti)
• Possibilita’ di testare differenti tipi di workflow e fare pratica con gli strumenti

Contro

• Uptime non allo stesso livello di Cloudflare (SPOF ovunque, del resto e’ il mio laboratorio e non ho nessuna ridondanza)
• Velocita’ forse leggermente minore (ma uso comunque Cloudflare per il caching)
• Piu’ elementi che possono rompersi e quindi potenzialmente piu’ tempo da perdere per sistemare cio’ che si rompe.

Prossimamente: come ho automatizzato tutto con ArgoCD

Nel prossimo articolo di questo blog analizzero’ nel dettaglio come ho implementato il deploy automatico tramite ArgoCD.