كيفية جعل البنية التحتية لتكنولوجيا المعلومات الخاصة بك مملة

مايكل ديهان هو الرجل الذي خلق Ansible. العديد من الأشياء التي يقوم بها مسؤولو النظام ومهندسو الإصدار و DevOps بشكل منتظم هي ، بشكل معتدل ، غير مثيرة للاهتمام. يريد DeHaan أن يقوم هؤلاء الأشخاص بتحرير وقتهم لأشياء أكثر إثارة للاهتمام (في العمل أو خارج باب المكتب) ، وكتابة رمز المنتج الذي يوفر وقت المسؤول.
المزيد من الوقت ، وقلة الأدرينالين خلال ساعات العمل ، وعدد أقل من النصوص البرمجية وأخطاء أقل.
بالمناسبة ، يمكنك إنهاء القراءة في هذه الفقرة عن طريق الاتصال بالبث المباشر في 6 حزيران (يونيو) هنا .



إذا كنت لا تزال تواصل القراءة ...

Ansible: التكامل والتوصيل المستمر

Ansible هي لغة أتمتة قوية مفتوحة المصدر. نعم ، إنه أمر رائع ليس فقط للإدارة ، ولكن أيضًا لنشر وتنسيق أنظمة تكنولوجيا المعلومات. تم إنشاء Ansible في الأصل لحل مجموعة واسعة من مهام الأتمتة بشكل فعال ، وكأساس عالمي بسيط لاستبدال عناصر التحكم التقليدية ، ولكن في النهاية تبين أنها مفيدة جدًا في العديد من المجالات. على سبيل المثال ، مع ضمان عدم التوقف عن العمل أثناء التكامل المستمر وتقديم التطبيقات (CI / CD). عادة يتم حل هذه المشكلة بسبب التحسين الشامل للبرامج ، واستخدام حزم البرامج المختلفة والكثير من الحيل الفريدة لكل تكوين محدد. تم تصميم Ansible في الأصل خصيصًا لمثل هذه السيناريوهات الخاصة بالتنسيق وتقديم حل جاهز "الكل في واحد".

التكامل المستمر وتقديم التطبيقات (CI / CD)

بعض الحقائق الشائعة. تُظهر ممارسة تطوير أنظمة البرمجيات على مدى السنوات العشر الماضية أن دورة الحياة الطويلة لإصدارات البرامج (نموذج التطوير المتتالي) لها نفقات أعلى بكثير مقارنة بالدورة القصيرة (ما يسمى "التكرار" أو التطوير الرشيق). كل شيء عن عدم انتظام ضربات القلب: عندما يبدأ المبرمجون للتو في العمل على إصدار جديد ، فلا يوجد ببساطة أي شيء لموظفي تكنولوجيا المعلومات المسؤولين عن الاختبار والنشر للقيام به. ولكن كلما اقترب الإصدار من الإصدار ، كلما كان محترفي تكنولوجيا المعلومات مشغولين ، وكثيراً ما يضطر المبرمجون إلى تبديل السياقات ، بالتناوب بين العمل على الأخطاء وتخطيط الإصدار التالي.

بالإضافة إلى ذلك ، تزيد الدورة الطويلة الفاصل الزمني بين تحديد أخطاء البرامج وأوجه القصور والقضاء عليها ، وهو أمر بالغ الأهمية بشكل خاص لأنظمة الويب الكبيرة مع جمهور المستخدمين بملايين الدولارات. لذلك ، تعتمد صناعة البرمجيات بسرعة منهجيات رشيقة تحت شعار "إطلاق أسرع وأكثر في كثير من الأحيان" بحيث يمكن للمشاركين في عملية التطوير تبديل سياق عملهم في كثير من الأحيان وإنشاء التحسينات والابتكارات وتصحيحها وتنفيذها بشكل أسرع.

إن أتمتة مراقبة الجودة ، تطوير TDD من خلال الاختبار والتقنيات الأخرى ذات الصلة تزيد من فعالية أساليب العمل الجديدة. أين الأتمتة؟ أين التقنيات التي تجعل التروس تدور بشكل أسرع وتقلل من مشاركة الإنسان إلى الحد الأدنى الضروري للغاية؟

