SSD Nodes Learn Hosting plans →

கல்வி வழிகாட்டிகள்

ஆல் Matt Connor 2026-07-30 · புதுப்பிக்கப்பட்டது 2026-08-30

Docker Compose பல கோப்புகளை கையாள்வது எப்படி?

Docker Compose-ல் பல கோப்புகளை இணைக்கும் முறை, compose.override.yaml தானாக இயங்கும் விதம் மற்றும் ports மோதல்களைத் தவிர்க்கும் வழிமுறைகளை இந்த வழிகாட்டியில் விரிவாகக் காணலாம்.

ஒன்றுக்கும் மேற்பட்ட கோப்புகளைக் கொண்டு Compose செயல்படும் விதம்

Docker Compose பல கோப்புகளைக் கொண்டு ஒரு project-ஐ உருவாக்க முடியும். அது கோப்புகளைப் பெறும் வரிசையிலேயே வாசித்து, அவற்றை ஒரே மாதிரியாக (model) இணைக்கும். ஏதேனும் மதிப்புகளில் முரண்பாடு ஏற்பட்டால், கடைசியாக வாசிக்கப்படும் கோப்பின் மதிப்பே எடுத்துக்கொள்ளப்படும். கட்டளை வரியிலிருந்து (command line) இதைச் செய்ய இரண்டு வழிமுறைகள் உள்ளன: Compose தானாகவே ஏற்றும் override கோப்பு மற்றும் நீங்கள் கைமுறையாக வழங்கும் -f flag. மூன்றாவது வழிமுறை கோப்பிற்குள்ளேயே உள்ளது, அதுதான் include உறுப்பு. இது மற்ற இரண்டிலிருந்தும் மாறுபட்ட முறையில் செயல்படுகிறது.

இந்த இணைப்பானது வெறும் மேலெழுதும் (overwrite) செயல்முறை அல்ல. Mappings ஒவ்வொன்றாக இணையும், sequences பின்னால் சேர்க்கப்படும், மேலும் ஒரு சில குறிப்பிட்ட fields முழுமையாக மாற்றப்படும். இந்த வேறுபாட்டால்தான் எதிர்பாராத முடிவுகள் ஏற்படுகின்றன. குறிப்பாக, ports பட்டியல் பலருக்கும் குழப்பத்தை ஏற்படுத்துகிறது.

கீழே உள்ள அனைத்தும் Compose v2-ஐ அடிப்படையாகக் கொண்டவை, அதாவது பழைய docker-compose script-க்கு பதிலாக docker compose plugin-ஐக் குறிக்கின்றன. இதைச் சரிபார்க்க docker compose version கட்டளையை இயக்கவும். நீங்கள் இன்னும் Compose கோப்பை எழுதவில்லை என்றால், Docker Compose அடிப்படைகள் வழிகாட்டி-யிலிருந்து தொடங்கிவிட்டு மீண்டும் இங்கே வரவும்.

Compose தானாகவே கண்டறியும் override கோப்பு

எந்தவொரு -f flag-ம் இல்லாமல் docker compose up கட்டளையை இயக்கினால், தற்போதைய பணி அடைவு (working directory) மற்றும் அதன் பெற்றோர் அடைவுகளில் compose.yaml அல்லது docker-compose.yaml கோப்புகளை Compose தேடும். அடிப்படை கோப்பிற்கு அருகிலேயே ஒரு override கோப்பு இருந்தால், Compose அதைத் தானாகவே இரண்டாவது கோப்பாக ஏற்றிக்கொள்ளும்.

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

இரண்டு கோப்புகளும் இருக்கும்போது, அவற்றை கைமுறையாகக் குறிப்பிடுவதற்குச் சமமான செயல்பாட்டை இது செய்யும்.

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-ஐப் பயன்படுத்தியவுடன், தானியங்கி முறையில் கோப்புகளை ஏற்றும் வசதி நின்றுவிடும். docker compose -f compose.yaml up அந்த ஒரு குறிப்பிட்ட கோப்பை மட்டுமே வாசிக்கும், override கோப்பைப் புறக்கணிக்கும். இந்த வழிகாட்டியின் பிற்பகுதியில் விவரிக்கப்பட்டுள்ள dev மற்றும் prod முறை இந்தத் தன்மையின் அடிப்படையிலேயே கட்டமைக்கப்பட்டுள்ளது.

