Docker Compose build vs image: வித்தியாசம் என்ன?

Docker Compose build மற்றும் image: சுருக்கமான விளக்கம்

ஒரு Docker Compose கோப்பில், image: என்பது registry-யிலிருந்து பதிவிறக்கம் செய்ய வேண்டிய image-ன் பெயரைக் குறிக்கிறது. build: என்பது இந்த கணினியில் உள்ள Dockerfile-ஐப் பயன்படுத்தி ஒரு image-ஐ உருவாக்க Compose-க்கு ஆணையிடுகிறது. image:-ஐ மட்டும் அமைத்தால், Compose அந்த குறிப்பிட்ட tag-ஐ பதிவிறக்கம் செய்து இயக்கும். build:-ஐ மட்டும் அமைத்தால், Compose உள்ளூர் கணினியில் image-ஐ உருவாக்கும்; அதற்கு project பெயர் மற்றும் service பெயரைக் கொண்டு ஒரு பெயரை வழங்கும். இரண்டையும் அமைத்தால், Compose உள்ளூரில் image-ஐ உருவாக்கி, அதை image:-ல் உள்ள பெயரில் tag செய்யும். நீங்கள் ஒரு image-ஐ உருவாக்கி, உங்களுக்கு விருப்பமான பெயரில் push செய்ய இதுவே வழி.

இதுவே இரண்டிற்கும் உள்ள அடிப்படை வேறுபாடு. கீழே உள்ளவை அனைத்தும் ஒரு server-ல் இது எவ்வாறு செயல்படுகிறது என்பதற்கான விளக்கமாகும். Docker Engine மற்றும் Compose plugin ஏற்கனவே நிறுவப்பட்டிருப்பதாக இது கருதுகிறது; VPS-ல் Docker-ஐ இயக்குதல் என்ற பகுதி அதை விளக்குகிறது.

மூன்று வடிவங்கள் முழுமையாக

வெளியிடப்பட்ட ஒரு tag-ஐ pull செய்து இயக்கவும். இதில் எந்த இடத்திலும் Dockerfile பயன்படுத்தப்படுவதில்லை.

services:
  web:
    image: nginx:1.27
    restart: unless-stopped
    ports:
      - "80:80"

தற்போதைய கோப்பகத்தில் (directory) உள்ள Dockerfile-லிருந்து build செய்யவும். FROM-ல் குறிப்பிடப்பட்டுள்ள base image-ஐத் தவிர வேறு எதுவும் pull செய்யப்படாது.

services:
  web:
    build: .
    restart: unless-stopped
    ports:
      - "80:80"

உள்ளூர் அளவில் build செய்து, அந்த முடிவிற்கு tag இடவும். docker compose push மூலம் அந்த குறிப்பிட்ட tag-ஐ ஒரு registry-க்கு அனுப்ப முடியும்.

services:
  web:
    build:
      context: .
      dockerfile: Dockerfile
    image: registry.example.com/acme/web:1.4.2
    restart: unless-stopped
    ports:
      - "80:80"

context என்பது builder-க்கு அனுப்பப்படும் கோப்பகம் ஆகும். dockerfile அந்த context-ஐ அடிப்படையாகக் கொண்டே தீர்மானிக்கப்படுகிறது, எனவே context: . உடன் dockerfile: docker/prod.Dockerfile-ஐப் பயன்படுத்துவது இயல்பானதும் சரியானதுமாகும். ஒவ்வொரு service container-க்கு பின்னால் உள்ள image பெயர் மற்றும் image ID-ஐப் பார்க்க docker compose images-ஐ இயக்கவும்; நீங்கள் உண்மையில் எந்த வடிவத்தை எழுதினீர்கள் என்பதை உறுதிப்படுத்த இதுவே வேகமான வழியாகும்.

Dockerfile-ஐ மாற்றிய பிறகு ஏன் docker compose up கட்டளை rebuild செய்வதில்லை?

ஏனெனில் up, image தற்போதைய நிலையில் உள்ளதா என்று பார்க்காமல், அது ஏற்கனவே உள்ளதா என்று மட்டுமே சரிபார்க்கிறது.

