Docker Composeలో అనేక ఫైళ్లను ఎలా merge చేయాలి

ఒకటి కంటే ఎక్కువ ఫైళ్లతో Compose చేసే పని

Docker Compose అనేక ఫైళ్ల నుంచి ఒకే project ను నిర్మించగలదు. ఇది ఆ ఫైళ్లను అందిన క్రమంలో చదివి, ఒకే model గా merge చేస్తుంది. అందువల్ల ఒకే value పై విరుద్ధత ఉంటే, తరువాతి ఫైల్‌లోని value అమలవుతుంది. కమాండ్ లైన్ నుంచి దీన్ని చేయడానికి రెండు విధానాలు ఉన్నాయి: Compose స్వయంగా load చేసే override file, మరియు మీరు చేతితో pass చేసే -f flag. మూడవ విధానం file లోనే ఉంటుంది. అది include element. ఇది మిగతా రెండింటికంటే భిన్నంగా పనిచేస్తుంది.

ఈ merge సాధారణ overwrite కాదు. Mappings key ప్రకారం merge అవుతాయి, sequences చివర append అవుతాయి, కొన్ని పరిమిత fields మాత్రం పూర్తిగా replace అవుతాయి. ఈ తేడానే అనూహ్య ఫలితాలకు కారణమవుతుంది. దాదాపు అందరికీ సమస్య కలిగించేది ports list.

క్రిందివన్నీ Compose v2 ను ఆధారంగా చేసుకున్నవి. అంటే పాత docker-compose script కు బదులుగా docker compose plugin ను ఉపయోగిస్తాయి. తనిఖీ చేయడానికి docker compose version అమలు చేయండి. మీరు ఇంకా Compose file రాయకపోతే, Docker Compose ప్రాథమికాల గైడ్ తో ప్రారంభించి తరువాత ఇక్కడికి తిరిగి రండి.

Compose చెప్పకుండానే లోడ్ చేసే override ఫైల్

docker compose up ను -f flag లేకుండా అమలు చేస్తే, 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 అందుబాటులో ఉంటే, వాటిని చేతితో నమోదు చేసినట్లే అవుతుంది.

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 వంటి ఇతర పేరును ఉపయోగించే file, దానిని -f తో స్పష్టంగా పేర్కొన్నప్పుడే లోడ్ అవుతుంది.

మీరు ఒక్క -f ను pass చేసిన వెంటనే automatic loading ఆగిపోతుంది. docker compose -f compose.yaml up ఆ ఒక్క file ను మాత్రమే చదివి override ను విస్మరిస్తుంది. ఈ లక్షణంపైనే ఈ guide లో తరువాతి dev మరియు prod pattern ఆధారపడి ఉంటుంది.

Server పై ఇది రెండు విధాలుగా ప్రభావితం చేస్తుంది. Deploy directory లో మిగిలిపోయిన override file, ఆ directory నుంచి అమలు చేసే ప్రతి bare docker compose command ద్వారా లోడ్ అవుతుంది. మీ cron job అమలు చేసే command కూడా ఇందులో ఉంటుంది. ఉద్దేశించని source directory ను production stack bind-mount చేయడానికి ఇదే కారణం కావచ్చు. ప్రతి deploy తర్వాత docker compose config ను అమలు చేసి, వచ్చిన output ను చదవండి. Deploy unattended గా నడిచేటప్పుడు, ఏదైనా తప్పు జరిగిందని మీకు తెలియజేసే వ్యవస్థ ఉంటేనే ఈ తనిఖీ ఉపయోగపడుతుంది. దీని కోసం cron job లేదా systemd OnFailure unit post చేయగల self-hosted ntfy server వంటి push channel ఉపయోగించాలి.

-fతో క్రమం, relative paths ఎక్కడ resolve అవుతాయి

Compose configuration ను మీరు files అందించే క్రమంలో రూపొందిస్తుంది. తరువాతి files, ముందు files లోని విలువలను override చేసి కొత్త విలువలను జోడిస్తాయి. ఎడమ నుంచి కుడికి, చివరిదే అమలవుతుంది.

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 ను run చేసి, ఒక file తో logs ను run చేస్తే, మీరు వేర్వేరు merged model లతో పని చేస్తున్నట్లే. దాంతో Compose వద్ద లేనట్లు చెప్పే service ఏర్పడటం సులభం. self-hosted Chatwoot support desk లోని database migration step వంటి one-off commands తో upgrades నిర్వహించే stack లో ప్రమాదం మరింత ఎక్కువ. ఇప్పటికే మీ services ఉపయోగిస్తున్న model కు బదులుగా, తప్పు file list తో జారీ చేసిన docker compose run వేరే model ను లక్ష్యంగా చేసుకోవచ్చు. File list ను ఒక్కసారి COMPOSE_FILE environment variable తో సెట్ చేయండి.

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 పై స్పష్టంగా సెట్ చేసిన ఏ విలువైనా environment variable కంటే ప్రాధాన్యత పొందుతుంది.