இது server-ல் இருபுறமும் பாதிப்பை ஏற்படுத்தலாம். deploy அடைவில் விடப்படும் ஒரு override கோப்பு, அந்த அடைவிலிருந்து இயக்கப்படும் ஒவ்வொரு docker compose கட்டளையாலும் ஏற்றப்படும்; இதில் cron job மூலம் இயக்கப்படும் கட்டளையும் அடங்கும். இதனால், யாரும் எதிர்பார்க்காத source அடைவு production stack-ல் bind-mount ஆகிவிட வாய்ப்புள்ளது. ஒவ்வொரு deploy-க்கு பிறகும் docker compose config கட்டளையை இயக்கி, அதன் வெளியீட்டைச் சரிபார்க்கவும். unattended deploy-களின் போது, ஏதேனும் தவறு நடந்தால் உங்களுக்குத் தெரியப்படுத்த வேண்டும். இதற்கு self-hosted ntfy server போன்ற ஒரு push channel-ஐப் பயன்படுத்தலாம்; cron job அல்லது systemd OnFailure unit மூலம் இதற்குத் தகவல்களை அனுப்ப முடியும்.

-f மூலம் வரிசைப்படுத்துதல் மற்றும் சார்புப் பாதைகள் (relative paths) எங்கு அமையும்

நீங்கள் வழங்கும் கோப்புகளின் வரிசையிலேயே Compose கட்டமைப்பை உருவாக்குகிறது. அடுத்தடுத்த கோப்புகள் முந்தைய கோப்புகளை மேலெழுதும் (override) அல்லது அவற்றுடன் இணையும். இடமிருந்து வலமாக, கடைசியாகக் குறிப்பிடப்படும் கோப்பே இறுதியானது.

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

அந்தத் திட்டத்தில் உள்ள ஒவ்வொரு கட்டளைக்கும் ஒரே கோப்புப் பட்டியல் தேவை. up கட்டளையை இரண்டு கோப்புகளுடனும், logs கட்டளையை ஒரு கோப்புடனும் இயக்கினால், நீங்கள் வெவ்வேறு ஒருங்கிணைந்த மாதிரிகளுடன் (merged model) பேசுகிறீர்கள் என்று அர்த்தம். இது Compose-ல் இல்லாத ஒரு சேவையைத் தேடும் நிலையை விரைவாக உருவாக்கிவிடும். சுயமாக ஹோஸ்ட் செய்யப்பட்ட Chatwoot support desk-ல் உள்ள database migration படிநிலை போன்ற, ஒருமுறை மட்டுமே இயங்கும் கட்டளைகளாக (one-off commands) மேம்படுத்தல்கள் நடக்கும்போது ஆபத்து அதிகம். தவறான கோப்புப் பட்டியலுடன் ஒரு docker compose run கட்டளையை வழங்கினால், அது உங்கள் சேவைகள் தற்போது பயன்படுத்தும் மாதிரியைத் தவிர்த்து வேறொன்றை அமைதியாக இலக்கு வைக்கும். அதற்குப் பதிலாக, 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-ஐ திட்டத்தின் .env கோப்பிலும் வைக்கலாம்; இது உங்கள் shell history-ல் இல்லாமல், checkout-ன் ஒரு பகுதியாக இருக்கும். கட்டளை வரியில் (command line) வெளிப்படையாக அமைக்கப்படும் எதையும் இந்த environment variable விட மேலானது.

