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

एकापेक्षा अधिक फाइल्ससह 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 वापरले जाते. तपासण्यासाठी 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 वर परत ठेवते. ही command एक value घेते आणि तिच्याकडे दुर्लक्ष करते. त्यामुळे वैध पण रिकामी value लिहा.

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

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

भागांपासून तयार केलेल्या स्टॅकसाठी 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 मध्ये जोडला जातो. project_directory included file मधील relative paths resolve करण्यासाठी वापरला जाणारा base path निश्चित करते. env_file included file साठी interpolation करता येतील अशी स्वतंत्र variables देते. त्यामुळे shared fragment तुमच्या project मधील .env शांतपणे वाचत नाही. 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 आणि included file मध्ये resource names सारखी असल्यास ती शांतपणे merge केली जात नाहीत; error नोंदवला जातो. हे जाणीवपूर्वक केलेले आहे. Included file मध्ये घोषित केलेली एखादी गोष्ट बदलायची असल्यास तो बदल compose.override.yaml मध्ये ठेवा. Override assembled model वर लागू होतो. त्यामुळे included resources शी name conflict न करता त्यांच्यात बदल करता येतो. Upstream file प्रत्येक release वेळी पुन्हा लिहिला जाणारा stack असल्यास ही पद्धत विशेषतः उपयुक्त ठरते. उदाहरणार्थ, PhotoPrism विरुद्ध Immich मध्ये तुलना केलेले multi-container photo servers. अशा वेळी localhost binding किंवा अतिरिक्त volume तुमच्या override मध्ये असावे; पुढील upgrade वेळी बदलली जाणाऱ्या file मध्ये नसावे.

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

एका 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 हा command कोणत्याही -f flag शिवाय चालवता. Compose working 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 साठी हीच list वापरणे आवश्यक आहे. यासाठी 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 वर layers म्हणून लागू करते. प्रत्येक file मधील relative path पहिल्या file च्या directory नुसार resolve होतो. include स्वतंत्र Compose application समाविष्ट करते. प्रत्येक included path स्वतःची project directory ठेवतो. त्यामुळे त्याचे relative paths त्याच directory नुसार resolve होतात. तुमच्या स्वतःच्या stack मधील environment layers साठी -f वापरा. दुसऱ्या ठिकाणी maintain केलेल्या fragment साठी include वापरा. include साठी Compose v2.20.0 किंवा त्यानंतरची आवृत्ती आवश्यक आहे.

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

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