في الساعة 2:40 فجرًا ذات ليلة، بدأت إحدى خدمات Skylane تفشل في فحوص الصحة على كل الـ nodes دفعة واحدة، مع أن الكود لم يتغيّر. تبيّن أن مكتبة أساسية على خادم البناء رُقّيت بصمت، فلم يعد البرنامج الذي شحنّاه مطابقًا للبرنامج الذي اختبرناه. وُجدت الـ containers (الحاويات) لتضع حدًّا لمثل هذه الليالي: تشحن البرنامج ومعه كل ما يحتاج إليه في حزمة واحدة، فيكون ما اختبرته هو نفسه ما يعمل.
\nأنا Amara Diallo. أتولّى المناوبة (on-call) على الـ clusters في Skylane، وكل ما في هذه الدورة إمّا شيء كسرته بنفسي أو شيء رأيته ينكسر أمامي. سنعمل على خدمة واحدة من البداية إلى النهاية.
\nnotes-api واجهة HTTP API صغيرة لإدارة الملاحظات، مكتوب بـ TypeScript ويعمل على Node.js 24. يخزّن بياناته في Postgres ويعرض أربعة مسارات: GET /notes وPOST /notes وGET /healthz (هل العملية حيّة؟) وGET /readyz (هل تصل إلى قاعدة البيانات؟). يستمع على المنفذ (port) 3000، ويقرأ إعداداته من متغيّرات البيئة مثل DATABASE_URL.
بنهاية الدورة ستكون قد بنيت الـ image الخاصة به، وشغّلته مع Postgres على جهازك، ونشرته على Kubernetes مع فحوص الصحة والتوسّع التلقائي وخطة للتراجع.
\nلا يوجد داخل نواة Linux كائن اسمه «container». حين تشغّل container، يبدأ الـ runtime عملية عادية ويغلّفها بثلاثة أشياء:
\nnode_modules، وبعض مكتبات النظام.ولأنه لا يوجد نظام تشغيل ضيف يحتاج إلى الإقلاع، يبدأ الـ container بسرعة البرنامج الذي بداخله. والثمن أن كل الـ containers على المضيف تتشارك نواة واحدة. الآلة الافتراضية جدار أقوى؛ أما الـ container فباب محكم القفل. لهذا تُصرّ الدروس اللاحقة على المستخدمين غير الـ root وعلى الـ images الصغيرة: فأنت تقلّص ما يستطيع المهاجم فعله إن تجاوز ذلك الباب.
\nعلى macOS وWindows، يشغّل Docker Desktop آلة Linux افتراضية خفيفة واحدة ويضع الـ containers داخلها. النموذج هو نفسه، كل ما في الأمر أن هناك طبقة إضافية واحدة في الأسفل.
\nالـ image لقطة لنظام ملفات مقسّمة إلى layers (طبقات)، للقراءة فقط، مع بيانات وصفية: أي أمر يُشغَّل، وأي منفذ يتوقّعه التطبيق، وبأي مستخدم يعمل. أما الـ container فنسخة قيد التشغيل من الـ image، فوقها layer رقيقة قابلة للكتابة.
\nينطبق تشبيه الـ class والـ object هنا جيدًا: image واحدة، وcontainers كثيرة. حين نوسّع notes-api إلى ست نسخ في Kubernetes، فهذه image واحدة وستة containers. والـ layer القابلة للكتابة في كل container خاصة به وقابلة للتخلّص منها، لذا فالقاعدة من اليوم الأول: الـ containers قطيع يُستبدل، والبيانات تعيش في مكان آخر. سيحفظ Postgres ملفاته في volume (وحدة تخزين دائمة)، وليس أبدًا في الـ layer القابلة للكتابة داخل container.
\n\nفي الدرس التالي ستكتب أول Dockerfile لـ notes-api، وتحوّل الكود المصدري إلى image تستطيع تشغيلها.
\n","toc":[{"id":"sec-1","text":"المشروع: notes-api","level":2},{"id":"sec-2","text":"الـ container عملية","level":2},{"id":"sec-3","text":"الـ image مقابل الـ container","level":2}],"takeaways":["الـ container عملية Linux عادية، تعزلها النواة بالـ namespaces وتحدّ مواردها بالـ cgroups.","تتشارك الـ containers نواة المضيف، ولهذا تبدأ خلال أجزاء من الثانية، ولهذا أيضًا يكون عزلها أضعف من عزل الآلة الافتراضية.","الـ image قالب للقراءة فقط مكوّن من layers لنظام الملفات مع بيانات وصفية؛ والـ container نسخة واحدة قيد التشغيل منها، فوقها layer رقيقة قابلة للكتابة.","كل ما يكتبه الـ container في نظام ملفاته الخاص يختفي عند حذف الـ container، إلا إذا وضعته في volume."],"further":[{"title":"What is a container?","url":"https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-a-container/"},{"title":"What is an image?","url":"https://docs.docker.com/get-started/docker-concepts/the-basics/what-is-an-image/"},{"title":"Kubernetes Overview","url":"https://kubernetes.io/docs/concepts/overview/"}],"quiz":[{"q":"تشغّل الأمر ps aux على مضيف Linux بينما يشغّل container خادم Node.js. ماذا ترى؟
dockerd فقط، وخادم Node.js مخفيّ بداخلها.","why":"الـ daemon يُطلق الـ containers لكنه لا يحتضنها. عملية الـ container لها سطرها المستقل في جدول عمليات المضيف."},{"text":"عملية node تظهر في القائمة مثل أي عملية أخرى على المضيف.","why":"صحيح. الـ container عملية على المضيف. الـ namespaces تخفي بقية المضيف عنها، لا العكس."},{"text":"نسخة من نظام التشغيل الكامل للـ container تُقلع في الخلفية.","why":"الـ containers لا تُقلع نظام تشغيل. إنها تعيد استخدام نواة المضيف ولا تشغّل إلا الأمر الذي طلبته."}],"answer":2},{"q":"أي ميزة في النواة تمنع container خرج عن السيطرة من استهلاك كل ذاكرة المضيف؟
","options":[{"text":"مجموعات التحكّم (cgroups)، التي تضع سقفًا لاستهلاك المعالج والذاكرة والإدخال والإخراج وتحسبه.","why":"صحيح. الـ cgroups تفرض حدود الموارد، وستجد لاحقًا في الدورة أن الـ limits في Kubernetes تُترجَم في النهاية إلى هذه الإعدادات نفسها."},{"text":"الـ PID namespace، التي تعطي الـ container شجرة عمليات خاصة به.","why":"الـ namespaces تتحكّم فيما تراه العملية، لا في مقدار ما تستهلكه. عملية في PID namespace خاصة بها تستطيع مع ذلك التهام كل بايت من الذاكرة."},{"text":"الـ layers المخصّصة للقراءة فقط في الـ image، لأنها لا تكبر أثناء التشغيل.","why":"الـ layers المخصّصة للقراءة فقط تحدّ ما على القرص، لا استهلاك الذاكرة. العملية تحجز الذاكرة بغضّ النظر عن طريقة تخزين ملفاتها."},{"text":"الـ layer القابلة للكتابة في الـ container، لأن حجمها مضبوط على حدّ الذاكرة.","why":"الـ layer القابلة للكتابة مساحة على القرص لتغييرات الملفات، ولا علاقة لها بالذاكرة."}],"answer":0},{"q":"تشغّل ثلاثة containers من الـ image notes-api:1.0.0. يكتب أحدها ملفًا في /tmp/cache.json. ماذا يرى الاثنان الآخران؟
لماذا يُعدّ الـ container حدًّا أمنيًا أضعف من الآلة الافتراضية؟
","options":[{"text":"لأن الـ containers لا تستطيع تقييد الوصول إلى الشبكة إطلاقًا.","why":"الـ network namespaces تعطي كل container حزمة شبكة خاصة به، ويمكنك تقييدها أكثر. الشبكة ليست هي الثغرة."},{"text":"لأن كل الـ containers على المضيف تتشارك نواة واحدة، فثغرة في النواة قد تعبر بينها.","why":"صحيح. للآلة الافتراضية نواتها الخاصة خلف الـ hypervisor، أما الـ container فيتحدّث مباشرة مع نواة المضيف. هذا ثمن البدء خلال أجزاء من الثانية."},{"text":"لأن الـ images لا يمكن توقيعها أو التحقّق منها.","why":"يمكن توقيع الـ images وتثبيتها بالـ digest؛ لكن هذا من أمن سلسلة توريد الـ images، وليس حدًّا للعزل."},{"text":"لأن الـ containers تعمل دائمًا كمستخدم root على المضيف.","why":"كثير منها يفعل ذلك افتراضيًا، وهذا سيئ، لكنك تستطيع، بل يجب، أن تشغّلها كمستخدم غير root. الفرق البنيوي هو النواة المشتركة."}],"answer":1}],"exercise":{"kind":"choice","multiple":true,"options":["shared-kernel","own-writable","vm-each","cgroups-see","image-many"],"correct":["shared-kernel","own-writable","image-many"],"title":"صح أم خطأ: ما هو الـ container","prompt":"يكتب زميلك دليلًا تعريفيًا للمنضمّين الجدد إلى notes-api، ويطلب منك مراجعة خمس عبارات عن الـ containers. اختر كل عبارة صحيحة.
\n","hints":["اسأل نفسك عن كل عبارة: هل تتحدّث عمّا تراه العملية، أم عمّا تستهلكه، أم عمّا على قرصها؟","الـ namespaces تخصّ الرؤية؛ والـ cgroups تخصّ حدود الموارد.","ثلاث من العبارات الخمس صحيحة."],"explanation":"الـ containers عمليات على المضيف تتشارك نواته، ولهذا تبدأ بسرعة، ولهذا أيضًا يكون عزلها أضعف من عزل الآلة الافتراضية. يحصل كل container على layer خاصة قابلة للكتابة فوق الـ image المشتركة المخصّصة للقراءة فقط، ويمكن لـ image واحدة أن تكون أساسًا لأي عدد من الـ containers. لا ينشئ Docker على Linux آلة افتراضية لكل container، والـ cgroups تحدّ استهلاك الموارد؛ أما ما تستطيع العملية رؤيته فتتحكّم فيه الـ namespaces.
\n","checkLabels":{},"optionText":{"shared-kernel":{"text":"كل container على مضيف Linux يستخدم نواة المضيف نفسها.","why":"صحيح. لا توجد نواة ضيف. ومن هنا تأتي السرعة ويأتي العزل الأضعف معًا."},"own-writable":{"text":"يحصل كل container على layer خاصة قابلة للكتابة؛ والتغييرات فيها تختفي عند حذف الـ container.","why":"صحيح. ولهذا توضع البيانات التي يجب أن تبقى في volume."},"vm-each":{"text":"ينشئ Docker آلة افتراضية صغيرة لكل container حتى لا يؤثّر بعضها في بعض.","why":"ليس على Linux. يستخدم Docker Desktop آلة افتراضية واحدة مشتركة على macOS وWindows، لكن الـ containers داخلها تبقى عمليات على نواة واحدة."},"cgroups-see":{"text":"الـ cgroups تحدّد الملفات والعمليات التي يُسمح للـ container برؤيتها.","why":"هذا عمل الـ namespaces. الـ cgroups تضع سقفًا لاستهلاك المعالج والذاكرة والإدخال والإخراج وتحسبه."},"image-many":{"text":"يمكن لـ image واحدة أن تكون قالبًا لعدّة containers تعمل في الوقت نفسه.","why":"صحيح. التوسّع إلى ست نسخ يعني ستة containers من image واحدة."}}},"words":543,"readMinutes":3}