இப்போது bind mounts-ஐப் பாதிக்கும் விதி. -f மூலம் பல கோப்புகளைப் பயன்படுத்தும்போது, அந்தக் கோப்புகளில் உள்ள அனைத்து சார்புப் பாதைகளும் (relative paths) அந்தந்தக் கோப்பு இருக்கும் இடத்திற்குப் பதிலாக, முதல் கோப்பு இருக்கும் கோப்பகத்தை (directory) அடிப்படையாகக் கொண்டே அமையும். deploy/prod/compose.prod.yaml-க்குள் ./data:/var/lib/postgresql/data என்று எழுதினாலும், Compose அந்த ./data-ஐ அடிப்படை கோப்பிற்கு அருகிலேயே தேடும். Docker அந்தத் தவறான பாதையில் ஒரு காலி கோப்பகத்தை உருவாக்கும், இதனால் container-க்குள் எதுவுமில்லாமல் தொடங்கும். இது தரவு இழப்பு போலத் தோன்றும், ஆனால் அது தரவு இழப்பு அல்ல. அடிப்படைப் பாதையை நீங்களே அமைக்க --project-directory-ஐப் பயன்படுத்தவும், அல்லது ஒவ்வொரு கோப்பையும் அதன் சொந்த கோப்பகத்துடன் இணைக்கும் include-ஐப் பயன்படுத்தவும்.

திட்டத்தின் பெயர் அதே அடிப்படை கோப்பகத்திலிருந்தே வருகிறது, எனவே முதல் கோப்பை மாற்றினால் திட்டத்தின் பெயரும் மாறிவிடும். திட்டத்தின் பெயர் மாறினால், புதிய container பெயர்களும் புதிய volume பெயர்களும் உருவாகும்; பழைய volume பழைய பெயரிலேயே வட்டில் (disk) இருக்கும். அதற்குப் பதிலாக, அடிப்படை கோப்பில் உயர்மட்ட name:-ஐப் பயன்படுத்தி அதை நிலைநிறுத்தவும்.

name: myapp

எந்த புலங்கள் ஒன்றிணைகின்றன, எவை மாற்றப்படுகின்றன

Compose, புலத்தின் பெயரை வைத்து அல்லாமல், மதிப்பின் வகையை வைத்தே ஒன்றிணைப்பை (merge) செய்கிறது.

ஒற்றை மதிப்பு கொண்ட புலங்கள் மாற்றப்படுகின்றன. image, command, entrypoint மற்றும் mem_limit ஆகியவை பிந்தைய மதிப்பை அப்படியே எடுத்துக்கொள்ளும். ஒரு command-ல் நீங்கள் கூடுதல் வாதங்களைச் சேர்க்க முடியாது, ஏனெனில் override முழு வரியையும் மீண்டும் எழுதிவிடும்.
Mappings சாவிகளின் (key) அடிப்படையில் ஒன்றிணைகின்றன. environment, labels, volumes மற்றும் devices ஆகியவை இரண்டு கோப்புகளிலும் உள்ள அனைத்து சாவிகளையும் தக்கவைக்கும்; இரண்டிலும் பொதுவான சாவி இருந்தால், பிந்தைய கோப்பில் உள்ள மதிப்பே எடுத்துக்கொள்ளப்படும். environment மற்றும் labels ஆகியவற்றிற்கு, variable அல்லது label பெயரே சாவியாகும். volumes மற்றும் devices ஆகியவற்றிற்கு, container பாதை சாவியாகும்.
Sequences இணைக்கப்படுகின்றன (append). dns, dns_search, expose, tmpfs மற்றும் external_links ஆகியவை ஒன்றோடொன்று சேர்க்கப்படுகின்றன. expose: ["3000"]-ஐக் கொண்ட ஒரு base கோப்பு, ["4000", "5000"]-ஐக் கொண்ட override கோப்புடன் இணையும்போது, அது ["3000", "4000", "5000"]-ஐ உருவாக்குகிறது.

நான்கு sequences ஒரு அடையாளச் சாவியைக் (identity key) கொண்டுள்ளன, எனவே அந்தச் சாவியில் பொருந்தும் பதிவுகள் இணைக்கப்படுவதற்குப் பதிலாக ஒன்றிணைகின்றன. volumes, secrets மற்றும் configs ஆகியவை target-ன் அடிப்படையில் பொருந்துகின்றன. ports ஆனது ip, target, published மற்றும் protocol ஆகியவற்றின் கலவையின் அடிப்படையில் பொருந்துகிறது.