ఇప్పుడు bind mounts ను ప్రభావితం చేసే నియమం. -f తో multiple files ఉపయోగించినప్పుడు, ఆ files అన్నింటిలోని relative paths, వాటిని కలిగి ఉన్న file ఆధారంగా కాకుండా మొదటి file ఉన్న directory ఆధారంగా resolve అవుతాయి. deploy/prod/compose.prod.yaml లో ./data:/var/lib/postgresql/data ను రాసినా, Compose base file పక్కనే ./data కోసం వెతుకుతుంది. ఆ తప్పు path వద్ద Docker ఖాళీ directory ను సృష్టిస్తుంది. Container దానిలో ఏమీ లేకుండానే ప్రారంభమవుతుంది. ఇది data loss లాగా కనిపిస్తుంది, కానీ data loss కాదు. Base path ను మీరే సెట్ చేయడానికి --project-directory ను pass చేయండి. లేదా include ను ఉపయోగించండి. అది ప్రతి file ను దాని స్వంత directory ఆధారంగా resolve చేస్తుంది.

Project name కూడా అదే base directory నుంచి వస్తుంది. అందువల్ల మొదటగా ఉన్న file ను మార్చితే project పేరు మారవచ్చు. పేరు మారిన project కు కొత్త container names మరియు కొత్త volume names ఏర్పడతాయి. పాత volume పాత పేరు కింద disk పై అలాగే ఉంటుంది. దీనికి బదులుగా base file లో top-level name: తో project name ను స్థిరంగా సెట్ చేయండి.

name: myapp

ఏ fields merge అవుతాయి, ఏవి replace అవుతాయి

Compose field పేరును బట్టి కాకుండా, value రకాన్ని బట్టి merge చేస్తుంది.

• ఒకే value కలిగిన fields replace అవుతాయి. image, command, entrypoint మరియు mem_limit తర్వాతి value ను పూర్తిగా స్వీకరిస్తాయి. command కు ఒక argument ను append చేయలేరు, ఎందుకంటే override మొత్తం line ను తిరిగి రాస్తుంది.
• Mappings key ఆధారంగా merge అవుతాయి. environment, labels, volumes మరియు devices రెండు files లోని ప్రతి key ను ఉంచుతాయి. రెండు files లో ఒకే key ఉంటే, తర్వాతి file లోని value గెలుస్తుంది. environment మరియు labels కోసం key అనేది variable లేదా label పేరు. volumes మరియు devices కోసం key అనేది container path.
• Sequences append అవుతాయి. dns, dns_search, expose, tmpfs మరియు external_links కలిపి ఒకే sequence గా మారుతాయి. expose: ["3000"] కలిగిన base ను ["4000", "5000"] కలిగిన override తో merge చేస్తే ["3000", "4000", "5000"] ఉత్పత్తి అవుతుంది.

నాలుగు sequences లో identity key ఉంటుంది. అందువల్ల ఆ key ఒకేలా ఉన్న entries append కాకుండా merge అవుతాయి. volumes, secrets మరియు configs target ఆధారంగా match అవుతాయి. ports, ip, target, published మరియు protocol కలయిక ఆధారంగా match అవుతుంది.

ఆ ports rule ను రెండుసార్లు చదవండి. ఇక్కడే సాధారణంగా పొరపాటు జరుగుతుంది. నాలుగు భాగాలూ ఒకేలా ఉన్నప్పుడే రెండు port entries ఒకే entry గా పరిగణించబడతాయి. వాటిలో ఏదైనా ఒకదాన్ని మార్చితే Compose దాన్ని వేరే, సంబంధం లేని port గా పరిగణిస్తుంది. అందువల్ల రెండు entries ను ఉంచుతుంది.

override తర్వాత మీ port ఎందుకు ఇంకా published గానే ఉంది

