تعد Docker Swarm وKubernetes وMesos من أكثر أطر عمل تنسيق الحاويات شيوعًا. في حديثه، يقارن آرون غوبتا الجوانب التالية لـ Docker وSwarm وKubernetes:
- التنمية المحلية.
- وظائف النشر.
- تطبيقات متعددة الحاويات.
- اكتشاف الخدمة.
- توسيع نطاق الخدمة.
- مهام التشغيل لمرة واحدة.
- التكامل مع مافن.
- التحديث "المتداول".
- إنشاء مجموعة قاعدة بيانات Couchbase.
ونتيجة لذلك، ستكتسب فهمًا واضحًا لما يجب أن تقدمه كل أداة تنسيق وستتعلم كيفية استخدام هذه الأنظمة الأساسية بشكل فعال.
آرون جوبتا هو كبير تقنيي المنتجات مفتوحة المصدر في Amazon Web Services، الذي قام بتطوير مجتمعات مطوري Sun وOracle وRed Hat وCouchbase لأكثر من 10 سنوات. يتمتع بخبرة واسعة في العمل في قيادة فرق متعددة الوظائف لتطوير وتنفيذ استراتيجية الحملات والبرامج التسويقية. قاد فرق مهندسي Sun، وهو أحد مؤسسي فريق Java EE ومنشئ فرع Devoxx4Kids في الولايات المتحدة. آرون جوبتا هو مؤلف أكثر من ألفي مشاركة في مدونات تكنولوجيا المعلومات وقد ألقى محاضرات في أكثر من 2 دولة.
يحتوي السطر 55 على COUCHBASE_URI الذي يشير إلى خدمة قاعدة البيانات هذه، والتي تم إنشاؤها أيضًا باستخدام ملف تكوين Kubernetes. إذا نظرت إلى السطر 2، يمكنك أن ترى النوع: الخدمة هي الخدمة التي أقوم بإنشائها تسمى خدمة الأريكة، ويتم إدراج نفس الاسم في السطر 4. وفيما يلي بعض المنافذ.
الخطان الرئيسيان هما 6 و7. في الخدمة أقول: "مرحبًا، هذه هي التسميات التي أبحث عنها!"، وهذه التسميات ليست أكثر من أسماء زوجية متغيرة، والسطر 7 يشير إلى Couchbase-rs-pod الخاص بي طلب. فيما يلي المنافذ التي توفر الوصول إلى هذه التسميات نفسها.
في السطر 19، قمت بإنشاء نوع جديد من ReplicaSet، ويحتوي السطر 31 على اسم الصورة، وتشير الأسطر 24-27 إلى البيانات الوصفية المرتبطة بالجراب الخاص بي. هذا هو بالضبط ما تبحث عنه الخدمة وما يجب أن يتم الاتصال به. في نهاية الملف يوجد نوع من الارتباط بين الأسطر 55-56 و4 يقول: "استخدم هذه الخدمة!"
لذلك، أبدأ خدمتي عندما تكون هناك مجموعة نسخ متماثلة، وبما أن كل مجموعة نسخ متماثلة لها منفذ خاص بها مع التسمية المقابلة، يتم تضمينها في الخدمة. من وجهة نظر المطور، يمكنك ببساطة الاتصال بالخدمة، والتي تستخدم بعد ذلك مجموعة النسخ المتماثلة التي تحتاجها.
ونتيجة لذلك، لدي حاوية WildFly التي تتواصل مع الواجهة الخلفية لقاعدة البيانات عبر خدمة Couchbase. يمكنني استخدام الواجهة الأمامية مع العديد من كبسولات WildFly، والتي تتواصل أيضًا مع الواجهة الخلفية لقاعدة الأريكة من خلال خدمة قاعدة الأريكة.
سننظر لاحقًا في كيفية تواصل الخدمة الموجودة خارج المجموعة من خلال عنوان IP الخاص بها مع العناصر الموجودة داخل المجموعة والتي لها عنوان IP داخلي.
لذا، فإن الحاويات عديمة الحالة رائعة، ولكن ما مدى جودة استخدام الحاويات ذات الحالة؟ دعونا نلقي نظرة على إعدادات النظام للحاويات ذات الحالة أو الدائمة. في Docker، هناك 4 طرق مختلفة لتخطيط تخزين البيانات التي يجب عليك الانتباه إليها. الأول هو ضمني لكل حاوية، مما يعني أنه عند استخدام حاويات satateful أو MySQL أو MyDB، تبدأ جميعها باستخدام Sandbox الافتراضي. أي أن كل ما يتم تخزينه في قاعدة البيانات يتم تخزينه في الحاوية نفسها. إذا اختفت الحاوية، تختفي البيانات معها.
والثاني هو الصريح لكل حاوية، عندما تقوم بإنشاء وحدة تخزين محددة باستخدام وحدة تخزين عامل الإرساء، قم بإنشاء أمر وتخزين البيانات فيه. يرتبط النهج الثالث لكل مضيف بتعيين التخزين، عندما يتم تكرار كل شيء مخزن في الحاوية في نفس الوقت على المضيف. إذا فشلت الحاوية، ستبقى البيانات على المضيف. الأخير هو استخدام العديد من المضيفين متعددي المضيفين، وهو أمر ينصح به في مرحلة إنتاج الحلول المختلفة. لنفترض أن حاوياتك مع تطبيقاتك تعمل على المضيف، لكنك تريد تخزين بياناتك في مكان ما على الإنترنت، ولهذا تستخدم التعيين التلقائي للأنظمة الموزعة.
تستخدم كل طريقة من هذه الطرق موقع تخزين محدد. تقوم البيانات الضمنية والصريحة لكل حاوية بتخزين البيانات على المضيف في /var/lib/docker/volumes. عند استخدام طريقة Per-Host، يتم تثبيت وحدة التخزين داخل الحاوية، ويتم تثبيت الحاوية نفسها على المضيف. بالنسبة للمضيفين المتعددين، يمكن استخدام حلول مثل Ceph وClusterFS وNFS وما إلى ذلك.
إذا فشلت الحاوية الدائمة، يصبح دليل التخزين غير قابل للوصول في الحالتين الأوليين، ولكن في الحالتين الأخيرتين يتم الحفاظ على الوصول. ومع ذلك، في الحالة الأولى، يمكنك الوصول إلى المستودع من خلال مضيف Docker الذي يعمل على جهاز افتراضي. وفي الحالة الثانية، لن يتم فقدان البيانات أيضًا، لأنك قمت بإنشاء مخزن صريح.
إذا فشل المضيف، فلن يكون دليل التخزين متاحًا في الحالات الثلاث الأولى، وفي الحالة الأخيرة، لن ينقطع الاتصال مع وحدة التخزين. وأخيرًا، يتم استبعاد الوظيفة المشتركة تمامًا للتخزين في الحالة الأولى، وهي ممكنة في الحالات المتبقية. في الحالة الثانية، يمكنك مشاركة التخزين اعتمادًا على ما إذا كانت قاعدة البيانات الخاصة بك تدعم التخزين الموزع أم لا. في حالة كل مضيف، يكون توزيع البيانات ممكنًا فقط على مضيف معين، وبالنسبة للمضيف المتعدد يتم توفيره من خلال توسيع المجموعة.
يجب أن يؤخذ ذلك في الاعتبار عند إنشاء حاويات ذات حالة. أداة Docker مفيدة أخرى هي ملحق Volume، الذي يعمل على مبدأ “البطاريات موجودة، ولكن يجب استبدالها”. عند بدء تشغيل حاوية Docker، تظهر رسالة: "مرحبًا، بمجرد بدء تشغيل حاوية بقاعدة بيانات، يمكنك تخزين بياناتك في هذه الحاوية!" هذه هي الميزة الافتراضية، ولكن يمكنك تغييرها. يتيح لك هذا البرنامج المساعد استخدام محرك أقراص الشبكة أو شيء مشابه بدلاً من قاعدة بيانات الحاوية. وهو يشتمل على برنامج تشغيل افتراضي للتخزين المعتمد على المضيف ويسمح بتكامل الحاويات مع أنظمة التخزين الخارجية مثل Amazon EBS وAzure Storage وأقراص GCE الدائمة.
تعرض الشريحة التالية بنية المكون الإضافي Docker Volume.
يمثل اللون الأزرق عميل Docker المرتبط بمضيف Docker الأزرق، والذي يحتوي على محرك تخزين محلي يوفر لك حاويات لتخزين البيانات. يشير اللون الأخضر إلى Plugin Client وPlugin Daemon، المتصلين أيضًا بالمضيف. أنها توفر الفرصة لتخزين البيانات في تخزين الشبكة من نوع التخزين الخلفي الذي تحتاجه.
يمكن استخدام المكون الإضافي Docker Volume مع تخزين Portworx. وحدة PX-Dev هي في الواقع حاوية تقوم بتشغيلها وتتصل بمضيف Docker الخاص بك وتسمح لك بتخزين البيانات بسهولة على Amazon EBS.
يتيح لك عميل Portworx مراقبة حالة حاويات التخزين المختلفة المتصلة بمضيفك. إذا قمت بزيارة مدونتي، يمكنك قراءة كيفية تحقيق أقصى استفادة من Portworx مع Docker.
يشبه مفهوم التخزين في Kubernetes مفهوم Docker ويتم تمثيله بواسطة أدلة يمكن الوصول إليها من خلال الحاوية الخاصة بك في حجرة. فهي مستقلة عن عمر أي حاوية. أنواع التخزين الأكثر شيوعًا المتوفرة هي hostPath، وnfs، وawsElasticBlockStore، وgsePersistentDisk. دعونا نلقي نظرة على كيفية عمل هذه المتاجر في Kubernetes. عادةً ما تتكون عملية ربطها من 3 خطوات.
الأول هو أن شخصًا ما على جانب الشبكة، عادةً ما يكون مسؤولاً، يزودك بتخزين مستمر. يوجد ملف تكوين PersistentVolume مطابق لهذا الغرض. بعد ذلك، يكتب مطور التطبيق ملف تكوين يسمى PersistentVolumeClaim، أو طلب تخزين PVC، والذي ينص على ما يلي: "لدي 50 جيجابايت من مساحة التخزين الموزعة المتوفرة، ولكن لكي يتمكن الأشخاص الآخرون أيضًا من استخدام سعتها، فأنا أخبر PVC بأنني حاليًا تحتاج فقط إلى 10 جيجابايت". أخيرًا، الخطوة الثالثة هي أن يتم تثبيت طلبك كتخزين، ويبدأ التطبيق الذي يحتوي على البود، أو مجموعة النسخ المتماثلة، أو شيء مشابه، في استخدامه. من المهم أن تتذكر أن هذه العملية تتكون من الخطوات الثلاث المذكورة وهي قابلة للتطوير.
تعرض الشريحة التالية حاوية Kubernetes Persistence لبنية AWS.
داخل المستطيل البني الذي يمثل مجموعة Kubernetes، توجد عقدة رئيسية واحدة وعقدتان عاملتان، موضحتان باللون الأصفر. تحتوي إحدى العقد العاملة على حجرة برتقالية اللون ومساحة تخزين ووحدة تحكم متماثلة وحاوية Docker Couchbase خضراء. داخل المجموعة، فوق العقد، يشير المستطيل الأرجواني إلى الخدمة التي يمكن الوصول إليها من الخارج. يوصى بهذه البنية لتخزين البيانات على الجهاز نفسه. إذا لزم الأمر، يمكنني تخزين بياناتي في EBS خارج المجموعة، كما هو موضح في الشريحة التالية. يعد هذا نموذجًا نموذجيًا للتوسع، ولكن هناك جانبًا ماليًا يجب مراعاته عند استخدامه - فقد يكون تخزين البيانات في مكان ما على الشبكة أكثر تكلفة من تخزينها على مضيف. عند اختيار حلول النقل بالحاويات، تعد هذه إحدى الحجج المهمة.
تمامًا كما هو الحال مع Docker، يمكنك استخدام حاويات Kubernetes الدائمة مع Portworx.
هذا هو ما يُطلق عليه في مصطلحات Kubernetes 1.6 الحالية اسم "StatefulSet" - وهي طريقة للعمل مع التطبيقات ذات الحالة التي تعالج الأحداث المتعلقة بإيقاف Pod وإجراء إيقاف تشغيل لطيف. في حالتنا، مثل هذه التطبيقات هي قواعد البيانات. في مدونتي، يمكنك قراءة كيفية إنشاء StatefulSet في Kubernetes باستخدام Portworx.
دعونا نتحدث عن الجانب التنموي. كما قلت، لدى Docker إصداران - CE وEE، في الحالة الأولى نتحدث عن إصدار مستقر من Community Edition، والذي يتم تحديثه مرة كل 2 أشهر، على عكس الإصدار المحدث شهريًا من EE. يمكنك تنزيل Docker لنظام التشغيل Mac أو Linux أو Windows. بمجرد التثبيت، سيتم تحديث Docker تلقائيًا ومن السهل جدًا البدء.
بالنسبة إلى Kubernetes، أفضّل إصدار Minikube - فهي طريقة جيدة لبدء استخدام النظام الأساسي من خلال إنشاء مجموعة على عقدة واحدة. لإنشاء مجموعات من عدة عقد، يكون اختيار الإصدارات أوسع: هذه هي kops، وkube-aws (CoreOS+AWS)، وkube-up (قديمة). إذا كنت تتطلع إلى استخدام Kubernetes المستند إلى AWS، فإنني أوصي بالانضمام إلى AWS SIG، الذي يجتمع عبر الإنترنت كل يوم جمعة وينشر مجموعة متنوعة من المواد المثيرة للاهتمام حول العمل مع AWS Kubernetes.
دعونا نلقي نظرة على كيفية تنفيذ التحديث المتداول على هذه الأنظمة الأساسية. إذا كان هناك مجموعة من عدة عقد، فإنها تستخدم إصدارًا محددًا من الصورة، على سبيل المثال، WildFly:1. التحديث المتتابع يعني أنه يتم استبدال إصدار الصورة بشكل تسلسلي بإصدار جديد على كل عقدة، واحدة تلو الأخرى.
للقيام بذلك، أستخدم أمر تحديث خدمة الإرساء (اسم الخدمة)، حيث أحدد الإصدار الجديد من صورة WildFly:2 وطريقة التحديث update-parallelism 2. الرقم 2 يعني أن النظام سيقوم بتحديث صورتين للتطبيق في الوقت نفسه، يتم تأخير التحديث لمدة 2 ثوانٍ لمدة 10 ثوانٍ، وبعد ذلك سيتم تحديث الصورتين التاليتين على عقدتين إضافيتين، وما إلى ذلك. يتم توفير آلية التحديث المتداول البسيطة هذه لك كجزء من Docker.
في Kubernetes، يعمل التحديث المتتابع بهذه الطريقة. تقوم وحدة التحكم في النسخ المتماثل rc بإنشاء مجموعة من النسخ المتماثلة من نفس الإصدار، ويتم تزويد كل حاوية في webapp-rc بملصق موجود في etcd. عندما أحتاج إلى حجرة، أستخدم خدمة التطبيق للوصول إلى مستودع etcd، الذي يزودني بالكبسولة باستخدام التسمية المحددة.
في هذه الحالة، لدينا 3 وحدات تحكم في وحدة التحكم في النسخ المتماثل تقوم بتشغيل تطبيق WildFly الإصدار 1. عند التحديث في الخلفية، يتم إنشاء وحدة تحكم أخرى في النسخ المتماثل بنفس الاسم والفهرس في النهاية - - xxxxx، حيث x عبارة عن أرقام عشوائية، و بنفس التسميات. تحتوي خدمة التطبيقات الآن على ثلاث حاويات مع الإصدار القديم من التطبيق وثلاث حاويات مع الإصدار الجديد في وحدة تحكم النسخ المتماثل الجديدة. بعد ذلك، يتم حذف الكبسولات القديمة، وإعادة تسمية وحدة التحكم في النسخ مع الكبسولات الجديدة وتشغيلها.
دعنا ننتقل إلى المراقبة. يحتوي Docker على العديد من أوامر المراقبة المضمنة. على سبيل المثال، تسمح لك واجهة سطر الأوامر Docker Container stats بعرض معلومات حول حالة الحاويات إلى وحدة التحكم كل ثانية - استخدام المعالج، واستخدام القرص، وتحميل الشبكة. توفر أداة Docker Remote API بيانات حول كيفية تواصل العميل مع الخادم. ويستخدم أوامر بسيطة، ولكنه يعتمد على Docker REST API. في هذه الحالة، الكلمات REST، Flash، Remote تعني نفس الشيء. عندما تتواصل مع المضيف، تكون هذه واجهة REST API. تتيح لك Docker Remote API الحصول على مزيد من المعلومات حول تشغيل الحاويات. توضح مدونتي تفاصيل استخدام هذه المراقبة مع Windows Server.
تتيح مراقبة أحداث نظام الإرساء عند تشغيل مجموعة متعددة المضيفين إمكانية الحصول على بيانات حول تعطل المضيف أو تعطل الحاوية على مضيف معين، وتوسيع نطاق الخدمات، وما شابه. بدءًا من Docker 1.20، فهو يشتمل على Prometheus، الذي يدمج نقاط النهاية في التطبيقات الحالية. يتيح لك ذلك تلقي المقاييس عبر HTTP وعرضها على لوحات المعلومات.
ميزة المراقبة الأخرى هي cAdvisor (اختصار لمستشار الحاوية). فهو يحلل ويوفر بيانات استخدام الموارد والأداء من الحاويات قيد التشغيل، مما يوفر مقاييس Prometheus مباشرة خارج الصندوق. الشيء المميز في هذه الأداة هو أنها توفر فقط بيانات لآخر 60 ثانية. ولذلك، يجب أن تكون قادرًا على جمع هذه البيانات ووضعها في قاعدة بيانات حتى تتمكن من مراقبة عملية طويلة المدى. ويمكن استخدامه أيضًا لعرض مقاييس لوحة المعلومات بيانيًا باستخدام Grafana أو Kibana. تحتوي مدونتي على وصف تفصيلي لكيفية استخدام cAdvisor لمراقبة الحاويات باستخدام لوحة تحكم Kibana.
تعرض الشريحة التالية الشكل الذي تبدو عليه مخرجات نقطة نهاية Prometheus والمقاييس المتاحة للعرض.
في الجزء السفلي الأيسر، ترى مقاييس لطلبات HTTP والاستجابات وما إلى ذلك، وعلى اليمين يوجد عرض رسومي لها.
يتضمن Kubernetes أيضًا أدوات مراقبة مدمجة. تعرض هذه الشريحة مجموعة نموذجية تحتوي على عقد رئيسية واحدة وثلاث عقد عاملة.
تحتوي كل عقدة عمل على cAdvisor الذي يتم تشغيله تلقائيًا. بالإضافة إلى ذلك، هناك Heapster، وهو نظام لمراقبة الأداء وجمع المقاييس متوافق مع الإصدار 1.0.6 من Kubernetes والإصدارات الأحدث. يسمح لك Heapster بجمع ليس فقط مقاييس أداء أعباء العمل والقرون والحاويات، ولكن أيضًا الأحداث والإشارات الأخرى التي تولدها المجموعة بأكملها. لجمع البيانات، فإنه يتحدث إلى Kubelet لكل حجرة، ويخزن المعلومات تلقائيًا في قاعدة بيانات InfluxDB، ويخرجها كمقاييس إلى لوحة معلومات Grafana. ومع ذلك، ضع في اعتبارك أنه إذا كنت تستخدم miniKube، فإن هذه الميزة غير متوفرة بشكل افتراضي، لذا سيتعين عليك استخدام الوظائف الإضافية للمراقبة. لذلك يعتمد الأمر كله على مكان تشغيل الحاويات وأدوات المراقبة التي يمكنك استخدامها افتراضيًا والتي تحتاج إلى تثبيتها كوظائف إضافية منفصلة.
تعرض الشريحة التالية لوحات معلومات Grafana التي تعرض حالة تشغيل الحاويات الخاصة بي. هناك الكثير من البيانات المثيرة للاهتمام هنا. بالطبع، هناك العديد من أدوات مراقبة عمليات Docker وKubernetes التجارية، مثل SysDig وDataDog وNewRelic. يتمتع بعضها بفترة تجريبية مجانية مدتها 30 عامًا، لذا يمكنك محاولة العثور على الخيار الذي يناسبك أكثر. أنا شخصياً أفضل استخدام SysDig وNewRelic، اللذين يتكاملان بشكل جيد مع Kubernetes. هناك أدوات تتكامل بشكل جيد مع كل من منصات Docker وKubernetes.
بعض الاعلانات 🙂
أشكركم على البقاء معنا. هل تحب مقالاتنا؟ تريد أن ترى المزيد من المحتوى المثير للاهتمام؟ ادعمنا عن طريق تقديم طلب أو التوصية للأصدقاء ، , تناظرية فريدة من خوادم المستوى المبتدئ ، اخترعناها من أجلك: (متوفر مع RAID1 و RAID10 ، حتى 24 مركزًا وحتى 40 جيجا بايت DDR4).
Dell R730xd أرخص مرتين في مركز بيانات Equinix Tier IV في أمستردام؟ هنا فقط في هولندا! Dell R420 - 2x E5-2430 2.2 جيجا هرتز 6C 128 جيجا بايت DDR3 2x960 جيجا بايت SSD 1 جيجا بايت في الثانية 100 تيرا بايت - من 99 دولارًا! أقرأ عن
المصدر: www.habr.com