அந்த ports விதியை இருமுறை வாசிக்கவும், ஏனெனில் இதுவே சிக்கலான பகுதி. நான்கு பகுதிகளும் ஒத்துப்போனால் மட்டுமே இரண்டு port பதிவுகள் ஒரே பதிவாகக் கருதப்படும். அவற்றில் ஏதேனும் ஒன்றை மாற்றினாலும், Compose அதை இரண்டாவது, தொடர்பில்லாத port-ஆகக் கருதி, இரண்டையுமே தக்கவைத்துக் கொள்ளும்.

ஏன் override செய்த பிறகும் உங்கள் port இன்னும் public-ஆக உள்ளது

அனைத்து 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

இரண்டு பதிவுகளும் output-ல் உள்ளன. ip பகுதி மாறுபடுகிறது, அதாவது 0.0.0.0 மற்றும் 127.0.0.1 என இரண்டு வெவ்வேறு ports merge செய்யப்படுகின்றன. நீங்கள் நீக்க முயன்ற public binding இன்னும் model-ல் உள்ளது. Docker-ல் இது மற்ற இடங்களை விட முக்கியமானது, ஏனெனில் ஒரு published port உங்கள் firewall விதிகளைத் தாண்டி iptables-ல் எழுதப்படுகிறது. இந்த நுட்பம் why published Docker ports walk past ufw-ல் விளக்கப்பட்டுள்ளது.

இதற்கு இரண்டு தீர்வுகள் உள்ளன. முதலாவது, !override tag-ஐப் பயன்படுத்துவது; இது முழு attribute-ஐயும் மாற்றி, merge விதிகளைத் தவிர்க்கும்:

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

!override-க்கு Compose v2.24.4 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. போர்ட்டபிள் (portable) தீர்வுக்கு எந்த tag-ம் தேவையில்லை: ports-ஐ base file-ல் இருந்து முழுமையாக நீக்கிவிட்டு, environment-specific கோப்புகளில் மட்டும் குறிப்பிடவும். Merge செய்ய எதுவும் இல்லை என்றால், தகவல்கள் கசிய வாய்ப்பில்லை. கீழே உள்ள எடுத்துக்காட்டில் இந்த முறையே பயன்படுத்தப்பட்டுள்ளது.

அடிப்படை கோப்பு தொகுப்பிலிருந்து ஒரு மதிப்பை நீக்குதல்

!reset ஒரு பண்புக்கூறை (attribute) நீக்கி, அதை அதன் இயல்புநிலை மதிப்பிற்கு அல்லது null நிலைக்கு மாற்றுகிறது. இது ஒரு மதிப்பை உள்ளீடாகப் பெற்று அதை நிராகரிக்கும், எனவே செல்லுபடியாகும் ஏதேனும் ஒரு காலி மதிப்பை உள்ளிடவும்.

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

!reset-க்கு Compose v2.24 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. அடிப்படை கோப்பை நீங்கள் திருத்த முடியாத சூழலில் இதைப் பயன்படுத்தவும்; உதாரணமாக, நீங்கள் பதிவிறக்கும் ஒரு vendor fragment-க்கு இது பொருந்தும். வெளியிடப்பட்ட ஒரு upstream stack இதற்குச் சரியான உதாரணம்: சுயமாக இயங்கும் AFFiNE workspace-ன் பின்னணியில் உள்ள Compose கோப்பு, நீங்கள் எழுதாத நான்கு containers-ஐக் குறிப்பிடுகிறது. அந்த கோப்பை fork செய்து, அதன் மாற்றங்களைக் கண்காணிக்கும் பொறுப்பை ஏற்காமல், அதில் உள்ள ஒரு container-ன் பண்புக்கூறை நீக்க !reset உதவுகிறது.

பகுதிகளிலிருந்து கட்டமைக்கப்பட்ட stack-களுக்கான include

include என்பது மற்றொரு Compose application-ஐ உங்கள் மாதிரியில் இணைக்கிறது. இது ஒரு top-level element, flag அல்ல.

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