ప్రతి interfaceపై ఒక service ను publish చేసే base file:

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

reverse proxy ముందుగా ఉండే కారణంగా, దాన్ని localhostకు మాత్రమే bind చేయడానికి రాసిన override:

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

ఇది పనిచేసిందని అనుకునే ముందు ఫలితాన్ని తనిఖీ చేయండి.

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

రెండు entries outputలో ఉన్నాయి. 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ను replace చేసి, merge rulesను వర్తింపజేయదు:

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

!override కు Compose v2.24.4 లేదా తర్వాతి version అవసరం. Portable పరిష్కారానికి ఎలాంటి tag అవసరం లేదు. ports ను base fileలో పూర్తిగా ఉంచకుండా, environment-specific filesలో మాత్రమే declare చేయండి. Merge చేయడానికి ఏదీ లేకపోతే leak అవ్వడానికి కూడా ఏదీ ఉండదు. దిగువ worked exampleలో ఇదే pattern ఉపయోగించబడింది.

బేస్ ఫైల్ సెట్ చేసిన విలువను తొలగించడం

!reset ఒక attribute ను తొలగిస్తుంది. దాంతో అది default విలువకు లేదా null కు తిరిగి వెళ్తుంది. ఇది ఒక విలువను స్వీకరించి పట్టించుకోదు. అందువల్ల చెల్లుబాటు అయ్యే ఖాళీ విలువను రాయాలి.

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

!reset కు Compose v2.24 లేదా అంతకంటే కొత్త వెర్షన్ అవసరం. బేస్ ఫైల్‌ను మీరు సవరించలేని సందర్భాల్లో, ఉదాహరణకు vendor fragment ను చేర్చుకున్నప్పుడు, దీనిని ఉపయోగించండి. ప్రచురించిన upstream stack దీనికి సరైన ఉదాహరణ. self-hosted AFFiNE workspace వెనుక ఉన్న Compose file మీరు రాయకపోయిన నాలుగు containers ను ప్రకటిస్తుంది. ఆ ఫైల్‌ను fork చేయకుండా, దాని మార్పులను ట్రాక్ చేసే బాధ్యత తీసుకోకుండా, వాటిలో ఒకదానిలోని ఒక attribute ను !reset ద్వారా తొలగించవచ్చు.

భాగాల నుంచి సమీకరించే stacks కోసం include

include మరో Compose application ను మీ model లోకి తీసుకువస్తుంది. ఇది top-level element, flag కాదు.

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

include లోని ప్రతి path ను ప్రత్యేక Compose application model గా load చేస్తుంది. ప్రతి model కు దాని స్వంత project directory ఉంటుంది. అందువల్ల ఆ file లోని relative paths, అదే file ఉన్న directory ఆధారంగా resolve అవుతాయి. ఇదే -f తో ఉన్న అసలు తేడా. Fragment మరో folder లేదా మరో repository లో ఉన్నప్పుడు include సరైన సాధనం కావడానికి ఇదే కారణం. మీరు రాయకపోయిన vendor stack సాధారణంగా ఇలాగే ఉంటుంది. ఉదాహరణకు self-hosted Authentik SSO install వెనుక ఉన్న multi-service Compose file, దాని స్వంత relative paths అలాగే ఉండేలా ప్రత్యేక directory లో ఉండవచ్చు. అదే సమయంలో మీ 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 చేసిన తర్వాత, వచ్చిన ఫలితాన్ని మీ model లోకి చేర్చుతుంది. Included file లోని relative paths ను resolve చేయడానికి ఉపయోగించే base path ను project_directory నిర్దేశిస్తుంది. Interpolation కోసం included file కు స్వంత variables ను env_file ఇస్తుంది. అందువల్ల shared fragment మీ project లోని .env ను తెలియకుండానే చదవదు. include కు Compose v2.20.0 లేదా అంతకంటే కొత్త version అవసరం. ఇప్పటికే నడుపుతున్న stack కు single-container add-on చేర్చేటప్పుడు కూడా ఇవే options ఉపయోగపడతాయి. ఉదాహరణకు Jellyfin library ను 90s rental storeలా రూపాంతరం చేసే Halcyon ను చేర్చవచ్చు. దాని file లో దాని స్వంత image tag మరియు స్వంత env_file ఉంటాయి. అందువల్ల దాన్ని upgrade చేయడానికి మీ media stack ఉన్న file ను మార్చాల్సిన అవసరం ఉండదు.