Compose ஒரு service-ஐத் தொடங்கும்போது, அதில் build: பகுதி இருந்தால், அது உள்ளூர் image store-ல் அந்த image-ஐத் தேடும். அந்தப் பெயரில் ஏற்கனவே ஒரு image இருந்தால், Compose அதையே பயன்படுத்தும். அது உங்கள் Dockerfile-ஐப் படிப்பதோ, source files-ஐ ஒப்பிடுவதோ அல்லது timestamp-ஐப் பார்ப்பதோ இல்லை. Compose விவரக்குறிப்பு இந்த விதியை pull_policy பண்பாகக் குறிப்பிடுகிறது, மேலும் இயல்பான நடத்தை (default behaviour) என்னவென்றால், image விடுபட்டிருந்தால் மட்டுமே அது build செய்யப்படும். ஏற்கனவே இருப்பது போதுமானதாகக் கருதப்படுகிறது.

எனவே, நீங்கள் app.py-ஐத் திருத்திவிட்டு, docker compose up -d-ஐ இயக்கினால், Compose அந்த container இயங்குவதாகக் காட்டும், ஆனால் பழைய code-ஐயே அது வழங்கும். எந்தப் பிழையும் ஏற்படாததால், எந்த எச்சரிக்கையும் வராது. Compose-ல் "எனது மாற்றம் நடைமுறைக்கு வரவில்லை" என்று வரும் புகார்களில் இதுவே மிகவும் பொதுவானது. container பெயருக்கு அருகில் Compose அச்சிடும் status வார்த்தையே இதற்கான அடையாளம்: Compose மாற்றியமைத்த container 'recreated' அல்லது 'started' என்று காட்டும், அதேசமயம் Compose எதையும் செய்யாமல் விட்டுவிட்ட container 'running' என்று காட்டும்.

இரண்டு சோதனைகள் மூலம் இதை உறுதிப்படுத்தலாம். docker compose images ஒவ்வொரு container-ம் பயன்படுத்தும் image ID-ஐ அச்சிடும், எனவே deploy செய்வதற்கு முன் அதைக் குறித்துக்கொண்டு, பிறகு ஒப்பிட்டுப் பார்க்கவும். docker image ls-ல் CREATED நெடுவரிசை உள்ளது; உங்கள் கடைசி commit-க்கு முன்பு உருவாக்கப்பட்ட image, deploy script என்ன சொன்னாலும் அது பழைய (stale) image தான்.

எந்தெந்த flags rebuild-ஐ கட்டாயப்படுத்துகின்றன

• docker compose up -d --build முதலில் build செய்து, பின்பு image மாறிய எந்தவொரு container-ஐயும் மீண்டும் உருவாக்குகிறது. பெரும்பாலான பயனர்கள் தேடும் flag இதுவே.
• docker compose build web ஒரு service-ஐ மட்டும் build செய்யும், எதையும் தொடங்காது. அந்த container-ஐ மட்டும் மாற்றிவிட்டு, மற்ற stack-ஐ தொடர்ந்து இயங்க வைக்க, இதைத் தொடர்ந்து docker compose up --no-deps -d web-ஐப் பயன்படுத்தவும்.
• docker compose build --no-cache web அனைத்து cached layer-களையும் நீக்கிவிட்டு, முதல் instruction-லிருந்து rebuild செய்யும்.
• docker compose build --pull FROM-ல் உள்ள base image-ன் புதிய பதிப்பைப் பதிவிறக்க முயற்சிக்கும். எனவே, node:22 போன்ற மாறும் tag-கள், நீங்கள் மார்ச் மாதம் பதிவிறக்கிய நகலுக்குப் பதிலாக அதன் தற்போதைய உள்ளடக்கத்தைப் பெறும்.
• docker compose up -d --force-recreate ஏற்கனவே பயன்படுத்தும் image-லிருந்து container-களை மீண்டும் உருவாக்கும். இது ஒருபோதும் build செய்யாது. --build-க்கு பதிலாக இதைத் தேர்ந்தெடுப்பது ஒரு பொதுவான தவறான அணுகுமுறையாகும்.

