أدوات البنية التحتية كخدمة
- 15 دقائق
الغرض من نظام إدارة التكوين (CM) في أي صناعة، بما في ذلك تكنولوجيا المعلومات، هو الحفاظ على العمليات والحفاظ عليها لبناء منتج مبني على النحو الأمثل وتصميمه وتجميعه. هناك طريقتان رئيسيتان:
- الأسلوب الحتمي
- الأسلوب التعريفي
الأسلوب الحتمي
الطريقة الحتمية، التي تسجل التسلسل الدقيق للتعليمات المطلوبة لتوفير الموارد والحفاظ عليها (على سبيل المثال، جهاز ظاهري، أو حاوية تطبيق، أو مستودع تخزين، أو ملف تعريف مستخدم) وفقاً لمواصفات مكتوبة. هنا، تكون الحالة النهائية للبنية الأساسية نتيجة تنفيذ هذه التعليمات بالتسلسل.
الأسلوب التعريفي
الطريقة التصريحية، التي يتم فيها تحديد الحالة النهائية للبنية الأساسية بشكل مباشر، ويجب أن يقوم النظام الذي يحافظ على تلك البنية الأساسية بتجميع خطة أو مسار للعمليات التي تكون نتيجتها النهائية هي الحالة المعلنة.
يتضمن الاختيار الذي تقوم به المؤسسات عند اختيار منصة CM، ومنهجية البنية التحتية كخدمة، ما يعتبرونه أكثر أهمية للحفاظ عليه وتوسيعه: أساليبهم أو أهدافهم. هناك إيجابيات وسلبيات لكلا النهجين. يفحص هذا الدرس الموقف الأساسي والمنهجيات التي تدعمها منصات CM الرئيسية ويقدم مقدمات موجزة للأنظمة الأساسية نفسها.
قوالب Azure Resource Manager
يعد نظام قالب Microsoft Azure Resource Manager من Microsoft أداة لإنشاء مواصفات صريحة لواحد أو أكثر من موارد السحابة. تم تصميم قالب Azure Resource Manager ليكون مخزونًا كاملاً للقيم والمعلمات اللازمة لتنفيذ تعليمات Azure لتوفير موارد جديدة وتحديث الموارد الحالية. يتم التعبير عن هذا المخزون في JSON، وهو تنسيق أصبح موجودًا في كل مكان تقريبًا في تطوير البرامج. قوالب Azure Resource Manager حصرية ل Azure ولا يمكنها تحديد الموارد لبنية تحتية متعددة السحابات.
يمكن إنشاء قوالب Azure Resource Manager يدويا، لكن غالبا ما يتم إنشاؤها (وتحريرها) عبر بوابة Azure أو باستخدام أدوات مثل Visual Studio وVisual Studio Code. يوضح الشكل 4 نموذجًا لتوفير حساب تخزين Azure. يتضمن النموذج الأقسام التالية:
قسم المعلمات الذي يحدد قيم المعلمات مثل اسم حساب التخزين الذي سيدخله المستخدم عند تنفيذ القالب، بالإضافة إلى القيم الظاهرية الاختيارية والقيم المسموح بها
قسم موارد يحدد موارد Azure التي سيقوم القالب بإنشائها أو تحديثها
يمكن أن يشتمل قالب Azure Resource Manager على أقسام أخرى أيضًا، بما في ذلك قسم الوظائف لتحديد الوظائف القابلة لإعادة الاستخدام التي ينفذها القالب (على سبيل المثال، وظيفة تنشئ اسم حساب فريدًا باستخدام تعبيرات البرمجة المضمنة التي يدعمها Azure Resource Manager)، وقسم المتغيرات يحدد المتغيرات المستخدمة في القالب، وقسم المخرجات الذي يحدد القيمة أو القيم التي يتم إرجاعها عند تنفيذ القالب. غالبًا ما تتكون القوالب من مئات أو حتى آلاف الأسطر. القالب في الشكل 4 بسيط، لكنه يوضح بعض أهم ميزات قوالب Azure Resource Manager، بما في ذلك القدرة على تحديد المعلمات التي يجب على المستخدم توفيرها بالإضافة إلى وضع قيود على المدخلات والقدرة على تحديد الموارد التي تشكل الحل، والقدرة على استخدام المدخلات التي يوفرها المستخدم لتحديد سمات الموارد التي يتم إنشاؤها أو تحديثها.
{
"$schema": "https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#",
"contentVersion": "1.0.0.0",
"parameters": {
"storageAccountType": {
"type": "string",
"defaultValue": "Standard_LRS",
"allowedValues": [
"Standard_LRS",
"Standard_GRS"
],
"metadata": {
"description": "Storage Account type"
}
},
"storageAccountName": {
"type": "string"
}
},
"resources": [
{
"type": "Microsoft.Storage/storageAccounts",
"name": "[parameters('storageAccountName')]",
"location": "[resourceGroup().location]",
"apiVersion": "2018-07-01",
"sku": {
"name": "[parameters('storageAccountType')]"
},
"kind": "StorageV2"
}
]
}
الشكل 4: قالب Azure Resource Manager البسيط لتوفير حساب تخزين Azure.
يمكن تنفيذ قوالب Azure Resource Manager باستخدام أوامر CLI أو PowerShell، أو بواسطة تطبيقات مكتوبة بلغة C# ولغات البرمجة الأخرى، أو من مدخل Microsoft Azure. يوضح الشكل 5 كيفية ظهور النموذج في الشكل 4 في المدخل. يوفر المدخل واجهة المستخدم لإنشاء مجموعة موارد أو تحديد مجموعة موجودة، وتقوم بإنشاء واجهة للمدخلات المحددة في قسم معلمات القالب - في هذه الحالة، اسم ونوع حساب التخزين، وآخرها هو تم تحديده من قائمة منسدلة تم إنشاؤها من قائمة تعداد allowedValues في القالب بدلاً من إدخال النموذج الحر.
الشكل 5: قالب Azure Resource Manager الذي تم تقديمه في مدخل Microsoft Azure.
يتطلب إنشاء حساب تخزين من خلال مدخل Microsoft Azure عادةً العديد من المدخلات. يقوم القالب بتقليلها إلى تلك المطلوبة فقط لعملية نشر معينة. تخيل قالبًا أكثر تعقيدًا ينشر العشرات من الموارد ذات الصلة التي تتطلب مئات من المعلمات، ولكن هذا يقلل من العملية برمتها إلى ثلاث من أربع معلمات أدخلها المستخدم وبضغطة زر بسيطة. علاوة على ذلك، فإن قالب Azure Resource Manager غير فعال، ما يعني أنه يمكن تنفيذه عدة مرات كما يحلو لك وستكون النتيجة هي نفسها في كل مرة. سيوفر موارد جديدة بالإضافة إلى تحديث الموارد الحالية.
يوفر قالب Azure Resource Manager تعريفًا كاملاً وواضحًا ومتكررًا لمورد أو مجموعة من الموارد التي يمكن استخدامها لأتمتة عمليات النشر والتحديثات. تعد قوالب Azure Resource Manager مثالاً على البنية التحتية كخدمة التي تستخدم نهجًا تعريفيًا لتعريف البنية التحتية السحابية.
Puppet
تم تصميم مفهوم البنية التحتية كخدمة في الأصل للتطبيق على الأنظمة الأساسية السحابية بشكل عام، بما في ذلك السحابة العامة بالإضافة إلى الأنظمة الأساسية السحابية المختلطة مثل VMware vCloud وOpenStack. تعتبر قوالب Azure Resource Manager خاصة بـ Azure، ولكن Puppet عبارة عن نظام أساسي CM كامل يعمل عبر الأنظمة الأساسية السحابية. Puppet هو الشكل الحديث لتجارب لوك كاني لعام 2006 مع تمديد طبقة تجريد عبر بيئات تشغيل خوادم متعددة. محركها هو مدير التكوين الذي تتمثل وظائفه الرئيسية في:
- أخذ مدخلات من المواصفات للحالة المثلى المرغوب فيها لنظام لتقديم تطبيق أو خدمة
- تحديد تسلسل الخطوات اللازمة لتوفير نظام موجود في تلك الحالة أو بالقرب منها
- نفذ الخطوات اللازمة لتحقيق هذه الحالة
باختصار، ما يسعى برنامج نصي في مدير التكوين الآخر إلى تعريفه والحفاظ عليه من أجل الأتمتة، ينشئ Puppet كنتيجة لحساباته.
يقوم Puppet بإدارة تكوين الموارد والخدمات عبر مجموعة من الخوادم من خلال عقدة تحكم مركزية تسمى master والتي يتم نسخها احتياطيًا بواسطة نسخ متماثلة. كما يوحي اسمها، تنشئ منصة Puppet علاقة بين الرئيس والعامل بين العقد المركزية وعدد متغير من عقد العميل حيث يتم تثبيت عملاء Puppet.
بدلاً من استخدام JSON كما تفعل قوالب Azure Resource Manager، يستخدم Puppet تعليمات مستوحاة من لغة برمجة Ruby التي تمت كتابتها في الأصل. يتم تمثيل مجموعة من التعليمات الخاصة بـ Puppet، والتي تمثل مهمة إدارة البنية الأساسية (على سبيل المثال، تزويد خادم بـ Linux وMySQL ومكونات أخرى من حزمة LAMP) بوحدة نمطية، وهي في الواقع دليل يحتوي على عدة ملفات في بنية معين. وأهم هذه الملفات هو ملف البيان، وهو مكتوب بلغة خاصة بالمجال (DSL) تنفرد بها Puppet. هذه ال DSL ليست لغة برمجة تقنيا لأنها لا تذكر الخطوات التي يجب أن يتبعها المفسر أو المعالج لإنجاز مهمة.
كما يوضح الشكل 6، فإن بنية النظام الذي يقوم بتشغيل منصة Puppet غير متطورة بشكل مدهش. العقدة في Puppet، مثل العقدة في Kubernetes أو في OpenStack، هي خادم - فعلي أو ظاهري، ولكنه مشارك في النظام الأساسي الجماعي. هناك عقد رئيسية وعقد عاملة. تلك الخوادم التي تديرها العقد الرئيسية لها عملاء نشطون مثبتون عليها. يتم الاتصال من خلال قنوات SSH. بشكل عام، يتم تأمين هذه القنوات من خلال شبكة فرعية محلية مغلقة إلى إنترنت خارجي. يمكن تخزين الوحدات النمطية لتعليمات Puppet واسترجاعها من المستودع، على الرغم من أن هذا الاتصال لا يحتاج إلى أن يكون خاصًا، ولا يتعرف Puppet نفسه على المستودع باعتباره عاملاً أو عقدة.
الشكل 6: بنية النشر القياسية لـ Puppet.
Chef
يعمل Chef بواسطة عملاء قادرين على البحث في النظام في الوقت الفعلي والإبلاغ عن تكوينه وحالته. بنية النشر الأساسية بسيطة (الشكل 7). تم تصميم الخادم ليتم تشغيله عن بُعد من محطة عمل. يتم تحميل جميع العقد، بما في ذلك الخادم مع Chef، على الرغم من توزيع الوظائف فيما بينها. تتلقى عقد العميل تعليمات مكتوبة من الخادم عن طريق محطة عمل المسؤول.
الشكل 7: بنية النشر القياسية لـ Chef.
تعتمد العديد من الاستعارات في Chef حول الطهي. ويسمى برنامج Chef النصي تعليمات. تعليماته مكتوبة بلغة Ruby بدلاً من DSL استنادًا إلى Ruby، لذلك سيكون المطورون المطلعون على Ruby مرتاحين لها. يتم تضمين جميع الإرشادات في كتاب التعليمات، وهو بمثابة وسيلة تسليم لـ Chef. لإدارة التكوين لفئة من المهام، يقوم المشغل إما بكتابة كتاب تعليمات أو الحصول على واحد من مستودع عام. مترجم العميل لهذه الإرشادات هو عامل يسمى Knife الذي تم تثبيته على كل عقدة خادم. يتلقى Knife التعليمات عبر SSH باستخدام CLI.
على عكس Puppet، تعليمات Chef هي البرنامج الذي يتم اختباره، وتحسينه ومن ثم الحفاظ عليه. ومع ذلك، فإن الطريقة التي يتم كتابتها بها هي إلى حد ما أكثر تجريدية من أي نصوص تعتمد على النظام شوهدت سابقًا. يعتبر استخدامه لـ Ruby أكثر رمزية، حيث يستطيع Knife ترجمة التعليمات المجردة إلى تفاصيل. هذه التعليمات ليست إعلانات كما هو الحال في Puppet، أو بيانات الأهداف، أو الأهداف، أو الحالات المرغوب فيها، ولكنها بالأحرى أوامر حتمية. على سبيل المثال، قد تحتوي عقد الخادم في مركز البيانات على توزيعات مختلفة من Linux مثبتة. قد تطلب التعليمات من Knife معرفة إصدار Linux المثبت على عقدة، وفي العبارة الشرطية، تحدد إصدار الحزمة الأكثر ملاءمة لهذا الإصدار. قد يقوم أيضًا بإجراء تعديلات على ملف التكوين المحلي لتلك الحزمة.
التعليمات من Chef إلى Knife صريحة. يدور Chef حول تحديد الأساليب التي يتم من خلالها الوصول إلى نسخة عمل من الحل والحفاظ عليها، ثم تحسينها. التحسين المستمر لا يزال ممكنًا؛ ولا يكون وضع تسلسل من التعليمات أمرًا حتميًا، كما هو الحال غالبًا مع النصوص القائمة بذاتها. لكن على الأقل هناك منهجية لتوجيه الطريق. يمكن أن يكون متعمدًا دون مقاطعة العمليات الحالية، خاصةً إذا كانت تلك العمليات، أو لتكون أكثر تحديدًا، تعليماتها، مصممة لتكون مرنة، ولاختبار ما إذا كانت ظروف معينة قد تغيرت قبل إجراء تعديلات مهمة على التكوينات. ومع ذلك، فقد خضع Chef لترقيات تطورية على مر السنين استلزمت تغييرات هيكلية في تعليماته الخاصة.
ريد هات أنسيبل
Ansible هي أداة CM تشترك في بعض السمات مع Puppet، على الرغم من أنها تشترك أيضًا في فكرة قائمة مخزون كاملة، مثل قوالب Azure Resource Manager. هدفه هو إنتاج برنامج نصي واحد يقوم بتثبيت وتكوين وصيانة خدمة أو تطبيق معين على أي بنية أساسية للخادم. يعتمد على مفهوم تكوين الدفع. على عكس الحالة مع كل من Puppet وChef، حيث يقوم وكلاء العميل بطلب تحديثات من خادم مركزي، لا يوجد وكلاء بعيدون في نظام Ansible.
تستند مهام التكوين لكل عقدة (وليس "العملاء" لأنه لا توجد علاقة مباشرة بينهم وبين الخادم) حول أدلة المبادئ الشائعة. دليل اللعب هو في الواقع قاعدة بيانات وليس سكريبت تعليمي، يحتوي على الشروط التي يجب تحقيقها لاكتمال التكوين ---, على سبيل المثال، لتركيب مكونات مكدس LAMP. يقوم خادم Ansible بتكييف دليل المبادئ هذا وفقًا لخصائص وغرابة كل عقدة، باستخدام قاعدة بيانات مخزون البنية الأساسية الخاصة به كدليل.
تمت كتابة كل من دليل المبادئ والمخزون بلغة YAML، وهي لغة تم إنشاؤها في الأصل كبديل لـ JSON لترميز البيانات. يوضح الشكل 8 قسمًا من دليل المبادئ من مستودع Ansible مفتوح المصدر1يقوم بإعداد المستخدمين لـ MySQL بمجرد تثبيت الحزمة الخاصة به. لا توجد صيغة إرشادية، فقط مفاتيح وقيم. نظرًا إلى أن هذه القيم تمثل حالات انتقالية - في هذه الحالة، لكل مستخدم في MySQL، يجد خادم Ansible أفضل طريقة لتطبيق هذه التغييرات على قائمة النظام التي يقوم بتكوينها. كما جادل بعض مستخدمي Ansible، يمكن اعتبار هذا نوعًا من تكوين الحالة المرغوب فيها، طالما أن هذه الحالة يمكن التعبير عنها صراحة باستخدام YAML.
- name : Ensure mysql started
become: yes
service: name=mysql state=started enabled=yes
- name: Update MySQL root password for all root accounts
mysql_user: name=root
host={{ item }}
password={{ mysql_root_password }}
login_user=root
login_password=""
state=present
with_items:
- 127.0.0.1
- ::1
- localhost
الشكل 8: عينة من برنامج Ansible النصي مكتوب بلغة YAML.
الملخص
تعمل إدارة التهيئة على تبسيط مهمة إدارة موارد السحابة بالطريقة التي تعمل بها آلة الحصاد على تبسيط مهمة جمع الحبوب من الحقل. يرفع نظام CM الأساسي من دور إدارة الخادم من مهمة إلى مهنة. إنها تدرك دائمًا الصورة الكبيرة وتجد طرقًا لدمج التكوينات الجديدة في الأنظمة الحالية بدلاً من مجرد الاستجابة للتأثير الذي تحدثه.
في هذا الدرس، قمنا بفحص أنظمة إدارة التكوين الأساسية البارزة وقدمنا سياقًا حول مصطلح البنية التحتية كخدمة. ولكن حتى أنظمة CM الأساسية لا توفر جميع الوظائف التي يحتاجها المسؤولون لإدارة الحلول السحابية بكفاءة وفعالية. الخطوة التالية هي الأنظمة الأساسية للتنسيق، ومن أكثرها شيوعًا Terraform، والذي، ليس من قبيل الصدفة، هو موضوع الدرس التالي.
المراجع
- دليل مبادئ مكدس GitHub Ansible lamp. https://github.com/jasodeep/ansible-lamp-stack-playbook.
اختبر معلوماتك
الملاحظات
هل كانت هذه الصفحة مفيدة؟
لا
هل تحتاج إلى مساعدة مع هذا الموضوع؟
هل تريد محاولة استخدام Ask Learn لتوضيح هذا الموضوع أو إرشادك خلاله؟