Docker Compose நெட்வொர்க்கிங் செயல்படும் விதம்

உங்கள் செயலி தொடங்குவதற்கு முன் Docker Compose உருவாக்கும் கட்டமைப்புகள்

Docker Compose நெட்வொர்க்கிங் ஒரு விதியுடன் தொடங்குகிறது: docker compose up அந்தத் திட்டத்திற்காக ஒரு பிரத்யேக நெட்வொர்க்கை உருவாக்கி, ஒவ்வொரு சேவையையும் அதனுடன் இணைத்து, அந்தச் சேவைகள் ஒன்றையொன்று சேவைப் பெயரின் மூலம் தொடர்பு கொள்ள அனுமதிக்கிறது. இதைப் பெறுவதற்கு நீங்கள் ஒரு networks: வரியைக் கூட எழுத வேண்டியதில்லை. Compose நெட்வொர்க்கிங் குறித்த பெரும்பாலான குழப்பங்கள், இந்த இயல்புநிலை அமைப்பு ஏற்கனவே உள்ளது என்பதை அறியாததால் ஏற்படுகின்றன.

இதோ ஒரு சிறிய கோப்பு. இதை shop என்ற கோப்பகத்தில் compose.yaml என்ற பெயரில் சேமிக்கவும்.

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

இதை இயக்கி, Docker உருவாக்கியுள்ளதைப் பார்க்கவும்:

docker compose up -d
docker network ls

இப்போது பட்டியலில் shop_default என்ற நெட்வொர்க் உள்ளது. Compose இதற்கு <project>_default என்று பெயரிடுகிறது, மேலும் திட்டத்தின் பெயர் இயல்பாகவே கோப்பகத்தின் சிறிய எழுத்துக்களாக (lowercase) அமைகிறது. இதை docker compose -p myproject up -d மூலமாகவோ அல்லது கோப்பில் உள்ள உயர்மட்ட name: myproject மூலமாகவோ மாற்றியமைக்கலாம். இதன் டிரைவர் bridge ஆகும், இது ஹோஸ்டுக்குள் இருக்கும் ஒரு மெய்நிகர் சுவிட்ச் (virtual switch) ஆகும். ஒவ்வொரு கன்டெய்னரும் ஒரு பிரத்யேக சப்நெட்டில் முகவரியைப் பெறுகிறது, மேலும் வெளிச்செல்லும் டிராஃபிக் (outbound traffic) வெளியேறும்போது ஹோஸ்டின் முகவரிக்கு மாற்றப்படுகிறது (translated).

docker compose down அந்த நெட்வொர்க்கை மீண்டும் நீக்குகிறது. பழைய திட்டத்திலிருந்து எஞ்சியிருக்கும் ஒரு கன்டெய்னர் நெட்வொர்க்கைத் திறந்து வைத்திருப்பதால்தான் இது நிகழ்கிறது: Docker error while removing network: network shop_default has active endpoints என்ற பிழையைக் காட்டி மறுத்துவிடும், அதனுடன் இணைக்கப்பட்டுள்ள கன்டெய்னரை நிறுத்துவது அல்லது நீக்குவதே இதற்கான தீர்வாகும்.

நீங்கள் Compose-க்கு புதியவர் என்றால், Compose கோப்பு அமைப்பு மற்றும் வாழ்க்கைச் சுழற்சி கட்டளைகள் என்பதை முதலில் படிப்பது நல்லது, ஏனெனில் கீழே உள்ள அனைத்தும் ஒரு திட்டத்தைத் தொடங்கவும் நிறுத்தவும் உங்களுக்குத் தெரியும் என்ற அடிப்படையில் விளக்கப்பட்டுள்ளன.

DNS மூலம் சேவைப் பெயர்களைக் கண்டறிதல் ஆரம்பநிலையாளர்கள் தவறவிடும் ஒரு பகுதி

எந்தவொரு பயனர் வரையறுத்த network-லும், Docker ஒரு embedded DNS server-ஐ இயக்குகிறது. ஒவ்வொரு container-ம் இதை 127.0.0.11 முகவரியில் காணும். இது சேவைப் பெயர்களை (service names) தற்போதைய container முகவரிகளுக்கு மாற்றுகிறது. எனவே, web எந்தவிதமான கூடுதல் அமைப்புகளும் இன்றி, 5432 port-ல் உள்ள db என்ற hostname-ல் இருக்கும் database-ஐ அடையும்.

