'docker system prune -a' ማሄድ ደህንነቱ የተጠበቀ ነው?

የቆሙ containers፣ ጥቅም ላይ ያልዋሉ networks፣ ባለቤት የሌለው build cache እና በሚሰራ container ጥቅም ላይ ያልዋለ እያንዳንዱን image ያጠፋል። --volumes ካልጨመሩ ዳታዎ ይቆያል። በ--volumes ጥቅም ላይ ያልዋሉ volumes ጭምር ይጠፋሉ — የቆመ የdatabase container volume ደግሞ ጥቅም ላይ እንዳልዋለ ይቆጠራል። እርግጠኛ ካልሆኑ ይህን flag አይጠቀሙ።

ትልቅ የlog ፋይል ሰረዝኩ፣ ግን df አሁንም ዲስኩ እንደሞላ ያሳያል። ለምን?

የሚሰራ process ፋይሉን አሁንም ከፍቶ ይዟል፣ ስለዚህ kernelኡ ቦታውን አይለቅም። በ'lsof +L1' ያግኙትና ያንን service እንደገና ያስጀምሩት። በሚቀጥለው ጊዜ ንቁ logን ከመሰረዝ ይልቅ በ'truncate -s 0 file' ባዶ ያድርጉት።

ምን ያህል ነፃ ቦታ መተው አለብኝ?

ቢያንስ 10–15%። databases፣ የpackage ዝማኔዎችና የDocker pull ጊዜያዊ ቦታ ያስፈልጋቸዋል፣ 100% የሞላ ዲስክ ደግሞ database በመጻፍ መሃል ሊያበላሽ ይችላል።

ዳግም ሳልጭን ዲስክ መጨመር እችላለሁ?

አዎ። ወደ ትልቅ ፕላን ማሳደግ ዲስኩን ባለበት ያሰፋዋል፣ ዳታዎም ይቆያል — Nano 15 GB፣ Micro 25 GB፣ Small 35 GB፣ Medium 45 GB አላቸው። ማሳደጉ ሰርቨሩን አንድ ጊዜ እንደገና ያስጀምረዋል።

ትንሽ VPSን ብዙውን ጊዜ የሚሞላው ምንድን ነው?

በልምዳችን፦ የDocker images እና build cache፣ የsystemd journal፣ ማንም የማያዞራቸው የመተግበሪያ logዎች፣ እና በ/root ውስጥ የተረሱ የdatabase dumps ወይም የbackup archives።

ምንም ሳይበላሽ በVPS ላይ የዲስክ ቦታ እንዴት እንደሚለቀቅ

የVPS ዲስክ ሞላ? በdu እና ncdu ቦታውን የያዘውን ያግኙ፣ ከዚያ የapt cache፣ journal፣ የDocker ቅሪቶችንና logዎችን ዳታ ሳያጡ ያጽዱ።

"No space left on device" በተመቸ ጊዜ በፍጹም አይመጣም። database መጻፍ መቀበል ያቆማል፣ apt ዝማኔን መጨረስ አይችልም፣ Docker ደግሞ አሁን የሚያስፈልግዎትን image ለማውረድ እምቢ ይላል። መልካሙ ዜና፦ በትንሽ VPS ላይ ጥፋተኛው ሁልጊዜ ማለት ይቻላል ከአምስት ነገሮች አንዱ ነው፣ በሁለት ደቂቃም ያገኙታል።

1. ሁኔታው ምን ያህል ከፍቷል?

df -h /
df -i /

የመጀመሪያው መስመር ጥቅም ላይ የዋለውን ቦታ ያሳያል። ሁለተኛው inodesን ያሳያል — ቦታው ደህና መስሎ inodes ግን 100% ከደረሱ፣ ሚሊዮኖች ጥቃቅን ፋይሎች አሉዎት (የsession ፋይሎች፣ የmail ወረፋ፣ የcache ማውጫ)። ችግሩ ሌላ ነው፣ ምልክቱ ግን አንድ ነው።

2. ትልቁን ያግኙ

ዛፉን ከላይ ጀምረው ይቃኙና በመጠን ይደርድሩ፦

du -xh / --max-depth=1 2>/dev/null | sort -h | tail -15

-x በአንድ file system ውስጥ ብቻ ይቆያል፣ ስለዚህ ወደ /proc አይጠፋም። ከዚያ ወደ ትልቁ ይግቡ። በይነተገናኝ ለመቃኘት ncdu እጅግ የተመቸ ነው፦

apt install -y ncdu
ncdu -x /

ለመንቀሳቀስ የቀስት ቁልፎች፣ ለመሰረዝ d። በመጨረሻው ይጠንቀቁ።

3. ፈጣን ድሎች