இந்த முடிவை நீங்கள் கோப்பிற்குள்ளேயே மாற்றலாம். Compose specification-ன் படி, pull_policy: build என்பது Compose அந்த image-ஐ build செய்யும் என்பதையும், ஏற்கனவே இருந்தால் அதை rebuild செய்யும் என்பதையும் குறிக்கிறது. ஒவ்வொரு up-ம் build-க்கான நேரத்தை எடுத்துக்கொள்ளும்; இது லேப்டாப்பில் தேவைப்படலாம், ஆனால் server-ல் அரிதாகவே தேவைப்படும்.

services:
  web:
    build: .
    image: registry.example.com/acme/web:dev
    pull_policy: build

மேலும் ஒரு செயல்பாட்டைத் தெரிந்துகொள்வது அவசியம். docker compose pull என்பது build பகுதியைக் கொண்ட service-களுக்கான image-களைப் பதிவிறக்க முயற்சிக்கும். அந்தப் பதிவிறக்கம் தோல்வியுற்றால், அந்த image-ஐ build செய்ய வேண்டும் என்று அது உங்களுக்குத் தெரிவிக்கும். அத்தகைய service-களைத் தவிர்க்க --ignore-buildable-ஐப் பயன்படுத்தவும்.

Build cache உங்கள் deploy நேரத்தை எவ்வாறு தீர்மானிக்கிறது

Dockerfile-ல் உள்ள ஒவ்வொரு instruction-ம் ஒரு layer-ஐ உருவாக்குகிறது. அந்த instruction மற்றும் அதன் உள்ளீடுகள் மாறாமல் இருக்கும்போது, builder ஏற்கனவே உள்ள cached layer-ஐ மீண்டும் பயன்படுத்துகிறது. COPY-க்கு, நகலெடுக்கப்படும் கோப்புகளின் உள்ளடக்கங்களே உள்ளீடுகளாகும். ஒரு layer cache-ல் கிடைக்கவில்லை என்றால், அதற்குப் பிறகு வரும் அனைத்து layer-களும் மீண்டும் உருவாக்கப்படும். ஏனெனில், ஒவ்வொரு layer-ம் அதற்கு முந்தைய layer உருவாக்கிய filesystem-ன் மேலேயே கட்டமைக்கப்படுகிறது.

இந்த ஒரு விதிதான் உங்கள் deploy சில வினாடிகளில் முடியுமா அல்லது பல நிமிடங்கள் ஆகுமா என்பதைத் தீர்மானிக்கிறது. அரிதாக மாறும் விஷயங்களிலிருந்து தொடங்கி, ஒவ்வொரு commit-லும் மாறும் விஷயங்கள் வரை Dockerfile-ஐ வரிசைப்படுத்துங்கள்.

FROM node:22-slim
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
CMD ["node", "server.js"]

npm ci, COPY . .-க்கு மேலே இருப்பதால், ஒரு source file-ஐ மாற்றும்போது install layer cache-லேயே இருக்கும், மேலும் build செயல்முறை copy படியிலிருந்து தொடரும். இந்த இரண்டு வரிகளையும் மாற்றினால், ஒரு சிறிய எழுத்து மாற்றமும் அனைத்து dependency-களையும் மீண்டும் install செய்ய வைக்கும். ஏனெனில், COPY . ., npm ci கட்டமைக்கப்பட்டுள்ள layer-ஐ செல்லாததாக்கிவிடும். இதே தர்க்கம் pip install -r requirements.txt மற்றும் go mod download-க்கும் பொருந்தும்.

உங்கள் திருத்தத்தை ஒரு பழைய layer மறைத்து வைத்திருப்பதாக நீங்கள் சந்தேகிக்கும்போது --no-cache சரியான கருவியாகும். ஆனால், இதை இயல்பான அமைப்பாக (default) வைத்திருப்பது தவறு. ஏனெனில், Dockerfile வரிசைப்படுத்துவதன் மூலம் பெறப்படும் cache பயன்பாட்டை இது முழுமையாகத் தவிர்த்துவிடும்.

Image-ல் அமைக்கப்பட்டு, Compose மூலம் மாற்றியமைக்கக்கூடிய ஒரு விஷயம் இது: Dockerfile-ன் CMD என்பது image இயல்பாக இயக்கும் கட்டளையாகும், மேலும் service-ல் உள்ள command: key அதை மாற்றியமைக்கும். Command மற்றும் entrypoint எவ்வாறு தொடர்பு கொள்கின்றன என்பது இங்கே முக்கியமானது. ஏனெனில், ஒரு Compose override மூலம் புதிதாக build செய்யப்பட்ட image-ஐ பழைய image போலவே செயல்பட வைக்க முடியும்.

