SSD Nodes Learn Hosting plans →

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

ஆல் Matt Connor 2026-10-27 · புதுப்பிக்கப்பட்டது 2026-10-28

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

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

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

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

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

கீழே உள்ள அனைத்தும் Compose v2 அல்லது அதற்குப் பிந்தைய பதிப்புகளை அடிப்படையாகக் கொண்டவை, பழைய docker-compose script-க்கு பதிலாக docker compose plugin-ஐப் பயன்படுத்துகின்றன. தற்போதைய releases v5 என எண்ணிடப்பட்டுள்ளன, மேலும் 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) நீக்கி, அதை அதன் இயல்புநிலை (default) அல்லது null நிலைக்கு மாற்றுகிறது. இது ஒரு மதிப்பை உள்ளீடாகப் பெற்று அதை நிராகரிக்கும், எனவே செல்லுபடியாகும் ஏதேனும் ஒரு வெற்று மதிப்பை உள்ளிடவும்.

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

!reset ஆனது Compose v2.18.0 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் செயல்படும், இது !override வருவதற்கு பல பதிப்புகளுக்கு முன்பே அறிமுகமானது. அடிப்படை கோப்பை நீங்கள் திருத்த முடியாத சூழலில் இதைப் பயன்படுத்தவும்; உதாரணமாக, நீங்கள் பதிவிறக்கும் ஒரு vendor fragment-க்கு இது பொருந்தும். வெளியிடப்பட்ட ஒரு upstream stack இதற்குச் சரியான உதாரணம்: சுயமாக இயங்கும் AFFiNE workspace-ன் பின்னணியில் உள்ள Compose கோப்பு, நீங்கள் எழுதாத நான்கு containers-ஐக் குறிப்பிடுகிறது. அந்த கோப்பை fork செய்யாமலும், அதைத் தொடர்ந்து கண்காணிக்கும் பொறுப்பை ஏற்காமலும், அதில் உள்ள ஒரு container-ன் ஒரு பண்புக்கூறை மட்டும் நீக்க !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 சரியான tool ஆக இருப்பதற்கான காரணமும் இதுதான். நீங்கள் எழுதாத 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 rules மூலம் ஒன்றிணைக்கப்பட்ட பிறகு உங்கள் model-ல் சேர்க்கப்படும். project_directory, included file-ல் உள்ள relative paths-ஐ resolve செய்யப் பயன்படுத்தப்படும் base path-ஐ அமைக்கிறது. env_file, included Compose file அதன் interpolation defaults-ஐ பெறும் file-ஐக் குறிப்பிடுகிறது. இது ஏற்கனவே அந்த file-ன் சொந்த project directory-யில் உள்ள .env-க்கு default ஆகிறது. அதே நேரத்தில், உங்கள் local project's environment அதைவிட முன்னுரிமை பெறும். இதனால் fragment-ஐ edit செய்யாமல், அதன் variables-ல் ஒன்றை நீங்கள் override செய்யலாம். 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-லும் ஒரே resource name அறிவிக்கப்பட்டால், அது conflict ஆகக் கருதப்பட்டு reject செய்யப்படும் என்று Docker-ன் documentation கூறுகிறது. ஆனால் தற்போதைய release-ன் loader அவ்வாறு செயல்படவில்லை. 2026-10-27 அன்று அது வழங்கும் loader source-ஐச் சரிபார்த்தபோது, Compose v5.6.1-ல் இரண்டு definitions-ம் merge செய்யப்படுகின்றன. Conflict உள்ள value-களில் உங்கள் file-ன் value முன்னுரிமை பெறுகிறது; error-உடன் செயல்முறை நிறுத்தப்படுவதில்லை. எனவே duplicate name இருந்தால் நிச்சயமாக வெளிப்படையான failure ஏற்படும் என்று நம்ப வேண்டாம். Included file அறிவிக்கும் ஏதாவது ஒன்றை மாற்ற வேண்டுமானால், அந்த மாற்றத்தை compose.override.yaml-ல் எழுதுங்கள். Override assembled model-க்கு பயன்படுத்தப்படும். இதனால் மாற்றம் வெளிப்படையாக இருக்கும்; குறிப்பிட்ட release ஒன்று அந்த clash-ஐ எவ்வாறு கையாளுகிறது என்பதையே சார்ந்திருக்காது. ஒவ்வொரு release-லும் upstream file மீண்டும் எழுதப்படும் stack-களில் இந்த நடைமுறை குறிப்பாக பயனுள்ளதாகும். PhotoPrism versus Immich-ல் மதிப்பிடப்படும் multi-container photo servers இதற்கான உதாரணம். அங்கு localhost binding அல்லது கூடுதல் volume, அடுத்த upgrade-ல் மாற்றப்படும் file-ல் அல்ல, உங்கள் override-ல் இருக்க வேண்டும்.

சுருக்கமாக: include தனித்தனி applications-ஐ ஒன்றிணைக்கிறது; -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

`docker compose` தானாகவே compose.override.yaml-ஐ ஏற்றுகிறதா?

ஆம், நீங்கள் -f flag இல்லாமல் docker compose-ஐ இயக்கும்போது இது நடக்கும். Compose தற்போதைய directory மற்றும் அதன் parent directory-களில் compose.yaml அல்லது docker-compose.yaml உள்ளதா என்று தேடும். அதனுடன் ஒரு override file இருந்தால், அது இரண்டாவதாக ஏற்றப்படும். அங்கீகரிக்கப்பட்ட கோப்புப் பெயர்கள் 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-க்கு எதிராக 127.0.0.1:8080:80-ஐ override செய்யும்போது, ip பகுதியில் மாற்றம் இருப்பதால், Compose அதை இரண்டாவது port-ஆகக் கருதி இரண்டையும் வைத்திருக்கும். docker compose config-ஐ இயக்கினால், இரண்டு உள்ளீடுகளையும் நீங்கள் காணலாம். Compose v2.24.4 அல்லது அதற்குப் பிந்தைய பதிப்புகளில் ports: !override-ஐப் பயன்படுத்தவும், அல்லது அடிப்படை கோப்பில் ports-ஐத் தவிர்த்துவிட்டால், ஒன்றிணைக்க எந்த முரண்பாடும் இருக்காது.

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

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

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

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

இந்தக் கட்டுரை பயனுள்ளதாக இருந்ததா?

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