التنمية الفعالة والحفاظ على الأدوار Ansible

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

Ansible ليس حبة سحرية ، ويساعد فقط في البداية. عندما ينمو المشروع ، يصبح من الصعب الحفاظ على عدد كبير من الأدوار. تساعد آلية التسليم المستمر للأدوار على حل المشكلة.

حول هذا الموضوع ، فك شفرة تقرير ألكساندر خاركيفيتش في DevOps Conf Russia . في التقرير: تطوير أدوار Ansible من خلال CI ، آلية لتطوير الأدوار العامة والأدوار العامة مع اختبار يعمل في بنية أساسية خاصة. وليس هناك استنتاج في التقرير.



نبذة عن المتحدث : ألكساندر خاركيفيتش ( خاركيفيتش ) مهندس نظم أول في شركة EPAM Systems .

لنبدأ بنظرة سريعة.

حول Ansible

Ansible هو نظام إدارة التكوين. هو مكتوب في بيثون ، تم تصميمه بواسطة Junja ، ويستخدم YAML DSL. تتم إدارته عبر Ansible Tower - WebUI لإدارة ومراقبة أداء النظام.

ظهرت Ansible في عام 2012 ، بعد 3 سنوات اشترت Red Hat المشروع بالكامل ، وبعد عامين قدمت AWX - نسخة مفتوحة المصدر من مشروع Ansible Tower.

التثبيت

لاستخدام Ansible ، عليك أن تفعل شيئين بسيطين.

في المرحلة الأولى ، قم بتجميع ملف مخزون في حالة وجود بنية أساسية ثابتة.



والثاني هو كتابة Playbook التي ستجلب النظام إلى الحالة المتوقعة.



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

الدور

هذا هو كيان منظم من شأنه أن يصل النظام إلى حالته المتوقعة مع القدرة على إعادة استخدام الأتمتة.



على سبيل المثال ، يمكننا كتابة دور لـ Oracle Java: أخذ Playbook ، ووضع دور ، وتطبيقه على النظام المستهدف. سوف تحصل على تثبيت جافا تثبيت.

كيف تخيلنا العمل مع الأدوار

نظرًا لأن Ansible لديه شيء رائع مثل الأدوار ، فقد اعتقدنا الآن أننا سنأخذ العديد من الأدوار ونكتبها في جميع المناسبات ، ونخدع ونعيد استخدامها لتقليل حجم العمل.


كنا نظن أننا سوف نكتب أدوار جميلة وذكية ...



لكن الحياة تبين أنها أكثر تعقيدًا.

كما اتضح ، في الواقع

عندما يعمل أكثر من شخص على كتابة دور أو تحسينه ، عندها يكتب الجميع في مكان واحد وتثور مفاجآت غير سارة: الدور يتصرف بشكل مختلف عن ما قصده المؤلف في الأصل.

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


نتيجة لذلك ، تنشأ الإنشاءات الرهيبة ، وتحاول نقل bash إلى Ansible وتقديم كل هذا تحت صلصة إدارة التكوين. واجهنا هذه الظاهرة وحزنا.



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

• جمع أفضل الممارسات.
• تطبيق تحليل ثابت ، الوبر.
• لاختبار.
• لرفع تردد التشغيل ، للحصول على إدارة الإصدار.

قررنا تنفيذ هذه الممارسة في المنزل وذهبنا على الفور للبحث عن الأدوات المناسبة.

الأدوات

من وجهة نظر أنظمة التحكم في الإصدار والتكامل المستمر ، هناك العشرات من الحلول المتاحة ، وحديقة حيوانات اختبار متفرعة.



من وجهة نظر إدارة الإصدار في Ansible ، لا يوجد الكثير من الحلول: للعلامة في Git ، أو لوضع علامة في Git والتحميل إلى Galaxy.

هناك طرق عديدة لأدوات الاختبار ، كل منها يستخدم ما يحلو له. الحلول الشائعة باستخدام KitchenCI و InSpec و Serverspec.

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



