Docker disk space-ஐ சுத்தம் செய்வது எப்படி?

எதையும் நீக்குவதற்கு முன்பு disk space-ஐ எவை பயன்படுத்துகின்றன என்பதைக் கண்டறியவும்

Docker ஒரு VPS-ல் நான்கு இடங்களில் disk space-ஐ எடுத்துக்கொள்கிறது: images, நிறுத்தப்பட்ட containers, build cache, மற்றும் local volumes. எவை அதிக இடத்தை ஆக்கிரமித்துள்ளன என்பதைக் கண்டறிய முதலில் docker system df-ஐ இயக்கவும், அதன் பிறகு அந்த இடத்தை விடுவிக்கத் தேவையான மிகச்சரியான prune கட்டளையை மட்டும் பயன்படுத்தவும். வரிசைமுறை முக்கியமானது, ஏனெனில் இந்த வழிகாட்டியின் கடைசி கட்டளையான docker volume prune -a தரவுகளை நிரந்தரமாக நீக்கிவிடும், அதைத் திரும்பப் பெற முடியாது.

Docker-ல் தொடங்குவதற்கு முன், filesystem-ல் இருந்து தொடங்கவும்.

df -h /
sudo du -xh --max-depth=1 /var/lib/docker | sort -h

df நிலை எவ்வளவு மோசமாக உள்ளது என்பதைக் கூறுகிறது. du இடம் எங்கே சென்றுள்ளது என்பதைக் காட்டுகிறது. -x flag, du-ஐ ஒரே filesystem-க்குள் வைத்திருக்கும், எனவே இது mount செய்யப்பட்ட தனி volume-க்குள் சென்று அதை இரண்டு முறை கணக்கிடாது. இதில் ஐந்து directories முக்கியம்: overlay2 image மற்றும் container layers-ஐ வைத்திருக்கிறது, volumes volume தரவுகளை வைத்திருக்கிறது, containers container metadata மற்றும் log files-ஐ வைத்திருக்கிறது, buildkit build cache-ஐ வைத்திருக்கிறது, மற்றும் image layer metadata-வை வைத்திருக்கிறது.

