SSD Nodes Learn Hosting plans →
मार्गदर्शक Matt Connorद्वारे Matt Connor · अपडेटेड 2026-10-30

Docker Compose मध्ये अनेक फाइल्स कशा विलीन होतात?

compose.override.yaml आपोआप कधी लोड होते, फाइल्सचा क्रम कसा लागू होतो, ports list मुळे पोर्ट का उघडे राहते आणि dev-prod विभाजनासाठी include कसे वापरावे ते जाणून घ्या.

एकापेक्षा जास्त फाइल्ससह Compose काय करते

Docker Compose अनेक फाइल्समधून एक प्रोजेक्ट तयार करू शकते. ते फाइल्स मिळालेल्या क्रमाने वाचते आणि त्यांचे एकाच मॉडेलमध्ये विलिनीकरण करते. त्यामुळे परस्परविरोधी मूल्य असल्यास नंतरची फाइल ते मूल्य लागू करते. कमांड लाइनमधून हे करण्यासाठी दोन पद्धती आहेत: Compose स्वतःहून लोड करते ती override फाइल आणि तुम्ही स्वतः देत असलेला -f flag. तिसरी पद्धत फाइलमध्येच असते. ती include element आहे आणि ती दोन्ही पद्धतींपेक्षा वेगळ्या प्रकारे कार्य करते.

हे विलिनीकरण साधे overwrite नसते. Mappings चे key नुसार विलिनीकरण होते, sequences शेवटी जोडल्या जातात आणि काही मोजकी fields पूर्णपणे replace केली जातात. याच फरकामुळे अनपेक्षित परिणाम दिसतात. ports list मुळे जवळजवळ सर्वांनाच समस्या येते.

खालील सर्व माहिती Compose v2 किंवा त्यानंतरच्या आवृत्तीवर आधारित आहे. येथे जुन्या docker-compose script ऐवजी docker compose plugin गृहीत धरले आहे. सध्याच्या releases ला v5 असे क्रमांक दिले जातात आणि plugin त्याच प्रकारे कार्य करते. तपासण्यासाठी docker compose version चालवा. तुम्ही अद्याप Compose file लिहिली नसेल, तर Docker Compose मूलभूत माहिती मार्गदर्शक पासून सुरुवात करा आणि नंतर येथे परत या.

Compose स्वतः लोड करते ती override file

-f flag न देता docker compose up चालवल्यास Compose working directory आणि त्यानंतर तिच्या parent directories मध्ये compose.yaml किंवा docker-compose.yaml शोधते. Base file च्या शेजारी override file असल्यास Compose ती दुसरी file स्वतः लोड करते.

ls compose.yaml compose.override.yaml
docker compose up -d

दोन्ही files उपलब्ध असतील, तर त्यांचा परिणाम त्या files हाताने लिहून दिल्यासारखाच असतो.

docker compose -f compose.yaml -f compose.override.yaml up -d

Compose compose.override.yaml, compose.override.yml आणि जुनी docker-compose.override.yml व docker-compose.override.yaml ही नावे ओळखते. compose.dev.yaml सारखे इतर कोणतेही नाव -f वापरून स्पष्टपणे दिल्यावरच लोड केले जाते.

तुम्ही एकही -f दिल्यावर automatic loading थांबते. docker compose -f compose.yaml up नेमकी तीच एक file वाचते आणि override file दुर्लक्षित करते. या guide मधील dev आणि prod pattern याच गुणधर्मावर आधारित आहे.

याचा सर्व्हरवर चांगला आणि वाईट, दोन्ही प्रकारे परिणाम होऊ शकतो. Deploy directory मध्ये ठेवलेली override file त्या directory मधून चालवलेल्या प्रत्येक साध्या docker compose command ने लोड केली जाते. यात तुमचे cron job चालवणारे command देखील येते. त्यामुळे production stack मध्ये कोणालाही deploy करायचा नसलेला source directory bind-mount होऊ शकतो. प्रत्येक deploy नंतर docker compose config चालवा आणि तयार झालेला output वाचा. Deploy unattended असल्यास काहीतरी चूक झाली आहे हे कोणीतरी कळवले तरच ही तपासणी उपयुक्त ठरते. हे काम cron job किंवा systemd OnFailure unit कडून post करता येणाऱ्या self-hosted ntfy server सारख्या push channel चे आहे.

