Il tuo sito va lento. O peggio, va giù. E quando apri il log, non capisci se il problema è l'applicazione, il database o il server web. Se stai gestendo più servizi su una singola macchina, sai che il collo di bottiglia è quasi sempre lì: un Nginx installato a mano, con configurazioni stratificate nel tempo, che nessuno osa toccare. Noi, di Meteora Web, lo vediamo ogni giorno nei progetti che ci arrivano. La soluzione non è un altro file di configurazione: è cambiare approccio. Mettere Nginx in un container Docker, usarlo come gateway unico per tutti i tuoi servizi. Non è una moda. È un modo per rendere il tuo stack riproducibile, testabile e — soprattutto — non distruttibile.
Perché usare Nginx con Docker come gateway per i tuoi servizi?
Pensa al gateway come al centralino della tua azienda. Ogni chiamata entra da un numero solo e viene smistata al reparto giusto. Senza centralino, ogni reparto avrebbe il suo numero, e i clienti non saprebbero mai chi chiamare. Nel tuo stack, Nginx è quel centralino: riceve tutte le richieste HTTP e le inoltra al servizio giusto — un container Node, un'API Python, un file statico. Metterlo in Docker significa che il centralino non è più un apparecchio fisico che si rompe: è un software che puoi ricreare identico in cinque minuti, su qualsiasi macchina.
I benefici concreti? Isolamento: se il gateway crasha, non tocca gli altri container. Riproducibilità: la configurazione è codice, versionabile in Git. Scalabilità: puoi duplicare il gateway o i servizi dietro di esso senza toccare il sistema operativo. E soprattutto: niente più "sulla mia macchina funziona". Se funziona nel container, funziona ovunque.
Errore comune da evitare: non installare Nginx direttamente sull'host e poi "farlo girare insieme" ai container. Questo crea conflitti di porte, configurazioni duplicate e un incubo di manutenzione. Il gateway deve essere un container come gli altri, orchestrato dallo stesso compose file.
Come strutturare il docker-compose per Nginx come gateway
Il file docker-compose.yml è la tua mappa. Definisci i servizi, le reti e i volumi. Ecco una base funzionante che puoi copiare e adattare:
Sponsored Protocol
version: '3.8'
services:
nginx:
image: nginx:1.27-alpine
container_name: gateway
ports:
- "80:80"
- "443:443"
volumes:
- ./nginx/conf.d:/etc/nginx/conf.d:ro
- ./nginx/ssl:/etc/nginx/ssl:ro
- ./www:/var/www/html:ro
networks:
- frontend
restart: unless-stopped
app1:
image: node:20-alpine
# ... configurazione dell'app
networks:
- frontend
- backend
db:
image: postgres:16
# ... configurazione del database
networks:
- backend
networks:
frontend:
driver: bridge
backend:
driver: bridge
Nota le due reti: frontend e backend. Il gateway è solo sulla rete frontend, il database solo sulla backend, e l'app su entrambe. Questo è il pattern più sicuro: il database non è raggiungibile dall'esterno, il gateway non può parlare direttamente col DB. Se un attaccante compromette Nginx, non ha accesso ai dati.
Come configurare il file nginx.conf per il routing dinamico?
Il cuore del gateway è la configurazione. Dimentica i file enormi e monolitici. In Docker, ogni sito o servizio ha il suo file dentro conf.d. Ecco un esempio per inoltrare le richieste a un'applicazione containerizzata:
# /etc/nginx/conf.d/app1.conf
server {
listen 80;
server_name app1.example.com;
location / {
proxy_pass http://app1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Il nome app1 nel proxy_pass è il nome del servizio nel compose file. Docker risolve automaticamente il DNS interno. Questo è il vantaggio enorme: non devi conoscere gli IP dei container, cambiano a ogni ricreazione. Usa i nomi dei servizi.
Errore comune: dimenticare gli header X-Forwarded-*. Senza di essi, la tua app dietro il proxy non vede l'IP reale del visitatore, ma quello del container Nginx. Se fai geolocalizzazione, rate limiting o log di sicurezza, perdi il dato più importante.
Sponsored Protocol
Come gestire più servizi con Nginx in Docker
Hai tre servizi: un blog WordPress, una API Laravel e un frontend statico. Con il gateway, ognuno ha il suo server block. Ecco un esempio di configurazione multi-servizio:
# blog.conf
server {
listen 80;
server_name blog.example.com;
location / {
proxy_pass http://wordpress:80;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
# api.conf
server {
listen 80;
server_name api.example.com;
location / {
proxy_pass http://laravel:9000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
# static.conf
server {
listen 80;
server_name static.example.com;
root /var/www/html;
index index.html;
}
Ogni file è indipendente. Ne modifichi uno senza toccare gli altri. E il bello? Puoi testare la configurazione prima di applicarla. Nel prossimo paragrafo vediamo come.
Come testare e ricaricare la configurazione senza downtime?
Il momento più temuto: cambiare la configurazione del gateway e avere paura di far cadere il sito. Con Docker, il rischio si riduce quasi a zero. Ecco la procedura che usiamo noi in produzione:
- Modifica il file di configurazione sul tuo host.
- Testa la sintassi con:
docker exec gateway nginx -t - Se il test passa, ricarica con:
docker exec gateway nginx -s reload
Il comando reload è il segreto: Nginx ricarica la configurazione senza interrompere le connessioni attive. I clienti in corso non vedono nemmeno un millisecondo di pausa. E se il test fallisce, Nginx continua con la vecchia configurazione. Nessun downtime, nessun panico.
Errore comune: ricreare il container a ogni modifica con docker-compose up -d. Questo forza il riavvio e può causare una breve interruzione. Usa sempre reload per le modifiche alla configurazione di Nginx, non restart.
Come automatizzare il reload con un bind mount e un watchdog
Vuoi il massimo dell'automazione? Monta la directory di configurazione come volume e usa uno script che osserva i cambiamenti. Ecco un esempio con inotifywait:
Sponsored Protocol
#!/bin/bash
while inotifywait -r -e modify,create,delete /path/to/nginx/conf.d; do
docker exec gateway nginx -t && docker exec gateway nginx -s reload
done
Ogni volta che salvi un file, il gateway si ricarica da solo. Ma attenzione: questo script è utile in sviluppo, non in produzione. In produzione, usa un pipeline CI/CD che testa la configurazione prima di applicarla.
Come gestire SSL e HTTPS nel container Nginx?
La sicurezza non è opzionale. Se il tuo gateway parla solo HTTP, stai mandando i dati dei clienti in chiaro. Con Docker, la gestione dei certificati è pulita: monti i file SSL come volume e li referenzi nella configurazione. Ecco un esempio con certificati Let's Encrypt:
server {
listen 443 ssl;
server_name secure.example.com;
ssl_certificate /etc/nginx/ssl/fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers HIGH:!aNULL:!MD5;
location / {
proxy_pass http://app1:3000;
proxy_set_header Host $host;
proxy_set_header X-Forwarded-Proto $scheme;
}
}
Il volume ./nginx/ssl nel compose file deve contenere i certificati. Puoi generare i certificati con certbot sull'host e poi montarli, oppure usare un container dedicato come certbot che li rinnova automaticamente. Noi preferiamo la seconda: il rinnovo è un problema che non vuoi gestire a mano.
Errore comune: dimenticare il redirect da HTTP a HTTPS. Aggiungi un secondo server block che redirige tutto il traffico:
server {
listen 80;
server_name secure.example.com;
return 301 https://$host$request_uri;
}
Questo garantisce che nessun visitatore finisca per sbaglio sulla versione non sicura.
Come monitorare i log del container Nginx in tempo reale?
Un gateway senza log è come un contabile senza registri: stai navigando a vista. I log di Nginx ti dicono chi accede, cosa richiede, e cosa fallisce. In Docker, i log vanno su stdout e stderr — e Docker li cattura automaticamente. Per vederli in tempo reale:
Sponsored Protocol
# Segui i log del container
docker logs -f gateway
# Vedi solo le ultime 100 righe
docker logs --tail 100 gateway
Ma i log a terminale non bastano per l'analisi. Noi consigliamo di montare i log su un volume e usarli con uno strumento di aggregazione. Ecco come modificare il compose per esportare i log:
services:
nginx:
volumes:
- ./logs:/var/log/nginx
Così i file access.log e error.log sono sull'host, pronti per essere analizzati o inviati a un sistema come ELK o Grafana. Il log è la tua memoria storica: se un giorno qualcosa va storto, è lì che trovi la risposta.
Come ottimizzare le performance del gateway Nginx in Docker?
Un gateway lento è un collo di bottiglia per tutto il sistema. Ecco le regolazioni che facciamo noi, basate su anni di esperienza con clienti che hanno picchi di traffico:
- Keepalive: abilita le connessioni persistenti verso i servizi backend. Nel blocco
upstream:
upstream app_backend {
server app1:3000;
keepalive 32;
}
server {
location / {
proxy_pass http://app_backend;
proxy_http_version 1.1;
proxy_set_header Connection "";
}
}
Questo riduce il numero di handshake TCP e migliora la latenza. Testa sempre: usa strumenti come ab o wrk per misurare le richieste al secondo prima e dopo la modifica.
- Compressione: abilita gzip per ridurre il traffico. Ma attenzione: non comprimere immagini o video, sprechi CPU. Solo testo, JSON, HTML.
gzip on;
gzip_types text/plain text/css application/json application/javascript text/xml;
gzip_min_length 1024;
- Limiti di connessione: proteggi il gateway da attacchi DoS con
limit_req:
limit_req_zone $binary_remote_addr zone=api_limit:10m rate=10r/s;
server {
location /api/ {
limit_req zone=api_limit burst=20 nodelay;
proxy_pass http://app_backend;
}
}
Questo limita a 10 richieste al secondo per IP, con un burst di 20. Se un bot impazzito ti martella, non butta giù il server.
Quali errori evitare quando si usa Nginx con Docker in produzione?
Abbiamo visto troppi progetti rovinati da errori banali. Ecco i tre che ricorrono più spesso:
Sponsored Protocol
1. Montare i file di configurazione senza modalità read-only. Se il container può scrivere nella configurazione, un attaccante che compromette Nginx può modificare le regole di routing e dirottare il traffico. Usa sempre :ro nel volume.
2. Usare latest come tag dell'immagine. nginx:latest cambia a ogni release, e quello che funziona oggi potrebbe rompersi domani. Pina il tag a una versione specifica, come nginx:1.27-alpine. Noi usiamo sempre versioni Alpine: più leggere, più sicure, meno superficie d'attacco.
3. Non impostare restart: unless-stopped. Se il container muore per un errore, Docker lo riavvia automaticamente. Senza questa direttiva, il gateway resta giù finché non intervieni tu. E in produzione, ogni minuto di downtime è denaro perso.
Cosa fare adesso
Non serve riscrivere tutto lo stack in una notte. Ma puoi iniziare a muoverti subito con questi passi concreti:
- Prendi un servizio esistente — anche solo un sito statico — e metti Nginx in Docker come gateway. Copia il compose file di esempio e adattalo.
- Testa il reload senza paura — modifica un file di configurazione, esegui
docker exec gateway nginx -te poireload. Verifica che il sito non vada giù. - Aggiungi HTTPS — genera un certificato Let's Encrypt e configuralo nel container. Ogni giorno senza HTTPS è un giorno in cui i dati dei tuoi clienti sono esposti.
- Imposta i limiti di connessione — anche se non hai un attacco in corso, la protezione è come l'assicurazione: la vuoi prima dell'incidente.
- Leggi la documentazione ufficiale — la guida di riferimento per Nginx è nginx.org e per Docker Compose docs.docker.com. Noi li consultiamo ogni giorno, e dovresti farlo anche tu.
Se vuoi approfondire l'intera gestione di Nginx in produzione, parti dalla nostra guida pillar su Nginx. E se ti serve una mano con il tuo stack, noi di Meteora Web lavoriamo su queste tecnologie ogni giorno. Il tuo gateway non deve essere un punto di fragilità: può diventare il tuo punto di forza.
