Docker Compose Networking: Default Network at DNS

Ano ang ginagawa ng Compose bago magsimula ang app

Nagsisimula ang Docker Compose networking sa isang panuntunan: ang docker compose up ay gumagawa ng pribadong network para sa project, ikinakabit dito ang bawat service, at hinahayaan ang mga service na maabot ang isa’t isa gamit ang service name. Hindi mo kailangang magsulat ng kahit isang linyang networks: para makuha iyon. Karamihan ng kalituhan sa Compose networking ay dahil hindi alam na mayroon na ang default na network.

Narito ang isang maliit na file. I-save ito bilang compose.yaml sa isang directory na tinatawag na shop.

services:
  web:
    image: nginx:1.27
    ports:
      - "8080:80"
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example

I-start ito at tingnan kung ano ang ginawa ng Docker:

docker compose up -d
docker network ls

May network na ngayon sa listahan na tinatawag na shop_default. Pinapangalanan ito ng Compose bilang <project>_default, at ang default na project name ay ang lowercase na pangalan ng directory. I-override ito gamit ang docker compose -p myproject up -d o gamit ang top-level na name: myproject sa file. Ang driver nito ay bridge, isang virtual switch sa loob ng host. Bawat container ay nakakakuha ng address sa isang pribadong subnet, at ang outbound traffic ay isinasalin sa address ng host habang lumalabas.

Muling dine-delete ng docker compose down ang network na iyon. Dahil dito, maaaring panatilihing bukas ng isang lumang container mula sa dating project ang network: tatanggi ang Docker gamit ang error while removing network: network shop_default has active endpoints, at ang solusyon ay i-stop o i-remove ang container na nakakabit pa rito.

Kung bago sa iyo ang Compose, makatutulong na basahin muna ang layout ng Compose file at mga command para sa lifecycle, dahil ipinapalagay ng lahat ng sumusunod na kaya mong mag-start at mag-stop ng project.

DNS ayon sa pangalan ng service ang bahaging kadalasang hindi napapansin ng mga baguhan

Sa anumang network na tinukoy ng user, nagpapatakbo ang Docker ng naka-embed na DNS server na nakikita ng bawat container sa 127.0.0.11. Nire-resolve nito ang mga pangalan ng service sa kasalukuyang mga address ng container. Kaya naaabot ng web ang database sa hostname na db, sa port na 5432, nang walang anumang configuration.

docker compose exec web getent hosts db

Nagpi-print ito ng linyang gaya ng 172.18.0.2 db. Kung walang na-print, wala sa iisang network ang dalawang service.

Ang pagkakamaling halos lahat ay nagagawa kahit isang beses ay ang paggamit ng localhost sa application config. Sa loob ng isang container, ang localhost ay ang container na iyon, hindi ang host at hindi ang ibang service. Malinaw itong iniuulat ng mga Postgres client:

could not connect to server: Connection refused
	Is the server running on host "localhost" (127.0.0.1) and accepting
	TCP connections on port 5432?

Dapat ay postgresql://postgres:example@db:5432/postgres ang connection string. Ang bahagi ng host ay pangalan ng service.

May dalawang detalyeng makakatipid ng oras sa susunod. Nire-resolve ang mga pangalan batay sa kasalukuyang tumatakbo, kaya nagbibigay ang docker compose up -d --scale web=3 ng isang pangalan na may tatlong address, at itinatali ng client na walang katapusang nagca-cache ng DNS ang sarili nito sa isang patay na container. Wala namang name resolution ang legacy na bridge network na ginagamit ng isang plain docker run kapag walang --network, kaya hindi tugma sa nakikita mo ang mga payo tungkol sa container links mula 2016.

Hindi mo kailangan ang ports: para ikonekta ang dalawang serbisyo

Ang ports: ay nagpa-publish ng container port sa host. Para ito sa network traffic na dumarating mula sa labas ng Docker. Wala itong kinalaman sa traffic sa pagitan ng mga serbisyo, na gumagana na sa buong port range sa project network.