-f सह क्रम आणि सापेक्ष path कसे resolve होतात

Compose configuration तुम्ही files ज्या क्रमाने देता त्या क्रमाने तयार करते. त्यानंतरच्या files त्यांच्या आधीच्या files मधील settings override करतात आणि नवीन settings जोडतात. डावीकडून उजवीकडे वाचल्यास, शेवटची setting लागू होते.

docker compose -f compose.yaml -f compose.prod.yaml config
docker compose -f compose.yaml -f compose.prod.yaml up -d

त्या project मधील प्रत्येक command साठी हीच file list आवश्यक असते. दोन files सह up आणि एका file सह logs चालवल्यास तुम्ही वेगळ्या merged model शी संवाद साधत असता. Compose अस्तित्वात नसल्याचे सांगत असलेली service निर्माण होण्याचा हा जलद मार्ग आहे. One-off commands म्हणून upgrades चालवणाऱ्या stack मध्ये ही बाब अधिक महत्त्वाची ठरते. उदाहरणार्थ, self-hosted Chatwoot support desk मधील database migration step साठी चुकीच्या file list सह चालवलेले docker compose run तुमच्या services आधीपासून वापरत असलेल्या model ऐवजी वेगळ्या model वर शांतपणे लागू होते. त्याऐवजी COMPOSE_FILE environment variable वापरून ही list एकदाच निश्चित करा.

export COMPOSE_FILE=compose.yaml:compose.prod.yaml
docker compose config
docker compose up -d

Linux वर separator : आहे आणि COMPOSE_PATH_SEPARATOR तो बदलतो. COMPOSE_FILE project .env file मध्येही ठेवता येते. त्यामुळे तो तुमच्या shell history ऐवजी checkout चा भाग राहतो. Command line वर स्पष्टपणे सेट केलेली कोणतीही value environment variable पेक्षा प्राधान्याने लागू होते.

आता bind mounts मोडणारा नियम पाहू. -f सह अनेक files वापरताना त्या सर्व files मधील सापेक्ष paths पहिल्या file च्या directory च्या संदर्भात resolve होतात. ज्या file मध्ये path लिहिला आहे तिच्या संदर्भात ते resolve होत नाहीत. deploy/prod/compose.prod.yaml मध्ये ./data:/var/lib/postgresql/data लिहिल्यास Compose तरीही base file च्या शेजारी ./data शोधते. त्यानंतर Docker त्या चुकीच्या path वर रिकामी directory तयार करते आणि container तिच्यात कोणतीही सामग्री नसताना सुरू होतो. हे data loss सारखे दिसते, परंतु data loss झालेला नसतो. Base path स्वतः सेट करण्यासाठी --project-directory द्या किंवा include वापरा. include प्रत्येक file चा path तिच्या स्वतःच्या directory च्या संदर्भात resolve करते.

Project name त्याच base directory मधून घेतले जाते. त्यामुळे कोणती file प्रथम आहे ते बदलल्यास project चे नाव बदलू शकते. नाव बदललेल्या project मुळे नवीन container names आणि नवीन volume names तयार होतात. जुना volume मात्र जुन्या नावाखाली disk वरच राहतो. Base file मध्ये top-level name: देऊन project name निश्चित करा.

name: myapp

कोणती क्षेत्रे विलीन होतात आणि कोणती बदलली जातात

