Come configurare una rete Docker dedicata per i backend dei reverse proxy

Eva Wong

IceWhale author

Eva Wong è la Technical Writer e smanettatrice residente di ZimaSpace. Una geek da sempre con una passione per homelab e software open-source, si specializza nel tradurre concetti tecnici complessi in guide accessibili e pratiche. Eva crede che l'auto-ospitare debba essere divertente, non intimidatorio. Attraverso i suoi tutorial, dà potere alla comunità di demistificare le configurazioni hardware, dalla costruzione del loro primo NAS al dominio dei container Docker.

How to Set Up a Dedicated Docker Network for Reverse-Proxy Backends - Zima Store Online

Collega il reverse proxy e ogni backend HTTP a una rete condivisa definita dall’utente; mantieni i database su reti private delle app.

Pubblicare ogni porta dei backend sull’host NAS non è necessario quando il proxy può risolvere i nomi dei servizi Compose su un bridge definito dall’utente. Un’architettura a due reti offre al proxy un percorso controllato verso i backend web, mentre i database restano raggiungibili solo dalle rispettive applicazioni. Definisci la proprietà delle reti, evita alias ambigui, decidi quali servizi richiedono accesso in uscita e verifica che le porte dell’host rimangano chiuse.

Traccia la matrice di raggiungibilità prevista

Elenca ogni connessione: client verso proxy, proxy verso backend, backend verso database, backend verso API esterne e amministratore verso endpoint di manutenzione. Indica protocollo, porta, nome DNS e se il percorso attraversa l’host.

Normalmente solo il reverse proxy dovrebbe pubblicare le porte 80 e 443. I backend espongono la propria porta applicativa alla rete Docker senza una mappatura ports sull’host. I database partecipano solo alla rete privata dell’app, salvo che sia richiesto un percorso di amministrazione esplicito.

Scegli nomi di servizio o alias di rete stabili e univoci. Il DNS Docker risolve i servizi sulle reti condivise definite dall’utente, ma alias generici come web possono entrare in conflitto quando molti progetti Compose sono collegati alla stessa rete del proxy.

Crea una rete condivisa per il proxy e una rete privata per l’app

Crea una volta sola la rete del proxy, contrassegnala come esterna in ogni progetto applicativo e collega il proxy insieme al backend previsto. In questo modo l’identità della rete rimane stabile quando un singolo progetto Compose viene ricreato.

Definisci una rete privata predefinita o denominata separata per ogni app e collega il suo backend e database. Il backend diventa il collegamento controllato tra il traffico del proxy e lo stato privato; il proxy non dovrebbe partecipare alla rete del database.

La documentazione sulle definizioni delle reti Compose illustra le reti esterne e il collegamento dei servizi in Compose. Considera una rete esterna come una risorsa il cui ciclo di vita è gestito al di fuori dello stack dell’app: la distribuzione deve verificare che esista invece di presumere che Compose la crei o la elimini.

networks:
  proxy:
    external: true
  app-private:
    internal: true
services:
  web:
    networks: [proxy, app-private]
  db:
    networks: [app-private]

Rimuovi le porte dell’host non necessarie e controlla il traffico in uscita

Dopo aver verificato il funzionamento del percorso del proxy, rimuovi le pubblicazioni delle porte dei backend sull’host. La dichiarazione expose può documentare la porta del container, ma non è un firewall; è l’appartenenza alla rete a determinare quali container possono connettersi.

Considera internal: true solo per le reti i cui membri non necessitano realmente di un percorso esterno. I backend che chiamano provider di identità, webhook, servizi di pacchetti o API remote potrebbero non funzionare su una rete solo interna. Usa una seconda rete con accesso in uscita quando il design dell’applicazione lo richiede.

Proteggi il socket Docker utilizzato per il rilevamento automatico del proxy. Un bind mount in sola lettura riduce le scritture accidentali, ma non rende innocuo il socket; un proxy del socket con accesso limitato o una configurazione statica offre una superficie di controllo più ristretta.

-15% OFF

ZimaBoard 2 - Mini server domestico per la tua grande idea

Single board computer zimaboard2

Verifica il DNS dei servizi, l’esposizione delle porte e l’isolamento

Dal container del proxy, risolvi il nome del servizio backend e richiama il relativo endpoint di stato sulla porta del container. Da un container non correlato, conferma che il nome o la connessione non siano disponibili, a meno che quel container non sia intenzionalmente collegato alla rete del proxy.

Esegui una scansione dell’host NAS da un altro dispositivo LAN e conferma che siano aperte solo le porte del proxy. Poi verifica TLS, intestazioni inoltrate, aggiornamenti WebSocket, caricamenti di grandi dimensioni e reindirizzamenti dell’applicazione tramite il nome host pubblico. La mappa dei servizi del server domestico dovrebbe registrare la rete del proxy come parte della mappa dei servizi del server domestico.

Esegui il rollback ripristinando la mappatura precedente delle porte solo per la diagnosi, non come dipendenza nascosta permanente. Interrompi la procedura se il proxy necessita di accesso diretto al database, se gli alias indirizzano al progetto sbagliato o se la rimozione di una porta dell’host interrompe un’integrazione non documentata.

FAQ

Una rete Docker esterna è automaticamente più sicura?

No. Il termine esterna descrive la proprietà del ciclo di vita, non la sicurezza. In genere ogni container collegato può comunicare secondo il comportamento del driver di rete e del firewall dell’host.

I servizi backend devono comunque dichiarare expose?

È facoltativo per la connettività su una rete definita dall’utente, ma può documentare la porta prevista del container. Non pubblica la porta sull’host.

La rete del proxy può essere contrassegnata come interna?

Solo se il proxy e il design di routing dispongono comunque dei percorsi in ingresso e in uscita necessari. Una rete interna blocca la normale connettività esterna per i container collegati e può interrompere i flussi dei certificati o dell’identità.

Perché usare i nomi dei servizi invece degli indirizzi IP dei container?

Gli indirizzi dei container possono cambiare dopo una ricreazione. Il rilevamento dei servizi Docker fornisce un nome stabile all’interno della rete condivisa, rendendo più duratura la configurazione del proxy.

Ripristina la baseline salvata, applica una volta la configurazione approvata, ripeti il carico di lavoro originale simile a quello di produzione, verifica il segnale di successo promesso e poi esegui il rollback documentato. Non chiudere la modifica finché log, tempistiche, autorizzazioni, capacità e output recuperato non corrispondono tutti ai criteri di accettazione.