نستخدم:

• لإدارة التكوين - جيثب وجيتلاب. GitLab يراقب مباشرة على جيثب. لماذا فعلت ذلك ، سأقول لاحقا.
• بالنسبة إلى CI ، أخذنا ترافيس للجزء العام وجيتلاب رنر للجزء الخاص.
• اختبار الجزيء.
• ابدأ في GitHub وأضف إلى Ansible Galaxy.

أصبحت دورة التطوير الخاصة بنا باستخدام هذه الأدوات أكثر متعة.

جزيء

هذه الأداة تساعد على اختبار دور ansible بالكامل. للقيام بذلك ، لديه كل شيء:

• التكامل مع YAML lint و Ansible lint للتحقق من الأدوار للتأكد من توافقها مع متطلباتنا.
• اختبار البنية التحتية لتشغيل الاختبارات الوظيفية.
• محركات Molecule هي المكان الذي تنشر فيه Molecule مقعد الاختبار الخاص بنا. كل شيء مدعوم: Azure ، المفوض ، Docker ، EC2 ، GCE ، LXC ، LXD ، Openstack ، Vagrant.
• لا يزال هناك شيء مفيد وبسيط - الوفد. هذا يعني أن Molecule غير مسؤول عن نشر مقاعد الاختبار ويجب على المطور كتابة Playbook لرفع مقعد الاختبار. إذا كان لديك سحابة فائقة الخصوصية ، ففوض إنشاء آلات الاختبار وإزالتها ، وسيضيف Molecule نفسه كل شيء بداخله.

اختبار المصفوفة

النظر في مصفوفة الاختبار في الخطوات. هناك 11 خطوة في المجموع ، لكنني سأكون مختصرا.

رقم 1. ينت

يديرون YAML lint و Ansible lint ، ويجدون شيئًا ما.



في المثال أعلاه ، يقسم الوبر بأنه لا ينبغي تسمية القذيفة في Ansible فحسب ، بل يجب أن تكون مثبتة وملزمة لشيء ما.

رقم 2. تدمير

يتخلص الجزيء من كل شيء يبقى بعد الاختبارات السابقة.

هناك أوقات عندما يكون الجري قد مر ، وقد تكشفت أرض التدريب ، واكتمل الاختبار. يجب تنظيف الحامل في النهاية ، لكن القوة القاهرة تدخلت ولم يكن هناك تنظيف. لمثل هذه الحالات ، يهرب الجزيء من تدمير بيئة المخلفات وتنظيفها.

رقم 3. التبعية

نأخذ ملف requirements.yml ونضيف تبعيات دورنا في الأدوار الأخرى. على سبيل المثال ، إشارة إلى حقيقة أن الدور لن ينطلق بدون تثبيت Java على النظام:

--- - src: lean_delivery.java version: 1.4 

يفهم الجزيء هذا وسوف ينفذ البرنامج النصي:

• يذهب غالاكسي أو بوابة
• سوف ندرك أنه من الضروري حل التبعيات ؛
• يذهب إلى المجرة مرة أخرى ؛
• التنزيلات
• سوف تتوسع.

رقم 4. بناء الجملة

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

تُظهر الشريحة أن الدور ansible يُسمى "kibana" ، وفي Playbook ، يُسمى ansible-role-kibana. يقول النظام: "كل شيء سيكون على ما يرام ويمكنك إنشاؤه هنا ، لكنني لن أفعل ذلك لأن الأسماء لا تتطابق!"

رقم 5. إنشاء

في هذه المرحلة ، نشير إلى برنامج التشغيل الذي تم نشر موقع الاختبار به. Point Google - سترفع آلات الاختبار في Google Cloud.

يمكننا أن نكتب في ملف molecule.yml ما نريد. دعونا نرى كيف يبدو على مثال ل Docker.

• أقوم بتحديد صور عامل ميناء لسحب ما يصل.
• أشير إلى كيفية تجميعها بحيث يتم تكوين ملف مخزون.