وهنا ، على سبيل المثال ، Red An's Ansible و Ansible Tower لتنسيق أنظمة تكنولوجيا المعلومات كجزء من عمليات تطوير البرمجيات الحديثة.

وقت التوقف صفر

أكثر وضوحا قليلا. التوقف عن العمل يعني فقدان الأرباح والعملاء غير الراضين. لذلك ، في أنظمة قوائم انتظار الويب ، التي يتم توزيع مستخدميها عبر جميع المناطق الزمنية ، يُسمح بإيقاف التشغيل المجدول فقط في الحالات الخطيرة حقًا ، ولا تتضمن القائمة صراحة تحديث إصدارات التطبيق. الوضع مشابه في بيئات الشركات حيث تقلل إمكانية الوصول إلى شبكة إنترانت أو نظام محاسبة بشكل كبير من إنتاجية الموظفين. وبالتالي ، يجب أن توفر أي أتمتة عملية تحديثات دون مقاطعة العمليات - وبعبارة أخرى ، بدون توقف.

من الممكن تمامًا تحقيق صفر من التعطل ، ولكننا نحتاج لهذا الغرض إلى أدوات مناسبة - مثل توفير تنسيق متقدم ومتعدد المستويات ومتعدد المراحل ، على سبيل المثال ، نظام Ansible.

أنظمة بناء التطبيقات

يبدأ التسليم المستمر (CD) بالتكامل المستمر (CI). نظام يراقب مستودعات رمز المصدر للتغييرات ، ويقوم بشكل مستقل بتشغيل الاختبارات المقابلة ويقوم تلقائيًا بإنشاء (جديد واختبار مثالي) إصدار جديد من التطبيق مع كل تحديث كود ، على سبيل المثال ، مشروع Jenkins (jenkins.io).

لترحيل العصا إلى نظام القرص المضغوط بعد تجميع الإصدار الجديد من التطبيق بنجاح ، يمكن للنظام الفرعي لبناء نظام CI استدعاء Ansible لتوفير هذا الإصدار الجديد على الفور لأولئك الذين يقومون بإجراء اختبار الوحدة أو التكامل. على وجه الخصوص ، يمكن لجينكينز استخدام Tower لنشر التجميعات في بيئات مختلفة ، ويمكن نمذجة الاختبار أو البيئة الوسيطة على أساس بيئة الإنتاج ، مما يحسن إلى حد كبير إمكانية التنبؤ طوال دورة حياة البرنامج. يمكن للبيانات التي تم إرجاعها بواسطة Ansible من نتائج تنفيذ البرامج النصية للأتمتة أن تشارك بشكل مباشر في وظائف Build Systems في نظام Tower. في الواقع ، يسمح لك Tower حتى باختبار سيناريوهات النشر في بيئة وسيطة قبل تشغيلها على خوادم "قتالية".

تحديث التطبيق متعدد المستويات واحدا تلو الآخر

يجب أن يكون نظام القرص المضغوط قادرًا على تنسيق عمليات التحديث الدورية للتطبيقات متعددة المستويات. بفضل هندسة الدفع وقدرات التنسيق متعدد المراحل متعدد المستويات ، يمكن لـ Ansible التعامل مع هذه المهمة من خلال تحديث أي مستوى تطبيق حسب المستوى ، أثناء تبادل البيانات بينهما.

لتنفيذ التحديثات واحدًا تلو الآخر ، يستخدم Ansible نصوص تشغيل Play التي تتيح لك تحديد مجموعة المضيفين المستهدفين بدقة وتعيين المهام (الدور) التي يجب القيام بها عليها. عادةً ما تكون المهام عبارة عن إعلانات مفادها أن مورد تكنولوجيا معلومات معين يجب أن يكون في حالة معينة ، على سبيل المثال ، يجب تثبيت حزمة معينة لإصدار واحد من البرنامج ، وللحصول على إصدار آخر ، من الضروري التحقق من مستودع التعليمات البرمجية. تتطلب طبولوجيا تطبيق الويب ، كقاعدة ، تحديثها بترتيب صارم ، ولا يزال لا يمكنك تحديث التطبيقات وتكوينات النظام على جميع الأجهزة في نفس الوقت.