docker compose exec web getent hosts db

இது 172.18.0.2 db போன்ற ஒரு வரியை அச்சிடும். இது எதையும் அச்சிடவில்லை என்றால், அந்த இரண்டு service-களும் ஒரே network-ல் இல்லை என்று அர்த்தம்.

அனைவரும் ஒருமுறை செய்யும் தவறு, application config-ல் localhost-ஐப் பயன்படுத்துவது. ஒரு container-க்குள், localhost என்பது அந்த container-ஐ மட்டுமே குறிக்கும்; அது host-ஐயோ அல்லது மற்றொரு service-ஐயோ குறிக்காது. Postgres clients இதைத் தெளிவாகக் காட்டுகின்றன:

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?

Connection string postgresql://postgres:example@db:5432/postgres என்று இருக்க வேண்டும். Host பகுதி என்பது service-ன் பெயராக இருக்க வேண்டும்.

பிற்காலத்தில் நேரத்தை மிச்சப்படுத்தும் இரண்டு விவரங்கள்: பெயர்கள் தற்போது இயங்கிக்கொண்டிருக்கும் எதற்கும் பொருந்தும். எனவே, docker compose up -d --scale web=3 மூன்று முகவரிகளைக் கொண்ட ஒரு பெயரைத் தரும். DNS-ஐ எப்போதும் cache செய்யும் client, செயலிழந்த container-உடன் தன்னை இணைத்துக்கொள்ளும். மேலும், --network இல்லாமல் ஒரு சாதாரண docker run பயன்படுத்தும் பழைய bridge network-ஆல் container பெயர்களைக் கண்டறிய முடியாது. அங்குள்ள container-கள் IP முகவரி மூலம் மட்டுமே ஒன்றையொன்று கண்டறிய முடியும், மேலும் அவை host-ன் /etc/resolv.conf நகல் மூலம் வெளிப்படையான hostnames-ஐத் தேடும். இதனால்தான் 2016-ல் இருந்த container links குறித்த ஆலோசனைகள் தற்போது நீங்கள் காண்பவற்றுடன் ஒத்துப்போவதில்லை.

இரண்டு சேவைகளை இணைக்க உங்களுக்கு ports: தேவையில்லை

ports: என்பது ஒரு container-ன் port-ஐ host-ல் வெளியிடுகிறது. இது Docker-க்கு வெளியிலிருந்து வரும் traffic-க்காக மட்டுமே. இது சேவைக்கு-சேவை (service-to-service) இடையிலான traffic-க்குத் தேவையில்லை, ஏனெனில் project network-ல் உள்ள அனைத்து port-களும் ஏற்கனவே அவற்றுக்கிடையே செயல்படும்.

எனவே, பலர் தங்கள் database சேவைக்குச் சேர்க்கும் ports: - "5432:5432" எந்தப் பயனும் தராது, மாறாகத் தீமையே விளைவிக்கும்: இது Postgres-ஐ server-ன் public interface-ல் வெளிப்படுத்துகிறது. அதை நீக்கிவிடவும். ஒரு migration-க்காக உங்கள் laptop-லிருந்து அதை அணுக விரும்பினால், "127.0.0.1:5432:5432" மூலம் loopback-ல் bind செய்து, SSH tunnel வழியாக அணுகவும். ஒரு listening socket, published port மற்றும் firewall rule ஆகியவற்றிற்கு இடையிலான வேறுபாடுகள் Linux-ல் ports மற்றும் listening services எவ்வாறு செயல்படுகின்றன என்பதில் விளக்கப்பட்டுள்ளன.

expose: என்பது Compose-ல் ஆவணப்படுத்துதலுக்காக மட்டுமே. இது எதையும் திறப்பதில்லை, ஏனெனில் ஒரே network-ல் உள்ள containers-க்கு இடையே எதுவும் மூடப்பட்டிருக்கவில்லை.

network_mode host எப்போது சரியானது மற்றும் அதன் விளைவுகள்

Host mode, container-ன் சொந்த network namespace-ஐ நீக்கிவிட்டு, process-ஐ நேரடியாக host-ன் interfaces-ஐப் பயன்படுத்த அனுமதிக்கிறது.

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