include-ல் உள்ள ஒவ்வொரு path-ம் தனித்தனி Compose application மாதிரியாக ஏற்றப்படும். ஒவ்வொன்றிற்கும் தனி project directory இருப்பதால், அந்த file-க்குள் இருக்கும் relative paths அனைத்தும் அந்தந்த directory-ஐ அடிப்படையாகக் கொண்டே செயல்படும். இதுவே -f-லிருந்து இதற்கு இருக்கும் முக்கிய வேறுபாடு. ஒரு fragment வேறொரு folder-ல் அல்லது repository-ல் இருக்கும்போது include-ஐப் பயன்படுத்துவதே சரியான முறையாகும். நீங்கள் உருவாக்காத ஒரு vendor stack-ஐப் பயன்படுத்தும்போது இதுவே பொதுவான வடிவம்: self-hosted Authentik SSO install-ன் பின்னால் இருக்கும் multi-service Compose file, அதன் சொந்த directory-ல், அதன் relative paths மாறாமல் அப்படியே இருக்கும். அதே சமயம் உங்கள் file-ல் உங்கள் சொந்த services மட்டுமே இருக்கும்.

இதன் நீண்ட வடிவம் சில sub-options-களைக் கொண்டுள்ளது.

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

path ஒரு பட்டியலை ஏற்கும்; அந்த file-கள் அனைத்தும் சாதாரண விதிகளின்படி ஒன்றிணைக்கப்பட்டு, அதன் முடிவே உங்கள் மாதிரியில் சேரும். project_directory என்பது சேர்க்கப்பட்ட file-ல் உள்ள relative paths-ஐத் தீர்மானிக்கப் பயன்படும் base path-ஐ அமைக்கும். env_file என்பது சேர்க்கப்பட்ட file-க்கு எனத் தனி variables-ஐ வழங்கும்; இது ஒரு பகிரப்பட்ட fragment உங்கள் project-ன் .env-ஐத் தன்னிச்சையாகப் படிப்பதைத் தடுக்கும். include-க்கு Compose v2.20.0 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை. இதே விருப்பங்கள் நீங்கள் ஏற்கனவே இயக்கும் stack-ல் ஒரு single-container add-on-ஐச் சேர்க்கவும் பொருந்தும். உதாரணமாக, Jellyfin library-ஐ 90-களின் rental store போல மாற்றும் Halcyon: இதன் file அதன் சொந்த image tag மற்றும் env_file-ஐக் கொண்டிருக்கும். எனவே, இதை upgrade செய்வது உங்கள் media stack இருக்கும் file-ஐப் பாதிக்காது.

உங்கள் file-க்கும் சேர்க்கப்பட்ட file-க்கும் இடையே ஒரே பெயரில் வளங்கள் (resource names) இருந்தால், அவை ஒன்றிணைக்கப்படாமல் பிழையாகக் காட்டப்படும்; இது வேண்டுமென்றே செய்யப்பட்டுள்ளது. சேர்க்கப்பட்ட file-ல் உள்ள ஒன்றை மாற்ற, அந்த மாற்றத்தை compose.override.yaml-ல் குறிப்பிடவும்: இந்த override தொகுக்கப்பட்ட மாதிரியில் பயன்படுத்தப்படும், எனவே சேர்க்கப்பட்ட வளங்களை அவை மோதாமல் மாற்ற முடியும். ஒவ்வொரு release-லும் upstream file மாற்றப்படும் stack-களுக்கு இந்த முறை மிகவும் பயனுள்ளது. உதாரணமாக, PhotoPrism மற்றும் Immich போன்ற multi-container photo servers-ல், localhost binding அல்லது கூடுதல் volume போன்றவற்றை உங்கள் override-ல் வைப்பதே சிறந்தது. இல்லையெனில், அடுத்த upgrade-ன் போது அந்த மாற்றங்கள் நீக்கப்படலாம்.

சுருக்கமாக: include தனித்தனி application-களை இணைக்கிறது, -f ஒரே application-ன் மீது configuration-ஐ அடுக்காக அமைக்கிறது.

