Så här konfigurerar du ett dedikerat Docker-nätverk för reverse proxy-backendservrar

Anslut reverse proxyn och varje HTTP-backend till ett gemensamt användardefinierat nätverk; håll databaserna på privata appnätverk.

Det är onödigt att publicera varje backend-port på NAS-värden när proxyn kan slå upp Compose-tjänsternas namn på en användardefinierad brygga. Ett tvånätverksmönster ger proxyn en kontrollerad väg till webbbackends, medan databaserna förblir nåbara endast för sina applikationer. Definiera nätverksägarskap, undvik tvetydiga alias, avgör vilka tjänster som behöver utgående åtkomst och verifiera att värdportarna förblir stängda.

Skapa den avsedda åtkomstmatrisen

Lista varje anslutning: klient till proxy, proxy till backend, backend till databas, backend till externa API:er och administratör till underhållsslutpunkter. Markera protokoll, port, DNS-namn och om vägen passerar värden.

Normalt bör endast reverse proxyn publicera portarna 80 och 443. Backends exponerar sin applikationsport för Docker-nätverket utan en ports-mappning till värden. Databaser ansluts endast till det privata appnätverket, om inte en uttrycklig administrationsväg krävs.

Välj stabila och unika tjänstenamn eller nätverksalias. Docker DNS slår upp tjänster på gemensamma användardefinierade nätverk, men generiska alias som web kan kollidera när många Compose-projekt ansluter till samma proxynätverk.

Skapa ett gemensamt proxynätverk och ett privat appnätverk

Skapa proxynätverket en gång, markera det som externt i varje applikationsprojekt och anslut proxyn samt den avsedda backend-tjänsten. Då förblir nätverksidentiteten stabil när ett enskilt Compose-projekt återskapas.

Definiera ett separat standardnätverk eller namngivet privat nätverk för varje app och anslut dess backend och databas. Backend blir den kontrollerade bryggan mellan proxytrafik och privat tillstånd; proxyn bör inte anslutas till databasnätverket.

Dokumentationen om Compose-nätverksdefinitioner beskriver externa nätverk och hur tjänster ansluts i Compose. Betrakta ett externt nätverk som livscykelhanterat utanför appstacken: distributionen måste kontrollera att det finns, i stället för att anta att Compose ska skapa eller ta bort det.

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

Ta bort onödiga värdportar och granska utgående trafik

När proxyrutten fungerar tar du bort publiceringen av backend-portar på värden. Deklarationen expose kan dokumentera containerporten, men är ingen brandvägg; nätverksmedlemskap avgör vilka containrar som kan ansluta.

Använd internal: true endast för nätverk vars medlemmar verkligen inte behöver någon extern rutt. Backends som anropar identitetsleverantörer, webhooks, pakettjänster eller fjärr-API:er kan sluta fungera på ett enbart internt nätverk. Använd ett andra nätverk med utgående åtkomst när applikationsdesignen kräver det.

Skydda Docker-socketen som används för automatisk proxyupptäckt. En skrivskyddad bind-montering minskar risken för oavsiktliga skrivningar, men gör inte socketen ofarlig; en begränsad socket-proxy eller statisk konfiguration ger en mindre kontrollyta.

-15% OFF

ZimaBoard 2 - Minihemmserver för din stora idé

Single board computer zimaboard2

$339.00 - $519.00

Buy Now

Verifiera tjänste-DNS, portexponering och isolering

Från proxycontainern slår du upp backend-tjänstens namn och begär dess hälsoslutpunkt på containerporten. Från en orelaterad container bekräftar du att namnet eller anslutningen inte är tillgänglig, såvida containern inte avsiktligt finns på proxynätverket.

Skanna NAS-värden från en annan enhet i det lokala nätverket och bekräfta att endast proxyportarna är öppna. Testa sedan TLS, vidarebefordrade huvuden, WebSocket-uppgraderingar, stora uppladdningar och applikationens omdirigeringar via det publika värdnamnet. Tjänstekartan för hemservern bör registrera proxynätverket som en del av hemserverns tjänstekarta.

Återställ genom att återinföra den tidigare portmappningen endast för felsökning, inte som ett permanent dolt beroende. Avbryt om proxyn behöver direktåtkomst till databasen, alias routar till fel projekt eller om borttagning av en värdport bryter en odokumenterad integration.

Vanliga frågor 

Är ett externt Docker-nätverk automatiskt säkrare?

Nej. Externt beskriver livscykelägarskap, inte säkerhet. Varje ansluten container kan i allmänhet kommunicera enligt nätverksdrivrutinens och värdbrandväggens beteende.

Bör backend-tjänster fortfarande deklarera expose?

Det är valfritt för anslutning på ett användardefinierat nätverk, men kan dokumentera den avsedda containerporten. Det publicerar inte porten på värden.

Kan proxynätverket markeras som internt?

Endast om proxyn och routningsdesignen fortfarande har de nödvändiga inkommande och utgående vägarna. Ett internt nätverk blockerar normal extern anslutning för anslutna containrar och kan bryta certifikat- eller identitetsflöden.

Varför använda tjänstenamn i stället för container-IP-adresser?

Containeradresser kan ändras efter återskapande. Dockers tjänsteupptäckt tillhandahåller ett stabilt namn inom det gemensamma nätverket, vilket gör proxykonfigurationen mer hållbar.

återställ den sparade baslinjen, tillämpa den godkända konfigurationen en gång, upprepa den ursprungliga produktionsliknande arbetsbelastningen, verifiera den utlovade signalen för lyckat resultat och genomför sedan den dokumenterade återställningen. Stäng inte ändringen förrän loggar, tidsåtgång, behörigheter, kapacitet och återställd utdata överensstämmer med acceptanskriterierna.