عند إعادة تشغيل الخدمة ، تظل غير متاحة لبعض الوقت ، ولا يتم استبدال إصدار التطبيق أيضًا على الفور. لذلك ، قبل تحديث النظام ، نقوم بسحبه من مجموعة الموازنة. ونتيجة لذلك ، تحتاج إلى القدرة على أتمتة عمليات توصيل وفصل الماكينات من التجمع. باستمرار هي الكلمة الرئيسية. يمكن لـ Ansible التحكم بدقة كبيرة في حجم نافذة التحديث المتتالي. حسنًا ، يتم تطوير هذه التحديثات بعناية فائقة ، وفي حالة حدوث فشل في مرحلة ما ، يتم تعليق التحديث حتى لا يتم تعطيل بقية البنية التحتية لتكنولوجيا المعلومات.

النشر المستمر لنصوص الأتمتة

بالإضافة إلى وظائف القرص المضغوط للخدمات التي تعمل في وضع التشغيل التجاري ، يمكنك أيضًا تنظيم النشر المستمر لنصوص الأتمتة نفسها (مجموعات تعليمات Ansible Playbook. لا تتوقف عن القراءة ، في الجزء الثاني ستكون هناك أمثلة على كتب التشغيل). يسمح ذلك لمسؤولي النظام والمطورين بإدارة البرامج النصية باستخدام مستودع شفرة المصدر واختبار هذه البرامج النصية في بيئة وسيطة ونقلها تلقائيًا إلى بيئة الإنتاج في حالة حدوث اختراق ناجح. بمعنى آخر ، عند العمل باستخدام البرامج النصية ، تحصل على جميع المزايا المنهجية والمزايا الأخرى لمستودع التعليمات البرمجية المركزي الذي اعتدت عليه عند تطوير البرامج.

يعد إجراء تغييرات على تكوينات البرامج والنظام أحد الأسباب الرئيسية للانقطاع غير المخطط له. لذلك ، بالإضافة إلى الاختبار الآلي ، هناك تحكم بشري. يمكن تنظيمه من خلال الدمج مع نظام فحص الكود مثل Gerrit ، وتطبيق التغييرات فقط بعد موافقة الرفاق المسؤولين عليها.

التحديثات البديلة وأنظمة موازنة التحميل

يعمل Ansible بشكل مستقل للغاية مع أنظمة موازنة التحميل عند إجراء تحديثات متتالية. لذلك ، يمكنك ببساطة الكتابة في نص Playbook النصي ، في أي دورة لمجموعة من المضيفين ، مثل "تنفيذ هذا الإجراء على النظام X نيابة عن المضيف Y" ، وسيتولى Ansible الباقي.

يتفاعل Ansible بشكل جيد مع موازنات التحميل من جميع الأنواع ، وهو قادر على تعيين علامة لفصل المضيف مؤقتًا من أجل إلغاء تنشيط مراقبة التوفر له خلال فترة التحديث. المخطط البسيط "إيقاف المراقبة - الإزالة من التجمع - تحديث مستوى البرنامج المطلوب - العودة إلى التجمع - تشغيل المراقبة" يطبق بسهولة تحديثًا تتابعيًا بدون توقف عن العمل وبدون إنذارات خاطئة. وكل هذا في وضع مؤتمت بالكامل بدون تدخل المشغل.

اختبار وسيط متكامل

يمكن لـ Tower العمل مع ملفات جرد الموارد المختلفة (Inventory) ، مما يجعل من السهل اختبار سيناريوهات التحديث المتتالية في بيئة وسيطة قبل تشغيلها على خوادم "المعركة". للقيام بذلك ، يكفي محاكاة بيئة الإنتاج في بيئة الاختبار ، وتشغيل Ansible مع المعلمة "-i" وتحديد ملف المخزون الذي يجب استخدامه عند تشغيل البرنامج النصي - لبيئة الاختبار أو لبيئة الإنتاج. لا يحتاج البرنامج النصي نفسه إلى تعديل.

نشر التحكم في الإصدار