இதற்குச் சில உண்மையான காரணங்கள் உள்ளன. Media server அல்லது home automation hub போன்றவற்றுக்கான device discovery போன்ற, local network-ல் broadcast அல்லது multicast traffic-ஐக் காண வேண்டிய ஒரு process, bridge-க்கு பின்னால் இருந்து அதைக் காண முடியாது. ஏனெனில், bridge அந்த traffic-ஐ container-க்கு அனுப்பாது. Host-ன் interface counters-ஐ வாசிக்கும் monitoring agent-க்கு host-ன் interfaces தேவை. மேலும், நீங்கள் address translation hop-ஐத் தவிர்க்கிறீர்கள், இது அதிக packet rates-ல் முக்கியமானது.

இதன் விளைவுகள் குறிப்பிட்டவை:

ports: வேலை செய்வதை நிறுத்திவிடும். Host network mode-ஐப் பயன்படுத்தும்போது published ports நிராகரிக்கப்படும் என்றும், process எதனுடன் இணைகிறதோ அதையே container-ம் பயன்படுத்தும் என்றும் Docker எச்சரிக்கிறது. ஒரே port 8080-ஐ விரும்பும் இரண்டு host mode container-கள் மோதிக்கொள்ளும், இரண்டாவது container bind: address already in use பிழையுடன் செயலிழக்கும்.

சேவை பெயர் மூலம் பெயர் கண்டறிதல் (Name resolution) இரண்டு திசைகளிலும் இருக்காது. Container project network-ல் இல்லாததால், அதால் db-ஐக் கண்டறிய முடியாது, மற்ற service-களாலும் இதைக் கண்டறிய முடியாது. இது பொதுவாக 127.0.0.1-ல் host-ல் publish செய்யப்பட்ட ports மூலம் அவற்றை அடைய முடியும். Linux-ல், இது ஒரு bridge container-ஐ அதன் IP முகவரி மற்றும் listening port மூலம் நேரடியாக அடைய முடியும். ஏனெனில், host அதன் bridge network-களில் உள்ள container-களுடன் திறந்த அணுகலைக் கொண்டுள்ளது மற்றும் host mode container, host-ன் network stack-ஐப் பகிர்ந்து கொள்கிறது. Container-கள் மீண்டும் உருவாக்கப்படும்போது அந்த முகவரிகள் மாறும், எனவே loopback-ல் publish செய்யப்பட்ட port ஒரு நிலையான வழியாகும்.

Isolation இருக்காது. Host mode container-க்குள் 0.0.0.0-ஐ bind செய்யும் ஒரு process, apt மூலம் நிறுவப்பட்ட ஒரு package-ஐப் போலவே, உங்கள் server-ன் ஒவ்வொரு interface-லும் கேட்கும் (listening). இதில் ஒரு நன்மை உண்டு: இந்த traffic சாதாரண input path-ஐப் பின்பற்றும், எனவே UFW விதிகள் இதற்குப் பொருந்தும், இது published ports-க்கு உண்மையானதல்ல.

Host mode என்பது ஒரு Linux Docker Engine வசதியாகும். Docker Desktop இதை 4.34 பதிப்பிற்குப் பிறகு மட்டுமே ஆதரிக்கிறது, அதுவும் நீங்கள் அதை enable செய்த பிறகு மட்டுமே. மேலும், container-களால் host IP முகவரிகளை bind செய்ய முடியாது மற்றும் TCP மற்றும் UDP மட்டுமே கையாளப்படும் போன்ற கூடுதல் கட்டுப்பாடுகள் உள்ளன. உங்கள் குழுவில் பாதி பேர் Linux server-களிலும், பாதி பேர் Docker Desktop-லும் இருந்தால், ஒரே கோப்பு வெவ்வேறு விதமாகச் செயல்படுவதை எதிர்பார்க்கலாம்.

Host-ன் interfaces தேவைப்படும்போது மட்டும் host mode-ஐத் தேர்ந்தெடுக்கவும். ஒரு connection சிக்கலைச் சரிசெய்ய இதை நாட வேண்டாம், ஏனெனில் இது பொதுவாக ஒரு சிக்கலை இன்னும் கடினமான மற்றொரு சிக்கலாக மாற்றும்.

இரண்டு Compose திட்டங்களை ஒரு external network மூலம் இணைத்தல்