Compose क्षेत्राच्या नावानुसार नव्हे, तर मूल्याच्या प्रकारानुसार विलीन करते.

  • एकल-मूल्याची क्षेत्रे बदलली जातात. image, command, entrypoint आणि mem_limit नंतरचे मूल्य थेट स्वीकारतात. command मध्ये एक युक्तिवाद जोडता येत नाही, कारण override संपूर्ण ओळ पुन्हा लिहिते.
  • Mappings key नुसार विलीन होतात. environment, labels, volumes आणि devices दोन्ही फाइलमधील प्रत्येक key ठेवतात. दोन्ही फाइलमध्ये समान key असल्यास नंतरच्या फाइलमधील मूल्य लागू होते. environment आणि labels साठी key म्हणजे variable किंवा label चे नाव असते. volumes आणि devices साठी key म्हणजे container path असतो.
  • Sequences जोडल्या जातात. dns, dns_search, expose, tmpfs आणि external_links एकत्र जोडल्या जातात. expose: ["3000"] असलेली base आणि ["4000", "5000"] असलेला override विलीन केल्यास ["3000", "4000", "5000"] तयार होते.

चार sequences मध्ये identity key असते. त्यामुळे त्या key वर जुळणाऱ्या entries जोडल्या जाण्याऐवजी विलीन होतात. volumes, secrets आणि configs यांचा मेळ target वर होतो. ports चा मेळ ip, target, published आणि protocol यांच्या संयोगावर होतो.

ports हा नियम दोनदा वाचा, कारण इथेच सामान्यतः चूक होते. दोन port entries तेव्हाच एकच entry मानल्या जातात, जेव्हा त्या चारही भागांमध्ये समानता असते. त्यापैकी कोणताही एक भाग बदलल्यास Compose त्याला दुसरा, असंबंधित port मानते आणि दोन्ही entries ठेवते.

तुमच्या override नंतरही port का प्रकाशित राहतो

प्रत्येक interface वर service प्रकाशित करणारी base file:

services:
  web:
    image: nginx:1.27
    ports:
      - "8080:80"

Reverse proxy तिच्यासमोर ठेवला जाणार असल्यामुळे service ला फक्त localhost वर bind करण्यासाठी लिहिलेला override:

services:
  web:
    ports:
      - "127.0.0.1:8080:80"

ते कार्य केले असे गृहीत धरण्यापूर्वी परिणाम तपासा.

docker compose -f compose.yaml -f compose.prod.yaml config

Output मध्ये दोन्ही entries आहेत. ip हा भाग वेगळा आहे: 0.0.0.0 विरुद्ध 127.0.0.1. त्यामुळे merge च्या दृष्टीने हे दोन वेगवेगळे ports आहेत आणि तुम्ही काढण्याचा प्रयत्न केलेला public binding अजूनही model मध्ये आहे. Docker मध्ये याचे अधिक महत्त्व आहे, कारण published port तुमच्या firewall rules च्या आधी iptables मध्ये लिहिला जातो. ही यंत्रणा published Docker ports ufw ला का वळसा घालतात येथे स्पष्ट केली आहे.

यासाठी दोन उपाय आहेत. स्पष्ट उपाय म्हणजे !override tag. हा संपूर्ण attribute बदलतो आणि merge rules वगळतो:

services:
  web:
    ports: !override
      - "127.0.0.1:8080:80"

!override साठी Compose v2.24.4 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. Portable उपायासाठी कोणत्याही tag ची गरज नाही: ports base file मधून पूर्णपणे काढून टाका आणि ते फक्त environment-specific files मध्ये declare करा. Merge करण्यासाठी काहीच नसेल, तर अनावश्यकपणे leak होण्यासाठीही काहीच नसेल. खालील worked example मध्ये हीच पद्धत वापरली आहे.

बेस फाइलमध्ये सेट केलेली value हटवणे

!reset एखादा attribute काढून टाकतो आणि त्याला default value किंवा null वर परत ठेवतो. तो एक value घेतो आणि तिच्याकडे दुर्लक्ष करतो. त्यामुळे वैध आणि रिकामी value लिहा.

services:
  web:
    ports: !reset []
    environment:
      DEBUG: !reset null