يحب بعض الأشخاص حزم التطبيقات جنبًا إلى جنب مع حزم نظام التشغيل (RPM ، debs ، وما إلى ذلك) أكثر سخونة ، ولكن في كثير من الأحيان ، وخاصة لتطبيقات الويب ، فإن هذا التغليف غير ضروري. لذلك ، يتضمن Ansible عدة وحدات لنشر التطبيقات مباشرة من أنظمة التحكم في الإصدار. في برنامج Playbook النصي ، يمكنك كتابة تسوية مع مستودع التعليمات البرمجية للعلامة المحددة أو رقم الإصدار المحدد ، وبعد ذلك سيتحقق Ansible من هذا الشرط على جميع الخوادم المستهدفة وينشط الخطوات التالية فقط إذا كان هناك حاجة إلى استبدال الإصدار ، وبالتالي القضاء على إعادة تشغيل الخدمة غير الضرورية.

التكامل مع أدوات المراقبة

باعتباره نظام تنسيق كامل ، يدعم Ansible التكامل مع أنظمة إدارة أداء التطبيقات المستندة إلى APM على مستوى المراقبة. على سبيل المثال ، أثناء مرحلة اختبار النشر أو التكامل ، يجب عليك تثبيت أو ترقية وكيل برنامج APM مع التطبيق. يلعب Ansible دورًا خاصًا في هذا ، وبعد تثبيت الوكيل وتنشيطه ، يمكن لـ Ansible تهيئته في مكدس مراقبة APM (إذا لم يتم تكوينه بالفعل) بحيث يمكن لمديري التطبيقات التحقق على الفور من تثبيت الإصدار الجديد ويعمل بدون مشاكل .

إذا حدث خطأ ما بعد تحديث التطبيق في بيئة الإنتاج ، فقد تستدعي أدوات المراقبة Ansible للرجوع إلى الإصدار السابق. بالطبع ، فقط إذا كان هذا التراجع مسموحًا به.

إعلام الحدث

في نموذج CI / CD ، يرغب الجميع في تلقي إشعارات الأحداث في أسرع وقت ممكن. تقدم Ansible كلاً من الوظائف المضمنة ، بما في ذلك وحدة البريد الإلكتروني ، بالإضافة إلى التكامل مع أدوات الإعلام الخارجية ، مثل برامج المراسلة الفورية أو الشبكات الاجتماعية أو أنظمة تسجيل الأحداث.

النشر باستخدام نموذج حالة الموارد

واحدة من الميزات الرئيسية لـ Ansible ، مما يجعلها أداة مفيدة للغاية لنشر التطبيقات ، هي الاستخدام المنتظم لنموذج حالة الموارد في عمليات تحديث البرامج ، والتي اكتسبت شعبية في إدارة تكوينات النظام. على عكس عناصر التحكم التقليدية مفتوحة المصدر ، لا يحتاج Ansible إلى أن يكون مزودًا بأي برنامج إضافي أو نصوص خاصة لتنظيم تسليم التطبيقات.

في Ansible ، يمكنك التسجيل والتحكم بدقة في ترتيب الأحداث على مستويات معمارية مختلفة ، مما يسمح لك بتفويض الإجراءات إلى أنظمة أخرى ، بالإضافة إلى دمج توجيهات نموذج الموارد (مثل "يجب أن تكون الحزمة X في الحالة Y") وأوامر البرنامج النصي التقليدية (مثل "تشغيل البرنامج النصي .sh ") ضمن عملية واحدة.

كما يجعل Ansible من السهل تشغيل عمليات التحقق من الشروط المختلفة واتخاذ القرارات بناءً على نتائجها. يعد الجمع بين عمليات تكوين النظام ونشر التطبيق ضمن سلسلة أدوات واحدة أكثر كفاءة من المخطط مع العديد من الأدوات المتخصصة ، بالإضافة إلى ذلك ، يزيد من اتساق سياسات وتطبيقات نظام التشغيل.

اختبار النشر

كلما زادت الفرص ، زادت المسؤولية. يزيد أتمتة عمليات التسليم المستمر بشكل كبير من خطر نشر تكوين فاشل على جميع عقد النظام. لتقليل المخاطر ، يقترح Ansible إدخال اختبارات التحكم في البرنامج النصي ، والتي ستقاطع التحديث التسلسلي إذا حدث خطأ ما. لاختبار الشروط المختلفة ، بما في ذلك حالة عمل الخدمات ، يمكنك نشر اختبارات عشوائية باستخدام وحدات الأوامر أو البرامج النصية ، وحتى إنشاء اختبارات مثل وحدات Ansible منفصلة.