ஒரே 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 நிபந்தனை, ஒரு container வெறும் இருப்பில் இருப்பதோடு நின்றுவிடாமல், database பதிலளிக்கும் வரை application-ஐக் காத்திருக்கச் செய்கிறது. இது healthchecks மற்றும் depends_on நிபந்தனைகள் பகுதியில் விளக்கப்பட்டுள்ளது. POSTGRES_PASSWORD என்பது .env திட்டக் கோப்பிலிருந்து பெறப்படுகிறது, இது ஒருபோதும் git-ல் இருக்கக்கூடாது. பாதுகாப்பான மாற்றுகளுக்கு env கோப்புகள் மற்றும் Compose secrets பகுதியைப் பார்க்கவும்.

அடுத்து, compose.override.yaml, இதை Compose தானாகவே ஏற்றிக்கொள்ளும். இது developer-க்கான கோப்பு.

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 கட்டளை அந்த இரண்டு கோப்புகளையும் இணைக்கும். command, image-ன் default மதிப்பை மாற்றுகிறது, ஏனெனில் இது ஒற்றை மதிப்புடையது. LOG_LEVEL, info-ஐ மாற்றுகிறது, ஏனெனில் environment key அடிப்படையில் இணைகிறது. Bind mount மற்றும் இரண்டு published ports ஆகியவை கூடுதல் அம்சங்கள்; database port, localhost-ல் மட்டுமே பிணைக்கப்பட்டுள்ளதால், பொதுவான network-ல் உள்ள laptop-ல் PostgreSQL மற்றவர்களுக்குத் தெரியாது.

இறுதியாக, compose.prod.yaml. இதன் பெயர் Compose தேடும் பட்டியலில் இல்லாததால், இது தவறுதலாக ஒருபோதும் ஏற்றப்படாது.

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

VPS-ல் நீங்கள் இரண்டு கோப்புகளையும் குறிப்பிட வேண்டும்; அவ்வாறு குறிப்பிடுவதன் மூலமே 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-ம் இயங்குவதைக் காட்ட வேண்டும், மேலும் db கட்டளையில் (healthy) இருக்க வேண்டும். நீங்கள் -f-ஐக் குறிப்பிட்டதால், compose.override.yaml வாசிக்கப்படவில்லை. எனவே, dev command, source bind mount மற்றும் public port 3000 ஆகியவை production-ஐ அடைய முடியாது, அந்த கோப்பு அதே directory-ல் இருந்தாலும் சரி. Port 8000, localhost-ல் மட்டுமே உள்ளது, இது proxy-க்குத் தயார்: இரண்டாவது service-ஐச் சேர்க்கும்போது Traefik-க்கு பின்னால் பல apps-ஐ இயக்குதல் பகுதியைப் பார்க்கவும்.

Server-ன் .env-ல் COMPOSE_FILE=compose.yaml:compose.prod.yaml-ஐ அமைக்கவும், அதன் பிறகு உங்கள் கட்டளைகள் மீண்டும் சாதாரண docker compose logs -f app-ஆகச் செயல்படும்.

ஒற்றை-service stack-ம் இதே அமைப்பைப் பெறுகிறது, ஏனெனில் self-hosted openGym workout tracker முதல் passkey-ஐப் பதிவு செய்வதற்கு முன்பே proxy-க்கு பின்னால் TLS மூலம் பதிலளிக்க வேண்டும். ports இல்லாத அடிப்படை கோப்புதான், தேவையற்ற public binding-கள் proxy-க்கு முன்பே செயல்படுவதைத் தடுக்கிறது.

deployment-க்கு முன் merged model-ஐ சரிபார்க்கவும்

docker compose config முழுமையாக இணைக்கப்பட்ட மற்றும் interpolated செய்யப்பட்ட model-ஐ வெளியிடும். இது ஒரு முன்னோட்டம் (preview) அல்ல. இது 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-களையும் plain text-ஆக அச்சிடும். --services என்பது service பெயர்களை மட்டும் பட்டியலிடும், இது include நீங்கள் எதிர்பார்த்ததை உள்ளிழுத்துள்ளதா என்பதை உறுதிப்படுத்த விரைவான வழியாகும்.

தோல்வி நிலைகள் மற்றும் நீங்கள் காண்பவை