أرغب في الحصول على صورتين لرسو السفن: صورة لـ RHEL-like ، والثانية لشبه دبيان ، للتأكد من أن كل شيء سيكون على ما يرام أثناء الاختبار مع كل من RHEL و Debian.

رقم 6. إعداد

هذه خطوة تحضير أولية لبيئة تنفيذ الاختبار.

يبدو أن كل شيء قد ارتفع ، ولكن في بعض الأحيان تحتاج إلى تنفيذ بعض الإعدادات الإضافية. في حالة الاختبار داخل Docker مرفوع في دبيان أو أوبونتو ، تحتاج إلى تثبيت Python الثاني ، والذي يحدث غالبًا.

رقم 7. تتلاقى

يتم تشغيل المرحلة من أول دورة كبيرة من الدور داخل المثيل ، للتأكد من وصولها إلى النهاية ، ويؤكد Ansible أن كل شيء على ما يرام.

• جزيء يشير إلى Ansible.
• نشر Ansible إلى موقع الاختبار.
• إنه يعمل.
• كل شيء على ما يرام!

رقم 8. العاطل

اختبار العاطفية بسيط ويبدو مثل هذا.

• في المرة الأولى التي يمر فيها الدور من خلال الخطوة السابقة.
• تقارير Ansible عدد التغييرات التي تم إجراؤها.
• إعادة إطلاق نفس الدور.
• يتحقق من أن النظام قد تم نقله إلى الحالة المتوقعة ، ولكن لا توجد تغييرات في الإيجار الثاني.

نتيجة لذلك ، نحن نفهم أن دورنا لا يعمل بشكل مدمر.

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



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

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



عندما تم القبض على هذه الخدعة أيضًا ، بدأت الصورة تبدو هكذا.



جيد - ركض البرنامج النصي تحت الاسم الافتراضي ، وهو غير منطقي.

رقم 9. الآثار الجانبية

في المرحلة التالية ، يتم تراكب الآثار الجانبية. ليس من الضروري القيام بذلك ، ولكنه مناسب عند اختبار أدوار النشر المعقدة التي تعتمد على بعضها البعض.

على سبيل المثال ، ارفع مكدس ELK ، ثم Elasticsearch في كتلة. في مرحلة side_effect ، أضف بيانات الاختبار وأزل بضع عقدتين من الكتلة. موقع الاختبار جاهز للاختبارات الوظيفية التي تجري في الخطوة التالية.

رقم 10. تحقق

اختبار البنية التحتية.



أعلاه مثال على اختبار بسيط للغاية. نتحقق من تثبيت حزمة Docker Community Edition إذا كان Ubuntu مثبتًا ، ولديه الإصدار الصحيح ، وكانت الخدمة قيد التشغيل.

في هذه المرحلة من إطلاق الاختبارات الوظيفية ، يمكن أن يكون كل شيء معقدًا إلى حد كبير.

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



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

رقم 11. تدمير

لقد أجرينا اختبارات ، وهناك تقرير اختبار في بعض الأشكال ، والآن نقوم بإزالة جميع القمامة التي خلفنا.

الأتمتة

جزيء هو أداة عظيمة. الآن يبقى أبسط شيء - توصيل نظام تكامل مستمر به من أجل الاستمتاع بالاختبار التلقائي لأدوارنا ، وهو ما قمنا به.



كما هو الحال في أي مكان آخر ، هناك العديد من الميزات.

بعض الأدوار التي نكتبها لأتمتة شيء جيد ، لكن لا يمكننا اختبار النظام باستخدام Travis ، لأن الأدوار تنشر منتجات لا يمكننا مشاركتها لأسباب الترخيص.

على سبيل المثال ، لديك نشر تلقائي لقاعدة بيانات Oracle. إذا وضعت قاعدة برنامج التثبيت في ملف ، فسوف يأتي إليك محامو الشركة وسيؤديون أقسمًا كبيرًا. لكي يعيش الجميع في سلام ولا يقسم ، قررنا القيام بما يلي.