يمكن أن تقاطع وحدة الفشل تنفيذ البرنامج النصي على المضيف في أي وقت ، مما يسمح بالتقاط الفشل في مرحلة مبكرة من التحديث التسلسلي. على سبيل المثال ، بسبب الاختلاف بين البيئة الوسيطة وبيئة الإنتاج ، تولد الأخيرة خطأ في التكوين ، مما يعطل الخوادم "القتالية". في هذه الحالة ، يمكن تسجيل مخرج الطوارئ في البرنامج النصي Playbooks في المرحلة الأولى من التحديث التسلسلي. وإذا كان لديك 100 خادم ، وكان حجم نافذة التحديث المتتالي 10 ، فإن هذا التوقف في حالات الطوارئ سيعطيك الوقت لاستكشافه بهدوء وإصلاح البرنامج النصي ومواصلة التحديث.

في حالة حدوث فشل ، لا تستمر Ansible في العمل ، تاركة الأنظمة في حالة شبه مكوّنة ، وتولد خطأ لجذب انتباه المشغل وإخباره بالمضيفين الذين استمرت دورة التحديث مع وجود أخطاء وعدد التغييرات التي تم إجراؤها على كل نظام أساسي. يحتوي Ansible على وضع تشغيل محاكاة ، عندما ينشئ النظام تقريرًا عن التغييرات التي كان سيتم إجراؤها إذا تم تنفيذ البرنامج النصي دون تنفيذه الحقيقي.

فحص الامتثال

هناك بيئات تتغير فيها التكوينات فقط عندما لا توجد طريقة بدونها. يتم تحليل أي تغييرات في مثل هذه البيئات مسبقًا. يستخدم أنظمة التسليم المستمر "مع التحفظات".

يحتوي Ansible على وضع تشغيل محاكاة (يتم تنشيطه بواسطة علامة "--check") ، عندما يقوم النظام بإنشاء تقرير حول التغييرات التي سيتم إجراؤها عند تنفيذ البرنامج النصي. في هذه الحالة ، لا يحدث التنفيذ الفعلي للنص البرمجي ، ولا يسمح تشغيل المحاكاة بالتقاط الأخطاء ، ولكنه يساعد على فهم وتحليل تفاصيل ونتائج التغييرات المقترحة بشكل أفضل.

من ناحية أخرى ، حتى مع النشر المستمر للتجميعات الجديدة ، يتيح لك Ansible تشغيل اختبارات المطابقة في كثير من الأحيان لالتقاط اللحظة التي تتغير فيها بعض الأشياء في بيئة الإنتاج نتيجة للتدخل البشري ويجب إصلاحها عن طريق تشغيل النص البرمجي Ansible المقابل ، على سبيل المثال ، للتغيير إصدار البرنامج ، وضبط الأذونات ، إلخ.

نشر الطيار الآلي

إذا كنت تعيش في عالم من تنسيق متعدد المستويات متعدد المراحل لعمليات تحديث البرامج المتسلسلة بدون وقت تعطل ، فمن المرجح أن يتم تنفيذ CI / CD حصريًا من قبل المشغلين (يدويًا ومع أتمتة جزئية) وتتطلب ، كما هو الحال في الرقص الدائري ، إجراءات منسقة لجميع المشاركين في العملية. يمكن أن يكون Ansible جنبًا إلى جنب مع بنيته الفريدة وغياب وكلاء البرامج على المضيفين المستهدفين (زيادة الأمان وإلغاء الحاجة إلى إدارة نظام الإدارة نفسه) وصف عمليات النشر المعقدة وأتمتتها بسهولة ، أي أن Ansible يطبق وضع الطيار الآلي الكامل هنا.

يمكن العثور على أمثلة لنصوص الأتمتة Ansible على GitHub ، والآن سنقدم أساسًا ومثالًا لكيفية كتابة برنامج نصي Playbook يمكن تشغيله في Ansible أو Ansible Tower. جنبًا إلى جنب مع قائمة الوحدات والمستندات الأخرى ، ستساعدك على تعلم كيفية إنشاء نصوص Playbooks الخاصة بك.

ما هو كتاب اللعب؟

