مقدّمة
تُمثِّل الحاويّات حلًّا أنيقًا لمن يبحث عن تصميم ونشر تطبيقات تعمل على نطاق واسع. يُوفّر Docker التّقنيّة المسؤولة عن إعداد الحاويّات، وتُساعده مشاريع أخرى عديدة عبر تطوير الأدوات المطلوبة لتحضير النّشر في بيئة العمل وللتّواصل بين مختلف مكوّناته.
استكشاف الخدمة Service discovery هي إحدى التّقنيّات المركزيّة الّتي تعتمد عليها العديد من بيئات Docker. تُمكّن هذه التّقنيّة التّطبيقاتِ أو العناصرَ المُكوّنةَ لها من معرفة معلومات عن بيئة عملها. يُستعان عادةً بمخازن تعتمد صيغة مفتاح-قيمة key-value لهذا الغرض.
تُستخدَم هذه المخازن أيضًا لإملاء تفاصيل حول ضبط الإعدادات. يُتيح ضبطُ أداة استكشاف الخدمة الاحتفاظَ بإعداد تشغيل الحاويّة خارجها وهو ما يُساعد من إعادة استخدام نفس الحاويّة في عدّة بيئات عبر إنشاء صورة منها.
يهدف هذا المقال إلى عرض فوائد استخدام آليّة استكشاف الخدمة في بيئة عنقوديّة Clustered من مستضيفات Docker. سنُركّز على المفاهيم العامّة مع إعطاء أمثلة مُحدَّدة عندما يكون ذلك مناسِبًا.
استكشاف الخدمة ومخازن الإعداد العامّة Global Configuration Stores
تقوم تقنيّة استكشاف الخدمة على فكرة أساسيّة تتمثّل في أنّه يجب أن تكون لدى أي نظير من التّطبيق Instance القُدرة على التّعرف برمجيًّا على تفاصيل البيئة التي يعمل فيها. هذا الأمر ضروري لتمكين "زرع" النّظير الجديد في بيئة التّطبيق دون الحاجة للتّدخل اليدوي. تُنَفَّذ أدوات استكشاف الخدمة في العادة على هيئة سجلّات تُخزّن معلوماتٍ عن التّطبيقات أو الخدمات العاملة حاليًّا ضمن بيئة العمل، ويُمكن الوصول إليها من جميع عناصر البيئة. تُوزَّع هذه السّجلّات بين عدّة مُستضيفات لجعلها قابلةً للتّوسّعScalable وقادرةً على العمل عند حصول أخطاء.
يُمكِن استخدام منصّات استكشاف الخدمة لحفظ أيّ نوع من معلومات الإعداد، رغم أنّ الهدف الأوليّ من إنشائها هو تقديم بيانات الاتّصال لربط العناصِر في ما بينها. تستفيد العديد من عمليّات النّشر من هذه الميزة عن طريق حفظ بيانات الإعداد لدى أداة الاستكشاف؛ حيثُ إن الحاويّات تستطيع تغيير سلوكها اعتمادًا على ما تعثُر عليه من إعدادات، إذا كانت مضبوطةً للقيّام بذلك.
كيف تعمل أداة استكشاف الخدمة؟
تُوفِّر كل أداة استكشاف واجهةَ تطبيقات برمجيّة API يُمكن للعناصِر استخدامُها لضبط إعداداتها أو الحصول على بيانات. لهذا السّبب نجد أنّ كل تطبيق يُضمِّن عنوانَ استكشاف الخدمة مُباشرةً في المصدَر Source أو يُوفّره كخيّار أثناء التّشغيل. تُتيح أدوات استكشاف الخدمة الوصول إلى القيّم الّتي تحتفِظ بها عن طريق طلبات Http.
تسجيلُ التّطبيق لنفسه لدى أداة الاستكشاف مباشرةً بعد بدْء عمله، هو أولى خطوات عمل خدمة الاستكشاف؛ فيُسجّل كل المعلومات الّتي ستحتاجها بقيّة العناصر عند محاولتها الاستفادة من الخدمة الّتي يُقدِّمها.يجب على قاعدة بيانات MySQL مثلًا، تسجيلُ عنوان IP ومنفَذ Port الوصول للبرنامج؛ يُمكن أن تُضيف أيضًا اسمَ المُستخدِم واعتمادات Credentials الحساب المطلوبة لتسجيل الدّخول.
أول ما يقوم به تطبيق يُريد الاستفادة من خدمةٍ مّا عند بدْء تشغيله، هوّ طلب أداة الاستكشاف لإعطائه معلومات عن نقطة اتّصال مُعرَّفة مُسبَقًا للارتباط بالخدمة. يُمكنه بعد ذلك التّفاعل مع العناصِر الّتي يحتاجها وفقًا للمعلومات الّتي يعثُر عليها. مُوزِّع الحِمل Load balancer مثالٌ جيّد، حيثُ بإمكانه - عن طريق أداة الاستكشاف - العثور على معلومات عن كل الخواديم الخلفيّّة Backend servers حتّى يُوجِّهَ إليها حركة الاتّصالات حسب إعداداتِها والمعلومات الّتي تُغذّي بها (أي الخواديم) أداةَ الاستكشاف.
ينتُج عن استخدام أداة استكشاف وضعُ تفاصيل الإعداد خارجَ إطار الحاويّة. يجعل هذا الأمر الحاويّات أكثر مرونة وأقل ارتهانًا لإعدادات مُعيَّنة؛ كما أنّه يُسهِّل على عناصِر التّطبيق التفاعلَ مع نظائر جديدة من نفس الخدمة متيحًا بذلك إمكانيّة الإعداد الدّيناميكي.
كيف يُؤثِّر تخزين الإعدادات؟
تُعدّ القُدرة على تخزين أي نوع من بيانات الإعداد، بما فيها بياناتٌ تطلُبها أجزاء التّطبيق أثناء تنفيذها، إحدى المزايا الأساسيّة في أي نظام عمومي موزَّع لاستكشاف الخدمة. يعني هذا أنّه بالإمكان وضع بيانات إعدادٍ أكثر خارج الحاويّة، ضمن بيئة تنفيذ أوسع.
يجب أن تُصمّم التّطبيقات - حتّى تعمل هذه الطّريقة بشكل فعّال - بعدد معقول من الخيّارات الافتراضيّة Defaults على أن يكون من الممكن إبدالُها بقيّم أخرى يُتَحصَّل عليها من مخزن الإعدادات أثناء التّنفيذ. تجعل هذه الطّريقة من استخدام مخزن الإعداد مُماثِلًا لاستخدام خيّارات سطر الأوامر Command line flags (أو Command line options) مع فرق أنّ استخدام مخزن إعدادات متاح للعموم يسمح بإنشاء وتشغيل نظائر أخرى من نفس العُنصر دون جهدٍ زائد.
كيف يُساعِد مخزن الإعدادات في إدارة العُنقود؟
لا يظهر للوهلة الأولى، العونُ الّذي يُقدّمه مخزنٌ مُوزَّع للإعدادات يستخدم صيغة مفتاح-قيمة، في حفظ وإدارة عُضويّات Membership العنقود. مخازن الإعدادات هي في الواقع البيئة المُثلى لحفظ آثار عضويّات المُستضيفات ووضعها تحت تصرّف أدوات إدارة العنقود.
في ما يلي بعض معلومات المُستضيفات الّتي يُمكن حفظها على شكل مفتاح-قيمة في مخازن إعدادات مُوزَّعة:
عناوين IP المُستضيفات.
معلومات الاتّصال بالمُستضيفات.
بيانات وصفيّة Metadata ومُلصقات Labels يُمكِن التّحكم بها من أجل اتّخاذ قرارت تتعلّق بالجدولة Scheduling.
الدّور Role داخل العنقود (في حال استخدام نموذج قائد/تابِع Leader/follower model).
لن تضطّر في الظّروف الاعتياديّة إلى الاهتمام بهذه التّفاصيل عند استخدام أداةٍ لاستكشاف الخدمة؛ ولكنّها وسيلة تُوفّر لأدوات الإدارة إمكانية الاستعلام أو التّعديل على معلوماتٍ تتعلّق بالعنقود.
ماذا عن التّعرّف على الإخفاق Failure detection أثناء التّنفيذ؟
يُمكن وضع آليّة للتّعرّف على إخفاق التّطبيقات عبر عدّة وسائل. السّؤال الّذي يجب طرحُه هنا هل ستُحدَّث خدمة الاستكشاف عند توقّف تطبيق عن العمل لتعكس حالة التّطبيق من حيثُ إنه لم يعُد يعمل؟ هذا النّوع من المعلومات حيوي للتّقليل من إخفاق الخدمة.
تُتيح العديدمن أدوات استكشاف الخدمة تعيينَ قيّم مع مهلة زمنيّة يُمكِن ضبطُها Configurable Timeout. في هذه الحالة يضبُط العنصُر قيمةً ويُرفق معها مهلة زمنيّة، ثم يُعلِم أداة الاستكشاف بانتِظام بوجوده وفي نفس الوقت يُعيد تعيين المُهلة. يُعتبر العُنصُر خارج الخدمة وتُسحب معلوماته من مخزن الإعدادات عند بلوغ المُهلة الزّمنيّة المُحدَّدَة دون أن يتّصل بأداة الاستكشاف لإعلامها بوجوده وإعادة تعيين المُهلة. يتغيَّر طول المُهلة حسب التّطبيق والمُدّة الّتي يحتاجها للتّعامل مع إخفاق أحد العناصِر المُكوّنة له.
توجد طريقة أخرى تعتمد على إنشاء حاويّة مُساعدة مع كل عنصُر، تقتصر مهمّة الحاويّة المُساعِدة على التّحقق من سلامة العنصُر دورِيًّا ثمّ تحديث السّجل في حال توقّف العنصُر عن العمل. نقطة ضعف هذه الطّريقة هي الحاويّة المُساعدة الّتي يُمكن أن تتوقّف عن العمل وهو ما قد ينتُج عنه معلومات خاطئة في مخزن الإعدادات. تتغلّب بعض النُّظُم على هذه المسألة عن طريق إضافة إمكانيّة التحقّق من سلامة الحاويّة إلى أداة الاستكشاف. يُمكن لخدمة الاستكشاف بهذه الطّريقة فحصُ العناصِر المُسجَّلة لديها دوريًّا للتّأكد من حالتها.
ماذا عن إعادة ضبط الخدمة عند التّعديل على بيانات الإعدادات؟
تُمثّل إعادة الضّبط ديناميكيًّا إحدى التّحسينات الأساسيّة على نموذج استكشاف الخدمة الأصلي. تعني إعادةُ الضّبط ديناميكيًّا قدرةَ أداة الاستكشاف على التّفاعل مع التّغييرات في مخزن الإعداد وضبط عناصِر التّطبيق حسب التّعديلات الجديدة؛ عكسَ النّموذج الأصلي الذي يقتصِر تأثيره على الإعداد الابتدائي للعُنصُر(عند بدْء تشغيله). على سبيل المثال، حينَ يفحص مُوزِّع حِمل الخواديمَ الخلفية ويجد أنّ أحدها توقّف عن العمل؛ فإنّه سيحتاج لأخذ ذلك بالحُسبان من أجل تعديل إعداداتِه لتُناسِب الوضعيّة الجديدة.
توجد عدّة مشاريع تُركِّز على موزّع الحِمل نظرًا لكونه أحد التّطبيقات الأكثر احتيّاجًا لهذه الخاصيّة. يتميّز HAProxy بأنّه أحد أكثر هذه المشاريع شُهرةً لما يتمتّع به من شعبيّة بين المُهتمّين بآليّات توزيع الحِمل، في حين أنّ مشاريع أخرى تتمتّع بمرونة أكبر حيثُ بالإمكان استخدامُها لإحداث تغييرات في كل أنواع البرامج. تستعلم هذه الأدوات بانتظام خدمةَ الاستكشاف بحثًا عن تغييرات، وفي حال وجودها تستخدم نظام قوالب لتوليد ملفّاتِ إعداد جديدةً تُدمِج القيّم الّتي أرسلتها خدمة الاستكشاف. في الأخير يُعاد تشغيل التّطبيق لأخذ التّغييرات الجديدة في الحسبان.
يحتاج هذا النّوع من الإعداد الدّيناميكي إلى تخطيط أكبر أثناء عمليّة بناء التّطبيق إذ أنّ كل هذه الآليّات يجب أن تتواجد في الحاويّة الّتي تُمثّل العُنصر، وهو ما يجعل من الحاويّة مسؤولةً عن تعديل إعداداتِها. يُمثِّل استخراج القيّم المطلوبِ كتابتُها في سجلّ استكشاف الخدمة، وتصميم بنية بيانات Data structure تسهُل الاستفادة منها تحدِّيًا آخر في بناء نظام إعداد ديناميكي. مع ذلك يُمكن لهذا النّظام أن يُقدّم مرونةً كبيرةً في الإعداد.
ماذا عن الأمان؟
يطرح كثيرٌ من المبتدئين مسألة الأمان عند الحديث عن مخازن الإعدادات المتاحة للعموم. هل من المُناسِب حقًّا حفظُ بيانات الاتّصال في أماكن يُتاح الوصول إليها للعموم؟
تختلف الإجابة على هذا السؤال كثيرًا حسب ما تُريد حفظَه في مخزن الإعدادات وحسب عدد طبقات الأمان الّتي ترى أنّها مناسِبة لتأمين بياناتك. تسمح أغلب أدوات استكشاف الخدمة بتعميّة Encryption الاتّصالات عن طريق SSL/TLS. يكفي وضعُ بعض أدوات الاستكشاف الّتي لا تهتم كثيرًا بالخصوصيّة Privacy في شبكة خاصّة، لكن وجود تأمين إضافي سيُفيد على الأرجح الكثير من التّطبيقات.
يكمُن أحد الحلول الأمنيّة في إتاحة الوصول العموميّ إلى أداة الاستكشاف ولكن تُعمَّى (تُشَفَّر) البيانات المكتوبة ضمن سجل الأداة بحيثُ يتوجَّب على أي تطبيق يُريد الاستفادة من معلومة متاحة في السّجلّ امتلاكُ المفتاح السّري الخاص بهذه المعلومة حتّى يستطيعَ فكّ تعميّة Decrypty البيانات.
تلجأ أدوات أخرى إلى مُقاربة مختفلة أساسُها إدخال قوائم تحكّم في الوصول Access control lists (أو ACL اختصارًا) لتقسيم فضاء المفاتيح إلى عدّة مناطِق، تُعرّف كل واحدة منها مُتطلّبات مُحدَّدة ويُعتَمَد عليها لإدارة مُلكيّة وإمكانيّة الوصول إلى المعلومات. تُؤسّس هذه المُقاربة لطريقة بسيطة تُوفّر لبعض الأطراف إمكانيّة الحصول على معلومات بينما تُبقيها خارج مُتناوَل أطراف أخرى. يُمكن ضبط كل عنصُر ليُتاح له الوصول إلى المعلومات الّتي يحتاجها فقط.
ما هيّ أدوات استكشاف الخدمة الأكثر انتِشارًا؟
نعرِض في الفقرات التّاليّة لبعض المشاريع الّتي تعمل على تنفيذ المبادئ العامّة المذكورة في الفقرات السّابقة. من أكثر هذه المشاريع رواجًا:
etcd: أنشأها مطوّرو توزيعة CoreOS لتوفير أداة استكشاف خدمة وإعداد عموميّ مُوزَّع لكل من الحاويّات والأنظمة المُستضيفة. تمتلك هذه الأداة واجهةَ تطبيقات برمجيّة API يُتوَصَّل إليها عن طريق Http إضافةً إلى سطر أوامر على كل مُستضيف.
consul: تتميّز هذه الأداة بالخصائص المتقدّمة الّتي توفّرها، مثل التحقّق من صلاحيّة الإعداد، قوائم التّحكّم في الوصول ACL، إعداد HAProxy، ...إلخ
zookeeper: وهيّ أداة أقدم من السّابقتيْن. تتميّز بمنصّة أكثر ثباتًا، وذلك على حساب نقص بعض الوظائف الحديثة.
المشاريع التّاليّة تعمل على تمديد وظيفة الأداة القاعديّة لاستكشاف الخدمة:
Crypt: يُعطي التّطبيقات إمكانيّة تعميّة المعلومات التّي تحتفِظ بها في مخزن الإعدادات عن طريق مفتاح تعميّة عمومي Public key. يُمكِن للتّطبيقات الّتي لديها مفتاح فك التّعميّة Decryption key فقط قراءةُ هذه المعلومات.
Confd: ويهدِف إلى إضافة قابليّة إعادة الضّبط ديناميكيًّا والتّحكّم في التّطبيقات حسب التّغييرات في خدمة الاستكشاف. يتضمّن هذا المشروع عدّة وظائف أهمّها مراقبَة مخزن الإعدادات بحثًا عن تعديلات، ونظامًا للقوالب يُستخدم لإنشاء ملفّات إعداد جديدة اعتمادًا على المعلومات المُمجمَّعة وقابليّة إعادة تحميل التّطبيقات عند تغيير إعداداتِها.
vulcand: يعمل Vulcand كموزِّع حِمل بين مجموعات من العناصِر. يتعرّف هذا المشروع على أداة etcd ويُمكنه العمل وفقًا للتّغيرات في مخزن الإعدادات.
marathon: وهو في الأساس مُجدوِل Scheduler (المقال الأخير من هذه السّلسلة يتناول المُجدوِلات)، ولكنّه يُضمّن آليّة بسيطة لإعادة تحميل HAProxy عند التّغيير على خدمات يجب توزيع الحِمل بينها.
frontrunner: يُلحق بmarathon لتقديم آليّة متقدّمة لتحديث HAProxy.
synapse: يُضمِّن HAProxy لتوجيه تدفّق البيانات بين مختلف عناصِر التّطبيق.
nerve: يُستخدَم بالتّوازي مع synapse للتحقّق من صلاحيّة الإعداد لكل واحد من نظائر العُنصُر. عند توقّف أحد العناصِر عن العمل يُعلِم nerve أداة synapse لأخذ ذلك بالحسبان.
خاتمة
يسمح استكشاف الخدمة والمخازن العموميّة للإعدادات لحاويّات Docker بالتكيّف مع البيئة المُحيطَة وتغيير سلوك العناصِر الموجودة فيها، وهي مُتطلَّبات أساسيّة لتوفير قابليّة التوسّع والانتشار بسهولة ودون تدخّل يديوي.
ترجمة -وبتصرّف- للمقال The Docker Ecosystem: Service Discovery and Distributed Configuration Stores
أفضل التعليقات
لا توجد أية تعليقات بعد
انضم إلى النقاش
يمكنك أن تنشر الآن وتسجل لاحقًا. إذا كان لديك حساب، فسجل الدخول الآن لتنشر باسم حسابك.