no configuration file provided: not found. Compose-ஆல் படிக்க எதுவும் கிடைக்கவில்லை. நீங்கள் project directory-க்கு வெளியே இருக்கிறீர்கள் அல்லது COMPOSE_FILE என்பது இல்லாத ஒரு பாதையைக் குறிக்கிறது. இயல்புநிலை base file-ஐத் தேட Compose parent directories-ஐச் சோதிக்கும், ஆனால் நீங்கள் குறிப்பிட்ட கோப்பை அது எங்கும் தேடாது.

WARN[0000] The "POSTGRES_PASSWORD" variable is not set. Defaulting to a blank string. Interpolation என்பது project .env கோப்பு மற்றும் shell environment-ஐ அடிப்படையாகக் கொண்டு செயல்படுகிறது. இங்கு project directory என்பது முதல் -f கோப்பு இருக்கும் directory ஆகும். .env இருக்கும் directory-க்கு மாற்றாக வேறொரு இடத்திலிருந்து deploy செய்யும்போது இந்த எச்சரிக்கை வரும், அதன் பிறகு database அனைத்து இணைப்புகளையும் நிராகரிக்கும்.

உங்கள் override திருத்தம் docker compose config-ல் காட்டப்படவில்லை. நீங்கள் -f-ஐப் பயன்படுத்தியிருக்கலாம், இது தானியங்கி override loading-ஐ முடக்கும். அல்லது Compose ஒரு parent directory-ல் compose.yaml-ஐக் கண்டறிந்திருக்கலாம், உங்கள் override கோப்பு அதற்கு அருகில் இல்லை. வேறு எந்த arguments-ம் இல்லாமல் docker compose config-ஐ இயக்கினால், Compose எந்த மாதிரியை (model) உருவாக்குகிறது என்பதைத் தெரிந்துகொள்ளலாம்.

Bind mount காலியாக உள்ளது மற்றும் நீங்கள் கேட்காத ஒரு directory-ஐ Docker உருவாக்கியுள்ளது. Relative path என்பது முதல் கோப்பின் directory-ஐ அடிப்படையாகக் கொண்டு தீர்மானிக்கப்பட்டது. பாதையைச் சரிசெய்யவும், --project-directory-ஐப் பயன்படுத்தவும் அல்லது அந்தப் பகுதியை include-க்கு பின்னால் நகர்த்தவும்.

Containers புதிய பெயர்களுடன் வருகின்றன மற்றும் volume காலியாகத் தெரிகிறது. Project பெயர் மாறிவிட்டது, ஏனெனில் project பெயர் முதல் கோப்பின் directory-ஐப் பின்பற்றும். Base file-ல் ஒரு top-level name:-ஐச் சேர்த்தால், பெயர் மாறுவது நின்றுவிடும். பழைய volume பழைய prefix-ன் கீழ் அப்படியே இருக்கும், அதை docker volume ls காட்டும்.

Override-ல் நீங்கள் நீக்கிய port இன்னும் திறந்தே உள்ளது. ports merge என்பது மாற்றுவதற்குப் பதிலாக இணைப்பை (append) ஏற்படுத்தியுள்ளது. docker compose config மூலம் இதை உறுதிப்படுத்தவும், பிறகு !override-ஐப் பயன்படுத்தவும் அல்லது ports-ஐ base file-லிருந்து வெளியேற்றவும்.

FAQ

compose.override.yaml கோப்பை Compose தானாகவே ஏற்றுகிறதா?

ஆம், நீங்கள் docker compose கட்டளையை எந்தவிதமான -f flag-உம் இல்லாமல் இயக்கும்போது இது நடக்கும். Compose உங்கள் தற்போதைய directory மற்றும் அதன் parent directories-ல் compose.yaml அல்லது docker-compose.yaml கோப்புகளைத் தேடும். அதன் அருகில் ஒரு override கோப்பு இருந்தால், அது இரண்டாவதாக ஏற்றப்படும். இதற்காக அங்கீகரிக்கப்பட்ட கோப்புப் பெயர்கள் compose.override.yaml, compose.override.yml, docker-compose.override.yml மற்றும் docker-compose.override.yaml ஆகும். ஏதேனும் ஒரு -f-ஐப் பயன்படுத்தினால் இந்த அம்சம் முடக்கப்படும், எனவே docker compose -f compose.yaml up ஒரு கோப்பை மட்டுமே வாசிக்கும்.