Build context மற்றும் .dockerignore

context: . என்பது அந்த directory-ஐ தொகுத்து, முதல் instruction இயங்குவதற்கு முன்பே builder-க்கு அனுப்புவதைக் குறிக்கிறது. .git மற்றும் உங்கள் source code-க்கு அருகில் நீங்கள் வைத்திருக்கும் எந்தவொரு தரவு directory-யும் உட்பட, அதன் கீழ் உள்ள அனைத்தும் அனுப்பப்படும். மாற்றமில்லாத ஒரு project-ன் "transferring context" நிலையில் build நின்றுவிட்டால், context அளவு மிக அதிகமாக உள்ளது என்று அர்த்தம்.

Context-ன் root-ல் உள்ள ஒரு .dockerignore கோப்பு, குறிப்பிட்ட பாதைகளை அந்தப் பரிமாற்றத்திலிருந்து விலக்குகிறது. இதன் syntax .gitignore-ஐப் போன்றது.

.git
node_modules
*.log
data/
.env

இதனால் இரண்டு நன்மைகள் உள்ளன. பரிமாற்ற அளவு குறைவதால், ஒவ்வொரு build-ம் வேகமாகத் தொடங்கும். மேலும், COPY . .-ஆல் இனி .env-ஐ image-க்குள் நகலெடுக்க முடியாது; அவ்வாறு நகலெடுத்தால், அந்த image-ஐப் பதிவிறக்கும் எவரும் அதை எளிதாகப் படிக்க முடியும்.

காலப்போக்கில் build வேகம் குறைவதற்கு bind mount ஒரு முக்கிய காரணம். Named volume உங்கள் project directory-க்கு வெளியே இருக்கும், ஆனால் ./data:/var/lib/postgresql/data போன்ற bind mount உங்கள் build context-க்கு உள்ளேயே இருக்கும். இதனால் database வளர வளர, ஒவ்வொரு வாரமும் உங்கள் build வேகம் குறையும். .dockerignore-ல் ஒரே ஒரு வரியைச் சேர்ப்பதன் மூலம் இதைச் சரிசெய்யலாம். Bind mounts against named volumes பகுதி இது குறித்த விரிவான ஒப்பீட்டை வழங்குகிறது.

Build arguments-ல் இதே போன்ற சிறிய ஆபத்து உள்ளது. args: வழியாக அனுப்பப்படும் மதிப்புகள், image-ஐ வைத்திருக்கும் எவருக்கும் அதன் history-ல் தெரியும். எனவே, அங்கு version number-ஐ மட்டும் குறிப்பிடவும், ஒருபோதும் token-களைப் பயன்படுத்த வேண்டாம். Env files and secrets in Compose பகுதி, credentials-ஐ எங்கு வைக்க வேண்டும் என்பதை விளக்குகிறது.

VPS-ல் build செய்வதா அல்லது பிற இடங்களில் build செய்து pull செய்வதா?

உங்கள் traffic-ஐக் கையாளும் server-லேயே build செய்வது இயல்பான முறை, ஏனெனில் இதுவே மிகக் குறுகிய வழி: git pull, பிறகு docker compose up -d --build. யாரும் சார்ந்திருக்காத சிறிய server-களில் இது சரியாக இருக்கும். ஆனால், அளவிடக்கூடிய இரண்டு காரணங்களாலும், ஒரு மோசமான சூழலில் மட்டும் வெளிப்படும் ஒரு காரணத்தாலும் இது தவிர்க்கப்பட வேண்டும்.