!reset Compose v2.18.0 किंवा त्यानंतरच्या आवृत्त्यांमध्ये कार्य करते. !override उपलब्ध होण्याच्या काही releases आधीपासून हे समर्थित आहे. बेस फाइल तुमच्या नियंत्रणाखाली संपादित करता येत नसेल, उदाहरणार्थ vendor fragment म्हणून ती समाविष्ट केली असेल, तेव्हा !reset वापरा. प्रकाशित upstream stack हे याचे स्पष्ट उदाहरण आहे: self-hosted AFFiNE workspace मागील Compose file मध्ये तुम्ही न लिहिलेले चार containers घोषित केलेले आहेत. फाइलचा fork तयार करून त्याचा मागोवा ठेवण्याची जबाबदारी न घेता, त्यांपैकी एका container मधील एक attribute रिकामा करण्यासाठी !reset वापरता येतो.

भागांपासून तयार केलेल्या stack साठी include

include दुसरे Compose application तुमच्या model मध्ये समाविष्ट करते. हा top-level element आहे; flag नाही.

include:
  - path: ../commons/compose.yaml

include मधील प्रत्येक path स्वतंत्र Compose application model म्हणून load केला जातो. त्याची स्वतःची project directory असते. त्यामुळे त्या file मधील relative paths त्याच file च्या स्वतःच्या directory च्या संदर्भात resolve होतात. -f पेक्षा हा मुख्य फरक आहे. Fragment दुसऱ्या folder किंवा repository मध्ये असल्यास include हे योग्य साधन ठरते. तुम्ही तयार न केलेल्या vendor stack मध्ये हीच नेहमीची रचना असते. उदाहरणार्थ, self-hosted Authentik SSO install मागील multi-service Compose file स्वतःच्या directory मध्ये राहू शकते आणि तिचे relative paths जसेच्या तसे राखले जातात. तुमची file मात्र तुमच्या स्वतःच्या services पुरतीच राहते.

Long form मध्ये sub-options वापरता येतात.

include:
  - path:
      - ../monitoring/compose.yaml
      - ../monitoring/compose.vps.yaml
    project_directory: ../monitoring
    env_file: ../monitoring/.env

path list स्वीकारते. त्या files सामान्य नियमांनुसार merge केल्या जातात आणि त्यानंतर तयार झालेला result तुमच्या model मध्ये जोडला जातो. समाविष्ट केलेल्या file मधील relative paths resolve करण्यासाठी वापरला जाणारा base path project_directory ठरवते. समाविष्ट केलेली Compose file तिचे interpolation defaults ज्या file मधून घेते, ती file env_file निर्दिष्ट करते. त्याचा default आधीच त्या file च्या स्वतःच्या project directory मधील .env असतो. तरीही तुमच्या local project चे environment त्यावर precedence ठेवते. त्यामुळे fragment edit न करता त्यातील एखादा variable override करता येतो. include साठी Compose v2.20.0 किंवा त्यानंतरची आवृत्ती आवश्यक आहे. तुम्ही आधीच चालवत असलेल्या stack मध्ये single-container add-on जोडतानाही हेच options योग्य ठरतात. उदाहरणार्थ, Jellyfin library ला 90s rental store सारखे रूप देणारा Halcyon: त्याच्या file मध्ये स्वतःचा image tag आणि स्वतःचे env_file राहते. त्यामुळे ते upgrade करताना तुमचा media stack ज्या file मध्ये आहे ती file बदलावी लागत नाही.

Docker च्या documentation नुसार, तुमच्या file मध्ये आणि included file मध्ये समान resource name घोषित केल्यास conflict म्हणून request नाकारली जाते. सध्याच्या release मधील loader असे करत नाही. 2026-10-27 रोजी उपलब्ध असलेल्या loader source विरुद्ध केलेल्या तपासणीनुसार, Compose v5.6.1 मध्ये दोन्ही definitions merge केल्या जातात. Conflict असल्यास तुमच्या file मधील value वापरली जाते; loader error देऊन थांबत नाही. त्यामुळे duplicate name मुळे नेहमी स्पष्टपणे failure होईल असे गृहीत धरू नका. Included file मध्ये घोषित केलेली एखादी गोष्ट बदलायची असल्यास तो बदल compose.override.yaml मध्ये ठेवा. Override assembled model वर लागू होतो. त्यामुळे बदल स्पष्ट राहतो आणि एखादा release clash कसा हाताळतो यावर अवलंबून राहत नाही. Upstream file प्रत्येक release वेळी पुन्हा लिहिली जाणाऱ्या stack साठी ही पद्धत विशेषतः उपयुक्त आहे. उदाहरणार्थ, PhotoPrism विरुद्ध Immich मध्ये तुलना केलेल्या multi-container photo servers मध्ये localhost binding किंवा अतिरिक्त volume तुमच्या override मध्ये असावा. पुढील upgrade मध्ये बदलली जाणाऱ्या file मध्ये तो ठेवू नका.