ஒரு திட்டத்தால் உருவாக்கப்பட்ட network மற்றொன்றுக்குத் தெரியாது. இதனால்தான் proxy/compose.yaml-ல் உள்ள ஒரு reverse proxy, அதே server-ல் இருந்தாலும் app/compose.yaml-ல் உள்ள ஒரு app-ஐப் பார்க்க முடியாது. இதற்குத் தீர்வு, எந்தத் திட்டத்திற்கும் சொந்தமில்லாத ஒரு network-ஐப் பயன்படுத்துவதாகும்.

இதை ஒருமுறை கைமுறையாக உருவாக்கவும்:

docker network create edge

பிறகு, ஒவ்வொரு திட்டத்திலும் இதை external என்று அறிவிக்கவும். 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

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:

external: true, ஒரு புதிய network-ஐ உருவாக்குவதற்குப் பதிலாக ஏற்கனவே உள்ள ஒன்றில் இணையுமாறு Compose-க்குக் கட்டளையிடுகிறது, மேலும் docker compose down-ன் போது அதை அப்படியே விட்டுவிடுகிறது. தனித்தனி name: key பார்ப்பதை விட முக்கியமானது: இது இல்லையென்றால், Compose சரியாக edge என்று பெயரிடப்பட்ட network-ஐத் தேடும்; இது இருந்தால், உங்கள் கோப்பில் ஒரு பெயரையும் host-ல் மற்றொரு பெயரையும் பயன்படுத்தலாம்.

Network இல்லை என்றால், Compose தொடங்க மறுத்துவிடும் மற்றும் network external என்று அறிவிக்கப்பட்டும் அதைக் கண்டறிய முடியவில்லை என்று பிழையைக் காட்டும். எனவே, முதலில் அதை உருவாக்கவும்.

Application கோப்பு internal-ஐ எவ்வாறு பயன்படுத்துகிறது என்பதைக் கவனிக்கவும். Database அந்தத் திட்டத்திற்குரிய local network-ல் மட்டுமே இருப்பதால், proxy-ஆல் அதை அணுக முடியாது, app-ஆல் மட்டுமே முடியும். ஒரு network-ன் கீழ் internal: true-ஐச் சேர்ப்பது, வெளிப்புற உலகிற்கான அதன் தொடர்பை முழுமையாக நீக்கிவிடும். Database-க்கு இது ஒரு சிறந்த இயல்புநிலை (default) அமைப்பாகும், ஆனால் இதை அமைக்கும் முன் ஒரு விஷயத்தை நினைவில் கொள்ள வேண்டும்: internal network-ல் உள்ள ஒரு container-ஆல் எதையும் download செய்ய முடியாது. எனவே, தொடக்கத்தின் போது apt-get update அல்லது pip install-ஐ இயக்கும் ஒரு entrypoint, timeout ஆகித் தோல்வியடையும்.

Routing விதிகள் மற்றும் certificates கொண்ட முழுமையான செயல்பாட்டு அமைப்பிற்கு, ஒரே Traefik instance-க்கு பின்னால் பல செயலிகளை இயக்குதல் என்பதைப் பார்க்கவும்.

Published ports UFW-ஐத் தவிர்க்கின்றன

Compose networking-ல் இதுவே பாதுகாப்புச் சிக்கலுக்கு வழிவகுக்கும் பகுதியாகும். நீங்கள் ஒரு port-ஐ publish செய்கிறீர்கள், UFW active நிலையில் உள்ளதா மற்றும் SSH தவிர மற்ற அனைத்தையும் அது தடுக்கிறதா என்று சரிபார்க்கிறீர்கள், ஆனாலும் அந்த service இணையத்திலிருந்து அணுகக்கூடியதாகவே இருக்கும்.

sudo ufw status
curl http://203.0.113.10:8080

UFW அந்த port தடுக்கப்பட்டுள்ளதாகக் கூறுகிறது. ஆனாலும் curl அந்தப் பக்கத்தைக் காட்டுகிறது. இதில் எதுவும் பழுதடையவில்லை. Docker தனது சொந்த address translation மற்றும் forwarding விதிகளை நேரடியாக iptables-ல் எழுதுகிறது. ஒரு published container port-க்கு வரும் traffic, host-க்கு வழங்கப்படுவதற்குப் பதிலாக நேரடியாக container-க்கு அனுப்பப்படுகிறது. எனவே, உள்ளூர் traffic-க்காக UFW நிர்வகிக்கும் chain வழியாக அது செல்வதில்லை. மேலும், UFW-ன் விதிகளுக்கு முன்பாகவே Docker-ன் விதிகள் சரிபார்க்கப்படுகின்றன.

