بدأت في 10 أغسطس في Slurm ، حيث نقوم بتحليلها بالكامل - بدءًا من التجريدات الأساسية وحتى معلمات الشبكة.
سنتحدث في هذه المقالة عن تاريخ Docker وتجريداته الرئيسية: Image، Cli، Dockerfile. المحاضرة مخصصة للمبتدئين، لذلك من غير المرجح أن تكون ذات فائدة للمستخدمين ذوي الخبرة. لن يكون هناك دم أو الزائدة الدودية أو الغمر العميق. الأساسيات ذاتها.
ما هو عامل الميناء
دعونا نلقي نظرة على تعريف Docker من ويكيبيديا.
Docker هو برنامج لأتمتة نشر وإدارة التطبيقات في البيئات الحاوية.
لا شيء واضح من هذا التعريف. ومن غير الواضح بشكل خاص ما تعنيه عبارة "في البيئات التي تدعم النقل بالحاويات". لمعرفة ذلك، دعونا نعود بالزمن إلى الوراء. لنبدأ بالعصر الذي أسميه تقليدياً "العصر المتجانس".
عصر متجانسة
العصر المتجانس هو أوائل العقد الأول من القرن الحادي والعشرين، عندما كانت جميع التطبيقات متجانسة، مع مجموعة من التبعيات. استغرق التطوير وقتا طويلا. وفي الوقت نفسه، لم يكن هناك الكثير من الخوادم، وكنا جميعًا نعرفها بالاسم ونراقبها. هناك مقارنة مضحكة:
الحيوانات الأليفة هي حيوانات منزلية. في العصر المتجانس، كنا نعامل خوادمنا كحيوانات أليفة، نعتني بها ونعتني بها، وننفخ عنها بقع الغبار. ومن أجل إدارة أفضل للموارد، استخدمنا المحاكاة الافتراضية: أخذنا خادمًا وقمنا بتقطيعه إلى عدة أجهزة افتراضية، وبالتالي ضمان عزل البيئة.
أنظمة المحاكاة الافتراضية القائمة على برنامج Hypervisor
ربما سمع الجميع عن أنظمة المحاكاة الافتراضية: VMware، VirtualBox، Hyper-V، Qemu KVM، إلخ. إنها توفر عزل التطبيقات وإدارة الموارد، ولكن لها أيضًا عيوب. للقيام بالمحاكاة الافتراضية، تحتاج إلى برنامج Hypervisor. وبرنامج Hypervisor هو عبء الموارد. وعادة ما تكون الآلة الافتراضية نفسها عبارة عن عملاق كامل - صورة ثقيلة تحتوي على نظام تشغيل، وNginx، وApache، وربما MySQL. الصورة كبيرة والجهاز الظاهري غير مناسب للعمل. ونتيجة لذلك، قد يكون العمل مع الأجهزة الافتراضية بطيئًا. لحل هذه المشكلة، تم إنشاء أنظمة المحاكاة الافتراضية على مستوى النواة.
أنظمة المحاكاة الافتراضية على مستوى النواة
يتم دعم المحاكاة الافتراضية على مستوى Kernel بواسطة أنظمة OpenVZ وSystemd-nspawn وLXC. ومن الأمثلة الصارخة على هذه المحاكاة الافتراضية LXC (حاويات Linux).
LXC هو نظام تشغيل افتراضي على مستوى نظام التشغيل لتشغيل مثيلات معزولة متعددة لنظام التشغيل Linux على عقدة واحدة. لا تستخدم LXC الأجهزة الافتراضية، ولكنها تنشئ بيئة افتراضية بمساحة العملية الخاصة بها ومكدس الشبكة.
تقوم LXC بشكل أساسي بإنشاء الحاويات. ما الفرق بين الأجهزة الافتراضية والحاويات؟
الحاوية غير مناسبة لعزل العمليات: توجد ثغرات أمنية في أنظمة المحاكاة الافتراضية على مستوى النواة والتي تسمح لها بالهروب من الحاوية إلى المضيف. لذلك، إذا كنت بحاجة إلى عزل شيء ما، فمن الأفضل استخدام جهاز افتراضي.
يمكن رؤية الاختلافات بين المحاكاة الافتراضية والحاويات في الرسم التخطيطي.
توجد برامج Hypervisor للأجهزة، وبرامج Hypervisor أعلى نظام التشغيل، وحاويات.
تعد برامج Hypervisor للأجهزة رائعة إذا كنت تريد حقًا عزل شيء ما. لأنه من الممكن العزل على مستوى صفحات الذاكرة والمعالجات.
هناك برامج Hypervisor كبرنامج، وهناك حاويات، وسنتحدث عنها أكثر. لا تحتوي أنظمة الحاويات على برنامج Hypervisor، ولكن يوجد محرك حاوية يقوم بإنشاء الحاويات وإدارتها. هذا الشيء خفيف الوزن، لذا نظرًا للعمل مع القلب، يكون هناك حمل أقل أو لا شيء على الإطلاق.
ما يستخدم للحاويات على مستوى النواة
التقنيات الرئيسية التي تسمح لك بإنشاء حاوية معزولة عن العمليات الأخرى هي مساحات الأسماء ومجموعات التحكم.
مساحات الأسماء: PID والشبكات والتركيب والمستخدم. هناك المزيد، ولكن لتسهيل الفهم سنركز عليها.
حدود مساحة الاسم PID العمليات. عندما، على سبيل المثال، نقوم بإنشاء مساحة اسم PID ووضع عملية هناك، تصبح مع PID 1. عادةً ما يكون PID 1 في الأنظمة هو systemd أو init. وفقًا لذلك، عندما نضع عملية في مساحة اسم جديدة، فإنها تتلقى أيضًا PID 1.
تسمح لك مساحة اسم الشبكة بتقييد/عزل الشبكة ووضع واجهاتك الخاصة بداخلها. يعد Mount أحد قيود نظام الملفات. المستخدم - تقييد المستخدمين.
مجموعات التحكم: الذاكرة، وحدة المعالجة المركزية، IOPS، الشبكة - حوالي 12 إعدادًا إجمالاً. بخلاف ذلك يطلق عليهم أيضًا اسم المجموعات C ("المجموعات C").
تقوم مجموعات التحكم بإدارة الموارد للحاوية. من خلال مجموعات التحكم يمكننا القول أن الحاوية يجب ألا تستهلك أكثر من قدر معين من الموارد.
لكي تعمل الحاويات بشكل كامل، يتم استخدام تقنيات إضافية: القدرات والنسخ عند الكتابة وغيرها.
القدرات هي عندما نخبر عملية ما بما يمكنها وما لا يمكنها فعله. على مستوى النواة، هذه مجرد صور نقطية تحتوي على العديد من المعلمات. على سبيل المثال، يتمتع المستخدم الجذر بامتيازات كاملة ويمكنه القيام بكل شيء. يمكن لخادم الوقت تغيير وقت النظام: فهو يتمتع بإمكانيات على Time Capsule، وهذا كل شيء. باستخدام الامتيازات، يمكنك تكوين قيود العمليات بمرونة، وبالتالي حماية نفسك.
يتيح لنا نظام النسخ عند الكتابة العمل مع صور Docker واستخدامها بشكل أكثر كفاءة.
يواجه Docker حاليًا مشكلات في التوافق مع Cgroups v2، لذا تركز هذه المقالة بشكل خاص على Cgroups v1.
ولكن دعونا نعود إلى التاريخ.
عندما ظهرت أنظمة المحاكاة الافتراضية على مستوى النواة، بدأ استخدامها بنشاط. اختفت الحمل الزائد على برنامج Hypervisor، ولكن بقيت بعض المشاكل:
- الصور الكبيرة: إنهم يدفعون نظام التشغيل والمكتبات ومجموعة من البرامج المختلفة إلى نفس OpenVZ، وفي النهاية لا تزال الصورة كبيرة جدًا؛
- لا يوجد معيار عادي للتغليف والتسليم، لذلك تظل مشكلة التبعيات قائمة. هناك حالات يستخدم فيها قطعتان من التعليمات البرمجية نفس المكتبة، ولكن بإصدارات مختلفة. وقد يكون هناك صراع بينهما.
لحل كل هذه المشاكل، جاء العصر التالي.
عصر الحاويات
وعندما جاء عصر الحاويات تغيرت فلسفة العمل بها:
- عملية واحدة - حاوية واحدة.
- نقوم بتوصيل جميع التبعيات التي تحتاجها العملية إلى حاويتها. وهذا يتطلب تقطيع الوحدات المتراصة إلى خدمات صغيرة.
- كلما كانت الصورة أصغر، كلما كان ذلك أفضل - هناك عدد أقل من نقاط الضعف المحتملة، ويتم نشرها بشكل أسرع، وما إلى ذلك.
- تصبح الحالات سريعة الزوال.
هل تتذكر ما قلته عن الحيوانات الأليفة مقابل الماشية؟ في السابق، كانت الحالات مثل الحيوانات الأليفة، لكنها أصبحت الآن مثل الماشية. في السابق، كان هناك متراصة - تطبيق واحد. والآن أصبح لدينا 100 خدمة صغيرة و100 حاوية. قد تحتوي بعض الحاويات على 2-3 نسخ متماثلة. يصبح أقل أهمية بالنسبة لنا للسيطرة على كل حاوية. والأهم بالنسبة لنا هو توفر الخدمة نفسها: ما الذي تفعله هذه المجموعة من الحاويات. وهذا يغير نهج الرصد.
في 2014-2015، ازدهرت شركة Docker - التكنولوجيا التي سنتحدث عنها الآن.
قام Docker بتغيير الفلسفة وتغليف التطبيقات الموحد. باستخدام Docker، يمكننا حزم تطبيق وإرساله إلى مستودع وتنزيله من هناك ونشره.
نضع كل ما نحتاجه في حاوية Docker، وبالتالي يتم حل مشكلة التبعية. يضمن Docker إمكانية التكاثر. أعتقد أن العديد من الأشخاص قد واجهوا عدم إمكانية إعادة الإنتاج: كل شيء يعمل من أجلك، وتدفعه إلى الإنتاج، وهناك يتوقف عن العمل. مع Docker تختفي هذه المشكلة. إذا بدأت حاوية Docker الخاصة بك وتفعل ما تحتاج إلى القيام به، فمن المرجح أن تبدأ في الإنتاج وتفعل الشيء نفسه هناك.
الاستطراد حول النفقات العامة
هناك دائما خلافات حول النفقات العامة. يعتقد بعض الأشخاص أن Docker لا يحمل حملاً إضافيًا، لأنه يستخدم Linux kernel وجميع عملياته اللازمة للنقل بالحاويات. مثل، "إذا قلت أن Docker في وضع علوي، فإن نواة Linux في وضع علوي."
من ناحية أخرى، إذا تعمقت أكثر، فستجد بالفعل العديد من الأشياء في Docker، والتي يمكن القول إنها علوية.
الأول هو مساحة الاسم PID. عندما نضع عملية في مساحة اسم، يتم تعيين PID 1 لها. وفي الوقت نفسه، تحتوي هذه العملية على PID آخر، والذي يقع في مساحة اسم المضيف، خارج الحاوية. على سبيل المثال، أطلقنا Nginx في حاوية، وأصبح PID 1 (عملية رئيسية). وعلى المضيف لديه PID 12623. ومن الصعب تحديد مقدار النفقات العامة.
الشيء الثاني هو Cgroups. لنأخذ مجموعات C حسب الذاكرة، أي القدرة على تحديد ذاكرة الحاوية. عند تمكينه، يتم تنشيط العدادات ومحاسبة الذاكرة: تحتاج النواة إلى فهم عدد الصفحات التي تم تخصيصها وعدد الصفحات التي لا تزال مجانية لهذه الحاوية. من المحتمل أن يكون هذا نفقة عامة، لكني لم أر أي دراسات دقيقة حول كيفية تأثيره على الأداء. وأنا بنفسي لم ألاحظ أن التطبيق الذي يعمل في Docker تعرض فجأة لخسارة حادة في الأداء.
وملاحظة أخرى حول الأداء. يتم تمرير بعض معلمات kernel من المضيف إلى الحاوية. على وجه الخصوص، بعض معلمات الشبكة. لذلك، إذا كنت ترغب في تشغيل شيء عالي الأداء في Docker، على سبيل المثال، شيء سيستخدم الشبكة بشكل نشط، فأنت على الأقل بحاجة إلى ضبط هذه المعلمات. بعض nf_conntrack، على سبيل المثال.
حول مفهوم دوكر
يتكون عامل الإرساء من عدة مكونات:
- Docker Daemon هو نفس محرك الحاوية؛ تطلق الحاويات.
- Docker CII هي أداة مساعدة لإدارة Docker.
- Dockerfile - تعليمات حول كيفية إنشاء صورة.
- الصورة - الصورة التي يتم إخراج الحاوية منها.
- حاوية.
- تسجيل Docker هو مستودع للصور.
من الناحية التخطيطية يبدو الأمر كالتالي:
يعمل برنامج Docker الخفي على Docker_host ويقوم بتشغيل الحاويات. هناك عميل يرسل الأوامر: إنشاء الصورة، تنزيل الصورة، تشغيل الحاوية. يذهب Docker daemon إلى السجل ويقوم بتنفيذها. يمكن لعميل Docker الوصول محليًا (إلى مقبس Unix) وعبر TCP من مضيف بعيد.
دعونا نذهب من خلال كل مكون.
عامل ميناء الخفي - هذا هو جزء الخادم، وهو يعمل على الجهاز المضيف: يقوم بتنزيل الصور وإطلاق الحاويات منها، وإنشاء شبكة بين الحاويات، وجمع السجلات. عندما نقول "اخلق صورة"، فإن الشيطان يفعل ذلك أيضًا.
عامل ميناء CLI — جزء عميل Docker، أداة مساعدة لوحدة التحكم للعمل مع البرنامج الخفي. وأكرر، أنه يمكن أن يعمل ليس فقط محليا، ولكن أيضا عبر الشبكة.
الأوامر الأساسية:
docker ps - إظهار الحاويات التي تعمل حاليًا على مضيف Docker.
صور عامل الإرساء - عرض الصور التي تم تنزيلها محليًا.
بحث عامل ميناء <> - ابحث عن صورة في التسجيل.
docker pull <> - قم بتنزيل صورة من السجل إلى الجهاز.
بناء عامل ميناء< > - جمع الصورة.
تشغيل عامل الإرساء <> - إطلاق الحاوية.
عامل ميناء rm <> - قم بإزالة الحاوية.
سجلات عامل الإرساء <> - سجلات الحاوية
بدء/إيقاف/إعادة تشغيل عامل الإرساء <> - العمل مع الحاوية
إذا كنت تتقن هذه الأوامر وكنت واثقًا من استخدامها، فاعتبر نفسك بارعًا في Docker بنسبة 70% على مستوى المستخدم.
Dockerfile - تعليمات لإنشاء صورة. تقريبًا كل أمر تعليمي عبارة عن طبقة جديدة. لنلقي نظرة على مثال.
هذا ما يبدو عليه ملف Dockerfile: الأوامر على اليسار والوسيطات على اليمين. يقوم كل أمر موجود هنا (ومكتوب بشكل عام في ملف Dockerfile) بإنشاء طبقة جديدة في الصورة.
حتى بالنظر إلى الجانب الأيسر، يمكنك فهم ما يحدث تقريبًا. نقول: "أنشئ مجلدًا لنا" - هذه طبقة واحدة. "جعل المجلد يعمل" هو طبقة أخرى، وهكذا. كعكة الطبقات تجعل الحياة أسهل. إذا قمت بإنشاء ملف Dockerfile آخر وقمت بتغيير شيء ما في السطر الأخير - قمت بتشغيل شيء آخر غير "python" "main.py"، أو قمت بتثبيت التبعيات من ملف آخر - فسيتم إعادة استخدام الطبقات السابقة كذاكرة تخزين مؤقت.
صورة - هذه حاوية تعبئة، يتم إطلاق الحاويات من الصورة. إذا نظرنا إلى Docker من وجهة نظر مدير الحزم (كما لو كنا نعمل مع حزم deb أو rpm)، فإن الصورة هي في الأساس حزمة rpm. من خلال yum install يمكننا تثبيت التطبيق وحذفه والعثور عليه في المستودع وتنزيله. الأمر نفسه تقريبًا هنا: يتم إطلاق الحاويات من الصورة، ويتم تخزينها في سجل Docker (على غرار yum، في المستودع)، وتحتوي كل صورة على تجزئة SHA-256 واسم وعلامة.
تم إنشاء الصورة وفقًا للتعليمات الواردة من ملف Dockerfile. تقوم كل تعليمات من ملف Dockerfile بإنشاء طبقة جديدة. يمكن إعادة استخدام الطبقات.
تسجيل عامل الميناء هو مستودع صور Docker. على غرار نظام التشغيل، يحتوي Docker على سجل قياسي عام - dockerhub. ولكن يمكنك إنشاء مستودعك الخاص وسجل Docker الخاص بك.
وعاء - ما ينطلق من الصورة. قمنا ببناء صورة حسب تعليمات ملف Dockerfile، ثم نطلقها من هذه الصورة. هذه الحاوية معزولة عن الحاويات الأخرى ويجب أن تحتوي على كل ما هو ضروري لكي يعمل التطبيق. في هذه الحالة، حاوية واحدة - عملية واحدة. يحدث أنه يتعين عليك القيام بعمليتين، لكن هذا يتعارض إلى حد ما مع أيديولوجية Docker.
يرتبط مطلب "حاوية واحدة، عملية واحدة" بمساحة اسم PID. عندما تبدأ عملية ذات PID 1 في Namespace، إذا ماتت فجأة، فستموت الحاوية بأكملها أيضًا. إذا كانت هناك عمليتان قيد التشغيل: إحداهما على قيد الحياة والأخرى ميتة، فستظل الحاوية على قيد الحياة. ولكن هذه مسألة أفضل الممارسات، وسوف نتحدث عنها في مواد أخرى.
لدراسة مميزات الدورة وبرنامجها الكامل بمزيد من التفاصيل يرجى اتباع الرابط: “".
المؤلف: Marcel Ibraev، مسؤول Kubernetes معتمد، مهندس ممارس في Southbridge، متحدث ومطور لدورات Slurm.
المصدر: www.habr.com