Memory. ஒரு build செயல்முறை, உங்கள் live application-க்கு அருகிலேயே compilers மற்றும் bundlers-ஐ இயக்குகிறது. இவை பெரும்பாலான stack-களில் அதிக memory-ஐப் பயன்படுத்தும் பகுதிகள். 1 GB VPS-ல், ஒரு JavaScript bundler அல்லது Rust compile செயல்முறை வழக்கமாக அந்த server-ன் மிகப்பெரிய process-ஆக இருக்கும். Kernel-க்கு memory பற்றாக்குறை ஏற்படும்போது, அது மிகப்பெரிய process-ஐக் கொல்லும்: ஒன்று build செயல்முறை Killed மற்றும் exit status 137-உடன் நின்றுவிடும், அல்லது உங்கள் database கொல்லப்பட்டு deploy நடக்கும்போதே தளம் முடங்கிவிடும். dmesg -T | grep -i oom கட்டளை, கொல்லப்பட்ட process-ன் பெயருடன் அந்த வரியைக் காட்டும்; எனவே எதனால் பாதிப்பு ஏற்பட்டது என்பதை ஊகிக்காமல் உறுதிப்படுத்தலாம்.

Disk. ஒவ்வொரு build-ம் சில layers-ஐ விட்டுச் செல்கிறது, மேலும் builder உங்கள் images-லிருந்து தனித்தனியாக அதன் cache-ஐப் பராமரிக்கிறது. docker system df இரண்டையும் காட்டும், build cache வரிசை தொடர்ந்து வளர்ந்துகொண்டே இருக்கும். தேவையற்ற images-ஐ நீக்க docker image prune கட்டளையையும், cache செய்யப்பட்ட layers-ஐ நீக்க docker builder prune கட்டளையையும் பயன்படுத்தவும். Disk முழுமையாக நிரம்பினால் build மட்டும் நிற்காது. Database-ம் எழுதுவதை நிறுத்திவிடும், இந்தத் தோல்வி மெதுவான deploy-ஐ விட அதிக இழப்பை ஏற்படுத்தும்.

Reproducibility. server-ல் build செய்யப்படும் ஒரு image அந்த server-ல் மட்டுமே இருக்கும். Rollback செய்ய வேண்டுமெனில், பழைய commit-ஐ எடுத்து மீண்டும் build செய்ய வேண்டும். ஆனால், base tag மாறியிருக்கலாம் அல்லது package mirrors மாறியிருக்கலாம் என்பதால், அதே output கிடைக்கும் என்பதற்கு உத்தரவாதம் இல்லை. பிற இடங்களில் build செய்து ஒரு tag-ஐ push செய்வது, rollback-ஐ ஒரு எளிய மாற்றமாக மாற்றும்: image:-ஐ முந்தைய tag-க்கு மாற்றி, docker compose up -d-ஐ இயக்கினால் போதும்.

சரியான அணுகுமுறை தெளிவானது. உங்கள் continuous integration முறையில் build-ஐ இயக்கி registry.example.com/acme/web:<git-sha>-ஐ push செய்யவும், VPS-ல் உள்ள Compose file-ல் image:-ஐ மட்டும் வைத்திருக்கவும், build: key-ஐ நீக்கிவிடவும். இப்போது deployment என்பது மிகக் குறைந்த memory தேவைப்படும் இரண்டு கட்டளைகள் மட்டுமே.

docker compose pull
docker compose up -d

server-ல் ஒருமுறை docker login registry.example.com-ஐ இயக்கினால், அதன் பிறகு Compose-ஆல் private tags-ஐ pull செய்ய முடியும்.

Build பகுதியை நீக்குவதற்குப் பதிலாக, நீங்கள் பெயரிடும் ஒரு தனி file-ல் வைத்து development-க்காகப் பயன்படுத்தவும்.

# compose.dev.yaml
services:
  web:
    build:
      context: .
    pull_policy: build

docker compose -f compose.yaml -f compose.dev.yaml up -d --build

அந்த file-க்கு compose.dev.yaml என்று பெயரிடவும், compose.override.yaml என்று பெயரிட வேண்டாம். Compose ஒரு override file-ஐக் கண்டால் தானாகவே அதை load செய்யும்; எனவே தவறுதலாக ஒரு override file server-க்கு நகர்த்தப்பட்டால், அது மீண்டும் server-லேயே build செய்யத் தொடங்கிவிடும். பல Compose file-களை அடுக்குதல் பகுதியில், key-கள் எவ்வாறு ஒன்றிணைக்கப்படுகின்றன என்பது விளக்கப்பட்டுள்ளது.