இதற்கான எளிய தீர்வு, உங்களுக்குத் தேவையான இடத்தில் மட்டும் port-ஐ publish செய்வதாகும்:

    ports:
      - "127.0.0.1:8080:80"

இது host-ன் பக்கத்தை loopback-உடன் இணைக்கிறது. எனவே, அந்த port-ஐ server-லிருந்தோ அல்லது SSH tunnel வழியாகவோ மட்டுமே அணுக முடியும், வேறு எங்கிருந்தும் அணுக முடியாது. பொதுவான entry point-ஐ, 80 மற்றும் 443 ports-ஐ முறையாகப் பயன்படுத்தும் ஒரு reverse proxy-க்கு பின்னால் வைக்கவும். நீங்கள் ஒரு published port-ஐ வடிகட்ட வேண்டிய சூழல்களுக்கான DOCKER-USER chain உள்ளிட்ட முழுமையான விளக்கம் Docker ஏன் UFW-ஐத் தாண்டி port-ஐ publish செய்கிறது மற்றும் அதை எப்படிச் சரிசெய்வது என்பதில் உள்ளது.

நான்கு கட்டளைகளில் பிழைத்திருத்தம் செய்வது எப்படி

ஒவ்வொரு container-ம் உண்மையில் எந்த network-ல் உள்ளது என்பதைக் கேட்பதன் மூலம் தொடங்கவும்:

docker network inspect shop_default

Containers தொகுதி, இணைக்கப்பட்ட ஒவ்வொரு container-ஐயும் அதன் முகவரியுடன் பட்டியலிடுகிறது. அந்தப் பட்டியலில் விடுபட்ட ஒரு service, வேறொரு network-ல் அல்லது host mode-ல் அல்லது இயங்காமல் இருக்கலாம்.

அதே network-ல் இணைக்கப்பட்ட ஒரு தற்காலிக container-லிருந்து பெயர் கண்டறிதலைச் சோதிக்கவும், இதன் மூலம் உங்கள் சொந்த images-க்குள் எந்தக் கருவியும் தேவையில்லை:

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

nslookup தோல்வியடைவது, பெயர் கண்டறிதல் அல்லது network உறுப்பினர் நிலையில் சிக்கல் இருப்பதைக் குறிக்கிறது. nslookup வெற்றிபெற்று, nc தோல்வியடைந்தால், பெயரும் network-ம் சரியாக உள்ளன, சிக்கல் connection-ல் மட்டுமே உள்ளது. nc, Connection refused என்று காட்டினால், service அந்த port-ல் கேட்கவில்லை அல்லது அது 0.0.0.0-க்கு பதிலாக அதன் சொந்த container-க்குள் 127.0.0.1-ல் கேட்கிறது என்று அர்த்தம். இது development server-களில் பொதுவானது, இதற்கான தீர்வு Docker-ல் இல்லை, application-ன் bind முகவரியில்தான் உள்ளது. nc செயலிழந்து நேரம் முடிந்துவிட்டால் (times out), firewall விதி அல்லது இடைநிறுத்தப்பட்ட (paused) அல்லது பதிலளிக்காத container போன்ற traffic-ஐத் தடுக்கும் ஏதேனும் ஒன்றைத் தேடவும்.

Docker பிழை போலத் தோன்றும் மற்றொரு தோல்வி: container-கள் தங்களுக்குள் பேசிக்கொள்ள முடிந்தாலும், உங்கள் அலுவலகம் அல்லது VPN network-ல் உள்ள ஒரு machine-ஐ அடைய முடியாவிட்டால், Docker subnet அந்த network-உடன் மேலெழுகிறது (overlaps) என்று அர்த்தம். Docker முன்னிருப்பாக 172.17.0.0/16-லிருந்து முகவரிகளை ஒதுக்குகிறது. /etc/docker/daemon.json-ல் pool-ஐ மாற்றவும்:

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

பிறகு sudo systemctl restart docker-ஐ இயக்கி, பாதிக்கப்பட்ட network-களை மீண்டும் உருவாக்கவும். ஏனெனில், ஏற்கனவே உள்ள ஒரு network அது உருவாக்கப்பட்ட அதே subnet-ஐத் தக்கவைத்துக்கொள்ளும்.

FAQ

எனது containers ஏன் service name மூலம் ஒன்றையொன்று தொடர்பு கொள்ள முடியவில்லை?