थोडक्यात: include स्वतंत्र applications एकत्र compose करते; -f एका application वर configuration चे layers लावते.

एका VPS वर dev आणि prod वेगळे ठेवणे

हा संपूर्ण नमुना तीन files मध्ये आहे. Base file मध्ये सर्वत्र लागू असणाऱ्या गोष्टी घोषित केल्या आहेत आणि त्यात कोणतेही ports publish केलेले नाहीत.

name: myapp

services:
  app:
    image: ghcr.io/example/app:1.4.2
    environment:
      DATABASE_URL: postgres://app:${POSTGRES_PASSWORD}@db:5432/app
      LOG_LEVEL: info
    depends_on:
      db:
        condition: service_healthy
    restart: unless-stopped

  db:
    image: postgres:16
    environment:
      POSTGRES_USER: app
      POSTGRES_DB: app
      POSTGRES_PASSWORD: ${POSTGRES_PASSWORD}
    volumes:
      - db_data:/var/lib/postgresql/data
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U app -d app"]
      interval: 10s
      timeout: 5s
      retries: 5
    restart: unless-stopped

volumes:
  db_data:

depends_on condition मुळे app फक्त अस्तित्वात असलेल्या container ची वाट पाहत नाही. त्याऐवजी database कडून उत्तर मिळेपर्यंत ती प्रतीक्षा करते. याचे स्पष्टीकरण healthchecks आणि depends_on conditions मध्ये आहे. POSTGRES_PASSWORD हे project .env file मधून interpolate केले जाते. ही file git मध्ये कधीही ठेवू नका. अधिक सुरक्षित पर्यायांसाठी env files आणि Compose secrets पहा.

यानंतर compose.override.yaml आहे. Compose ही file आपोआप load करते. ही developer ची file आहे.

services:
  app:
    build: .
    command: npm run dev
    environment:
      LOG_LEVEL: debug
    ports:
      - "3000:3000"
    volumes:
      - ./src:/app/src

  db:
    ports:
      - "127.0.0.1:5432:5432"

Laptop वर साधा docker compose up वापरल्यास या दोन files merge होतात. command हे image default बदलते, कारण त्याची एकच value असते. LOG_LEVEL हे info बदलते, कारण environment key नुसार merge करते. Bind mount आणि publish केलेले दोन ports ही केवळ अतिरिक्त भर आहेत. Database port localhost वर bind केला आहे. त्यामुळे shared network वरील इतर laptop कडे PostgreSQL उपलब्ध होत नाही.

शेवटी compose.prod.yaml आहे. Compose ज्या files शोधते त्यांपैकी ही file नाही. त्यामुळे ती चुकून कधीही load होत नाही.

services:
  app:
    ports:
      - "127.0.0.1:8000:3000"
    deploy:
      resources:
        limits:
          memory: 512M

VPS वर दोन्ही files ची नावे स्पष्टपणे द्या. ही नावे देण्याची कृतीच override वगळते.

docker compose -f compose.yaml -f compose.prod.yaml config
docker compose -f compose.yaml -f compose.prod.yaml up -d
docker compose -f compose.yaml -f compose.prod.yaml ps