பிற இடங்களில் உருவாக்கும்போது ஏற்படும் architecture சிக்கல்

ஒரு image, அது உருவாக்கப்பட்ட CPU architecture-ஐயே கொண்டிருக்கும். Apple Silicon laptop-ல் உருவாக்கி, push செய்து, பின்னர் அந்த tag-ஐ x86_64 VPS-ல் pull செய்தால், கோரப்பட்ட image platform-க்கும் கண்டறியப்பட்ட host platform-க்கும் பொருத்தம் இல்லை என்று Docker எச்சரிக்கும். இந்தச் செயல்முறை exec format error பிழையுடன் நின்றுவிடும்; இது binary சிதைந்திருப்பதாகத் தோன்றினாலும், உண்மையில் அது அவ்வாறு இல்லை. இலக்கு architecture-க்காக நேரடியாக build செய்யவும்:

docker buildx build --platform linux/amd64 \
  -t registry.example.com/acme/web:1.4.2 --push .

உங்கள் laptop x86 ஆக இருந்து, நீங்கள் x86-க்கு பதிலாக ARM VPS-ல் இயக்கினால், இதே பொருத்தமின்மை தலைகீழாக நிகழும். நீங்கள் deploy செய்யும் அதே architecture-ல் CI-ஐ build செய்ய அனுமதிப்பது, இந்தச் சிக்கலை நீக்கிவிடும்.

Deploy செய்த பிறகு சரிபார்க்க வேண்டியவை

• docker compose images இயங்கிக்கொண்டிருக்கும் ஒவ்வொரு container-ன் பின்னால் உள்ள image மற்றும் tag-ஐக் காட்டும். மாறியுள்ள image ID, புதிய build பயன்பாட்டில் இருப்பதற்கான சான்றாகும்.
• docker compose config variable substitution செய்யப்பட்ட பிறகுள்ள merged file-ஐக் காட்டும். எனவே, எதையும் இயக்கும் முன்பே Compose பயன்படுத்தப்போகும் இறுதி image பெயரை உங்களால் படிக்க முடியும்.
• docker compose logs -f web swap செய்த பிறகு முதல் அரை நிமிடத்திற்கு இதைப் பயன்படுத்தவும். தொடங்கும் மற்றும் வெளியேறும் (starts and exits) ஒரு container, இயங்கிக்கொண்டிருக்காமல் மீண்டும் மீண்டும் restart ஆகும். நீங்கள் கவனிக்காவிட்டால் இந்த loop அமைதியாகவே இருக்கும்.
• docker image ls CREATED என்ற column-ஐக் காட்டும். உங்கள் கடைசி commit-ஐ விட பழைய image என்றால், அது மீண்டும் build செய்யப்படவில்லை என்று அர்த்தம்.

இந்தச் சோதனைகளைச் செய்யும் கோப்பை நீங்கள் இன்னும் உருவாக்கிக்கொண்டிருக்கிறீர்கள் என்றால், VPS-ல் Compose கோப்பின் அடிப்படைகள் பகுதியில் அதற்கான முக்கிய அம்சங்கள் உள்ளன. மேலும், Compose கட்டளைகளின் சுருக்கக் குறிப்பு பகுதியில் மீதமுள்ள subcommands பட்டியலிடப்பட்டுள்ளன.

FAQ

ஒரே service-ல் build மற்றும் image ஆகிய இரண்டையும் பயன்படுத்தலாமா?

ஆம், நீங்கள் சொந்தமாக உருவாக்கும் ஒரு project-க்கு இதுவே வழக்கமான அமைப்பாகும். build: பகுதியில் உள்ளவற்றை வைத்து Compose build செய்கிறது, மேலும் அதன் முடிவை image:-ன் மதிப்பைக் கொண்டு tag செய்கிறது. அந்த tag-ஐத்தான் docker compose push ஒரு registry-க்கு அனுப்புகிறது, அதைத்தான் மற்றொரு machine pull செய்கிறது. image: key இல்லையென்றாலும் Compose build செய்யும், ஆனால் அது project மற்றும் service-ன் பெயரையே image-க்கு வைக்கும். மேலும், அந்த attribute விடுபட்டிருப்பதால் image-ஐ push செய்ய முடியாது என்று எச்சரிக்கும்.

