أهلاً بالجميع. اسمي لي، وأنا أقوم باستضافة Discourse بنفسي بشكل متقطع منذ عام 2013. أتذكر أنني اضطررت للعبث بـ rbenv حتى أتمكن من البدء. أتذكر أنني اضطررت إلى تجميع nginx مع Phusion Passenger لجعل الأمور تعمل. أتذكر أنني تشاجرت مع @sam ربما قبل عشر سنوات بأن التحول إلى Docker كان استسلامًا لضعف المطور “إنه يعمل مع دليل منزلي الخاص بي وكابوسي الخاص بالملفات المخفية” (وكنت مخطئًا تمامًا!). أتذكر المرة الأولى التي سمعت فيها عبارة “bike-shedding”. لاقتباس الرجل، أتذكر كل شيء.
بعد الابتعاد لعدة سنوات، سنحت لي الفرصة للعودة إلى استضافة Discourse بنفسي كبديل لتعليقات WordPress الأصلية على موقع طقس في منطقة هيوستن والذي يحقق عادةً حوالي 10 آلاف زيارة صفحة في اليوم، ولكن خلال الأعاصير، قد يصل إلى حوالي 2 مليون زيارة صفحة في اليوم إلى حوالي مليون زائر فريد. لقد واجهنا صعوبات مع تعليقات WordPress الأصلية لسنوات، ولكن اعتبارًا من الأربعاء الماضي، نحن مباشرون على Discourse المستضاف ذاتيًا. (وعلى Graviton3، لا أقل! بجدية، إنه يعمل فقط وهو رائع.)
هذه هي النقطة التي أصل إليها: إنه عام 2025، وبصفتي مستضيفًا ذاتيًا، ما زلت أتعامل مع إدارة مساحة صور Docker الخاصة بي يدويًا. أقدم قصة عن /dev/root، تُروى في مقتطفات برمجية، بعد أقل من أسبوع في الإنتاج:
[11:49:56] 0 ✓ (1.8ms)
root@discourse:/var/discourse # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 21G 9.6G 69% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 3.1G 1.1M 3.1G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
efivarfs 128K 3.6K 125K 3% /sys/firmware/efi/efivars
/dev/nvme1n1p16 891M 109M 720M 14% /boot
/dev/nvme1n1p15 98M 6.4M 92M 7% /boot/efi
/dev/nvme0n1 32G 346M 30G 2% /var/discourse
tmpfs 1.6G 12K 1.6G 1% /run/user/1001
overlay 30G 21G 9.6G 69% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged
[11:49:59] 0 ✓ (4.8ms)
root@discourse:/var/discourse # ./launcher cleanup
WARNING! This will remove all stopped containers.
Are you sure you want to continue? [y/N] y
Total reclaimed space: 0B
WARNING! This will remove all images without at least one container associated to them.
Are you sure you want to continue? [y/N] y
Deleted Images:
untagged: discourse/base@sha256:3696bdf18652b5455bd33795ec3b8e0f201c17a04f0e0126fc0317ed821373cd
....
[مجموعة كبيرة جدًا من الأسطر محذوفة]
....
Total reclaimed space: 12.43GB
[11:50:34] 0 ✓ (27.8s)
root@discourse:/var/discourse # df -h
Filesystem Size Used Avail Use% Mounted on
/dev/root 30G 6.9G 24G 23% /
tmpfs 7.7G 0 7.7G 0% /dev/shm
tmpfs 3.1G 1.1M 3.1G 1% /run
tmpfs 5.0M 0 5.0M 0% /run/lock
efivarfs 128K 3.6K 125K 3% /sys/firmware/efi/efivars
/dev/nvme1n1p16 891M 109M 720M 14% /boot
/dev/nvme1n1p15 98M 6.4M 92M 7% /boot/efi
/dev/nvme0n1 32G 346M 30G 2% /var/discourse
tmpfs 1.6G 12K 1.6G 1% /run/user/1001
overlay 30G 6.9G 24G 23% /var/lib/docker/overlay2/5a649418bbfc064f488e895572eec1ace487a3eaa324fe1d8e3b395e6c5e3645/merged
[11:55:28] 0 ✓ (3.3ms)
root@discourse:/var/discourse #
أحبكم يا رفاق. أحب Discourse. أنا متزوج من المنتج وأعتزم الاستمرار في استخدامه أكثر أو أقل إلى الأبد.
ولكن، مثل… فقط، لماذا. لماذا عام 2025 وما زلت أنا بنفسي أدير launcher cleanup يدويًا؟ لماذا لا تكون إدارة الصور وظيفة متأصلة في launcher؟
مرة أخرى، أحبكم يا رفاق. اخترت Discourse لـ SCW لأنني أؤمن بما بنيتموه وأحب استخدامه. ولكن مثل… هذا نصف حجم تمهيد AMI المسكين الخاص بي مرتبط بأشياء غير مفيدة يمكن - على الأقل إذا فهمت الجانب التقني للأمور - إدارتها تلقائيًا.
لا أقصد الشكوى - فقط أتحقق مرة أخرى بعد بضع سنوات بعيدًا عن كرسي المسؤول. أحب اكتشاف البريد العشوائي بالذكاء الاصطناعي وفرز البريد العشوائي بالذكاء الاصطناعي، خاصة في منتدى الطقس حيث تكون المشاركات المشحونة سياسيًا بخصوص تغير المناخ (سواء مع أو ضد) ميزة منتظمة. شكراً على كل شيء
لقد حدث لي نفس الشيء على موقعي المستضاف ذاتيًا هذا الأسبوع. كانت النسخ الاحتياطية تفشل وتركت ذلك لمدة أسبوع تقريبًا لأنني كنت بعيدًا ولم يكن لدي وصول إلى جهاز الكمبيوتر المحمول الخاص بي. بمجرد عودتي ، قمت بتشغيل التنظيف واستعدت مساحة قرص كبيرة وتمكنت النسخ الاحتياطية من العمل مرة أخرى.
جزء من ذلك هو أنه كان “جيدًا بما فيه الكفاية” - نحن لا نستخدمه داخليًا في الاستضافة الخاصة بنا نظرًا لأننا نقوم بتدوير الحاويات والصور بشكل متكرر، لذا فإن وتيرتنا تختلف كثيرًا عن شكل موقع الاستضافة الذاتية.
التفسير الآخر هنا هو أنه بين المشغل و Docker، لا يوجد نظام يريد تحمل المسؤولية الكاملة عن جدول إزالة البيانات - يجب أن يكون الجدول الزمني لحذف بيانات المستخدم تحت سيطرة المستخدم الكاملة.
لقد واجهت بعض المشكلات في المواقع ذاتية الاستضافة حيث يؤدي التنظيف أيضًا إلى تنظيف قاعدة Discourse الجديدة التي كنت بحاجة إلى بنائها، مما يؤدي إلى مشكلة بيضة/دجاجة مروعة. إن عدم ملاحظة ذلك بسبب تشغيله تلقائيًا قد يكون عقبة كبيرة لمحاولة اكتشافها.
قد يكون الاقتراح البسيط هنا هو جدولة docker system prune أو launcher clean على مسؤوليتك الخاصة. هل يمكن أن ينجح؟
لا أعرف أي شيء آخر ولكن اليوم، مرة أخرى، فشل إعادة البناء لأن المساحة الفارغة المتبقية لدي كانت أقل من 5 جيجابايت. بالتأكيد، قامت cleanup بالمهمة، ولم يكن ذلك سوى أمر مزعج بعض الشيء. ومع ذلك، أود ألا أرى مثل هذه المواقف.
وهنا يظهر مدى قلة فهمي لكيفية عمل دوكر إذا فهمت بشكل صحيح، فإن تلك الصور، التي تم تدميرها لأنها لم تكن مستخدمة من قبل أي حاوية، لم تكن صورًا بالمعنى الحرفي للكلمة كما كنت أعتقد طوال الوقت
الإجابة المباشرة هي أنه يمكنك استخدام echo y | launcher cleanup لإرسال “y” مبكرًا.
الإجابة غير المباشرة هي أن تنظيف المشغل الفعلي (بعد أن يكون مكافئًا) هو هذه الأوامر:
في الواقع، أنا أشير إلى الأسئلة التي حصلت عليها عند تشغيل ./launcher cleanup. أولاً، يقوم بإزالة جميع الحاويات المتوقفة. ثم يعرض حذف جميع الصور التي لا تستخدمها حاوية واحدة على الأقل - وهذا الجزء هو الذي يحرر المساحة بالنسبة لي، ما يقرب من 40 جيجابايت في المرة الأخيرة.
لهذا السبب كنت مرتبكًا للغاية لأنني لم أتمكن من فهم سبب وجود العديد من الصور اليتيمة (jpg، png، إلخ). لكننا نتحدث هنا عن صور مختلفة تمامًا، أليس كذلك.
نعم، أقوم بإعادة البناء مرتين على الأقل كل أسبوع. أو مؤخرًا جدًا عندما كنت أبحث عن مكون إضافي واحد ذي سلوك سيء، قمت بإعادة البناء عشرات المرات.
وهو ما قد يكون محبطًا إذا كنت تقوم بتشغيله باستخدام برنامج نصي؛ سيتوقف البرنامج النصي عن الاستجابة في انتظار رد (أعتقد أن هذا هو سبب توجيه yes إليه). أنا فقط أقوم بالتنظيف إذا كان القرص يحتوي على أقل من 10 جيجابايت مساحة خالية.
إليك ربما حل بديل محتمل قد ينجح معي. سأطرحه هنا في حال كان مفيدًا للآخرين.
أفكر في إضافة إعداد data-root إلى /etc/docker/daemon.json، لمعرفة ما إذا كان ذلك سيجبر دوكر على وضع صوره - صور ديسكورس، في هذه الحالة، نظرًا لعدم استضافة أي شيء آخر على الجهاز - في موقع أقل أهمية لن يؤدي إلى تفجير وحدة التمهيد الخاصة بي.
البحث في ميتا عن مواضيع سابقة حول هذا الموضوع يعطيني نتيجتيناثنتين لا تخبراني بالكثير حقًا، وقبل أن أتسبب في انهيار نسخة ديسكورس الإنتاجية الخاصة بي في كومة مشتعلة متفحمة، أردت أن أسأل لمعرفة ما إذا كان هذا ممكنًا
لقد اتبعت نهجًا مختلفًا، وقمت بتركيب نظام ملفات منفصل على /var/lib/docker
في حالتي، ولأسباب خاصة جدًا بالموقع، اخترت أنظمة ملفات منفصلة لكل من /var/discourse/shared و /var/discourse/shared/data و /var/discourse/shared/app/uploads/default/original و /var/lib/docker - ولكن إذا كنت ترغب فقط في أن يكون /var/discourse كنظام ملفات منفصل، يمكنك على الأرجح إنشاء الدليل /var/discourse/share/docker وربطه بـ /var/lib/docker (من الواضح أن القيام بذلك مع نظام هادئ ونقل الملفات حسب الضرورة).
إذا فهمت بشكل صحيح، فإن تلك الصور، التي تم تدميرها لأنها لم تكن مستخدمة من قبل أي حاوية، لم تكن صورًا بالمعنى الحرفي للكلمة كما كنت أعتقد طوال الوقت 
