ingress-nginx è morto a marzo e la migrazione la stai ancora rimandando
A marzo 2026 il progetto ingress-nginx è stato ritirato: repository archiviato, niente più release, nessun fix nemmeno per le vulnerabilità che verranno. Il problema è che i cluster non se ne sono accorti, perché tutto continua a funzionare, ed è esattamente così che un componente esposto a internet, che termina il TLS e parla con l'API server, diventa una bomba a orologeria silenziosa. Le strade di uscita sono quattro e non si equivalgono affatto. Continua a leggere
Ultima modifica:
Molti team trattano il container come una sandbox di sicurezza, ma per default non lo è. I vettori di escape su Docker: privileged mode, socket Docker montato, capability eccessive, namespace condivisi. Come un attaccante esce dal container verso l'host e l'hardening che lo previene: user namespace, capability minime, seccomp, read-only filesystem. Dalla prospettiva offensiva, per capire cosa difendere davvero in una infrastruttura containerizzata. 
Un setup Docker per Laravel che funziona uguale in sviluppo e in produzione elimina la classe di bug che si manifestano solo sul server. Come containerizzare un'applicazione Laravel in modo pulito: ambiente di sviluppo riproducibile, Dockerfile multi-stage per la produzione, gestione separata di code, cache e asset, e i punti dove la configurazione dev e prod deve divergere. Pattern concreti, non un docker-compose copiato. 
Kubernetes è potente e, per la maggior parte delle PMI, prematuro. Quando ha davvero senso adottarlo (più team, scaling imprevedibile, deploy multipli al giorno) e quando è over-engineering che brucia budget e tempo. Se la decisione è sì, come iniziare in modo graduale: managed contro self-hosted, il percorso da Docker Compose a un cluster minimo, e i costi nascosti operativi da mettere in conto prima di partire. 
Containerizzare per la produzione è diverso dal farlo per lo sviluppo. Architettura Docker reale su Hetzner per un'applicazione PHP: Dockerfile multi-stage ottimizzato, gestione dei segreti, reverse proxy con TLS, e la transizione dalla singola VPS al piccolo cluster quando il carico cresce. Pattern operativi da campo, non teoria, con i tradeoff di costo e complessità dichiarati. 
Anthropic ha rilasciato in public beta il 1 aprile 2026 Claude Managed Agents - harness fully-managed con container configurabili, SSE streaming, zero DIY su E2B/Modal/Firecracker. Ma ha senso dismettere l'harness self-hosted con gVisor + seccomp + cap-drop che ho descritto nell'articolo sul sandboxing? Diagnosi punto per punto: TCO su scala PMI, superficie di attacco comparativa, vendor lock-in, compliance data sovereignty. Spoiler: la risposta è 'dipende da quattro variabili'. 
La build Docker di un'applicazione Laravel richiedeva 8 minuti ogni volta. Con l'ottimizzazione del layer caching (dipendenze Composer separate dal codice applicativo), multi-stage build e l'immagine finale Alpine, siamo scesi a 90 secondi. Il CI è diventato abbastanza veloce da aspettare il feedback. 
Datadog costa 30€ per host al mese. Per un'architettura con 8 microservizi PHP su Kubernetes, il costo era insostenibile. Ho migrato verso OpenTelemetry con collector auto-hosted e Jaeger come backend: zero costi aggiuntivi, stessa visibilità sulle trace distribuite tra i servizi. 
Quando hai dieci microservizi che si parlano tra loro, la gestione della sicurezza e dell'osservabilità a livello applicativo diventa insostenibile. Con Istio, mutual TLS tra tutti i servizi, distributed tracing con Jaeger e circuit breaker configurabili via YAML - senza cambiare una riga di codice PHP. 
I test con SQLite in memoria non trovano i bug che nascono dalle differenze tra SQLite e MySQL. Con Testcontainers per PHP, ogni test di integrazione ottiene un'istanza MySQL reale in un container Docker, azzerata tra le esecuzioni. Ho adottato questo approccio per un cliente e-commerce: i bug in staging sono scesi del 60%.