Kaya walang naidudulot na mabuti ang ports: - "5432:5432" na idinaragdag ng maraming tao sa kanilang database service, at nagdudulot pa ito ng seryosong panganib: inilalantad nito ang Postgres sa public interface ng server. Tanggalin ito. Kung kailangan itong maabot mula sa iyong laptop para sa migration, i-bind ito sa loopback gamit ang "127.0.0.1:5432:5432" at i-access ito sa pamamagitan ng SSH tunnel. Ipinaliwanag sa kung paano gumagana ang mga port at listening service sa Linux ang pagkakaiba ng listening socket, published port, at firewall rule.

Documentation lamang ang expose: sa Compose. Wala itong binubuksan dahil walang isinara sa pagitan ng mga container na nasa iisang network.

Kailan ang tama ang network_mode host, at ano ang kapalit nito

Inaalis ng host mode ang sariling network namespace ng container at direktang ginagamit ng proseso ang mga interface ng host.

services:
  probe:
    image: alpine:3.20
    network_mode: host
    command: sleep infinity

May mga lehitimong dahilan para gamitin ito. Hindi makikita ng prosesong kailangang makakita ng broadcast o multicast traffic sa local network ang traffic na iyon kapag nasa likod ito ng bridge, dahil hindi ipinapasa ng bridge ang traffic papunta sa container. Kabilang dito ang device discovery para sa media server o home automation hub. Kailangan din ng monitoring agent na nagbabasa ng interface counters ng host ang mga interface ng host. Iniiwasan din nito ang address translation hop, na mahalaga kapag mataas ang packet rate.

May partikular na kapalit ang paggamit nito.

Hindi na gumagana ang ports:. Nagbibigay ng babala ang Docker na itinatapon ang mga published port kapag ginagamit ang host network mode, at nagbi-bind ang container sa anumang bina-bind ng proseso nito. Magkakaroon ng conflict kapag dalawang host mode container ang parehong gustong gumamit ng port 8080, at mamamatay ang pangalawa na may bind: address already in use.

Hindi na gumagana sa dalawang direksiyon ang name resolution gamit ang service name. Wala ang container sa project network, kaya hindi nito ma-resolve ang db, at hindi rin ito ma-resolve ng ibang service. Maaabot lamang nito ang mga iyon sa pamamagitan ng mga port na naka-publish sa host, karaniwan sa 127.0.0.1.

Wala na ang isolation. Kapag nag-bind ang isang proseso sa 0.0.0.0 sa loob ng host mode container, nakikinig ito sa bawat interface ng server mo, pati sa public interface, katulad ng package na na-install gamit ang apt. May isang pakinabang ito: dumadaan ang traffic na ito sa normal na input path, kaya nalalapat dito ang mga rule ng UFW. Hindi ito totoo para sa published ports.

Linux Docker Engine feature ang host mode. Sinusuportahan lamang ito ng Docker Desktop mula version 4.34, at kailangan mo muna itong i-enable. May karagdagang limitasyon: hindi maaaring mag-bind ang mga container sa mga IP address ng host, at TCP at UDP lamang ang pinangangasiwaan. Kung kalahati ng team mo ay gumagamit ng Linux server at ang kalahati ay Docker Desktop, asahan mong magkakaiba ang magiging behavior ng parehong file.

Gamitin ang host mode kapag kailangan mo ang mga interface ng host. Huwag itong gamitin para ayusin ang problema sa koneksiyon, dahil karaniwan nitong pinapalitan ang isang problema ng mas mahirap na problema.

Ikonekta ang dalawang Compose project gamit ang external network

Ang network na ginawa ng isang project ay hindi nakikita ng ibang project. Kaya hindi makita ng reverse proxy sa proxy/compose.yaml ang app sa app/compose.yaml, kahit nasa iisang server ang mga ito. Ang solusyon ay isang network na hindi pagmamay-ari ng alinmang project.

Gawin ito nang isang beses, nang mano-mano:

docker network create edge