మీ file మరియు included file మధ్య duplicate resource names ఉంటే, వాటిని నిశ్శబ్దంగా merge చేయకుండా error గా report చేస్తుంది. ఇది ఉద్దేశపూర్వకమైన ప్రవర్తన. Included file ప్రకటించే ఏదైనా అంశాన్ని మార్చాలంటే, ఆ మార్పును compose.override.yaml లో ఉంచండి. Override assembled model పై వర్తిస్తుంది. అందువల్ల included resources తో collision లేకుండా వాటిని మార్చవచ్చు. ప్రతి release సమయంలో upstream file తిరిగి రాయబడే stack లతో ఈ పద్ధతి ముఖ్యంగా ఉపయోగపడుతుంది. ఉదాహరణకు PhotoPrism versus Immich లో పరిశీలించిన multi-container photo servers లో localhost binding లేదా అదనపు volume అవసరమైతే, దాన్ని override లో ఉంచాలి. తదుపరి upgrade సమయంలో భర్తీ అయ్యే file లో ఉంచకూడదు.

సంక్షిప్తంగా: include ప్రత్యేక applications ను సమీకరిస్తుంది; -f ఒకే application పై configuration layers ను వర్తింపజేస్తుంది.

ఒక VPSపై dev మరియు prod విభజన

మూడు ఫైళ్లలో మొత్తం నమూనా ఇలా ఉంటుంది. 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 వల్ల కేవలం container ఉన్నదని కాకుండా, ప్రతిస్పందించే database కోసం app వేచి ఉంటుంది. దీని వివరణ healthchecks మరియు depends_on conditionsలో ఉంది. POSTGRES_PASSWORD project .env file నుంచి interpolate అవుతుంది. ఆ file ఎప్పుడూ gitలో ఉండకూడదు. మరింత సురక్షితమైన విధానాల కోసం env files మరియు Compose secrets చూడండి.

తర్వాత compose.override.yaml ఉంటుంది. దీన్ని Compose స్వయంగా 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పై bare docker compose up ఈ రెండు files ను merge చేస్తుంది. command ఒకే విలువ కలిగినందున image default ను భర్తీ చేస్తుంది. LOG_LEVEL, info స్థానాన్ని భర్తీ చేస్తుంది, ఎందుకంటే environment key ఆధారంగా merge అవుతుంది. Bind mount మరియు publish చేసిన రెండు ports పూర్తిగా అదనపు అంశాలు. Database port localhostకు bind అవుతుంది. అందువల్ల shared networkలో ఉన్న laptop, ఆ networkలోని ఇతరులకు PostgreSQLను అందించదు.

చివరగా compose.prod.yaml ఉంటుంది. దాని పేరు Compose వెతికే పేర్లలో లేదు. కాబట్టి అది అనుకోకుండా ఎప్పుడూ 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 చదవబడలేదు. అందువల్ల 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గా ఉంటాయి.

ఒకే-service stack కూడా ఇదే నిర్మాణాన్ని ఉపయోగిస్తుంది. ఎందుకంటే self-hosted openGym workout tracker మొదటి passkeyను నమోదు చేయడానికి ముందు proxy వెనుక TLS ద్వారా ప్రతిస్పందించాలి. ports లేని base file stray public binding proxy కంటే ముందుగా ఆ trafficను స్వీకరించకుండా నిరోధిస్తుంది.

అమలు చేయడానికి ముందు merged model ను చదవండి

docker compose config పూర్తిగా merged, పూర్తిగా interpolated model ను ప్రింట్ చేస్తుంది. ఇది preview కాదు. Compose అమలు చేసే ఖచ్చితమైన input ఇదే. కాబట్టి output మీ అంచనాతో సరిపోలకపోతే, సరైనది output నే.

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} ను unexpanded గానే ఉంచుతుంది. Output ను ఎక్కడైనా paste చేయడానికి ముందు దీన్ని ఉపయోగించండి. ఎందుకంటే సాధారణ config ప్రతి resolved secret ను clear text లో ప్రింట్ చేస్తుంది. --services service names మాత్రమే జాబితా చేస్తుంది. మీరు ఊహించిన విధంగా ఒక include ను pull చేసిందో లేదో త్వరగా నిర్ధారించడానికి ఇది ఉపయోగపడుతుంది.

