# شرح تقني: الـ container في Docker عملية Linux عادية تجمع خمس ميزات في النواة، والـ image مجلد

> **المغزى:** المغزى: فهم الـ container كعملية لا كجهاز صغير يغيّر طريقة تشخيص أعطاله، فالبحث يصبح عن namespace أو cgroup أو mount مضبوط بشكل خاطئ لا عن جهاز معطل.

- المصدر: المغزى (https://almaghza.com/a/2026-10-25-docker-container-is-linux-process/)
- التاريخ: 14 جمادى الأولى - 25 أكتوبر 2026 (2026-10-25)
- القسم: برمجيات
- الوسوم: Docker، الحاويات، Linux

نُشرت في 22 أكتوبر 2026 مقالة بعنوان Docker is weird على مدونة codeandcake.dev، كتبها مطوّر لم يذكر اسمه ويقول إنه يبني container runtime صغيرًا بنفسه. وتشرح المقالة أمرًا يفاجئ كثيرين عند تعلّم Docker: الـ container ليس جهازًا صغيرًا، بل عملية Linux عادية يمكن رؤيتها في /proc على الجهاز المضيف نفسه.

فكلمة container لا تشير إلى ميزة واحدة في النواة، بل إلى خمس ميزات تعمل معًا. وأشهرها ثلاث: الـ namespaces التي تحدد ما تراه العملية وما يُخفى عنها، والـ cgroups التي تحدد حصتها من الموارد، وعزل الشبكة الذي يمنحها طبقة شبكة مستقلة.

والجزء الأغرب في الشرح أن الـ image مجلد. فعند تشغيل docker run على ubuntu، ينزّل Docker الطبقات ويفكها في مجلد على القرص، ثم يستخدم pivot_root ليجعل هذا المجلد هو الجذر، ويشغّل bin/bash داخله.

وتعرض المقالة تفصيلة هندسية. فأداة runc مكتوبة بلغة Go، لكن Go لا تدعم fork، وبعض الـ syscalls يجب أن تُنفَّذ على خيط واحد. ولذلك يوجد داخل runc موديول صغير مكتوب بـ C اسمه nsenter، يعمل قبل أن تبدأ بيئة تشغيل Go أصلًا.

وتشرح المقالة أيضًا سبب حاجة Docker تقليديًا إلى صلاحيات root: أغلب واجهات النواة التي يستخدمها كانت تتطلب صلاحيات، فيعمل الـ daemon بها. وتحسّن الوضع مع الوضع rootless، لكن الشبكة تظل الاستثناء الكبير، إذ قد يحتاج الـ runtime الذي يعمل دون root إلى إعادة بناء طبقة الشبكة في مساحة المستخدم.

ويغيّر هذا الفهم طريقة التعامل مع الأعطال. فحين يتصرف الـ container على نحو غير متوقع، لا يكون المطلوب تشخيص جهاز، بل تشخيص عملية، والبحث عن الـ namespace أو الـ cgroup أو الـ mount المضبوط بشكل خاطئ.

## المصادر

- [مقالة Docker is weird على codeandcake.dev](https://codeandcake.dev/posts/2026-10-22-docker-is-weird)