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

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

المستوى المتوقع من القارئ هو أن عدة آلاف من سطور اليامل قد تمت كتابتها بالفعل ، وهناك شيء ما قيد الإنتاج بالفعل ، ولكن "كل شيء معوج بطريقة ما".

أسماء

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

فلنبدأ بواحد بسيط: ما يسمى. ربما تعرف هذا ، أو ربما لا تعرفه ، لأنك لم تنتبه عندما تقرأ الوثائق.

ansible-playbook ينفذ قواعد اللعبة. Playbook هو ملف yml / yaml يحتوي على شيء مثل هذا بالداخل:

---
- hosts: group1
  roles:
    - role1

- hosts: group2,group3
  tasks:
    - debug:

لقد فهمنا بالفعل أن هذا الملف بأكمله عبارة عن دليل. يمكننا إظهار مكان الأدوار ، وأين توجد المهام. لكن أين اللعب؟ وكيف يختلف اللعب عن الدور أو الدليل؟

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

لذا تذكر: دليل اللعب هو قائمة اللعب و import_playbook.
هذه مسرحية واحدة:

- hosts: group1
  roles:
    - role1

وهذه أيضًا مسرحية أخرى:

- hosts: group2,group3
  tasks:
    - debug:

ما هو اللعب؟ لماذا هل هي؟

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

إذا كنت تريد أداء "شيء ما" "في مكان ما" - تكتب مسرحية. ليس دور. لا دور مع الوحدات والمندوبين. أنت تأخذ وتكتب اللعب. حيث تقوم ، في حقل المضيفين ، بإدراج مكان التنفيذ ، وفي الأدوار / المهام - ما يجب تنفيذه.

ببساطة ، أليس كذلك؟ وكيف يمكن أن يكون خلاف ذلك؟

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

من الأمثلة النموذجية المراقبة. أود أن يكون لي دور رقابي سيحدد عملية المراقبة. يتم تعيين دور المراقبة لمراقبة المضيفين (acc. play). لكن اتضح أنه من أجل المراقبة ، نحتاج إلى وضع حزم على المضيفين الذين نراقبهم. لماذا لا تستخدم المفوض؟ تحتاج أيضًا إلى ضبط iptables. مندوب؟ ولا يزال من الضروري كتابة / تصحيح تهيئة لنظام إدارة قواعد البيانات (DBMS) التي بدأت المراقبة. مندوب! وإذا ظهر الإبداع ، فيمكنك عمل تفويض include_role في حلقة متداخلة من خلال مرشح صعب في قائمة المجموعات ، وفي الداخل include_role يمكنك فعل المزيد delegate_to مرة أخرى. وها نحن ننطلق...

الرغبة الجيدة - أن يكون لديك دور مراقبة واحد "يفعل كل شيء" - يقودنا إلى جحيم في الملعب يوجد منه غالبًا مخرج واحد: إعادة كتابة كل شيء من البداية.

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

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

هنا خطأ كبير آخر. خطأ حول العديد من المشاريع من كتابتها بشكل مقبول (يمكن أن يكون أفضل ، لكن كل شيء يعمل ويسهل إضافته) إلى رعب كامل لا يستطيع حتى المؤلف اكتشافه. إنه يعمل ، ولكن لا قدر الله أن يتغير شيء.

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

شكرا لك انت على حق يتخذ Play قرارًا (بشكل أكثر دقة ، يحتوي على معلومات) حول المهام والأدوار التي يجب أداؤها على المضيفين.

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

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

ملاحظة للتآكل: الدور ، بالطبع ، يمكن أن يؤثر على تدفق التحكم. يأكل delegate_to ولها استخدامات معقولة. يأكل meta: end host/play. لكن! تذكر أننا نعلم الأساسيات؟ نسيت بشان delegate_to. نحن نتحدث عن أبسط وأجمل كود Ansible. وهو سهل القراءة والكتابة وسهل التصحيح والاختبار والكتابة. إذن ، مرة أخرى:

اللعب واللعب فقط يقرر أي المضيفين يتم تنفيذه.

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

المهام والأدوار

فكر في اللعب:

- hosts: somegroup
  pre_tasks:
    - some_tasks1:
  roles:
     - role1
     - role2
  post_tasks:
     - some_task2:
     - some_task3:

لنفترض أنك بحاجة إلى فعل foo. ويبدو أن foo: name=foobar state=present. أين تكتبها؟ في مرحلة ما قبل؟ بريد؟ إنشاء دور؟

… وأين ذهبت المهام؟