ps मध्ये दोन्ही services running म्हणून दिसल्या पाहिजेत आणि db मध्ये (healthy) दिसले पाहिजे. तुम्ही -f दिल्यामुळे compose.override.yaml read केले गेले नाही. त्यामुळे dev command, source bind mount आणि public port 3000 production पर्यंत पोहोचू शकत नाहीत, जरी ती file त्याच directory मध्ये असली तरी. Port 8000 फक्त localhost वर आहे आणि proxy साठी तयार आहे. दुसरी service जोडताना Traefik च्या मागे अनेक apps चालवणे पहा.

Server च्या .env मध्ये COMPOSE_FILE=compose.yaml:compose.prod.yaml सेट करा. त्यानंतर तुमच्या उर्वरित commands पुन्हा साध्या docker compose logs -f app commands राहतील.

एका service च्या stack ला देखील हीच रचना लागू होते. self-hosted openGym workout tracker ला पहिला passkey enrol करण्यापूर्वी proxy मागे TLS द्वारे उत्तर द्यावे लागते. त्यामुळे त्यात ports नसलेली base file वापरा. यामुळे एखादा अनपेक्षित public binding proxy पेक्षा आधी traffic स्वीकारणार नाही.

तैनात करण्यापूर्वी विलीन केलेले मॉडेल वाचा

docker compose config पूर्णपणे विलीन केलेले आणि पूर्णपणे इंटरपोलेट केलेले मॉडेल प्रिंट करते. हे पूर्वावलोकन नाही. Compose ज्या अचूक इनपुटवर कार्य करणार आहे तेच हे आहे. त्यामुळे आउटपुट तुमच्या अपेक्षेशी जुळत नसल्यास, आउटपुट योग्य आहे.

docker compose -f compose.yaml -f compose.prod.yaml config
docker compose -f compose.yaml -f compose.prod.yaml config --no-interpolate
docker compose -f compose.yaml -f compose.prod.yaml config --services

--no-interpolate मध्ये ${VAR} चा विस्तार केलेला नसतो. आउटपुट कुठेही पेस्ट करण्यापूर्वी याचा वापर करा, कारण साधे config प्रत्येक resolved secret स्पष्ट मजकुरात प्रिंट करते. --services फक्त सेवेची नावे सूचीबद्ध करते. त्यामुळे include ने अपेक्षित गोष्टी समाविष्ट केल्या आहेत का हे जलद पडताळता येते.

अपयशाची कारणे आणि दिसणारे परिणाम

no configuration file provided: not found. Compose ला वाचण्यासाठी काहीही सापडले नाही. तुम्ही project directory च्या बाहेर आहात किंवा COMPOSE_FILE मध्ये अस्तित्वात नसलेल्या path कडे निर्देश आहे. Compose default base file शोधण्यासाठी parent directories तपासते; मात्र तुम्ही स्वतः निर्दिष्ट केलेली file ती कुठेही शोधत नाही.

WARN[0000] The "POSTGRES_PASSWORD" variable is not set. Defaulting to a blank string. Interpolation project मधील .env file आणि shell environment यांच्या आधारे होते. येथे project directory ही पहिल्या -f file ची directory आहे. .env असलेल्या directory पेक्षा वेगळ्या directory मधून deployment केल्यास ही warning दिसते आणि त्यानंतर database प्रत्येक connection नाकारते.

तुमच्या override मधील बदल docker compose config मध्ये दिसत नाहीत. तुम्ही -f पास केले असावे; त्यामुळे automatic override loading बंद होते. किंवा Compose ला parent directory मध्ये compose.yaml सापडले असून तुमची override file त्याच्या शेजारी नाही. इतर कोणतेही arguments न देता docker compose config चालवल्यास Compose प्रत्यक्षात कोणते model तयार करत आहे ते कळते.

Bind mount रिकामा आहे आणि Docker ने तुम्ही न मागितलेली directory तयार केली आहे. Relative path पहिल्या file च्या directory च्या आधारे resolve झाला. Path दुरुस्त करा, --project-directory पास करा किंवा fragment ला include च्या मागे हलवा.

