17 سبتمبر 2025·7 دقيقة
مبادئ كين طومسون في UNIX وراء الحاويات ونظام التشغيل السحابي
استكشف مبادئ UNIX لكين طومسون—الأدوات الصغيرة، الأنابيب، نظام الملفات كواجهة، والواجهات المستقرة—وكيف شكّلت الحاويات، لينكس، وبُنية السحابة.
استكشف مبادئ UNIX لكين طومسون—الأدوات الصغيرة، الأنابيب، نظام الملفات كواجهة، والواجهات المستقرة—وكيف شكّلت الحاويات، لينكس، وبُنية السحابة.
لم يكن هدف كين طومسون بناء "نظام تشغيل يدوم للأبد". مع دينيس ريتشي وآخرين في بيل لابس، سعى إلى نظام صغير وقابل للاستخدام يمكن للمطوّرين فهمه وتحسينه ونقله بين الآلات. صيغ UNIX بأهداف عملية: إبقاء النواة بسيطة، جعل الأدوات تعمل معاً جيداً، وتجنب قفل المستخدمين في نموذج حاسوبي واحد.
المفاجأة أنّ تلك الاختيارات المبكرة تتطابق جيداً مع الحوسبة الحديثة. استبدلنا الطرفيات بلوحات تحكم الويب والخوادم الوحيدة بأساطيل من الآلات الافتراضية، لكن الأسئلة نفسها تظهر مراراً:
تطورت (أو استبدلت) ميزات UNIX المحددة، لكن مبادئ التصميم بقيت مفيدة لأنها تصف كيفية بناء الأنظمة:
تظهر هذه الأفكار في كل مكان—من توافق Linux و POSIX إلى وقت التشغيل الخاص بالحاويات الذي يعتمد على عزل العمليات، namespaces وحِيَل نظام الملفات.
سنربط مفاهيم UNIX من عصر طومسون بما تتعامل معه اليوم:
دليل عملي: مصطلحات قليلة، أمثلة ملموسة، وتركيز على "لماذا يعمل" بدلاً من التوافه. إذا أردت نموذجاً ذهنياً سريعاً للحاويات وسلوك نظام التشغيل السحابي، فأنت في المكان المناسب.
يمكنك أيضاً القفز مباشرة إلى /blog/how-unix-ideas-show-up-in-containers عندما تكون جاهزاً.
لم يبدأ UNIX كاستراتيجية منصة كبرى. بدأ كنظام صغير وعملي بناه كين طومسون (مع مساهمات مهمة من دينيس ريتشي وآخرين في بيل لابس) يفضّل الوضوح والبساطة وإنجاز العمل المفيد.
في الأيام الأولى، كانت نظم التشغيل مرتبطة غالباً بنموذج حاسوبي محدد. عند تغيير العتاد، كان عليك عملياً تغيير نظام التشغيل (وغالباً البرمجيات) أيضاً.
نظام تشغيل قابل للنقل كان يعني شيئاً عملياً: يمكن أن تعمل نفس مفاهيم نظام التشغيل وكثير من الشفرة على آلات مختلفة مع إعادة كتابة أقل بكثير. عبر التعبير عن UNIX بلغة C، قلّل الفريق الاعتماد على أي CPU واحد وجعل تبني UNIX وتعديله أمراً واقعياً للآخرين.
عندما يقول الناس "UNIX" ربما يقصدون نسخة بيل لابس الأصلية، أو متغيراً تجارياً، أو نظاماً حديثاً شبيهاً بـ UNIX (مثل Linux أو BSD). الخيط المشترك أقل عن علامة تجارية وأكثر عن مجموعة مشتركة من اختيارات التصميم والواجهات.
وهنا تبرز أهمية POSIX: معيار يصيغ الكثير من سلوكيات UNIX (الأوامر، استدعاءات النظام، الاصطلاحات)، مما يساعد البرمجيات على البقاء متوافقة عبر أنظمة UNIX ومشتقاتها—حتى عندما لا تكون تطبيقاتها متطابقة.
شاع UNIX قاعدة تبدو بسيطة: ابنِ برامج تقوم بمهمة واحدة جيداً، واجعلها سهلة التركيب مع غيرها. لم يهدف كين طومسون وفريقه إلى تطبيقات عملاقة شاملة؛ بل إلى أدوات صغيرة ذات سلوك واضح—لكي تتمكن من تكديسها معاً لحل مشكلات حقيقية.
أداة تقوم بمهمة واحدة جيدة أسهل للفهم لأنه عدد الأجزاء المتحركة أقل. كما أنها أسهل للاختبار: يمكنك تغذيتها بمدخل معروف وفحص المخرج دون إعداد بيئة كاملة. عندما تتغير المتطلبات، يمكنك استبدال جزء واحد دون إعادة كتابة كل شيء.
يشجّع هذا النهج أيضاً على "قابلية الاستبدال". إذا كانت أداة بطيئة أو محدودة أو تفتقد ميزة، يمكنك استبدالها بأخرى طالما حافظت على توقعات الإدخال/الإخراج الأساسية.
فكّر في أدوات UNIX كقطع LEGO. كل قطعة بسيطة. القوة تأتي من كيفية اتصالها.
مثال كلاسيكي لمعالجة النصوص حيث تحول البيانات خطوة بخطوة:
cat access.log | grep \" 500 \" | sort | uniq -c | sort -nr | head
حتى لو لم تحفظ الأوامر، الفكرة واضحة: ابدأ بالبيانات، صفِّها، لخصها، وعرِض النتائج العليا.
الخدمات الصغيرة ليست "أدوات UNIX على الشبكة"، وإجبار هذا التشبيه قد يضلل. لكن الغريزة الأساسية مألوفة: اجعل المكونات مركّزة، حدّد حدوداً واضحة، واجمع أنظمة أكبر من أجزاء صغيرة تستطيع التطور بشكل مستقل.
استفاد UNIX كثيراً من اصطلاح بسيط: على البرامج أن تستطيع قراءة الإدخال من مكان وكتابة الإخراج إلى مكان آخر بطريقة متوقعة. سمح هذا الاصطلاح بتركيب أدوات صغيرة لصنع "أنظمة" أكبر دون إعادة كتابتها.
الأنبوب يربط مخرج أمر مباشرة بمدخل أمر آخر. فكّر فيه كتمرير ورقة: أداة تنتج نصاً، والأداة التالية تستهلكه.
عادةً تستخدم أدوات UNIX ثلاثة قنوات قياسية:
بسبب ثبات هذه القنوات، يمكنك "توصيل" البرامج معاً دون أن يعرف كلٌ منها شيئاً عن الآخر.
تشجع الأنابيب الأدوات على أن تكون صغيرة ومركّزة. إذا كان البرنامج يقبل stdin ويصدر stdout، يصبح قابلاً لإعادة الاستخدام في سياقات عديدة: الاستخدام التفاعلي، الوظائف الدفعية، المهام المجدولة، والنصوص البرمجية. لهذا السبب أنظمة شبيهة يونكس مناسبة جداً للسكريبتات: الأتمتة غالباً هي مجرد "وصل هذه القطع".
هذه القابلية للتركيب هي خط مباشر من UNIX المبكر إلى كيفية تجميع سير عمل السحابة اليوم.
قام UNIX بتبسيط جرئ: عامل العديد من الموارد كما لو كانت ملفات. ليس لأن ملف القرص ولوحة المفاتيح متشابهان، بل لأن منحهم واجهة مشتركة (فتح، قراءة، كتابة، إغلاق) يجعل النظام سهل الفهم وسهل الأتمتة.
/dev/. القراءة من /dev/urandom تشعر كما لو أنك تقرأ ملفاً، رغم أنها في الواقع برنامج تشغيل جهاز ينتج بايتات.عندما تشترك الموارد في واجهة واحدة، تحصل على رافعة: مجموعة صغيرة من الأدوات تعمل عبر سياقات كثيرة. إذا كان "الإخراج بايتات" و"الإدخال بايتات"، فإن الأدوات البسيطة يمكن ربطها بطرق لا حصر لها—دون أن يحتاج كل أداة لمعرفة خاصة عن الأجهزة أو الشبكات.
هذا يشجّع أيضاً على الاستقرار. يمكن للفرق بناء سكربتات وعادات تشغيل حول مجموعة من البديهيات (تيارات القراءة/الكتابة، مسارات الملفات، الصلاحيات) وتثق أن هذه المبادئ لن تتغير مع كل تقنية جديدة.
لا تزال عمليات السحابة الحديثة تعتمد على هذه الفكرة. تُعامل سجلات الحاويات عادةً كتدفقات يمكنك متابعتها وإعادة توجيهها. يكشف /proc في لينكس عن قياسات النظام والعملية كملفات، حتى تتمكن عوامل الرصد من "قراءة" CPU والذاكرة وإحصاءات العملية كنص عادي. هذه الواجهة الشبيهة بالملف تجعل الرصد والأتمتة قابلة للتطبيق حتى على نطاق واسع.
نموذج صلاحيات UNIX بسيط لكنه فعّال: لكل ملف (والعديد من موارد النظام التي تتصرف كملفات) مالك، مجموعة، ومجموعة بتات صلاحية لثلاثة جماهير—المستخدم، المجموعة، والآخرون. ببتات القراءة/الكتابة/التنفيذ، أسس UNIX لغة مشتركة لمن يمكنه فعل ماذا.
إذا رأيت شيئاً مثل -rwxr-x--- فقد رأيت النموذج كله في سطر واحد:
هذا الهيكل يتدرج جيداً لأنه سهل الاستدلال وسهل التدقيق. كما أنه يدفع الفرق نحو عادة نظيفة: لا تفتح كل شيء فقط لتعمل الأشياء.
الأقل امتيازاً يعني منح شخص أو عملية أو خدمة فقط ما تحتاجه لأداء مهمتها—وليس أكثر. عملياً، هذا غالباً يعني:
منصات السحابة ووقت تشغيل الحاويات تعكس الفكرة نفسها بأدوات مختلفة:
صلاحيات UNIX قيّمة—لكنها ليست استراتيجية أمان كاملة. لا تمنع كل تسرب بيانات، ولا توقف استغلال كود ضعيف، ولا تغني عن ضوابط الشبكة وإدارة الأسرار. اعتبرها الأساس: ضرورية ومفهومة وفعّالة—لكن غير كافية بمفردها.
تعامل UNIX مع العملية—مثيل قيد التشغيل لشيء ما—كوحدة أساسية، ليس فكرة ثانوية. يبدو هذا تجريدياً حتى ترى كيف يشكّل الاعتمادية وتعدد المهام وطريقة مشاركة الخوادم (والحاويات) لمورد واحد.
البرنامج كالـ "ورقة وصفة": يصف ما يجب فعله.
العملية كالطباخ الذي يطبخ من تلك الوصفة الآن: لديه خطوة حالية، مكونات مرصوفة، موقد يعمل، ومؤقت. يمكنك وجود عدة طهاة يستخدمون نفس الوصفة في آنٍ واحد—كل طباخ عملية منفصلة بحالته الخاصة، حتى لو انطلقتوا من نفس البرنامج.
تصمم أنظمة UNIX بحيث يكون لكل عملية "فقاعة" تنفيذ خاصة بها: ذاكرة خاصة، عرض خاص للملفات المفتوحة، وحدود واضحة لما يمكنها لمسه.
هذا العزل مهم لأن الأعطال تبقى محصورة. إذا تعطلت عملية، فعادةً لا تسقط العمليات الأخرى معها. هذا سبب رئيسي لأن الخوادم يمكنها تشغيل خدمات متعددة على نفس الجهاز: خادم ويب، قاعدة بيانات، مجدول خلفي، جامعي سجلات—كلٌ كعمليات منفصلة يمكن بدءها، إيقافها، إعادة تشغيلها ومراقبتها باستقلال.
على الأنظمة المشتركة، يدعم العزل أيضاً مشاركة موارد أكثر أماناً: يمكن لنظام التشغيل فرض حدود (مثل وقت CPU أو الذاكرة) ومنع عملية خارجة عن السيطرة من تجويع الباقي.
يوفر UNIX أيضاً الإشارات، وسيلة خفيفة وزن لإخبار عملية بشيء. اعتبرها نقرة على الكتف:
يبني "التحكم بالوظائف" على هذه الفكرة في الاستخدام التفاعلي: يمكنك إيقاف مهمة، استئنافها في المقدمة، أو تركها تعمل في الخلفية. الفكرة ليست راحة فقط—بل أن العمليات مخصّصة لتُدار كوحدات حية.
بمجرد أن تصبح العمليات سهلة الإنشاء والعزل والتحكم، يصبح تشغيل workloads متعددة بأمان على آلة واحدة أمراً طبيعياً. هذا النموذج الذهني—وحدات صغيرة يمكن الإشراف عليها وإعادة تشغيلها وتقييدها—هو سلف مباشر لكيفية عمل مديري الخدمات وأوقات تشغيل الحاويات اليوم.
لم يفز UNIX لأنه كان أول من يملك كل ميزة. استمر لأنه جعل بعض الواجهات مملة—وظلّها كذلك. عندما يعتمد المطوّرون على نفس استدعاءات النظام، نفس سلوك سطر الأوامر، ونفس اصطلاحات الملفات لسنوات، تتراكم الأدوات بدل إعادة كتابتها.
الواجهة هي الاتفاق بين برنامج والنظام المحيط: "إذا طلبت X ستحصل على Y." حافظ UNIX على اتفاقات رئيسية مستقرة (العمليات، مؤشرات الملفات، الأنابيب، الصلاحيات)، مما سمح للأفكار الجديدة أن تكبر فوقها دون كسر البرمجيات القديمة.
غالباً ما يذكر الناس "توافُق API"، لكن هناك طبقتين:
واجهات ABI المستقرة سبب كبير لاستمرار الأنظمة: تحمي البرمجيات المترجمة الجاهزة.
التقييس POSIX قام بالتقاط مساحة مستخدمية "شبيهة UNIX": استدعاءات النظام، الأدوات، سلوك الشِل، والاصطلاحات. لا يجعل كل نظام مطابقاً، لكنه يخلق تداخلاً كبيراً حيث يمكن بناء واستخدام نفس البرمجيات عبر Linux و BSDs وأنظمة مشتقة أخرى.
تعتمد صور الحاويات بهدوء على سلوك شبيه يونكس مستقر. تفترض العديد من الصور:
تبدو الحاويات محمولة ليس لأنها تضم "كل شيء"، بل لأنها تجلس فوق عقدة مشتركة واسعة ومستقرة. هذه العقدة أحد أهم مساهمات UNIX الباقية.
تبدو الحاويات حديثة، لكن النموذج الذهني يونكس جداً: عالج برنامج قيد التشغيل كعملية مع مجموعة واضحة من الملفات، الصلاحيات وحدود الموارد.
الحاوية ليست "آلة افتراضية خفيفة". هي مجموعة من العمليات العادية على المضيف تم تغليفها (التطبيق مع مكتبته وتكوينه) وعزلها لتتصرف كأنها وحيدة. الاختلاف الكبير: الحاويات تشارك نواة المضيف، بينما الآلات الافتراضية تشغّل نواة خاصة بها.
العديد من ميزات الحاويات امتداد مباشر لأفكار UNIX:
آليتان في النواة تقومان بمعظم العمل الثقيل:
بما أن الحاويات تشارك النواة، العزل ليس مطلقاً. ثغرة في النواة قد تؤثر على كل الحاويات، والتكوينات الخاطئة (التشغيل كجذر، صلاحيات واسعة، تركيب مسارات حساسة من المضيف) يمكن أن تثقّب الحدود. مخاطر "الهروب" واقعية—لكن عادةً يتم التخفيف منها عبر إعدادات افتراضية حذرة، أقل الصلاحيات، وممارسات تشغيلية جيدة.
شاع UNIX عادة بسيطة: ابنِ أدوات صغيرة تقوم بمهمة واحدة، وصلها بواجهات واضحة، ودع البيئة تتكفل بالتوصيل. تبدو أنظمة cloud-native مختلفة على السطح، لكن نفس الفكرة تناسب العمل الموزع بشكل مدهش: تظل الخدمات مركزة، تبقى نقاط التكامل واضحة، وتبقى عمليات التشغيل متوقعة.
في الكتلة، "الأداة الصغيرة" غالباً ما تعني "حاوية صغيرة". بدلاً من شحن صورة ضخمة تحاول فعل كل شيء، تفصل الفرق المسؤوليات إلى حاويات ذات سلوك ضيق، قابل للاختبار ومدخلات/مخرجات مستقرة.
أمثلة شائعة تردّد صدى تركيب UNIX الكلاسيكي:
كل قطعة لها واجهة واضحة: منفذ، ملف، نقطة HTTP، أو stdout/stderr.
ربطت الأنابيب البرامج؛ المنصات الحديثة توصل تيارات القياس. تتدفق السجلات والقياسات والتتبعات عبر عوامل، جامعات، وخلفيات تماماً مثل خط أنابيب:
application → عامل عقدة/sidecar → جامع → تخزين/تنبيهات.
الفائدة هي نفسها كمع الأنابيب: يمكنك إدراج مرحلة، استبدالها، أو إزالتها (تصفية، عيّنة، إثراء) دون إعادة كتابة المنتج.
القطع القابلة للتركيب تجعل النشر قابلاً للتكرار: منطق "كيفية تشغيل هذا" يعيش في بيانات تصريحية والتشغيل الآلي، لا في ذاكرة شخص ما. تسهّل الواجهات القياسية نشر التغييرات، إضافة التشخيصات، وتطبيق السياسات عبر الخدمات—وحدة صغيرة في كل مرة.
أحد أسباب عودة مبادئ UNIX هو أنها تتطابق مع كيفية عمل الفرق فعلاً: التكرار بخطوات صغيرة، الحفاظ على واجهات مستقرة، والتراجع عند المفاجأة.
إذا كنت تبني خدمات ويب أو أدوات داخلية اليوم، فإن منصات مثل Koder.ai هي في الجوهر طريقة راجحة لتطبيق هذه العقلية بأقل احتكاك: تصف النظام في محادثة، تتكرر على مكونات صغيرة، وتحافظ على الحدود واضحة (الواجهة الأمامية React، الخلفية Go مع PostgreSQL، الجوال Flutter). ميزات مثل وضع التخطيط، اللقطات والتراجع، وتصدير الشيفرة المصدرية تدعم نفس عادة التشغيل التي شجّعها UNIX—غيّر بأمان، راقب النتائج، واجعل النظام مفهوماً.
كين طومسون وفريق بيل لابس ركزوا على أن تكون الأنظمة قابلة للفهم والتعديل: جوهر صغير، اصطلاحات بسيطة، وأدوات يمكن إعادة تركيبها. هذه الاختيارات ما زالت تخدم حاجات حديثة مثل الأتمتة، العزل، وإدارة أنظمة كبيرة مع مرور الوقت.
إعادة كتابة UNIX بلغة C خفّضت الاعتماد على نموذج مُعالج واحد أو جهاز محدد. هذا جعل نقل نظام التشغيل (والبرمجيات المبنية عليه) بين أجهزة مختلفة أمراً عملياً، ومهد الطريق لتوقعات القابلية للنقل ومعايير مثل POSIX.
POSIX يوثّق مجموعة مشتركة من سلوكيات شبيهة يونكس (استدعاءات النظام، الأدوات، اصطلاحات الشِل). لا يجعل كل نظام متطابقاً، لكنه يخلق منطقة توافق واسعة بحيث يمكن بناء وتشغيل البرمجيات عبر أنظمة يونكس ومشتقاتها مع مفاجآت أقل.
الأدوات الصغيرة أسهل للفهم والاختبار والاستبدال. عندما يكون لكل أداة عقدة إدخال/إخراج واضحة، يمكنك حل مشكلات أكبر بتركيبة هذه الأدوات—غالباً دون تغيير الأدوات نفسها.
الـ pipe (|) يصل stdout لبرنامج واحد إلى stdin للبرنامج التالي، مما يتيح بناء أنابيب تحويل. فصل stderr يساعد الأتمتة: يمكن معالجة المخرجات العادية بينما تبقى الأخطاء مرئية أو تُعاد توجيهها بشكل مستقل.
الفكرة أن يونكس يستخدم واجهة موحدة—open, read, write, close—لموارد متعددة، وليس فقط لملفات القرص. هذا يعني أن نفس الأدوات والعادات تعمل في سياقات كثيرة (تحرير التكوين، متابعة السجلات، قراءة معلومات النظام).
أمثلة شائعة: ملفات الأجهزة في /dev وملفات التشخيص مثل /proc.
نموذج المالك/المجموعة/الآخرون مع بتات القراءة/الكتابة/التنفيذ يجعل الصلاحيات سهلة الفهم والتدقيق. مبدأ الأقل امتيازاً هو عادة تشغيلية تمنح فقط ما يلزم.
خطوات عملية:
الـ برنامج هو الكود الثابت؛ الـ عملية هي مثيل قيد التشغيل بحالته الخاصة. عزل العمليات في يونكس يحسّن الاعتمادية لأن الأعطال عادةً تبقى محصورة، ويمكن التحكم في كل عملية بإشارات وأكواد خروج.
هذا النموذج يدعم اليوم أدوات الإشراف وإدارة الخدمات (ابدأ/أوقف/أعد تشغيل/راقب).
الواجهات الثابتة هي عقود طويلة الأمد (استدعاءات النظام، مؤشرات الملفات، الأنابيب، الإشارات) تسمح بتراكم الأدوات بدل إعادة كتابتها.
ثبات الـ ABI مهم لأن يحمي البرمجيات المترجمة من الكسر عبر الزمن. الحاويات تستفيد لأن كثيراً من الصور تفترض سلوكاً يونكسياً ثابتاً من المضيف.
الحاوية تُفهم أفضل كعزل عمليات + تغليف، لا كآلة افتراضية خفيفة الوزن. الحاويات تشارك نواة المضيف بينما الآلات الافتراضية تشغّل نواة خاصة بها.
آليات النواة الرئيسية:
المخاطر: لأن الحاويات تشارك النواة، فإن ثغرة نواة أو تكوين خاطئ (تشغيل كـ root، صلاحيات واسعة، تركيب مسارات حساسة من المضيف) قد يضعف العزل.