እነዚህ በማንኛውም የUbuntu ወይም Debian ሰርቨር ላይ ደህንነታቸው የተጠበቀ ነው፦

apt clean
apt autoremove --purge -y
journalctl --disk-usage
journalctl --vacuum-size=200M

apt autoremove የቆዩ kernelsንም ያጸዳል። ሰዎችን የሚያስገርመው የsystemd journal ነው — ዝም ከተባለ እስከ ብዙ gigabytes ሊያድግ ይችላል። በቋሚነት ለመገደብ በ/etc/systemd/journald.conf ውስጥ SystemMaxUse=200M ያስቀምጡና systemctl restart systemd-journald ያሂዱ።

4. የDocker ቅሪቶች

Docker የሚጠቀሙ ከሆነ መጀመሪያ እዚህ ይመልከቱ። የቆዩ images እና build cache በእያንዳንዱ deploy ይከማቻሉ፦

docker system df
docker image prune -a
docker builder prune

docker image prune -a ምንም የሚሰራ container የማይጠቀምባቸውን images ያጠፋል። ብዙውን ጊዜ የሚፈልጉት ይህ ነው፣ ግን ቀጣዩ deploy እንደገና ያወርዳቸዋል።

አደገኛው docker system prune -a --volumes ነው። volumes ዳታዎን ይይዛሉ፣ ከየቆመ container ጋር የተያያዘ volume ደግሞ ጥቅም ላይ እንዳልዋለ ይቆጠራል። ሰዎች databasesን የሚያጡት እንደዚህ ነው። ከforum መልስ ገልብጠው አይለጥፉት።

ሌላው የተደበቀ ቦታ በዪ የcontainer logዎች ናቸው። በ/etc/docker/daemon.json ውስጥ ይገድቧቸው፦

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

ከዚያ Dockerን እንደገና ያስጀምሩ። ገደቡ የሚሠራው ከዚያ በኋላ በሚፈጠሩ containers ላይ ብቻ ነው፣ ስለዚህ ብዙ log የሚጽፉትን በdocker compose up -d --force-recreate እንደገና ይፍጠሩ።

5. logዎችና የተረሱ ፋይሎች

በዲስኩ ላይ በየትኛውም ቦታ ትልልቅ ፋይሎችን ያግኙ፦

find / -xdev -type f -size +500M -exec ls -lh {} + 2>/dev/null
find /var/log -type f -size +100M -exec ls -lh {} + 2>/dev/null

የተለመዱ ግኝቶች፦ በ/root ውስጥ ከስድስት ወር በፊት የነበረ backup.tar.gz፣ አንድ ሰው ሊያወርደው ያሰበው የdatabase dump፣ በፍጹም የማይዞር የመተግበሪያ log።

service አሁንም የሚጽፍበትን log በrm አይሰርዙት — ባዶ ያድርጉት፦

truncate -s 0 /var/log/myapp/app.log

አንዱን ቀድመው ሰርዘው ቦታው ካልተመለሰ፣ አንድ process አሁንም ከፍቶ ይዞታል፦

lsof +L1

እዚያ የተዘረዘረውን service እንደገና ያስጀምሩ፣ ቦታውም ይመለሳል።

ማጽዳት በቂ ካልሆነ

አንዳንድ ጊዜ ዳታው በእርግጥ ያስፈልጋል — የሚያድግ database፣ የተጠቃሚዎች uploads፣ የmodel ፋይል። ያኔ ሐቀኛው መፍትሄ ተጨማሪ ዲስክ ነው። ፕላኑን ማሳደግ ዲስኩን ባለበት ያሰፋዋል፣ ሁሉንም ይጠብቃል፦ Nano 15 GB፣ Micro 25 GB፣ Small 35 GB፣ Medium 45 GB አላቸው። ሰርቨሩ አንድ ጊዜ እንደገና ይጀምራል። ዝርዝሩ በፕላኖች ሰነድ ውስጥ ነው።

በጸጥታ ቦታ የሚበላ ሌላ ነገር፦ የswap ፋይል። የእኛን swap መመሪያ ከተከተሉ፣ ያ 1–2 GB ሆን ተብሎ የተያዘ ነው። Docker ዋናው ተጠቃሚ ከሆነ ደግሞ የDocker መጫኛ መመሪያ እና የCompose stack መመሪያ imagesን እንዴት በቁጥጥር ስር እንደሚይዙ ያሳያሉ።

ይህን ሁሉ የሚከላከለው ልማድ፦ journalን እና የDocker logዎችን ከመጀመሪያው ቀን ይገድቡ። ሁለት መስመር ቅንብር፣ እና "ዲስክ ሞላ" መከሰቱ ከሞላ ጎደል ይቆማል።