نبدأ من جديد بالأساسيات - جهاز اللعب. إذا كنت تتجول في هذا الأمر ، فلا يمكنك استخدام اللعب كأساس لكل شيء آخر ، وتكون نتيجتك "متذبذبة".

جهاز اللعب: توجيه المضيفين ، وإعدادات المسرحية نفسها ، وقسم ما قبل المهام ، والمهام ، والأدوار ، وما بعد المهام. المعلمات المتبقية للعب ليست مهمة بالنسبة لنا الآن.

ترتيب أقسامهم بالمهام والأدوار: pre_tasks, roles, tasks, post_tasks. منذ ، من الناحية المعنوية ، ترتيب التنفيذ بين tasks и roles ليس واضحًا ، إذًا تشير أفضل الممارسات إلى أننا نضيف قسمًا tasks، فقط إذا لم يكن كذلك roles... إذا كان هناك roles، ثم يتم وضع جميع المهام المرفقة في الأقسام pre_tasks/post_tasks.

يبقى فقط أن كل شيء واضح لغويًا: أولاً pre_tasksإذن rolesإذن post_tasks.

لكننا ما زلنا لم نجب على السؤال: أين مكالمة الوحدة foo يكتب؟ هل نحتاج إلى كتابة دور كامل لكل وحدة؟ أم أنه من الأفضل أن يكون لك دور كبير في كل شيء؟ وإذا لم يكن دورًا ، فأين تكتب - في ما قبل أو بعد؟

إذا لم تكن هناك إجابة منطقية على هذه الأسئلة ، فهذه علامة على نقص الحدس ، أي تلك "الأسس الهشة". دعونا نفهم ذلك. سؤال الأمان أولاً: إذا كان اللعب به pre_tasks и post_tasks (وليس هناك مهام ولا أدوار) ، إذًا يمكن أن ينكسر شيء ما إذا كانت المهمة الأولى منه post_tasks تحرك حتى النهاية pre_tasks?

بالطبع ، تشير صياغة السؤال إلى أنه سيتعطل. لكن ماذا بالضبط؟

... معالجات. تكشف قراءة الأساسيات عن حقيقة مهمة: يتم مسح جميع المعالجات تلقائيًا بعد كل قسم. أولئك. كل المهام من pre_tasks، ثم كل المتعاملين الذين تم إخطارهم. ثم يتم تنفيذ جميع الأدوار وجميع المعالجات التي تم إخطارها في الأدوار. بعد post_tasks ومعالجيهم.

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

الآن دعونا نفكر مرة أخرى ، لماذا نحن pre_tasks и post_tasks؟ على سبيل المثال ، من أجل أداء كل ما هو ضروري (بما في ذلك المعالجات) قبل تنفيذ الدور. أ post_tasks سيسمح لنا بالعمل مع نتائج تنفيذ الأدوار (بما في ذلك المعالجات).

سوف يخبرنا المتذوق Ansible ما هو meta: flush_handlers، ولكن لماذا نحتاج إلى معالجات flush_handlers عندما نتمكن من الاعتماد على ترتيب تنفيذ الأقسام في اللعب؟ علاوة على ذلك ، فإن استخدام meta: flush_handlers يمكن أن يسلمنا أشياء غير متوقعة من خلال معالجات متكررة ، ويعطينا تحذيرات غريبة في حالة استخدام when у block إلخ. كلما عرفت ما هو غير مقبول بشكل أفضل ، زادت الفروق الدقيقة التي يمكنك تسميتها لحل "صعب". والحل البسيط - باستخدام الفصل الطبيعي بين الأدوار / ما قبل / بعد - لا يسبب فروقًا دقيقة.

ونعود إلى "foo". أين وضعها؟ في ما قبل ، ما بعد أو الأدوار؟ من الواضح أن هذا يعتمد على ما إذا كنا نريد نتائج المعالج لـ foo. إذا لم تكن موجودة ، فلن تحتاج إلى وضع foo إما قبل أو بعد - فهذه الأقسام لها معنى خاص - أداء المهام قبل وبعد مصفوفة الكود الرئيسي.

الآن الإجابة على السؤال "الدور أو المهمة" تعود إلى ما هو موجود بالفعل - إذا كانت هناك مهام ، فأنت بحاجة إلى إضافة المهام. إذا كانت هناك أدوار ، فأنت بحاجة إلى القيام بدور (وإن كان من مهمة واحدة). أذكرك أنه لا يتم استخدام المهام والأدوار في نفس الوقت.

يوفر فهم أساسيات Ansible إجابات معقولة على أسئلة التذوق على ما يبدو.

المهام والأدوار (الجزء الثاني)