Pagkatapos, ideklara ito bilang external sa bawat project. Sa panig ng proxy:

services:
  proxy:
    image: traefik:v3.1
    ports:
      - "80:80"
      - "443:443"
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock:ro
    networks:
      - edge

networks:
  edge:
    name: edge
    external: true

Sa panig ng application:

services:
  app:
    image: nginx:1.27
    networks:
      - edge
      - internal
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    networks:
      - internal

networks:
  edge:
    name: edge
    external: true
  internal:

Sinasabi ng external: true sa Compose na kumonekta sa isang umiiral na network sa halip na gumawa ng bago, at iwan ito sa lugar sa docker compose down. Mas mahalaga kaysa sa inaakala ang hiwalay na name: key: kung wala ito, hahanapin ng Compose ang network na eksaktong pinangalanang edge. Gamit ito, maaari mong ibang pangalan ang gamitin para sa network sa file at sa host.

Kung hindi umiiral ang network, tatangging mag-start ang Compose at iuulat nitong idineklara ang network bilang external ngunit hindi ito natagpuan. Gawin muna ang network.

Pansinin kung ano ang ginagawa ng application file sa internal. Nasa project-local network lamang ang database, kaya hindi ito maaabot ng proxy at app lamang ang makakakonekta rito. Kapag idinagdag ang internal: true sa ilalim ng isang network, tuluyan ding inaalis ang route nito papunta sa labas. Magandang default ito para sa database, ngunit dapat mong malaman ang isang kapalit bago ito itakda: walang mada-download ang container sa internal network, kaya magha-hang at pagkatapos ay mabibigo dahil sa timeout ang entrypoint na nagpapatakbo ng apt-get update o pip install sa startup.

Para sa kumpletong setup na may routing rules at certificates, tingnan ang pagpapatakbo ng ilang app sa likod ng isang Traefik instance.

Ang mga naka-publish na port ay lumalampas sa UFW

Ito ang bahagi ng Compose networking na maaaring mauwi sa security incident. Nag-publish ka ng port, sinuri mong aktibo ang UFW at tinatanggihan nito ang lahat maliban sa SSH, pero naa-access pa rin mula sa internet ang service.

sudo ufw status
curl http://203.0.113.10:8080

Sinasabi ng UFW na naka-block ang port. Ibinabalik pa rin ng curl ang page. Walang sira. Direktang nagsusulat ang Docker ng sarili nitong address translation at forwarding rules sa iptables, at ipinapasa ang traffic papunta sa naka-publish na container port sa container sa halip na ihatid ito sa host. Kaya hindi ito dumaraan sa chain na pinamamahalaan ng UFW para sa traffic na lokal na nakalaan sa host. Tinitingnan din ang rules ng Docker bago ang rules ng UFW.

Ang maikling ayos ay i-publish lamang ang port kung saan mo ito kailangan:

    ports:
      - "127.0.0.1:8080:80"

Itinatali nito ang host side sa loopback, kaya naa-access ang port mula mismo sa server at sa pamamagitan ng SSH tunnel, ngunit hindi mula sa ibang lugar. Ilagay ang public entry point sa likod ng reverse proxy na sadyang nagpa-publish ng 80 at 443. Nasa kung bakit direktang lumalampas sa UFW ang Docker publishing at kung paano ito ayusin ang buong paliwanag, kabilang ang DOCKER-USER chain para sa mga sitwasyong kailangan mong mag-filter ng naka-publish na port.

Paano i-debug ito gamit ang apat na command

Magsimula sa pagtukoy kung saang network talaga nakakonekta ang bawat container:

docker network inspect shop_default

Inililista sa block na Containers ang bawat nakakonektang container at ang address nito. Ang serbisyong wala sa listahang iyon ay nasa ibang network, gumagamit ng host mode, o hindi tumatakbo.

Subukan ang name resolution mula sa isang pansamantalang container na nakakonekta sa parehong network. Sa ganitong paraan, hindi mo kailangan ng anumang tooling sa sarili mong images:

