← Tutte le competenze

03

Infrastruttura e DevOps

La domanda che uso come metro è sempre la stessa: se questa macchina sparisse stanotte, quanto ci metto a rifarla identica? Se la risposta è «dipende da cosa mi ricordo», l’infrastruttura non è finita.

Provisioning ripetibile, non documentato a memoria

Ogni host nasce da ruoli e script versionati, non da una sessione SSH ben riuscita. Le procedure operative stanno nel repository accanto al codice che governano, e ogni scelta strutturale lascia un documento di decisione che spiega perché — così chi arriva dopo non la ribalta per sbaglio.

Le operazioni distruttive hanno semantica esplicita e sono ripetibili: rieseguire non deve fare danni, e questo va provato, non sperato.

La rete è il primo confine

Separare i clienti a livello di rete costa più fatica che filtrarli nel codice, ma è l’unico livello che regge quando il codice sbaglia: overlay dedicati, routing per tenant, e ingresso attraverso un tunnel invece che con porte esposte su internet.

I segreti stanno in un vault con PKI interna e certificati a scadenza breve; l’applicazione riceve credenziali generate al momento, non stringhe copiate in un file di configurazione.

Rilasci che si possono rifare (e disfare)

Build riproducibili in container, rilascio staccato dalla sessione SSH che lo lancia (una connessione che cade non deve lasciare un deploy a metà), verifica dello stato subito dopo, e un percorso di rollback pensato prima e non durante l’emergenza.

Portfolio

Cosa ho fatto, progetto per progetto, su questa competenza.

Orbitas

Cloud privato multi-tenant su bare metal

  • Cluster Proxmox a tre nodi in datacenter tedesco, con overlay EVPN/VXLAN e VRF per isolare le reti dei clienti.
  • Service discovery e DNS interno con Consul, segreti e PKI con Vault, credenziali rese all’applicazione da agenti che le rinnovano da soli.
  • Ingresso via tunnel Cloudflare Zero Trust: nessuna porta di gestione esposta su internet.
  • PostgreSQL in alta disponibilità, ruoli Ansible per nodi di calcolo, nodi di uscita, vault e patching coordinato; una libreria condivisa di script operativi installata con make sui target.
  • NetBox come CMDB e piano di allocazione IP documentato: la rete ha una fonte di verità, non un foglio di calcolo.
  • Proxmox VE
  • EVPN/VXLAN
  • Consul
  • Vault
  • Ansible
  • PostgreSQL HA
  • Cloudflare Zero Trust
  • NetBox

CocoonServer

Odoo multi-istanza su Kubernetes

  • Istanze Odoo isolate su K3s con chart Helm dedicato, ingress Traefik e middleware per autenticazione e instradamento.
  • Volumi persistenti separati per moduli custom e template di database, così un aggiornamento del contenitore non porta via il lavoro fatto sui moduli.
  • CronJob di raccolta metriche e dashboard Grafana per tenere sotto controllo consumo e salute delle istanze.
  • Kubernetes (K3s)
  • Helm
  • Traefik
  • PostgreSQL
  • Prometheus
  • Grafana

Manora

Infrastruttura della catena Layer 2

  • Stack in Docker Compose con sequencer Nitro, nodo RPC pubblico, batch poster verso L1, PostgreSQL, Redis, Prometheus e Grafana.
  • Reti separate per sviluppo, testnet e mainnet con chain id distinti per la protezione dal replay, e documento di hardening dedicato al passaggio in mainnet.
  • Docker Compose
  • Arbitrum Nitro
  • PostgreSQL
  • Redis
  • Prometheus
  • Grafana
  • Terraform

BigFishIta

Questo sito, in produzione su VPS

  • Docker Compose con applicazione, PostgreSQL, reverse proxy Caddy (TLS automatico) e n8n sulla stessa macchina.
  • Rilascio staccato dalla sessione SSH e verificato subito dopo; backup notturni di database e allegati con retention e script di ripristino.
  • Docker Compose
  • Caddy
  • PostgreSQL
  • n8n
  • cron
  • rsync

Ti serve questo?

Raccontami il problema e ti dico come lo affronterei — e se non è il caso di farlo, te lo dico lo stesso.

Parliamone