الآن دعنا نناقش الموقف عندما تبدأ للتو في كتابة كتاب قواعد اللعبة. تحتاج إلى جعل foo و bar و baz. هل هذه المهام الثلاث ، دور واحد أم ثلاثة أدوار؟ تلخيص السؤال: في أي نقطة يجب أن تبدأ في كتابة الأدوار؟ ما الهدف من كتابة الأدوار عندما تستطيع كتابة المهام؟ ... وما هو الدور؟

أحد أكبر الأخطاء (تحدثت بالفعل عن هذا) هو التفكير في أن الدور يشبه وظيفة في مكتبة البرنامج. كيف يبدو الوصف العام للدالة؟ يأخذ حجج المدخلات ، يتفاعل مع الأسباب الجانبية ، يفعل الآثار الجانبية ، ويعيد قيمة.

الآن ، الاهتمام. ما الذي يمكن عمله من هذا في الدور؟ نداء الآثار الجانبية - مرحبًا بك دائمًا ، هذا هو جوهر Ansible كله - للقيام بآثار جانبية. هل لديك أسباب جانبية؟ ابتدائي. ولكن مع "تمرير قيمة وإعادتها" - فهذا ليس الأمر كذلك. أولاً ، لا يمكنك تمرير قيمة إلى دور ما. يمكنك تعيين متغير عام مع عمر تشغيل بالحجم في قسم vars للدور. يمكنك تعيين متغير عام مع وجود مدى الحياة في اللعب داخل الدور. أو حتى مع عمر كتيب اللعبة (set_fact/register). لكن لا يمكن أن يكون لديك "متغيرات محلية". لا يمكنك "أخذ قيمة" و "إعادتها".

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

المجموع: الدور ليس وظيفة.

ما الجيد في الدور؟ أولاً ، الدور له قيم افتراضية (/default/main.yaml) ، ثانيًا ، يحتوي الدور على أدلة إضافية للملفات القابلة للطي.

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

ما هو الجيد في الأدوار؟ حقيقة أن لديهم الدلائل الخاصة بهم. هذه أدلة للمتغيرات ، سواء كانت ثابتة (أي محسوبة للدور) وديناميكية (يوجد مثل هذا النمط ، أو نمط مضاد - include_vars مع {{ ansible_distribution }}-{{ ansible_distribution_major_version }}.yml.). هذه أدلة لـ files/, templates/. أيضًا ، يتيح لك الحصول على أدوار للوحدات والمكونات الإضافية الخاصة بك (library/). ولكن ، بالمقارنة مع مهام كتاب التشغيل (الذي يمكن أن يحتوي أيضًا على كل هذا) ، فإن الفائدة الوحيدة هنا هي أن الملفات لا يتم تفريغها في كومة واحدة ، ولكن يتم تفريغ عدة أكوام منفصلة.

تفصيل آخر: يمكنك محاولة إنشاء أدوار ستكون متاحة لإعادة الاستخدام (عبر المجرة). بعد ظهور المجموعات ، يمكن اعتبار توزيع الأدوار شبه منسي.

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

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

من الممكن أن تقوم بـ import_role كمهمة ، ولكن إذا كتبت هذا ، فكن مستعدًا لشرح لشعورك بالجمال ، ولماذا تريد القيام بذلك.

قد يقول القارئ الذكي أن الأدوار يمكن أن تستورد الأدوار ، والأدوار يمكن أن يكون لها تبعية عبر galaxy.yml ، ومن ثم هناك المخيف والرهيب include_role - أذكرك بأننا نحسن المهارات في Ansible الأساسية ، وليس في الجمباز الرقم.

المعالجات والمهام

دعنا نناقش شيئًا أكثر وضوحًا: المعالجات. معرفة كيفية استخدامها بشكل صحيح يكاد يكون فنًا. ما هو الفرق بين المعالج والمهمة؟

بما أننا نتذكر الأساسيات ، فإليك مثال:

- hosts: group1
  tasks:
    - foo:
      notify: handler1
  handlers:
     - name: handler1
       bar:

معالجات الدور موجودة في rolename / handlers / main.yaml. يتم البحث عن المعالجات بين جميع المشاركين في المسرحية: يمكن لما قبل / post_tasks سحب معالجي الأدوار ، ويمكن للدور أن يسحب المتعاملين من المسرحية. ومع ذلك ، تتسبب استدعاءات "الأدوار المتقاطعة" للمعالجات في حدوث wtf أكثر بكثير من تكرار معالج تافه. (عنصر آخر من أفضل الممارسات هو تجنب تكرار أسماء المعالج).

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

