أي نصائح حول كيفية توفير المساحة؟

نحن ندير موقع Discourse مستضاف ذاتيًا على DigitalOcean ولدينا قرص بسعة 25 جيجابايت. لقد حاولت للتو تحديث صورة Discourse الخاصة بنا وحصلت على رسالة تفيد بأنك بحاجة إلى مساحة أكبر للمتابعة. بعد تنظيف صورة Docker والحاويات، ما زلنا بحاجة إلى 0.4 جيجابايت.

أي نصائح حول كيفية توفير المساحة؟ سواء لتحديث الآن أو لتوفير المساحة في المستقبل. أعلم أننا سنحتاج إلى تغيير الحجم قريبًا، ولكن سيكون من المفيد تجاوز تحديث واحد آخر لصورة Discourse على الأقل.

4 إعجابات

هل تخزن النسخ الاحتياطية محليًا؟
إذا كان الأمر كذلك، فربما يساعد التخلص من بعض النسخ القديمة. 0.4 جيجابايت (أي 400 ميجابايت) يجب أن تكون قابلة للإدارة.

يمكنك أيضًا محاولة تنظيف بعض المساحة على النظام المضيف أيضًا.

إعجاب واحد (1)

حاول إعادة تشغيل الخادم الخاص بك ثم حاول مرة أخرى إذا كنت متأكدًا من وجود مساحة كافية.

نحن نستخدم وظيفة النسخ الاحتياطي الخاصة بـ DigitalOcean. لم أرَ خيارًا لحذف إحدى نسخنا الاحتياطية يدويًا.

كيف يمكنني القيام بذلك؟ أنا شخص ليس لدي خبرة في البرمجة ولكني قادر على فهم ما يجب القيام به ولماذا أقوم به بعد الحصول على بعض التوجيهات.

جربت إعادة التشغيل ولم يحدث تغيير.

بعد تشغيل sudo du -h --max-depth 1، هذه هي نتائجي:

جرب تقليم كائنات Docker غير المستخدمة

إعجاب واحد (1)

في هذه المرحلة، سأوفر على نفسي عناء القيام بالعمل لتغيير الحجم الآن.

3 إعجابات

لقد قمت بتقليم كل شيء باستثناء وحدات التخزين غير المستخدمة لأن docker volume ls أظهر أن لدينا واحدة فقط.

هل جربت؟

./launcher cleanup

إعجاب واحد (1)

نعم!\n\nلقد تعمقت أكثر في صور دوكر الخاصة بنا باستخدام docker images -a، ورأيت هذا.\n\n

\n\nماذا يحدث مع <none>؟

إعجاب واحد (1)

أدت بعض عمليات البحث على جوجل إلى هذا التعليق المثير للاهتمام للغاية.

rofranoJohn Rofrano

Nov '17

من المهم فهم سبب ظهور الصور الوسيطة غير المسماة على أنها <none> <none> لتجنبها، لأنه كما رأيت، لا يمكنك إزالتها إذا كانت قيد الاستخدام.

السبب في ظهور الصور غير المسماة هو أنك قمت ببناء صورة، ثم قمت بتغيير Dockerfile وقمت ببناء تلك الصورة مرة أخرى، وأعادت استخدام بعض الطبقات من البناء السابق. الآن لديك صورة غير مسماة لا يمكن حذفها لأن بعض طبقاتها قيد الاستخدام من قبل إصدار جديد من تلك الصورة.

الحل هو:

  • حذف الإصدار الجديد من الصورة
  • حذف الصورة غير المسماة و
  • إعادة بناء الإصدار الجديد من الصورة بحيث تمتلك جميع الطبقات.

سيتبقى لديك صورة مسماة واحدة تحتوي على جميع طبقات الصور غير المسماة السابقة والصورة الجديدة.

~jr