docker run --rm --network shop_default busybox nslookup db
docker run --rm --network shop_default busybox nc -zv db 5432

Ang nslookup na nagfa-fail ay nagpapahiwatig ng problema sa name resolution o network membership. Kung nagtatagumpay ang nslookup habang nagfa-fail ang nc, tumatakbo ang serbisyo ngunit hindi ito nakikinig sa port na iyon, o nakikinig ito sa 127.0.0.1 sa loob ng sarili nitong container sa halip na sa 0.0.0.0. Karaniwan ito sa mga development server. Ang dapat ayusin ay ang bind address ng application, hindi ang Docker.

May isa pang failure na maaaring mapagkamalang bug sa Docker. Kung nakakapag-communicate ang mga container sa isa't isa ngunit hindi nila maabot ang isang machine sa office o VPN network, malamang na nag-o-overlap ang Docker subnet sa network na iyon. Bilang default, nag-a-allocate ang Docker mula sa 172.17.0.0/16 pataas. Ilipat ang pool sa /etc/docker/daemon.json:

{
  "default-address-pools": [
    { "base": "10.200.0.0/16", "size": 24 }
  ]
}

Pagkatapos, patakbuhin ang sudo systemctl restart docker at likhain muli ang mga apektadong network, dahil pinananatili ng isang umiiral na network ang subnet na ginamit noong ginawa ito.

FAQ

Bakit hindi maabot ng aking mga container ang isa’t isa gamit ang service name?

Wala sila sa parehong network. Awtomatikong inilalagay ng Compose ang bawat service sa <project>_default, ngunit kapag nagdagdag ka ng listahang networks: sa isang service, iyon na ang kumpletong set ng mga network nito at hindi na ipinapahiwatig ang default. Patakbuhin ang docker network inspect <network> at tingnan kung parehong lumilitaw ang mga container sa block na Containers. Tingnan din kung walang service na gumagamit ng network_mode: host, dahil ang container na nasa host mode ay walang Docker network at hindi makakapag-resolve ng service names.

Kailangan ko bang mag-publish ng ports para maabot ng isang service ang isa pa?

Hindi. Sa isang Compose network, maaabot ng ibang container sa network ang bawat port ng bawat container. Ang ports: ay para lamang ilantad ang container sa network traffic mula sa labas ng Docker, at ang expose: ay dokumentasyon. Karaniwan at magastos na gawing public ang database port, dahil inilalagay nito ang database sa public interface ng iyong server.

Ano ang pagkakaiba ng bridge at host networking?

Binibigyan ng bridge ang container ng sarili nitong network namespace at address sa isang virtual switch, kasama ang awtomatikong name resolution sa pagitan ng mga container at pagsasalin ng outbound traffic. Direktang ginagamit ng host ang network stack ng host: walang hiwalay na address, walang resolution gamit ang service name, walang port publishing, at walang isolation mula sa iba pang listener ng host. Default ang bridge at ito ang tamang gamitin maliban kung kailangan ng proseso ang mga interface ng host.

Paano ko ikokonekta ang mga container mula sa 2 magkaibang Compose file?

Gumawa ng shared network gamit ang docker network create edge, pagkatapos ay ideklara ito sa parehong file gamit ang external: true at i-attach ang mga service na kailangang mag-usap. Hindi ito gagawin o buburahin ng Compose. Kung lalaktawan mo ang paggawa nito, tatangging mag-start ang Compose at iuulat na declared external ang network ngunit hindi ito natagpuan.

Bakit naaabot mula sa internet ang aking container kahit bina-block ng UFW ang port?

Dahil pinangangasiwaan ang published port ng forwarding rules na idinaragdag ng Docker sa iptables. Tinutugma ang mga rule na iyon bago ang mga rule ng UFW, at hindi dumadaan ang forwarded traffic sa chain na sini-filter ng UFW. I-bind ang host side sa loopback gamit ang "127.0.0.1:8080:80" at ilagay ang anumang public service sa likod ng reverse proxy sa ports 80 at 443.