الموقف مع التكوين غير قابل للحل (بتعبير أدق ، يمكنك اختراع بروتوكول إعادة تشغيل خاص لنفسك باستخدام أعلام الملفات ، وما إلى ذلك ، ولكن هذا لم يعد "أساسيًا" بأي شكل من الأشكال). ولكن هناك قصة أخرى مشتركة: قمنا بتثبيت التطبيق وتسجيله .service-ملف ، والآن نريده daemon_reload и state=started. ويبدو أن المكان الطبيعي لذلك هو المعالج. ولكن إذا لم تجعلها معالجًا بل مهمة في نهاية قائمة المهام أو الدور ، فسيتم تنفيذها على نحو عابر في كل مرة. حتى لو كسرت قواعد اللعبة في المنتصف. هذا لا يحل مشكلة إعادة التشغيل على الإطلاق (لا يمكنك القيام بمهمة مع السمة المعاد تشغيلها ، لأن idempotency ضاع) ، ولكن الأمر يستحق بالتأكيد فعل الحالة = بدأ ، ويزداد الاستقرار العام لقواعد اللعبة ، لأن. عدد الاتصالات والحالة الديناميكية ينخفض.

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

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

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

يلاحظ القارئ الذكي بحق أننا لم نناقش listenيمكن للمعالج أن يستدعي الإخطار على معالج آخر ، وأن المعالج يمكن أن يتضمن import_tasks (والتي يمكن أن تتضمن __ole c with_items) ، وأن نظام معالج Ansible هو Turing-Complete ، والذي يتضمن معالجات_السلع تتقاطع مع معالجات التشغيل بطرق غريبة ، وما إلى ذلك. د. - من الواضح أن كل هذا ليس "أساسيات").

على الرغم من وجود WTF واحد معين إلا أنه في الواقع ميزة يجب مراعاتها. إذا تم تنفيذ مهمتك باستخدام delegate_to وقد أخطرت ، ثم يتم تنفيذ المعالج المقابل بدون delegate_to، أي. على المضيف حيث يتم تعيين اللعب. (على الرغم من أن المعالج ، بالطبع ، قد يكون delegate_to نفس).

بشكل منفصل ، أود أن أقول بضع كلمات حول الأدوار التي يمكن إعادة استخدامها. قبل المجموعات ، كانت هناك فكرة أنه يمكنك القيام بأدوار عامة يمكنك القيام بها ansible-galaxy install و ذهب. يعمل على جميع أنظمة التشغيل بجميع المتغيرات في جميع المواقف. إذن هذا هو رأيي: إنه لا يعمل. أي دور ضخم include_vars، دعم 100500 حالة محكوم عليه بالهاوية من حشرات الزاوية. يمكن توصيلها باختبارات مكثفة ، ولكن كما هو الحال مع أي اختبار ، إما أن يكون لديك منتج ديكارتي لقيم الإدخال ووظيفة كاملة ، أو لديك "سيناريوهات منفصلة مغطاة". رأيي هو أنه من الأفضل كثيرًا أن يكون الدور خطيًا (التعقيد السيكلومي 1).

أقل if'ov (صريح أو تصريحي - في النموذج when أو النموذج include_vars على مجموعة من المتغيرات) ، كان الدور أفضل. في بعض الأحيان عليك أن تصنع أغصانًا ، لكني أكرر ، كلما قلت ، كان ذلك أفضل. لذلك يبدو أنه دور جيد مع المجرة (إنه يعمل!) مع مجموعة من when قد يكون أقل تفضيلاً من الدور "الخاص" في خمس مهام. اللحظة التي يكون فيها الدور مع المجرة أفضل عندما تبدأ في كتابة شيء ما. اللحظة التي يزداد فيها الأمر سوءًا هي عندما ينكسر شيء ما ، ولديك شك في أن ذلك بسبب "الدور مع المجرة". تفتحه ، وهناك خمسة إدراجات وثماني قوائم مهام وكدس من when'Ov ... وهذا يحتاج إلى تسوية. بدلاً من 5 مهام ، قائمة خطية ، لا يوجد فيها شيء يمكن كسره.

في الأجزاء التالية

• قليلا عن المخزون ، متغيرات المجموعة ، البرنامج المساعد host_group_vars ، hostvars. كيفية ربط العقدة الجوردية من السباغيتي. متغيرات النطاق والأسبقية ، نموذج الذاكرة Ansible. "فأين تخزن اسم المستخدم لقاعدة البيانات؟".
• jinja: {{ jinja }} - nosql notype البلاستيسين الناعم nosense. إنه موجود في كل مكان ، حتى حيث لا تتوقعه. قليلا عن !!unsafe واليامل اللذيذ.

المصدر: www.habr.com