[اقتباس=“Michael Brown, post:7, topic:252779, username:supermathie”]
في هذه المرحلة، سأوفر على نفسي المتاعب وأقوم بتغيير الحجم الآن.
[/اقتباس]

لم أكن أتوقع أن أجد 2.64 جيجابايت في صورة
docker image، لذلك أحاول الآن معرفة ما يحدث هناك. إذا لم أكن بحاجة إلى هذه الصورة على الإطلاق، فنحن بالتأكيد بعيدون عن الحاجة إلى تغيير الحجم.

هل قمت بتشغيل

./launcher cleanup

لكنني أوصي بتغيير الحجم. أنا متفاجئ من أنك استمررت بهذه المدة الطويلة بمساحة 25 جيجابايت.

أيضًا، هل نظرت في shared/backups/default؟

بالتأكيد لا أثق في نسخ DigitalOcean الاحتياطية كوسيلة لعمل نسخة احتياطية لمنتدىك.

إعجابَين (2)

كم من الوقت؟ لا أرى أي تلميح لذلك - أعرف أنني أقوم بتشغيل منتدى واحد بسعة 20 جيجابايت ومنتدى آخر بسعة 25 جيجابايت بسعادة.

تحت المشاركة قد يكون لديك الكثير من بيانات النسخ الاحتياطي (ربما في shared/standalone/backups/default). قد يكون لديك أيضًا نسخ قديمة من قاعدة البيانات، أو ملفات سجل قديمة. أوصي بتشغيل
du -kx / | sort -n | tail -49
أو ما شابه.

من العدل ملاحظة أنه يمكنك توفير الوقت، على حساب المال، بالانتقال إلى مثيل أكبر. أو يمكنك إجراء المقايضة المعاكسة.

هذا يقلقني قليلاً. قد تساعدك DO في عمل نسخ احتياطية لنظامك بأكمله، ولكن لو كنت مكانك، لكان سيسعدني معرفة كيفية عمل نسخ احتياطية لـ Discourse وكيفية الحصول على نسخة محلية آمنة. وكيفية تقليم النسخ الاحتياطية. (إذا قام DO بحذف مثيلك وحسابك لسوء حظ ما، فستحتاج إلى أن تنجو بياناتك من ذلك.)

:woman_facepalming:t3: نستخدم وظيفة النسخ الاحتياطي لـ Discourse أيضًا، وأدركت أننا لم نمسح النسخ الاحتياطية القديمة هناك.

حسنًا، لقد حذفت كل النسخ الاحتياطية باستثناء الأحدث باستخدام واجهة Discourse وقمت أيضًا بتنزيل أحدث نسخة احتياطية إلى محرك الأقراص المحلي الخاص بي. هذا يجعلني أقل من 100 ميجابايت بعيدًا عن الحصول على مساحة كافية.

إليك ما أحصل عليه عند تشغيل هذا الأمر في var/discourse