• تعلمت GitLab ، في واحدة من أحدث إصداراتها ، كيفية القيام بـ CI لمستودعات الجهة الخارجية.
• يكمن الدور في GitHub العام ، نفس GitLab.com العام المتصل به ، والذي أشرنا إليه: "عزيزي GitLab ، نجمع لنا CI للمستودع الخارجي."
• يتم غلق المتسابقين من القطاع الخاص إلى GitLab ، في محيط مغلق ، ولديهم بالفعل إمكانية الوصول إلى ثنائي ، والذي يمكنهم نشره.

في الواقع ، الدور يكمن علنًا ، البيانات أيضًا ، ونحن لا نخدع أي شخص - فنحن نجري اختبارات حقيقية باستخدام أدوات حقيقية.

دعونا نلقي نظرة على خطوات ما يبدو عليه في ترافيس.

ترافيس

الخطوات:

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

CI العامة

CI العامة تبدو الابتدائية.



من GitHub ، سهم إلى Travis ، بداخله يعيش Molecule و Docker.

CI الخاص

بالنسبة للجزء الخاص من GitLab ، كل شيء هو نفسه.



في المحيط الخاص ، ندير عداءًا ، وتبدو الصورة أكثر متعة.



يحصل الرمز من GitHub إلى GitLab ، في مكان ما يعمل فيه عداء خاص يمكنه سحب الخدمات الخارجية ، على سبيل المثال ، تشغيل شيء ما على Amazon.

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

حتى هنا ، كنا كسولًا قليلاً وفعلنا ما يلي. نحن في EPAM لدينا سحابة خاصة بنا وهي مختلطة. هذا يعني أن العديد من السحب العامة يمكن الوصول إليها من السحابة الداخلية ، مثل المناطق. لا يمكنك كتابة ألف اختبار ، ولكن تجوّل مع المناطق وتقول: "اختبر الآن وفقًا لسيناريو الاختبار هذا لـ AWS ، EPAM Cloud ، Azure region".

مجرة غير مرئية

وصلنا إلى النهاية ، دورنا أخضر ، جميل ، سننشره في Galaxy.



هذه عملية بسيطة:

• مكالمة webhook الموجودة في ترافيس.
• في هذه الحالة ، سيتم تشغيل Travis ، سيتم تشغيل CI مرة أخرى.
• دعوة webhook.
• سوف ينمو الإصدار الجديد بنجاح في Galaxy.

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

إذا نشرت شيئًا على Galaxy ، فلا تنس وضع علامة عليه ، فهناك إصدارات ، وكل شيء كان رائعًا.

أنماط

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

يحتوي القالب على الإعدادات الافتراضية لـ Ansible lint و GitHub issue_template. كل شيء موجود في المجال العام ، وبالتالي ، فإن issue_template في شكل جميل كان جميلًا أيضًا بالنسبة لنا لإصدار تقارير السحب أو الأخطاء. نضيف قوالبًا لـ Gitignore و Gitlab-ci وترخيصًا لنفس المستودع.



بشكل افتراضي ، ننشر تحت رخصة Apache 2.0. إذا كنت تريد القدوم إلينا وإعادة استخدام القوالب ، فيمكنك أخذ كل شيء بعيدًا وإنشاء مستودع مغلق وعدم شرح أي شيء لأي شخص. شكرا اباتشي.

لدينا العديد من خيارات الاختبار حتى تتمكن من البدء وبدء كل شيء بسرعة.

ملخص

لن يكون هناك أي استنتاج ، بدلاً من ذلك ، توجد روابط إلى GitHub وملف تعريف Galaxy الخاص بي و GitHub Lean Delivery و Ansible Galaxy . باستخدام الروابط يمكنك أن ترى كيف يعمل كل شيء. جميع الأمثلة متاحة بحرية.

سيعقد مؤتمر DevOps التالي في مايو.

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

اشترك ، سيكون من المثير للاهتمام :)