Containers नवीन नावांसह पुन्हा सुरू होतात आणि volume रिकामा दिसतो. Project name बदलले आहे, कारण project name पहिल्या file च्या directory वर आधारित असते. Base file मध्ये top-level name: जोडा; त्यामुळे naming बदलणे थांबेल. जुना volume जुन्या prefix अंतर्गत अद्याप उपलब्ध आहे आणि docker volume ls तो दाखवेल.

Override मध्ये काढलेला port अद्याप open आहे. ports merge ने replacement करण्याऐवजी entries append केल्या. docker compose config ने याची खात्री करा. त्यानंतर !override वापरा किंवा ports ला base file मधून बाहेर हलवा.

FAQ

Compose compose.override.yaml आपोआप लोड करते का?

होय, जेव्हा तुम्ही docker compose हे -f flag शिवाय चालवता. Compose कार्यरत directory आणि तिच्या parent directories मध्ये compose.yaml किंवा docker-compose.yaml शोधते. त्याच्या शेजारी override file असल्यास ती file दुसऱ्या क्रमांकाने लोड केली जाते. मान्य नावे compose.override.yaml, compose.override.yml, docker-compose.override.yml आणि docker-compose.override.yaml आहेत. कोणतेही -f दिल्यास ही प्रक्रिया बंद होते. त्यामुळे docker compose -f compose.yaml up फक्त एकच file वाचते.

अनेक -f files कोणत्या क्रमाने merge होतात?

डावीकडून उजवीकडे. तुम्ही files ज्या क्रमाने देता, त्या क्रमाने Compose configuration तयार करते. प्रत्येक file त्यापूर्वीच्या files मधील settings override करते आणि नवीन settings जोडते. त्यामुळे command line वरील शेवटच्या file ला कोणत्याही conflict मध्ये प्राधान्य मिळते. त्या project मधील प्रत्येक command साठी हीच यादी वापरावी लागते. यासाठी COMPOSE_FILE=compose.yaml:compose.prod.yaml वापरले जाते.

Override केल्यानंतरही माझा port published का राहतो?

कारण ports entries ची ओळख ip, target, published आणि protocol या सर्व घटकांच्या संपूर्ण संचावर आधारित असते. 8080:80 या base वर 127.0.0.1:8080:80 चे override केल्यास ip घटक वेगळा राहतो. त्यामुळे Compose त्याला दुसरा port मानते आणि दोन्ही ठेवते. docker compose config चालवल्यावर तुम्हाला या दोन entries दिसतील. Compose v2.24.4 किंवा त्यानंतरच्या आवृत्तीत ports: !override वापरा. किंवा base file मधून ports काढून टाका, म्हणजे merge करण्यासाठी काही उरणार नाही.

include आणि -f यांच्यात काय फरक आहे?

-f अनेक files एकाच application वर स्तरित करते. प्रत्येक file मधील relative path पहिल्या file च्या directory च्या संदर्भात resolve होतो. include स्वतंत्र Compose application समाविष्ट करते. समाविष्ट केलेल्या प्रत्येक file चा स्वतःचा project directory कायम राहतो. त्यामुळे तिचे relative paths तिच्याच संदर्भात resolve होतात. तुमच्या स्वतःच्या stack साठी environment layers वापरताना -f वापरा. इतरत्र maintain केलेला fragment समाविष्ट करण्यासाठी include वापरा. include साठी Compose v2.20.0 किंवा त्यानंतरची आवृत्ती आवश्यक आहे.

Base file ने सेट केलेली value कशी काढू?

Compose v2.18.0 किंवा त्यानंतरच्या आवृत्तीत !reset tag वापरा. Override file मध्ये ports: !reset [] किंवा MY_VAR: !reset null लिहा. त्यामुळे attribute त्याच्या default value वर किंवा null वर परत जाते. Tag ला दिलेली value आवश्यक असते, पण तिच्याकडे दुर्लक्ष केले जाते. Attribute clear करण्याऐवजी ती बदलायची असल्यास !override ते करते. त्यासाठी v2.24.4 किंवा त्यानंतरची आवृत्ती आवश्यक आहे.

हा लेख उपयुक्त होता का?

#docker-compose#docker#override#configuration#self-hosting