அவை ஒரே network-ல் இல்லை. Compose ஒவ்வொரு service-ஐயும் தானாகவே <project>_default-ல் சேர்க்கிறது. ஆனால், நீங்கள் ஒரு service-க்கு networks: பட்டியலைச் சேர்த்தவுடன், அந்தப் பட்டியல் மட்டுமே அதன் முழுமையான network தொகுப்பாகிவிடும்; இயல்பான (default) network இனி அதில் இருக்காது. docker network inspect <network> கட்டளையை இயக்கி, இரண்டு containers-ம் Containers தொகுதியில் உள்ளனவா என்று சரிபார்க்கவும். மேலும், எந்த service-ம் network_mode: host-ஐப் பயன்படுத்தவில்லை என்பதை உறுதிப்படுத்தவும்; ஏனெனில் host mode-ல் உள்ள container எந்த Docker network-லும் இருக்காது, அதனால் service name-களை resolve செய்ய முடியாது.

ஒரு service மற்றொன்றைத் தொடர்பு கொள்ள ports-ஐ publish செய்ய வேண்டுமா?

தேவையில்லை. ஒரு Compose network-ல், ஒரு container-ன் அனைத்து ports-ம் அந்த network-ல் உள்ள பிற containers-க்கு அணுகக்கூடியவை. ports: என்பது Docker-க்கு வெளியிலிருந்து வரும் traffic-ஐ அனுமதிக்க மட்டுமே பயன்படுகிறது, expose: என்பது ஆவணப்படுத்துதலுக்காக மட்டுமே. database port-ஐ publish செய்வது பொதுவான மற்றும் ஆபத்தான பழக்கமாகும், ஏனெனில் இது உங்கள் server-ன் public interface-ல் database-ஐ வெளிப்படையாக வைக்கிறது.

bridge மற்றும் host networking-க்கு என்ன வித்தியாசம்?

Bridge முறை container-க்கு அதன் சொந்த network namespace மற்றும் virtual switch-ல் ஒரு முகவரியை வழங்குகிறது; இது containers-க்கு இடையே தானியங்கி பெயர் தீர்மானிப்பு (name resolution) மற்றும் outbound traffic மாற்றத்தை (translation) செய்கிறது. Host முறை container-க்கு host-ன் network stack-ஐ நேரடியாக வழங்குகிறது: இதில் தனி முகவரி கிடையாது, service name மூலம் பெயர் தீர்மானிக்க முடியாது, port publishing கிடையாது, மேலும் host-ன் பிற listeners-லிருந்து எந்தப் பாதுகாப்பும் (isolation) கிடையாது. Bridge முறையே இயல்பானது மற்றும் சரியான தேர்வாகும்; process-க்கு host-ன் interfaces தேவைப்பட்டால் ஒழிய இதையே பயன்படுத்தவும்.

இரண்டு வெவ்வேறு Compose files-ல் உள்ள containers-ஐ எவ்வாறு இணைப்பது?

docker network create edge மூலம் பகிரப்பட்ட network ஒன்றை உருவாக்கவும். பின், இரண்டு கோப்புகளிலும் external: true மூலம் அதை அறிவித்து, தொடர்பு கொள்ள வேண்டிய services-ஐ அதனுடன் இணைக்கவும். Compose இதை உருவாக்கவோ அல்லது நீக்கவோ செய்யாது. நீங்கள் உருவாக்கும் படியைத் தவிர்த்தால், network external என்று அறிவிக்கப்பட்டும் அது கிடைக்கவில்லை என்று கூறி Compose தொடங்க மறுத்துவிடும்.

UFW port-ஐத் தடுத்தும், எனது container ஏன் இணையத்திலிருந்து அணுக முடிகிறது?

ஏனெனில், publish செய்யப்பட்ட port-ஐ Docker-ன் iptables forwarding விதிகள் கையாளுகின்றன. அந்த விதிகள் UFW விதிகளை விட முன்னதாகவே பொருந்தும், மேலும் forwarded traffic UFW வடிகட்டும் சங்கிலி (chain) வழியாகச் செல்வதில்லை. host-ன் பக்கத்தை "127.0.0.1:8080:80" மூலம் loopback-க்கு பிணைக்கவும் (bind), பொதுமக்களுக்குத் தேவையான அனைத்தையும் ports 80 மற்றும் 443-ல் உள்ள reverse proxy-க்கு பின்னால் வைக்கவும்.