ஏன் docker compose up எனது Dockerfile மாற்றங்களை எடுத்துக்கொள்வதில்லை?

ஏனெனில், up அந்தப் பெயரில் image உள்ளதா என்று மட்டுமே சரிபார்க்கும். ஒரு image ஏற்கனவே இருந்தால், Compose அதைத் தொடங்கிவிடும்; அது உங்கள் Dockerfile அல்லது source files-உடன் ஒப்பிட்டுப் பார்க்காது. docker compose up -d --build-ஐ இயக்கவும், அல்லது ஒரு குறிப்பிட்ட service-ஐ மட்டும் மாற்ற docker compose build web-ஐத் தொடர்ந்து docker compose up --no-deps -d web-ஐ இயக்கவும். ஒரு service-ல் pull_policy: build-ஐ அமைத்தால், ஒவ்வொரு up-ம் மீண்டும் build செய்யப்படும்; இது development machine-க்கு ஏற்றது.

--build மற்றும் --force-recreate ஆகியவற்றுக்கு என்ன வித்தியாசம்?

--build image-ஐ மீண்டும் build செய்யும், பிறகு மாறிய image-ஐக் கொண்ட containers-ஐ மீண்டும் உருவாக்கும். --force-recreate ஏற்கனவே உள்ள image-லிருந்து containers-ஐ மீண்டும் உருவாக்கும், எனவே இது code மாற்றங்களை ஒருபோதும் எடுத்துக்கொள்ளாது. உங்கள் மாற்றம் source-ல் அல்லது Dockerfile-ல் இருந்தால், நீங்கள் பயன்படுத்த வேண்டிய flag --build ஆகும். --force-recreate என்பது container-ஐயே reset செய்யப் பயன்படுகிறது; உதாரணமாக, அதே image-ஐ வைத்துக்கொண்டு அதன் writable layer-ஐ மட்டும் நீக்க இது உதவும்.

எனது Docker images-ஐ VPS-ல் build செய்ய வேண்டுமா அல்லது வேறு எங்காவது செய்ய வேண்டுமா?

வேறு இடத்தில் build செய்துவிட்டு, server traffic-ஐக் கையாளத் தொடங்கியதும் ஒரு tag-ஐ pull செய்யவும். ஒரு build செயல்முறை உங்கள் application-ன் memory-க்காகப் போட்டியிடும். ஒரு சிறிய VPS-ல், kernel அதிக memory-ஐப் பயன்படுத்தும் process-ஐ (அது build-ஆகவோ அல்லது database-ஆகவோ இருக்கலாம்) நீக்கிவிடும். மேலும், build செய்யும்போது disk-ல் சேரும் cache-ஐ யாரும் தானாக நீக்க மாட்டார்கள். பயனர்கள் இல்லாத சிறிய project-களுக்கு server-ல் build செய்வது சரிதான். பிற்காலத்தில் மாற்றிக்கொள்வது எளிது, அதற்கு build: பகுதியை development-க்கு மட்டுமேயான Compose file-ல் வைத்திருங்கள்.

Docker build cache எனது disk-ஐ நிரப்புவதைத் தடுப்பது எப்படி?

உங்கள் images மற்றும் build cache எவ்வளவு இடத்தை ஆக்கிரமித்துள்ளன என்பதைப் பார்க்க docker system df-ஐ இயக்கவும். docker builder prune cached layers-ஐ நீக்கும், docker image prune பழைய build-களால் எஞ்சியிருக்கும் dangling images-ஐ நீக்கும். இவை இரண்டிலும் -a-ஐச் சேர்த்தால் அது இன்னும் தீவிரமாகச் செயல்படும், மேலும் உங்கள் அடுத்த build-ஐ ஆரம்பத்திலிருந்தே (cold) செய்ய வைக்கும். server-ல் docker system prune -af --volumes-ஐ schedule செய்ய வேண்டாம், ஏனெனில் --volumes எந்த container-உம் பயன்படுத்தாத அனைத்து volumes-ஐயும் நீக்கிவிடும். பராமரிப்புக்காக நீங்கள் நிறுத்தி வைத்துள்ள stack-ன் database அத்தகைய volume-ல் இருக்கலாம்.