sudo மற்றும் shell wildcards குறித்த ஒரு குறிப்பு, ஏனெனில் இது பலரது நேரத்தை வீணாக்குகிறது. /var/lib/docker root-க்கு சொந்தமானது மற்றும் உங்கள் சாதாரண user-ஆல் அதைப் படிக்க முடியாது, எனவே ls /var/lib/docker கட்டளை Permission denied-ஐத் தரும். sudo du -sh /var/lib/docker/* போன்ற கட்டளைகளும் தோல்வியடையும், ஏனெனில் sudo இயங்குவதற்கு முன்பே உங்கள் shell *-ஐ விரிவுபடுத்திவிடும், மேலும் உங்கள் shell-ஆல் அந்த directory-ஐப் படிக்க முடியாது. கீழே உள்ள ஒவ்வொரு கட்டளையும் அந்த காரணத்திற்காகவே wildcard-க்கு பதிலாக find அல்லது --max-depth-ஐப் பயன்படுத்துகிறது.

இப்போது Docker-ன் பார்வையில் பார்ப்போம்.

docker system df

TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          24        6         12.4GB    8.91GB (71%)
Containers      31        6         1.42GB    1.39GB (97%)
Local Volumes   14        5         6.03GB    4.11GB (68%)
Build Cache     212       0         9.87GB    9.87GB

இந்த எண்கள் ஒரு குறிப்பிட்ட machine-லிருந்து வந்தவை, உங்கள் machine-ஐப் பற்றி இவை எதையும் கூறாது. அதன் அமைப்பைப் புரிந்துகொள்ளுங்கள். TOTAL object-களின் எண்ணிக்கையைக் காட்டுகிறது, ACTIVE தற்போது பயன்பாட்டில் உள்ளவற்றைக் காட்டுகிறது, மற்றும் RECLAIMABLE என்பது ஒரு prune கட்டளை மூலம் எவ்வளவு இடத்தை விடுவிக்க முடியும் என்பதற்கான Docker-ன் மதிப்பீடு ஆகும்.

RECLAIMABLE குறித்து இரண்டு விஷயங்கள் பலரைத் தடுமாறச் செய்யும். இது பகிரப்பட்ட image layers-ஐ, அதைப் பயன்படுத்தும் ஒவ்வொரு image-க்கும் ஒருமுறை கணக்கிடுகிறது, எனவே image வரிசையில் காட்டப்படும் அளவு நீங்கள் உண்மையில் பெறுவதை விட அதிகமாக இருக்கும். மேலும், இது container log files-ஐ உள்ளடக்குவதில்லை, ஏனெனில் Docker ஒரு log file-ஐ மீண்டும் பெறக்கூடிய (reclaimable) object-ஆகக் கருதுவதில்லை. du காட்டும் directory அளவு, docker system df ஒப்புக்கொள்ளும் அளவை விட மிக அதிகமாக இருந்தால், அதற்கு log files-தான் காரணம், இதைப் பற்றி கீழே ஒரு பகுதி உள்ளது.

ஒவ்வொரு object-க்கும் தனித்தனி விவரங்களைப் பெற -v-ஐச் சேர்க்கவும்.

docker system df -v

இது சுருக்கத்தை ஒவ்வொரு object வகைக்கும் தனித்தனிப் பிரிவுகளாகப் பிரிக்கிறது. Image பிரிவில் SHARED SIZE மற்றும் UNIQUE SIZE columns சேர்க்கப்படுகின்றன, இதன் மூலம் ஒரு குறிப்பிட்ட image உண்மையில் எவ்வளவு இடத்தை எடுத்துக்கொள்கிறது என்பதை நீங்கள் அறியலாம். Volume பிரிவில் LINKS எண்ணிக்கை சேர்க்கப்படுகிறது, இது அந்த volume-உடன் இணைக்கப்பட்டுள்ள containers-ன் எண்ணிக்கையாகும். LINKS-ஐ நினைவில் கொள்ளுங்கள், ஏனெனில் 0 என்ற மதிப்புதான் அந்த volume prune கட்டளைகள் எவற்றிற்குப் பொருந்தும் என்பதற்கான முழுமையான சோதனையாகும்.

Dangling images மற்றும் unused images-க்கு இடையிலான வேறுபாடு

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

Dangling image என்பது எந்தவொரு tag-உம் இல்லாத image ஆகும். இது <none> கட்டளையின் வெளியீட்டில் docker images என்று காட்டப்படும். ஒவ்வொரு முறை நீங்கள் rebuild செய்யும்போதும் இது உருவாகிறது: docker build -t myapp:latest . கட்டளையானது myapp:latest tag-ஐ புதிய image-க்கு மாற்றுகிறது; பழைய image அதன் அனைத்து layer-களையும் வைத்திருந்தாலும், அதன் பெயரை இழந்துவிடுகிறது. இதை எதனுடனும் இணைக்க முடியாது, தானாகவே இது நீக்கப்படவும் செய்யாது.

Unused image என்பது தற்போது எந்தவொரு container-ஆலும் பயன்படுத்தப்படாத, tag செய்யப்பட்ட அல்லது செய்யப்படாத எந்தவொரு image-உம் ஆகும். நீங்கள் கடந்த மாதம் pull செய்த, ஆனால் தற்போது இயங்காத ஒரு postgres:16, unused image ஆகும்; இது dangling image அல்ல.

docker image prune        # dangling images only
docker image prune -a     # every image no container refers to

இரண்டாவது கட்டளை முதலில் ஒரு உறுதிப்படுத்தலைக் கேட்கும்.

WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N]

அந்தக் குறிப்பை கவனமாகப் படிக்கவும். "Associated to them" என்பது தற்போது இயங்கிக்கொண்டிருக்கும் அல்லது நிறுத்தப்பட்டிருக்கும் ஒரு container object-ஐக் குறிக்கிறது. நீங்கள் docker compose down கட்டளையை இயக்கினால், containers நீக்கப்பட்டுவிடும்; எனவே அந்த services பயன்படுத்திய அனைத்து image-களும் unused நிலைக்குச் சென்றுவிடும், மேலும் -a கட்டளை அவை அனைத்தையும் நீக்கிவிடும். இதனால் நீங்கள் மீண்டும் பெற முடியாத தரவுகள் எதுவும் இழக்கப்படாது, ஆனால் அடுத்த முறை docker compose up -d கட்டளையை இயக்கும்போது, அவை அனைத்தும் மீண்டும் pull செய்யப்படும் அல்லது rebuild செய்யப்படும். இது சிறிய VPS-களில் bandwidth மற்றும் build நேரத்தை வீணடிக்கும். எதையும் prune செய்வதற்கு முன்பு, docker compose down எவற்றை நீக்குகிறது மற்றும் stop எவற்றை அப்படியே வைத்திருக்கிறது என்பதைத் தெரிந்துகொள்வது நடைமுறை ரீதியாக அவசியமாகும்.

ஒரு filter சமீபத்திய image-களை நீக்கப்படாமல் பாதுகாக்கிறது.

docker image prune -a --filter "until=240h"

இது 240 மணிநேரத்திற்கு (10 நாட்கள்) முன்பு உருவாக்கப்பட்ட unused image-களை மட்டும் நீக்கும், புதியவற்றை அப்படியே விட்டுவிடும். until மதிப்பு, 240h போன்ற Go duration string-ஐ அல்லது 2026-08-01T00:00:00 போன்ற ஒரு குறிப்பிட்ட timestamp-ஐ எடுத்துக்கொள்ளும்.

Build cache என்றால் என்ன மற்றும் அது ஏன் வரம்பின்றி வளர்கிறது

Docker Engine 23.0 முதல் docker build மற்றும் docker compose build ஆகியவற்றிற்கு Docker இயல்பாகப் பயன்படுத்தும் builder தான் BuildKit. இது தான் இயக்கும் ஒவ்வொரு Dockerfile-ன் ஒவ்வொரு படிநிலையின் முடிவையும் cache செய்கிறது, மேலும் அந்த cache-ஐ /var/lib/docker/buildkit-ல் சேமித்து வைக்கிறது. உங்கள் இரண்டாவது build சில நொடிகளில் முடிவதற்கு இந்த cache தான் காரணம், எனவே அது தனது பணியைச் சரியாகச் செய்கிறது. இதில் உள்ள சிக்கல் என்னவென்றால், பழைய பதிவுகளை நீக்குவதற்கு இயல்பாக எந்த வழிமுறையும் இல்லை. ஒவ்வொரு முறையும் மாறும் COPY படிநிலையைக் கொண்டு ஒரே image-ஐ ஐம்பது முறை build செய்தால், நீங்கள் ஐம்பது அடுக்குகள் (layers) கொண்ட தொகுப்புகளை வைத்திருப்பீர்கள்.

இந்த build cache docker image prune-க்குத் தெரியாது. இது தனித்துவமான கட்டளைகளைக் கொண்ட ஒரு தனி வகை object ஆகும்.

docker builder prune                        # dangling cache
docker builder prune -a                     # all unused cache
docker builder prune --filter until=168h    # cache untouched for 7 days

இவற்றில் எதையும் நீக்குவது உங்கள் images அல்லது தரவுகளைப் பாதிக்காது. build cache-ஐ நீக்குவதால் ஏற்படும் ஒரே இழப்பு, அடுத்த build ஒருமுறை மெதுவாக நடக்கும் என்பது மட்டுமே. தொடர்ந்து images-ஐ rebuild செய்யும் VPS-ல், docker system df-ல் Build Cache பெரும்பாலும் மிகப்பெரிய அளவை ஆக்கிரமித்திருக்கும், எனவே நீங்கள் நீக்கக்கூடிய பாதுகாப்பான பெரிய கோப்பு இதுவே ஆகும்.

பாதுகாப்பான முறையிலிருந்து அழிக்கும் முறை வரை வரிசைப்படுத்தப்பட்ட prune கட்டளைகள்

இந்த வரிசையைப் பின்பற்றிச் செயல்படவும். df -h / மீண்டும் இயல்பான நிலைக்குத் திரும்பியவுடன் நிறுத்திவிடவும். ஒவ்வொரு கட்டளையும் முடிவடையும் போது ஒரு Total reclaimed space: வரியை வெளியிடும்.

1. docker container prune நிறுத்தப்பட்ட containers-ஐ நீக்கும். அவற்றின் writable layers-ம் நீக்கப்படும் என்பதால், volume-க்கு வெளியே container எழுதிய தரவுகள் அனைத்தும் அழிந்துவிடும். Volumes பாதிக்கப்படாது.
2. docker image prune பயன்பாட்டில் இல்லாத (dangling) images-ஐ மட்டும் நீக்கும். இதுவே மிக பாதுகாப்பான image கட்டளையாகும்.
3. docker builder prune பயன்பாட்டில் இல்லாத build cache-ஐ நீக்கும். இதனால் ஒருமுறை build செய்வது மெதுவாக இருக்கும்.
4. docker image prune -a எந்த container-உம் பயன்படுத்தாத அனைத்து images-ஐயும் நீக்கும். இதனால் மீண்டும் pull செய்யவோ அல்லது rebuild செய்யவோ வேண்டியிருக்கும்.
5. docker system prune முதல் மூன்று கட்டளைகளையும் ஒரே நேரத்தில் செய்து, பயன்படுத்தப்படாத networks-ஐயும் நீக்கும்.
6. docker volume prune பயன்படுத்தப்படாத anonymous volumes-ஐ நீக்கும்.
7. docker volume prune -a பெயரிடப்பட்டவை உட்பட பயன்படுத்தப்படாத அனைத்து volumes-ஐயும் நீக்கும். இந்த கட்டளைதான் database-களை அழிக்கும்.

docker system prune இயங்குவதற்கு முன்பு அதன் வரம்பை (scope) தெரிவிக்கும்.

WARNING! This will remove:
        - all stopped containers
        - all networks not used by at least one container
        - all dangling images
        - unused build cache
Are you sure you want to continue? [y/N]

Volumes இந்த பட்டியலில் வேண்டுமென்றே சேர்க்கப்படவில்லை. --volumes-ஐச் சேர்ப்பது anonymous volumes-ஐ வரம்பிற்குள் கொண்டுவரும். -a-ஐச் சேர்ப்பது, dangling images-ஐ மட்டும் நீக்கும் நிலையை, பயன்படுத்தப்படாத அனைத்து images-ஐயும் நீக்கும் நிலைக்கு விரிவுபடுத்தும். ஒரு production host-ல் முழுமையான docker system prune -a --volumes -f கட்டளையை இயக்குவது, இடவசதியை உருவாக்க முயலும்போது தரவுகளை இழக்க வழிவகுக்கும்.

ஏன் volumes-ஐ prune செய்வது உங்கள் database-ஐ நீக்குகிறது

இந்த பகுதியை இரண்டு முறை படிக்கவும்.

ஒரு volume-உடன் எந்த container-ம் இணைக்கப்படாதபோது, அது பயன்படுத்தப்படாததாகக் கருதப்படுகிறது. இதுவே முழுமையான சோதனை. அந்த volume காலியாக உள்ளதா, compose file-ல் அது இன்னும் குறிப்பிடப்பட்டுள்ளதா, அல்லது உங்கள் database-ன் ஒரே நகல் அதில் உள்ளதா என்பதை Docker சரிபார்ப்பதில்லை. LINKS 0 என்பது docker system df -v-ல் உள்ளதை நீக்கக்கூடியது என்று மட்டுமே குறிக்கும், வேறு எதையும் குறிக்காது.

இப்போது இரண்டு சாதாரண செயல்களை வரிசையாகச் செய்து பார்ப்போம். ஒரு stack-ஐ முறையாக restart செய்ய நீங்கள் docker compose down-ஐ இயக்குகிறீர்கள். இது containers-ஐ நீக்கிவிட்டு, named volumes-ஐ அப்படியே வைத்திருக்கும்; இதுவே அதன் ஆவணப்படுத்தப்பட்ட செயல்பாடு. இப்போது உங்கள் Postgres volume எதனுடனும் இணைக்கப்படவில்லை. பத்து நிமிடங்களுக்குப் பிறகு, இடத்தை விடுவிக்க நீங்கள் docker volume prune -a-ஐ இயக்குகிறீர்கள், இப்போது database அழிந்துவிடும். இரண்டு கட்டளைகளும் சரியாகவே செயல்பட்டன. ஆனால், இந்த வரிசைமுறை தரவுகளை அழித்துவிட்டது.

Docker Engine 23.0 (API version 1.42) முதல், சாதாரண கட்டளை முன்பை விடக் குறுகிய செயல்பாட்டைக் கொண்டுள்ளது.

WARNING! This will remove anonymous local volumes not used by at least one container.

Anonymous volume என்பது Docker உங்களுக்காக உருவாக்கியது; பொதுவாக ஒரு image VOLUME-ஐக் குறிப்பிடும்போது, நீங்கள் அதற்குப் பெயர் வைக்காததால் இது உருவாகிறது. இவை பொதுவாக நீங்கள் வைத்திருக்க விரும்பாத தரவுகளைக் கொண்டிருக்கும். உங்கள் compose file-ல் நீங்கள் குறிப்பிட்ட named volume, நீங்கள் -a-ஐச் சேர்க்கும்போது மட்டுமே நீக்கப்படும். பழைய Docker பதிப்புகள் சாதாரண கட்டளையின் மூலம் இரண்டையும் நீக்கின, எனவே நீங்கள் upgrade செய்த ஒரு server-ல் பழைய பழக்கங்களை நம்ப வேண்டாம். named volumes மற்றும் bind mounts-க்கு இடையிலான வேறுபாடு தெரிந்தால் மட்டுமே இந்த வித்தியாசம் புரியும், ஏனெனில் bind mount என்பது Docker volume அல்ல, எனவே எந்த prune கட்டளையும் அதைத் தொடாது.

நீக்குவதற்கு முன் கவனிக்கவும். நீங்கள் சரிபார்க்கும் volume பெயருக்கு myapp_pgdata-ஐ மாற்றவும்.

docker volume ls -f dangling=true
docker volume inspect myapp_pgdata
sudo ls -la /var/lib/docker/volumes/myapp_pgdata/_data

ஒரு volume-ல் உள்ள dangling=true filter என்பது அது எதனுடனும் இணைக்கப்படவில்லை என்று அர்த்தமே தவிர, அது காலியாக உள்ளது என்று அர்த்தமல்ல. _data-ஐப் பட்டியலிடுவது உள்ளே உண்மையில் என்ன இருக்கிறது என்பதைக் காட்டும். அதில் pgdata அல்லது mysql directory-ஐக் கண்டால், மேற்கொண்டு எதையும் செய்வதற்கு முன் நிறுத்திவிட்டு ஒரு நகலை எடுக்கவும். docker compose down -v மூலமாகவும் இதே அழிவு நிகழும், இது compose file-ல் குறிப்பிடப்பட்டுள்ள அனைத்து volumes-ஐயும் உங்களிடம் கேட்காமல் நீக்கிவிடும்.

Docker host-ல் ஒரு rebuild-ஆல் மீண்டும் உருவாக்க முடியாத ஒரே விஷயம் volume மட்டுமே. அதனால்தான் volume தரவுகள் server-க்கு வெளியே இயங்கும் restic backup-ல் இருக்க வேண்டும், அங்கு தவறான flag-ஆல் அதை அணுக முடியாது.

எதுவும் நீக்கப்படாதபோது: container log கோப்புகள்

நீங்கள் அனைத்தையும் நீக்கிவிட்டீர்கள், docker system df எதையும் மீட்டெடுக்க முடியாது என்று காட்டுகிறது, ஆனால் disk இன்னும் நிரம்பியுள்ளது. Log கோப்புகளைச் சரிபார்க்கவும்.

sudo find /var/lib/docker/containers -name '*-json.log' -exec du -h {} + | sort -h | tail -10

ஒவ்வொரு container-ம் அதன் standard output மற்றும் standard error-ஐ /var/lib/docker/containers/-க்குக் கீழ் உள்ள ஒரு JSON கோப்பில் எழுதுகிறது. இயல்புநிலை நிறுவலில் max-size அமைக்கப்படாமல் இருக்கும், அதாவது வரம்பற்றது. இதனால், crash loop-ல் சிக்கிய ஒரு container, partition நிரம்பும் வரை தரவுகளை எழுதிக்கொண்டே இருக்கும். எந்த prune கட்டளையும் இந்தக் கோப்புகளை நீக்காது, ஏனெனில் அவற்றை உருவாக்கும் container-கள் இயங்கிக்கொண்டிருக்கின்றன; எனவே அவை நீக்கக்கூடியவை அல்ல.

கோப்பை நீக்க வேண்டாம். திறந்திருக்கும் log கோப்பில் rm கட்டளையை இயக்குவது எதையும் விடுவிக்காது, ஏனெனில் Docker daemon அந்த கோப்பின் file descriptor-ஐத் தொடர்ந்து வைத்திருக்கும். அந்த handle மூடப்படும் வரை kernel அந்தத் தொகுதிகளை (blocks) ஒதுக்கீடு செய்தே வைத்திருக்கும். df-ல் எந்த மாற்றமும் இருக்காது. அதற்குப் பதிலாக, கோப்பை truncate செய்யவும்; இது அதே inode-ஐ வைத்திருக்கும் மற்றும் daemon தொடர்ந்து எழுத அனுமதிக்கும்.

sudo find /var/lib/docker/containers -name '*-json.log' -exec truncate -s 0 {} +
df -h /

இது ஒரு தற்காலிகத் தீர்வு மட்டுமே. அந்த container-களுக்கான docker logs இப்போது எதையும் காட்டாது, ஆனால் கோப்புகள் உடனடியாக மீண்டும் வளரத் தொடங்கும். இதற்கான நிரந்தரத் தீர்வு rotation ஆகும், இது அடுத்த பகுதியில் விளக்கப்பட்டுள்ளது.

ஒவ்வொரு முறையும் மாற்றத்திற்கு முன்பும் பின்பும் அளவிடவும்

ஒரு prune செயல்பாடு என்ன செய்தது என்பதை யூகிக்க வேண்டாம். முதலில் ஒரு அளவீட்டை எடுக்கவும், ஒரு கட்டளையை இயக்கவும், பிறகு மீண்டும் ஒரு அளவீட்டை எடுக்கவும்.

df -h /
docker system df
docker builder prune -f --filter until=168h
docker image prune -f
docker system df
df -h /

இரண்டு df வெளியீடுகளையும் ஒப்பிடவும். உங்கள் server தொடர்ந்து இயங்குமா என்பதைத் தீர்மானிக்கும் ஒரே எண் இதுதான். எந்த வரிசை உண்மையில் மாறியது என்பதை docker system df உங்களுக்குத் தெரிவிக்கும், மேலும் ஒவ்வொரு prune செயல்பாடும் அதன் சொந்த Total reclaimed space: மதிப்பைப் பதிப்பிக்கும்.

df மாறவில்லை, ஆனால் docker system df இடவசதி விடுவிக்கப்பட்டதாகக் கூறினால், திறந்திருக்கும் ஒரு file handle நீக்கப்பட்ட தொகுதிகளை (blocks) பிடித்துக் கொண்டிருக்கிறது என்று அர்த்தம்; இது மேலே குறிப்பிடப்பட்ட log file சிக்கலாகும். இரண்டுமே மாறி, ஒரு நாளுக்குள் மீண்டும் வட்டு (disk) நிரம்பிவிட்டால், அது cleanup சிக்கல் அல்ல, அது வளர்ச்சிச் சிக்கலாகும். இதற்கு rotation மற்றும் திட்டமிடப்பட்ட பணி (scheduled job) ஆகியவையே தீர்வாகும்.

மீண்டும் disk நிரம்பாமல் தடுப்பது எப்படி

Log அளவை கட்டுப்படுத்துங்கள். /etc/docker/daemon.json-ஐ உருவாக்கி அல்லது திருத்துங்கள்.

{
  "log-driver": "json-file",
  "log-opts": {
    "max-size": "10m",
    "max-file": "3"
  }
}

இது ஒவ்வொரு container-ன் log அளவையும் 30 MB-ஆகக் கட்டுப்படுத்தும். log-opts-ன் கீழ் உள்ள அனைத்து மதிப்புகளும், எண்களாக இருந்தாலும், string-ஆகவே இருக்க வேண்டும். நீங்கள் restart செய்வதற்கு முன், கோப்பு சரியாக உள்ளதா என்று சரிபார்க்கவும்; ஏனெனில் தவறான daemon.json இருந்தால், daemon தொடங்காது மற்றும் அனைத்து container-களும் செயலிழந்துவிடும்.

python3 -m json.tool /etc/docker/daemon.json
sudo systemctl restart docker
docker info | grep -i 'logging driver'

docker info இப்போது Logging Driver: json-file என்று காட்ட வேண்டும். restart செய்த பிறகு உருவாக்கப்பட்ட container-ன் docker inspect-ல் உள்ள LogConfig பகுதியில் இந்த வரம்புகள் தெரியும். இது முக்கியமான அம்சம்: இந்த அமைப்பு புதிய container-களுக்கு மட்டுமே பொருந்தும். ஏற்கனவே உள்ள container-கள் அவை உருவாக்கப்பட்டபோது இருந்த configuration-லேயே இருக்கும், எனவே அவற்றை மீண்டும் உருவாக்க வேண்டும்.

docker compose up -d --force-recreate

ஒரே service-க்கு அதிக log தேவைப்பட்டால், compose கோப்பிலேயே அந்த service-க்கு மட்டும் இந்த வரம்பை அமைக்கலாம்.

services:
  app:
    logging:
      driver: json-file
      options:
        max-size: "10m"
        max-file: "3"

Prune செய்வதை திட்டமிடுங்கள். வாரந்தோறும், பயன்படுத்தப்படாத images மற்றும் பழைய build cache-ஐ நீக்குமாறு திட்டமிடுங்கள். -a அல்லது --volumes ஆகியவற்றை ஒரு scheduled job-ல் ஒருபோதும் சேர்க்காதீர்கள். ஏனெனில், ஒரு stack இயங்காத நேரத்தில் இந்த job இயங்கினால், அந்த stack-ன் images நீக்கப்படும்; மேலும் --volumes-ஐப் பயன்படுத்தினால், அது உங்கள் தரவுகளையும் பாதிக்கும்.

sudo tee /etc/cron.weekly/docker-prune >/dev/null <<'EOF'
#!/bin/sh
docker image prune -f
docker builder prune -f --filter until=168h
EOF
sudo chmod +x /etc/cron.weekly/docker-prune
sudo /etc/cron.weekly/docker-prune

கடைசி வரி அந்த script-ஐ ஒருமுறை கைமுறையாக இயக்கும், எனவே அது தானாக இயங்குவதற்கு முன்பே அதன் output-ஐ நீங்கள் பார்க்கலாம். கோப்பு executable-ஆக இருக்க வேண்டும், மேலும் அதன் பெயரில் dot இருக்கக்கூடாது. ஏனெனில் run-parts, executable அல்லாத கோப்புகளையும் extension கொண்ட கோப்புகளையும் தவிர்க்கும்.

Free space குறித்து எச்சரிக்கை செய்யுங்கள். disk நிரம்பிய பிறகு prune செய்வது ஒரு மீட்பு நடவடிக்கை. 80 சதவீதம் நிரம்பும்போதே எச்சரிக்கை செய்வது தடுப்பு நடவடிக்கை.

usage=$(df --output=pcent / | tr -dc '0-9')
[ "$usage" -ge 80 ] && echo "root filesystem at ${usage} percent full"

இதை நீங்கள் ஏற்கனவே பயன்படுத்தும் notifier-உடன் சேர்த்து cron-ல் பதிவேற்றுங்கள். Free space என்பது ஒரு பகுதி மட்டுமே, எனவே இதனுடன் உங்கள் VPS-ல் disk health monitoring-ஐயும் இணைக்கவும். ஏனெனில், disk பழுதடைவதும், disk நிரம்புவதும் உங்கள் container-களை நிறுத்திவிடும், ஆனால் இவை இரண்டிற்கும் வெவ்வேறு தீர்வுகள் தேவை.

மேலே உள்ள அனைத்தும் /var/lib/docker-ல் data root உள்ள ஒரு standard install-ஐ அடிப்படையாகக் கொண்டவை. நீங்கள் daemon.json-ல் உள்ள data-root key மூலம் அதை மாற்றியிருந்தால், ஒவ்வொரு command-லும் உங்கள் path-ஐப் பயன்படுத்தவும். ஒரு புதிய server-ல் இந்த அமைப்பைச் சரியாகச் செய்வது VPS-ல் Docker-ஐ அமைப்பதன் ஒரு பகுதியாகும். தவறான partition-ல் 40 GB அளவுள்ள container-கள் சேர்ந்த பிறகு மாற்றுவதை விட, தொடக்கத்திலேயே இதைத் தீர்மானிப்பது எளிது.

FAQ

docker system prune எனது volumes-ஐ நீக்கிவிடுமா?

இல்லை. இந்த எளிய கட்டளை நிறுத்தப்பட்ட containers, பயன்படுத்தப்படாத networks, dangling images மற்றும் பயன்படுத்தப்படாத build cache ஆகியவற்றை மட்டுமே நீக்கும். உறுதிப்படுத்தும் prompt-ல் எவை நீக்கப்படும் என்பது தெளிவாகக் காட்டப்படும். --volumes-ஐச் சேர்க்கும்போது மட்டுமே volumes நீக்கப்படும். Docker Engine 23.0 பதிப்பிலிருந்து, இந்த flag anonymous volumes-ஐ மட்டுமே பாதிக்கும், named volumes-ஐ அல்ல. Named volumes-ஐ நீக்க docker volume prune -a மற்றும் docker compose down -v ஆகிய கட்டளைகளைப் பயன்படுத்த வேண்டும். இந்த இரண்டு கட்டளைகளைப் பயன்படுத்தும்போது கவனமாக இருக்கவும்.

docker prune செய்த பிறகும் எனது disk ஏன் இன்னும் நிரம்பியுள்ளது?

இதற்கு இரண்டு பொதுவான காரணங்கள் உள்ளன. முதலாவது, /var/lib/docker/containers/-ல் உள்ள container log files ஆகும். எந்தவொரு prune கட்டளையும் இவற்றை நீக்காது. நீங்கள் max-size-ஐ அமைக்கும் வரை இவை வரம்பின்றி வளர்ந்துகொண்டே இருக்கும். இரண்டாவது, ஒரு process இன்னும் திறந்து வைத்திருக்கும் நீக்கப்பட்ட கோப்பு. ஒரு container இயங்கிக்கொண்டிருக்கும்போது rm மூலம் log கோப்பை நீக்கினால், daemon அதன் file descriptor-ஐத் தக்கவைத்துக்கொள்ளும். இதனால் kernel அந்தத் தொகுதிகளை (blocks) விடுவிக்காது, எனவே df எந்த மாற்றத்தையும் காட்டாது. உங்களிடம் எந்தப் பிரச்சனை உள்ளது என்பதை அறிய sudo du -xh --max-depth=1 /var/lib/docker மற்றும் docker system df ஆகியவற்றை ஒப்பிட்டுப் பார்க்கவும்.

docker image prune மற்றும் docker image prune -a ஆகியவற்றுக்கு என்ன வித்தியாசம்?

எளிய கட்டளை dangling images-ஐ மட்டுமே நீக்கும். அதாவது, tag இல்லாத, பெரும்பாலும் rebuild செய்யப்பட்ட பிறகு எஞ்சியிருக்கும் images மட்டுமே நீக்கப்படும். -a வடிவம், எந்தவொரு container-ஆலும் பயன்படுத்தப்படாத அனைத்து images-ஐயும் நீக்கும்; இதில் நீங்கள் வேண்டுமென்றே தரவிறக்கம் செய்த tagged images-ம் அடங்கும். docker compose down செய்த பிறகு containers நீக்கப்பட்டுவிடும், எனவே -a அந்த stack-ன் images-ஐயும் சேர்த்து நீக்கிவிடும். எதையும் நிரந்தரமாக இழக்க மாட்டீர்கள், ஏனெனில் அடுத்த முறை தொடங்கும் போது அவை மீண்டும் தரவிறக்கம் செய்யப்படும் அல்லது உருவாக்கப்படும். ஆனால், இணைய வேகம் குறைவாக இருந்தால் இது அதிக நேரம் எடுக்கும்.

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

/etc/docker/daemon.json-ல் உள்ள log-opts பிரிவின் கீழ் max-size மற்றும் max-file ஆகியவற்றை அமைக்கவும். பின்னர் sudo systemctl restart docker மூலம் daemon-ஐ restart செய்யவும். இந்த அமைப்பு restart செய்த பிறகு உருவாக்கப்படும் containers-க்கு மட்டுமே பொருந்தும். எனவே, தற்போது இயங்கிக்கொண்டிருக்கும் containers-ஐ docker compose up -d --force-recreate மூலம் மீண்டும் உருவாக்கவும். ஒரு compose கோப்பில் logging key-ன் கீழ் ஒவ்வொரு service-க்கும் இதே இரண்டு விருப்பங்களை அமைக்கலாம். மற்றவற்றை விட ஒரு service அதிக logs-ஐ உருவாக்கினால், இந்த முறை சிறந்தது.

cron job-ல் docker system prune-ஐ இயக்குவது பாதுகாப்பானதா?

அனைத்து stacks-ம் எப்போதும் இயங்கிக்கொண்டிருக்கும் ஒரு host-ல் எளிய docker system prune -f கட்டளையைப் பயன்படுத்துவது பாதுகாப்பானது. ஆனால், இது நிறுத்தப்பட்ட containers-ஐ நீக்கிவிடும் என்பதால், நீங்கள் வேண்டுமென்றே நிறுத்தி வைத்திருக்கும் மற்றும் பின்னர் பயன்படுத்தத் திட்டமிட்டிருக்கும் container-ம் நீக்கப்படலாம். பாதுகாப்பான scheduled job என்பது docker image prune -f உடன் docker builder prune -f --filter until=168h-ஐச் சேர்ப்பதாகும். இது மிக வேகமாக வளரும் இரண்டு தரவுகளை நீக்கும், மேலும் இது எந்தவொரு volume-ஐயும் பாதிக்காது. -a அல்லது --volumes ஆகியவற்றை ஒருபோதும் schedule செய்ய வேண்டாம்.