பல -f கோப்புகள் எந்த வரிசையில் ஒன்றிணைகின்றன?

இடமிருந்து வலமாக. நீங்கள் வழங்கும் வரிசையிலேயே Compose configuration-ஐ உருவாக்குகிறது. ஒவ்வொரு கோப்பும் அதற்கு முன்னால் உள்ள கோப்பின் மதிப்புகளை override செய்யும் அல்லது புதியவற்றைச் சேர்க்கும். எனவே, கட்டளையின் இறுதியில் உள்ள கோப்பே முரண்பாடுகளைத் தீர்மானிக்கும். அந்த project-ன் ஒவ்வொரு கட்டளைக்கும் ஒரே பட்டியலைப் பயன்படுத்த வேண்டும், இதற்காகவே COMPOSE_FILE=compose.yaml:compose.prod.yaml உள்ளது.

நான் override செய்த பிறகும் எனது port ஏன் இன்னும் வெளியிடப்படுகிறது?

ஏனெனில் ports பதிவுகள் ip, target, published மற்றும் protocol ஆகியவற்றின் முழுத் தொகுப்பைக் கொண்டு அடையாளம் காணப்படுகின்றன. அடிப்படை கோப்பில் உள்ள 8080:80-க்கு எதிராக, override கோப்பில் உள்ள 127.0.0.1:8080:80-ஐப் பயன்படுத்தினால், அதன் ip பகுதியில் மாற்றம் இருப்பதால், Compose அதை இரண்டாவது port-ஆகக் கருதி இரண்டையுமே வைத்திருக்கும். docker compose config கட்டளையை இயக்கினால், அந்த இரண்டு பதிவுகளையும் நீங்கள் காணலாம். Compose v2.24.4 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் ports: !override-ஐப் பயன்படுத்தவும், அல்லது அடிப்படை கோப்பில் ports-ஐத் தவிர்த்துவிட்டால், ஒன்றிணைக்க எந்தப் பதிவும் இருக்காது.

include மற்றும் -f ஆகியவற்றுக்கு இடையே உள்ள வேறுபாடு என்ன?

-f பல கோப்புகளை ஒரே application-ன் மேல் அடுக்குகளாகச் சேர்க்கிறது. இதில் உள்ள ஒவ்வொரு relative path-உம் முதல் கோப்பின் directory-ஐ அடிப்படையாகக் கொண்டே அமையும். include ஒரு தனித்தனி Compose application-ஐ உள்ளிழுக்கிறது. இதில் உள்ள ஒவ்வொரு path-உம் அதன் சொந்த project directory-ஐக் கொண்டிருக்கும், எனவே அதன் relative path-கள் அந்தந்த directory-ஐயே சார்ந்து இருக்கும். உங்கள் stack-ன் environment அடுக்குகளுக்கு -f-ஐயும், பிற இடங்களில் பராமரிக்கப்படும் ஒரு பகுதிக்கு include-ஐயும் பயன்படுத்தவும். include-க்கு Compose v2.20.0 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை.

அடிப்படை கோப்பில் உள்ள ஒரு மதிப்பை நான் எவ்வாறு நீக்குவது?

Compose v2.24 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் !reset tag-ஐப் பயன்படுத்தவும். overriding கோப்பில் ports: !reset [] அல்லது MY_VAR: !reset null என்று எழுதினால், அந்த attribute அதன் default மதிப்பிற்கு அல்லது null-க்குத் திரும்பிவிடும். நீங்கள் tag-க்கு வழங்கும் மதிப்பு கட்டாயமானது, ஆனால் அது புறக்கணிக்கப்படும். ஒரு attribute-ஐ நீக்குவதற்குப் பதிலாக மாற்றீடு செய்ய விரும்பினால், !override-ஐப் பயன்படுத்தலாம்; இதற்கு v2.24.4 அல்லது அதற்குப் பிந்தைய பதிப்பு தேவை.

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