విఫలత పరిస్థితులు, మీరు చూసే ఫలితాలు

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 నుంచి deploy చేస్తే ఈ warning కనిపిస్తుంది. ఆ తర్వాత ప్రతి connection ను తిరస్కరించే database ఏర్పడుతుంది.

మీ override edit docker compose config లో కనిపించదు. మీరు -f pass చేసి ఉండవచ్చు. ఇది automatic override loading ను ఆపుతుంది. లేదా Compose parent directory లో compose.yaml ను కనుగొని ఉండవచ్చు. అప్పుడు మీ override file దాని పక్కన ఉండదు. ఇతర arguments లేకుండా docker compose config run చేస్తే Compose నిజంగా ఏ model ను build చేస్తోందో తెలుస్తుంది.

Bind mount ఖాళీగా ఉంది. మీరు అడగని directory ను Docker సృష్టించింది. Relative path మొదటి file ఉన్న directory ఆధారంగా resolve అయింది. Path ను సరిచేయండి, --project-directory pass చేయండి, లేదా fragment ను include వెనుకకు తరలించండి.

Containers కొత్త పేర్లతో తిరిగి వస్తున్నాయి, ఒక volume ఖాళీగా కనిపిస్తోంది. Project name మారింది. ఎందుకంటే project name మొదటి file ఉన్న directory ను అనుసరిస్తుంది. Base file లో top-level name: జోడించండి. అప్పుడు పేర్లు మారడం ఆగుతుంది. పాత volume పాత prefix కింద ఇంకా ఉంటుంది. docker volume ls దానిని చూపిస్తుంది.

Override లో తొలగించిన port ఇంకా open గా ఉంది. ports merge replace చేయకుండా append చేసింది. docker compose config తో నిర్ధారించండి. తరువాత !override ఉపయోగించండి లేదా ports ను base file నుంచి బయటకు తరలించండి.

FAQ

Compose స్వయంచాలకంగా compose.override.yaml ను load చేస్తుందా?

అవును. -f flag లేకుండా docker compose ను run చేసినప్పుడు ఇది జరుగుతుంది. Compose working directory మరియు దాని parent directories లో compose.yaml లేదా docker-compose.yaml కోసం search చేస్తుంది. Override file దాని పక్కన ఉంటే, దాన్ని రెండవదిగా load చేస్తుంది. గుర్తించబడే పేర్లు 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 లోని విలువలను override చేసి, కొత్త విలువలను జోడిస్తుంది. అందువల్ల ఒకే conflict ఉంటే command line లో చివర ఉన్న file కు ప్రాధాన్యం ఉంటుంది. ఆ 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 run చేస్తే రెండు entries కనిపిస్తాయి. Compose v2.24.4 లేదా ఆ తర్వాతి version లో ports: !override ఉపయోగించండి. లేదా base file నుంచి ports ను తొలగించండి. అప్పుడు merge చేయడానికి ఆ విలువ ఉండదు.

include మరియు -f మధ్య తేడా ఏమిటి?

-f అనేక files ను ఒకే application పై layers గా అమలు చేస్తుంది. ప్రతి file లోని relative path, మొదటి file ఉన్న directory ఆధారంగా resolve అవుతుంది. include ఒక ప్రత్యేక Compose application ను చేర్చుతుంది. చేర్చిన ప్రతి file తన స్వంత project directory ను ఉంచుకుంటుంది. అందువల్ల దాని relative paths ఆ file ఉన్న directory ఆధారంగా resolve అవుతాయి. మీ స్వంత stack లోని environment layers కోసం -f ఉపయోగించండి. వేరే చోట నిర్వహించే fragment కోసం include ఉపయోగించండి. include కు Compose v2.20.0 లేదా ఆ తర్వాతి version అవసరం.

Base file సెట్ చేసిన value ను ఎలా తొలగించాలి?

Compose v2.24 లేదా ఆ తర్వాతి version లో !reset tag ఉపయోగించండి. Override file లో ports: !reset [] లేదా MY_VAR: !reset null రాయండి. అప్పుడు ఆ attribute దాని default విలువకు లేదా null కు తిరిగి వెళుతుంది. Tag కు ఇచ్చే value తప్పనిసరి, కానీ దాన్ని పరిగణనలోకి తీసుకోరు. Attribute ను clear చేయకుండా replace చేయాలనుకుంటే !override ఉపయోగించండి. దీనికి v2.24.4 లేదా ఆ తర్వాతి version అవసరం.