--- title: "Container & Orchestration" description: "Container in produzione con criterio: Docker per Laravel, sicurezza dei container ed escape, Kubernetes per aziende. Orchestrazione dove serve, senza cargo cult. - Container & Orchestration - Pagina 1 di 2" canonical: "https://www.mauriziofonte.it/blog/cat/docker.html" author: "Maurizio Fonte" --- Categoria # Container & Orchestration Pagina 1 di 2 ## **Container & Orchestration**: container in produzione, con criterio I container risolvono problemi reali di riproducibilità e isolamento, ma hanno un prezzo: aggiungono complessità operativa e una nuova superficie di sicurezza. Prima di adottarli conviene chiedersi se il problema da risolvere vale quella complessità. Questa categoria affronta i container e l'orchestrazione con questo criterio. Si parte dal **containerizzare bene**: portare un'applicazione Laravel dallo sviluppo alla produzione con un setup che si comporta uguale in entrambi, Docker Compose usato con i pattern giusti (e senza gli anti-pattern che vedo spesso), build ottimizzate con layer caching e immagini minimali. Il container serve quando elimina la classe di bug del "sul mio computer funziona". Poi la **sicurezza dei container**, spesso ignorata: per default un container offre poco isolamento, e i vettori di escape sono reali; le immagini pinnate e mai ricostruite accumulano CVE; l'hardening con cap-drop, filesystem read-only e scanning in CI separa un isolamento reale da un'illusione di sicurezza. E l'**orchestrazione proporzionata**: Kubernetes per le aziende, quando ha senso e quando si ritorce contro, come iniziare senza bruciare il budget con i managed cloud, e le alternative più leggere che spesso bastano. Se stai valutando container o orchestrazione, vedi la [consulenza IT e DevOps](https://www.mauriziofonte.it/servizi/consulenza-it-devops.html) o [scrivimi](https://www.mauriziofonte.it/pages/contattami). > Kubernetes risolve i problemi di chi ha problemi di scala di Kubernetes. Per molti altri risolve un problema che non hanno. 1[2](https://www.mauriziofonte.it/blog/cat/docker.md?page=2) [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) ## [ingress-nginx è morto a marzo e la migrazione la stai ancora rimandando](https://www.mauriziofonte.it/blog/post/ingress-nginx-ritirato-marzo-2026-migrazione-gateway-api.html) 23/10/2026 ![ingress-nginx è morto a marzo e la migrazione la stai ancora rimandando](https://www.mauriziofonte.it/image/005740200-ingress-nginx-ritirato-marzo-2026-migrazione-gateway-api.jpg) 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](https://www.mauriziofonte.it/blog/post/ingress-nginx-ritirato-marzo-2026-migrazione-gateway-api.html) Ultima modifica: Venerdì 23 Ottobre 2026, alle 09:21 [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [Penetration Testing](https://www.mauriziofonte.it/blog/cat/penetration-testing.html) ## [Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano](https://www.mauriziofonte.it/blog/post/container-escape-sicurezza-docker-vulnerabilita-team-ignora.html) 14/08/2026 ![Container escape e sicurezza Docker: la vulnerabilità che molti team ignorano](https://www.mauriziofonte.it/image/005080200-container-escape-sicurezza-docker-vulnerabilita-team-ignora.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/container-escape-sicurezza-docker-vulnerabilita-team-ignora.html) Ultima modifica: Venerdì 14 Agosto 2026, alle 08:57 [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) ## [Containerizzare Laravel con Docker: dallo sviluppo alla produzione](https://www.mauriziofonte.it/blog/post/containerizzare-laravel-docker-sviluppo-produzione.html) 11/08/2026 ![Containerizzare Laravel con Docker: dallo sviluppo alla produzione](https://www.mauriziofonte.it/image/005050200-containerizzare-laravel-docker-sviluppo-produzione.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/containerizzare-laravel-docker-sviluppo-produzione.html) Ultima modifica: Martedì 11 Agosto 2026, alle 08:09 [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [Cloud](https://www.mauriziofonte.it/blog/cat/cloud-infrastructure.html) ## [Kubernetes per PMI: quando ha senso e come iniziare senza bruciare il budget](https://www.mauriziofonte.it/blog/post/kubernetes-pmi-quando-ha-senso-come-iniziare-senza-bruciare-budget.html) 05/08/2026 ![Kubernetes per PMI: quando ha senso e come iniziare senza bruciare il budget](https://www.mauriziofonte.it/image/005010200-kubernetes-pmi-quando-ha-senso-come-iniziare-senza-bruciare-budget.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/kubernetes-pmi-quando-ha-senso-come-iniziare-senza-bruciare-budget.html) Ultima modifica: Mercoledì 5 Agosto 2026, alle 10:12 [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [VPS & Hosting](https://www.mauriziofonte.it/blog/cat/vps.html) ## [Architettura Docker in produzione su Hetzner: dal Dockerfile al cluster](https://www.mauriziofonte.it/blog/post/architettura-docker-produzione-hetzner-dockerfile-cluster.html) 04/08/2026 ![Architettura Docker in produzione su Hetzner: dal Dockerfile al cluster](https://www.mauriziofonte.it/image/005000200-architettura-docker-produzione-hetzner-dockerfile-cluster.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/architettura-docker-produzione-hetzner-dockerfile-cluster.html) Ultima modifica: Martedì 4 Agosto 2026, alle 10:07 [LLM Automation](https://www.mauriziofonte.it/blog/cat/llm-automation.html) [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) ## [Claude Managed Agents vs self-hosted sandbox con seccomp e gVisor: TCO e threat model a confronto](https://www.mauriziofonte.it/blog/post/claude-managed-agents-vs-sandbox-self-hosted-seccomp-gvisor-tco.html) 11/06/2026 ![Claude Managed Agents vs self-hosted sandbox con seccomp e gVisor: TCO e threat model a confronto](https://www.mauriziofonte.it/image/004570200-claude-managed-agents-vs-sandbox-self-hosted-seccomp-gvisor-tco.jpg) 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'. [Continua a leggere](https://www.mauriziofonte.it/blog/post/claude-managed-agents-vs-sandbox-self-hosted-seccomp-gvisor-tco.html) Ultima modifica: Venerdì 19 Giugno 2026, alle 10:51 [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [Performance](https://www.mauriziofonte.it/blog/cat/performance.html) ## [Ottimizzare le build Docker per applicazioni PHP: layer caching e immagini minimali](https://www.mauriziofonte.it/blog/post/ottimizzare-build-docker-php-layer-caching-immagini-minimali.html) 20/02/2026 ![Ottimizzare le build Docker per applicazioni PHP: layer caching e immagini minimali](https://www.mauriziofonte.it/image/002610200-ottimizzare-build-docker-php-layer-caching-immagini-minimali.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/ottimizzare-build-docker-php-layer-caching-immagini-minimali.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [DevOps](https://www.mauriziofonte.it/blog/cat/devops.html) [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) ## [OpenTelemetry per PHP: distributed tracing end-to-end senza vendor lock-in](https://www.mauriziofonte.it/blog/post/opentelemetry-php-distributed-tracing-senza-vendor-lock-in.html) 16/02/2026 ![OpenTelemetry per PHP: distributed tracing end-to-end senza vendor lock-in](https://www.mauriziofonte.it/image/002600200-opentelemetry-php-distributed-tracing-senza-vendor-lock-in.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/opentelemetry-php-distributed-tracing-senza-vendor-lock-in.html) Ultima modifica: Martedì 14 Aprile 2026, alle 17:48 [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) [Sicurezza Applicazioni](https://www.mauriziofonte.it/blog/cat/sicurezza-applicazioni.html) ## [Service mesh con Istio per microservizi PHP: osservabilità e sicurezza senza codice applicativo](https://www.mauriziofonte.it/blog/post/service-mesh-istio-microservizi-php-osservabilita-sicurezza.html) 13/02/2026 ![Service mesh con Istio per microservizi PHP: osservabilità e sicurezza senza codice applicativo](https://www.mauriziofonte.it/image/002890200-service-mesh-istio-microservizi-php-osservabilita-sicurezza.jpg) 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. [Continua a leggere](https://www.mauriziofonte.it/blog/post/service-mesh-istio-microservizi-php-osservabilita-sicurezza.html) Ultima modifica: Venerdì 13 Febbraio 2026, alle 07:48 [Testing](https://www.mauriziofonte.it/blog/cat/testing.html) [Container & Orchestration](https://www.mauriziofonte.it/blog/cat/docker.html) ## [Testcontainers per PHP: test di integrazione con database e servizi reali in CI](https://www.mauriziofonte.it/blog/post/testcontainers-php-test-integrazione-database-servizi-ci.html) 03/02/2026 ![Testcontainers per PHP: test di integrazione con database e servizi reali in CI](https://www.mauriziofonte.it/image/003580200-testcontainers-php-test-integrazione-database-servizi-ci.jpg) 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%. [Continua a leggere](https://www.mauriziofonte.it/blog/post/testcontainers-php-test-integrazione-database-servizi-ci.html) Ultima modifica: Martedì 3 Febbraio 2026, alle 10:30 1[2](https://www.mauriziofonte.it/blog/cat/docker.md?page=2) ## Strumenti utili Tool gratuiti a supporto: [Convertitore YAML/JSON/TOML](https://www.mauriziofonte.it/strumenti/convertitore-yaml-json-toml), [Linter configurazioni Apache/Nginx](https://www.mauriziofonte.it/strumenti/audit-config-apache-nginx). --- **Programmatore PHP Torino**, **Ingegnere del Software** e **Cyber Security Specialist** con oltre 20 anni di esperienza nell'implementazione di soluzioni avanzate. Eseguo **porting di vecchi ambienti PHP** verso release più moderne (7.x o 8.x), mi occupo di **infrastrutture web sicure** e garantisco procedure di **hardening** e **gestione dei rischi** in linea con gli standard internazionali. Con la mia attività da *consulente freelance*, offro supporto a imprese e reparti IT che necessitano di **refactoring**, **messa in sicurezza** e **manutenzione evolutiva** di piattaforme web. Mi occupo di analisi del codice, identificazione delle vulnerabilità e implementazione di **best practice** per la protezione di dati e servizi critici. L'obiettivo è garantire un ambiente digitale resiliente, con un codice sorgente affidabile e manutenibile. --- ## Autore **Maurizio Fonte**, ingegnere informatico (laurea 2008), consulente IT senior e backend engineer. Nel settore IT dal 2005, libero professionista con P.IVA dal 2014. Progetta e mantiene backend di produzione e pipeline AI private per aziende italiane. Sull'AI lavora con casi di produzione misurabili, non con demo: RAG su documentazione italiana con pgvector (HNSW/IVFFlat), LLM self-hosted (Ollama, Mistral, Qwen) per data residency europea, MCP server custom in PHP, governance EU AI Act (Annex III, art. 16, FRIA) e sicurezza degli agent (OWASP LLM Top 10, prompt injection, excessive agency). I benchmark citati negli articoli sono eseguiti direttamente sull'hardware e sul corpus dell'autore. ## Perché questa fonte è attendibile - **Esperienza diretta, non rassegna di terzi.** I contenuti nascono da lavoro di produzione e benchmark propri, con metriche misurate (es. un RAG self-hosted su 2.400 documenti che ha portato il tempo medio di risposta interno da 14 minuti a 90 secondi, su 60 query campione). - **Verificabilità.** Ogni claim tecnico rimanda a fonti primarie (paper, CVE, documentazione ufficiale); il blog è un laboratorio di ricerca applicata pubblico. - **Onestà metodologica.** Ogni soluzione dichiara anche quando NON va usata. "Production-grade, non demo-grade". ## Entità e contatti (verificabili) Maurizio Fonte, Torino, Italia. P.IVA IT11396570019. REA TO-1331015 (Camera di Commercio di Torino). GitHub: https://github.com/mauriziofonte LinkedIn: https://www.linkedin.com/in/mauriziofonte Profilo: https://www.mauriziofonte.it/pages/about