يعد البرنامج النصي لـ Playbook بشكل أساسي مجموعة من المسرحيات التي يتم إرسالها للتنفيذ على مضيف بعيد واحد أو مجموعة من المضيفين. إنه مثل دليل تجميع أثاث ايكيا: اتبع الإرشادات بالضبط واحصل على ما رأيته بالضبط في المتجر. هكذا تعمل البرامج النصية.

الوحدات

سنقوم بإنشاء Playbook يقوم بتثبيت خادم الويب على مضيف RHEL / CentOS 7 وإنشاء ملف index.html عليه بناءً على القالب المحدد في البرنامج النصي. نموذج البرنامج النصي المعروض هنا يعمل بكامل طاقته وجاهز للاستخدام. أدناه سنلقي نظرة على مثال البرنامج النصي Playbook ونوضح كيفية استخدام الوحدات.

المؤلفون (المؤلفون)

المؤلف هو شخص يقوم بإنشاء تعليمات سيتم تنفيذها بواسطة الوحدات (غالبًا مع قيم إضافية: الحجج والمواقع وما إلى ذلك). يتم تنفيذ الوحدات على المضيف المستهدف بالترتيب الذي تتبعه في البرنامج النصي Playbook (بما في ذلك'y وملفات إضافية أخرى مضمنة فيه). تتغير حالة المضيف (أو لا تتغير) اعتمادًا على نتائج تنفيذ الوحدة ، والتي يتم عرضها في شكل إخراج Ansible و Tower.

تنفيذ البرنامج النصي Playbook

أولاً ، هناك بعض الأشياء التي تحتاج إلى معرفتها حول تشغيل البرامج النصية لـ Playbook. Playbook هو نوع من النظام الرمزي الذي يعلم الوحدة حول الحاجة إلى أداء بعض المهام. لإطلاق Playbook بنجاح ، من المهم فهم النقاط التالية:

1. نظام الهدف (الهدف)
لأن نصوص Playbook توفر تعليمات للوحدات وتتفاعل معها ، تعتقد Ansible أنك تفهم ما تحاول القيام به وتقوم بأتمتة ذلك. لهذا السبب نقول أن Playbooks تشبه التعليمات أو التوجيهات: فأنت تخبر العناصر التلقائية كيف تريد تكوين المهمة. ولكن في نفس الوقت ، أنت بحاجة إلى فهم جيد لكيفية عمل المضيف المستهدف الذي يعمل عليه البرنامج النصي Playbook.

2. المهام
إذا كنت بحاجة إلى بدء خادم ويب في جزء من Playbook ، فأنت بحاجة إلى فهم كيفية القيام بذلك من أجل معرفة وحدة الخدمة التي ستستخدمها لهذا وبدء خادم الويب بالاسم. إذا قام Playbook بتثبيت حزمة البرنامج ، يجب أن تعرف كيفية القيام بذلك على المضيف المستهدف. يجب أن تفهم أيضًا ، على الأقل على المستوى الأساسي ، جوهر المهام التي يتم تنفيذها. هل يلزم تكوين مضيف إضافي للبرنامج الذي تريد تثبيته؟ هل هناك فروع تعتمد على شروط وقيم الحجج؟ إذا تم تمرير أي متغيرات في العملية ، يجب أن تفهم بالضبط ماذا ولماذا.

مثال البرنامج النصي ل Playbook
سيساعدك المثال التالي لبرنامج Playbook على فهم ما قرأته للتو. المضيف المستهدف فيه هو خادم RHEL / CentOS 7 ، حيث يقوم برنامجنا النصي بتثبيت خادم الويب NGINX ، ثم يقوم بإنشاء ملف index.html في دليل webroot الافتراضي.بعد الانتهاء من التثبيت وإنشاء الفهرس ، يبدأ خادم الويب.

* ملاحظة: لتشغيل نموذج Playbook النصي هذا في Ansible Tower ، يجب عليك أولاً تكوين المخزون والحسابات.

تبدأ كتب التشغيل بثلاث واصلات YAML (---) ، متبوعة بما يلي:

الاسم : ببساطة اسم البرنامج النصي للحفاظ على سهولة القراءة في Playbook.

Hosts : قائمة بالمضيفات المستهدفة التي يجب أن تعمل عليها Ansible.

أصبح : لقد كتبنا هنا بيانًا حقيقيًا للتأكد من تثبيت nginx دون مشاكل (هذا الحقل ليس مطلوبًا دائمًا).

1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 

مع المسافة البادئة كخطوط الثلاثة السابقة ، هناك المهام : التوجيه ، وبعد ذلك ، مع المسافة البادئة الإضافية (وفقًا لقواعد تداخل YAML) ، يتم سرد المهام (التشغيل). في هذا المثال ، لدينا مهمتان ، وكلاهما يستخدم وحدة Yum. تضيف المهمة الأولى مستودع تحرير epel حتى تتمكن من تثبيت nginx. بعد ظهور epel على النظام ، تقوم المهمة الثانية بتثبيت حزمة nginx.

الحالة : التوجيه يعني أنه يجب على Ansible التحقق من حالة المضيف المستهدف قبل تنفيذ أي إجراءات أخرى. في مثالنا ، إذا كان هناك بالفعل مستودع أو nginx على المضيف ، يفهم Ansible أنه ليس من الضروري تنفيذ هاتين المهمتين ، ويستمر إلى ما يلي.

 1 tasks: 2 - name: Add epel-release repo 3 yum: 4 name: epel-release 5 state: present 6 7 - name: Install nginx 8 yum: 9 name: nginx 10 state: present 

تعتبر صفحة التنزيل ، التي يتم استخدامها بشكل افتراضي في nginx ، رائعة للتحقق من تثبيت nginx بشكل صحيح ، ولكن ربما تريد القيام بذلك باستخدام ملف html لبدء التشغيل. في هذا المثال ، من أجل البساطة ، يوجد قالب ملف الفهرس في نفس الدليل حيث يبدأ Playbook. الوجهة هي المسار الافتراضي في nginix بدون تكوين مواقع.

 1 - name: Insert Index Page 2 template: 3 src: index.html 4 dest: /usr/share/nginx/html/index.html 

لا يعمل السطر الأخير في Playbook إلا للتحقق من أن خدمة nginx قد بدأت بنجاح (أو لبدء تشغيلها إن لم يكن).

 1 - name: Start NGiNX 2 service: 3 name: nginx 4 state: started 

كان نص برنامج Playbook بأكمله تقريبًا بنفس طول الفقرة الافتتاحية في هذا المنشور:

 1 --- 2 - name: Install nginx 3 hosts: host.name.ip 4 become: true 5 6 tasks: 7 - name: Add epel-release repo 8 yum: 9 name: epel-release 10 state: present 11 12 - name: Install nginx 13 yum: 14 name: nginx 15 state: present 16 17 - name: Insert Index Page 18 template: 19 src: index.html 20 dest: /usr/share/nginx/html/index.html 21 22 - name: Start NGiNX 23 service: 24 name: nginx 25 state: started 

الملخص

تعد برامج Playbook النصية طريقة سهلة ومريحة للقيام بالعديد من الأشياء باستخدام القليل من التعليمات البرمجية. في المثال أعلاه ، استخدمنا ثلاث وحدات - yum ، القالب والخدمة ، لتثبيت المستودع وحزمة البرامج على الخادم ، وإنشاء ملف من القالب المحلي ثم بدء الخدمة التي تم تثبيتها للتو. في الوقت نفسه ، خرج نص Playbook الخاص بنا لفترة أطول قليلاً من هذا العرض! وعلى الرغم من أننا قمنا بتشغيله على مضيف واحد ، إلا أنه يمكنه القيام بذلك أيضًا على العشرات والمئات من الخوادم ، لذلك يحتاج فقط إلى إجراء تغييرات صغيرة جدًا عليه. بالإضافة إلى ذلك ، يتيح لك Tower وضع نص Playbook النصي في قالب مهمة ليتم تشغيله على مجموعة من الخوادم في سحابة AWS أو في مركز بيانات الشركة.

الميزات المعمارية غير المرئية والقدرة على التكامل مع أنظمة CI ، مثل Jenkins ، لا تعمل فقط على أتمتة عمليات إدارة التكوين ، ولكن أيضًا مجموعة أوسع بكثير من مهام تكنولوجيا المعلومات. هذا هو السبب في أننا نسمي Ansible بمودة نظام متكامل للتنسيق ، وليس مجرد أداة لنشر البرامج وإدارة التكوين.