656876  /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var/www/discourse/vendor
819624  /var/log/journal/e734ad1931dbee4740881cc15c9e7a9a
826292  /var/discourse/shared/standalone
826296  /var/discourse/shared
831476  /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse/.cache/yarn/v6
831484  /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse/.cache/yarn
831492  /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse/.cache
832188  /var/discourse
845992  /lib/modules
850136  /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home/discourse
850144  /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/home
898764  /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91/diff/usr/lib
966656  /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff/var/www/discourse
966660  /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff/var/www
966664  /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff/var
991800  /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765/diff
991816  /var/lib/docker/overlay2/21f4d6109bd809c584ae84f9f7c50286c6126176f86a2ef61c4c24ce1e633765
994980  /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6/diff/usr/lib
1089092 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff/var/www/discourse
1089096 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff/var/www
1130168 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff/var
1177644 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49/diff
1177660 /var/lib/docker/overlay2/9817d45d2728572ad6dc4d62df5944dfad69c35b76753ceb260e0130863ece49
1224436 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var/www/discourse
1224440 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var/www
1224444 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff/var
1234612 /lib
1248080 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d/diff
1248096 /var/lib/docker/overlay2/81fd81f27d0d8fe795f510fe8d70c4ecad96405b0e1dbb57f0440fe9c398a30d
1342320 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91/diff/usr
1516440 /usr
1543656 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/var/www/discourse
1543664 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/var/www
1558580 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff/var
1659548 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91/diff
1659564 /var/lib/docker/overlay2/58e9df9d9e2e10efb3dcf68771edd172664f8d91e3aa2e0b280fd4549bfd2a91
2040472 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6/diff/usr
2171304 /var/log/journal/d893af269dfb5f73239a5b6761d49ea0
2388612 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6/diff
2388628 /var/lib/docker/overlay2/2749f8a24b3e28af399b256ecab7f2db0cb146939a0ef56e83858a0e696c3df6
2461904 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058/diff
2461924 /var/lib/docker/overlay2/7bedcd4746ebce6e3fe7bbb5ec2c987a1c046efc715fad1e53201b18b97b6058
3064672 /var/log/journal
3276268 /var/log
10107180        /var/lib/docker/overlay2
10131984        /var/lib/docker
10396840        /var/lib
14869684        /var
20007992        /

لقد تلقيت تعليمات إضافية حول كيفية التعامل مع ما يلي:

التفاصيل هي:

rofranoJohn Rofrano

1

20h

الأمر لإزالة صورة هو:

docker rmi {image_name}

حيث {image_name} هو اسم الصورة التي تريد حذفها. يمكنك أيضًا استخدام معرف الصورة لحذف الصورة (على سبيل المثال، docker rmi {image_id}). هذا ما ستحتاج إلى استخدامه لحذف صورة باسم <none>.

على سبيل المثال، لنفترض أن لديك الصور التالية:

REPOSITORY           TAG        IMAGE ID       CREATED              SIZE
my-new-image         latest     c18f86ab8daa   12 seconds ago       393MB
<none>               <none>     b1ee72ab84ae   About a minute ago   393MB
my-image             latest     f5a5f24881c3   2 minutes ago        393MB

من الممكن أن الصورة <none> لا يمكن حذفها لأن my-new-image تستخدم بعض الطبقات منها. ما تحتاج إلى القيام به هو:

docker rmi my-new-image:latest
docker rmi b1ee72ab84ae
docker built -t my-new-image .

ما يفعله هذا هو إزالة my-new-image:latest التي تعيد استخدام طبقات من صورة <none>. ثم يحذف صورة <none> باستخدام معرف الصورة الخاص بها b1ee72ab84ae. أخيرًا، يعيد بناء my-new-image مما يؤدي إلى إنشاء جميع الطبقات المطلوبة.

تحقق أيضًا للتأكد من عدم وجود حاويات متوقفة لا تزال تستخدم صورة <none> “غير الموسومة”. استخدم docker ps -a لرؤية جميع الصور بما في ذلك تلك التي تم إنهاؤها. إذا كان الأمر كذلك، استخدم docker rm {container_id} لإزالة الحاوية ثم حاول إزالة صورة <none> مرة أخرى.

ما رأيكم جميعًا؟

أعتقد أنه يمكنك تحسين الأمور هنا:

انظر هذا التبادل السابق:

و

3 إعجابات

لقد نجح هذا وقمت بتغيير السياسة أيضًا!

ما زلت أرغب في تتبع المشكلة المتعلقة بصورة <none> (نظرًا لأنه من السخيف أن تشغل مساحة تزيد عن 2 جيجابايت)، لكنك قمت بحل مشكلتي الأكثر إلحاحًا المتمثلة في إنشاء مساحة كافية للترقية! شكرًا لك!!

3 إعجابات

صحيح تمامًا! في الوقت الحالي، أستمتع كثيرًا بتعلم أشياء جديدة، لذا فإن الوقت يستحق العناء.