🥇كيف تبدأ اختبار Ansible، وتعيد بناء المشروع خلال عام ولا تصاب بالجنون

هذا هو النص العروض في DevOps-40 2020-03-18:

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

ولادة التراث

اليوم رقم 1: المريض صفر

ذات مرة كان هناك مشروع مشروط. كان لديها فريق تطوير ومهندسي العمليات. لقد كانوا يحلون نفس المشكلة: كيفية نشر الخوادم وتشغيل التطبيق. وكانت المشكلة أن كل فريق حل هذه المشكلة بطريقته الخاصة. في المشروع، تقرر استخدام Ansible لمزامنة المعرفة بين فريقي Dev وOps.

اليوم رقم 89: ولادة الإرث

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

لدينا مهمة عاجلة هنا، فلنقم بعملية اختراق قذرة ثم نصلحها.
ليس عليك كتابة الوثائق وكل شيء واضح عما يحدث هنا.
أعرف Ansible/Python/Bash/Terraform! انظروا كيف يمكنني مراوغة!
أنا مطور Full Stack Overflow وقمت بنسخ هذا من Stackoverflow، لا أعرف كيف يعمل، لكنه يبدو رائعًا ويحل المشكلة.

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

- hosts: localhost
  tasks:
    - shell: echo -n Z >> a.txt && cat a.txt
      register: output
      delay: 1
      retries: 5
      until: not output.stdout.find("ZZZ")

اليوم رقم 109: الوعي بالمشكلة

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

إعادة هيكلة IAC

اليوم رقم 139: هل تحتاج حقًا إلى إعادة البناء؟

قبل أن تتسرع في إعادة البناء، يجب عليك الإجابة على عدد من الأسئلة المهمة:

لماذا تحتاج كل هذا؟
هل لديك وقت؟
هل المعرفة كافية؟

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

اليوم رقم 149: التحضير لإعادة البناء

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

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

محاولات اختبار غير قابلة للتنفيذ

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

اليوم رقم -997: توفير SDS

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

اليوم رقم -701: مطبخ عملي واختباري

كان تطوير فكرة اختبار Ansible هو استخدام الأدوات الجاهزة، وهي مطبخ الاختبار / Kitchen-ci وinspec. تم تحديد الاختيار بمعرفة روبي (لمزيد من التفاصيل، راجع مقال حبري: هل يحلم مبرمجو YML باختبار Ansible؟) عملت بشكل أسرع، حوالي 40 دقيقة لـ 10 أدوار. لقد أنشأنا حزمة من الأجهزة الافتراضية وأجرينا اختبارات بداخلها.

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

اليوم رقم -601: غير قابل للجزيء

من الناحية النظرية، هذا مشابه لـ testkitchen، لكننا فقط قمنا بنقل اختبار الأدوار إلى عامل الإرساء وقمنا بتغيير المكدس. ونتيجة لذلك تم تقليص الوقت إلى 20-25 دقيقة مستقرة لـ 7 أدوار.

من خلال زيادة عدد الأدوار التي تم اختبارها إلى 17 وفحص 45 دورًا، قمنا بتشغيل هذا في 28 دقيقة على 2 من العبيد من جينكينز.

اليوم رقم 167: إضافة اختبارات Ansible إلى المشروع

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

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

إعادة الهيكلة بسيطة:

تناول الطعام.
النوم.
الشفرة.
اختبار إيك.
كرر

ونكرر ذلك حتى نصل إلى الهدف المقصود.

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

اليوم رقم 181: سيد البناء الأخضر

تعتبر عملية الفحص خطوة أولى صغيرة نحو برنامج Green Build Master. لن يؤدي هذا إلى كسر أي شيء تقريبًا، ولكنه سيسمح لك بتصحيح أخطاء العمليات وإنشاء تصميمات صديقة للبيئة في Jenkins. الفكرة هي تطوير العادات بين الفريق:

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

اليوم رقم 193: من الفحص إلى اختبارات الوحدة

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

اليوم رقم 211: من اختبارات الوحدة إلى التكامل

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

باستخدام جينكينز، أنشأنا العديد من المراحل التي ربطت الأدوار/كتب اللعب بالتوازي، ثم اختبارات الوحدة في الحاويات، وأخيرًا اختبارات التكامل.

Jenkins + Docker + Ansible = الاختبارات

الخروج الريبو وإنشاء مراحل البناء.
قم بتشغيل مراحل كتاب اللعب Lint بالتوازي.
قم بتشغيل مراحل دور الوبر بالتوازي.
قم بتشغيل مراحل دور التحقق من بناء الجملة بالتوازي.
قم بتشغيل مراحل دور الاختبار بالتوازي.
1. دور الوبر.
2. التحقق من التبعية للأدوار الأخرى.
3. التحقق من بناء الجملة.
4. إنشاء مثيل عامل ميناء
5. قم بتشغيل الجزيء/الافتراضي/playbook.yml.
6. التحقق من العجز الجنسي.
تشغيل اختبارات التكامل
نهاية

اليوم رقم 271: عامل الحافلات

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

وينبغي أن تكون مريحة هنا. من الملائم إجراء مراجعة، والاطلاع على إطار المهمة التي تم إنجازها وتاريخ المناقشات. لقد قمنا بدمج جينكينز + بيتبوكيت + جيرا.

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

- get_url:
    url: "{{ actk_certs }}/{{ item.1 }}"
    dest: "{{ actk_src_tmp }}/"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ item.1 }}"
    dest: "{{ actk_dst_tmp }}"
  with_subelements:
    - "{{ actk_cert_list }}"
    - "{{ actk_certs }}"

ثم قاموا بإصلاحه، ولكن بقيت الرواسب.

get_url:
    url: "{{ actk_certs }}/{{ actk_item }}"
    dest: "{{ actk_src_tmp }}/{{ actk_item }}"
    username: "{{ actk_mvn_user }}"
    password: "{{ actk_mvn_pass }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"
  delegate_to: localhost

- copy:
    src: "{{ actk_src_tmp }}/{{ actk_item }}"
    dest: "{{ actk_dst_tmp }}"
  loop_control:
    loop_var: actk_item
  with_items: "{{ actk_cert_list }}"

اليوم رقم 311: تسريع الاختبارات

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

بالمعنى الدقيق للكلمة، كانت هناك مجموعة من التدابير:

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

ونتيجة لذلك، تم أيضًا توحيد خط الأنابيب في جنكينز

إنشاء مراحل البناء.
لينت كل ذلك بالتوازي.
قم بتشغيل مراحل دور الاختبار بالتوازي.
النهاية.

الدروس المستفادة

تجنب المتغيرات العامة

يستخدم Ansible المتغيرات العامة، ويوجد حل جزئي في النموذج Private_role_vars، ولكن هذا ليس حلا سحريا.

اسمحوا لي أن أقدم لكم مثالا. دعونا لها role_a и role_b

# cat role_a/defaults/main.yml
---
msg: a

# cat role_a/tasks/main.yml
---
- debug:
    msg: role_a={{ msg }}

# cat role_b/defaults/main.yml
---
msg: b

# cat role_b/tasks/main.yml
---
- set_fact:
    msg: b
- debug:
    msg: role_b={{ msg }}

- hosts: localhost
  vars:
    msg: hello
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

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

سيئة: استخدم المتغير العالمي.

# cat roles/some_role/tasks/main.yml
---
debug:
  var: java_home

جيد: الخامس defaults تحديد المتغيرات الضرورية واستخدامها لاحقًا فقط.

# cat roles/some_role/defaults/main.yml
---
r__java_home:
 "{{ java_home | default('/path') }}"

# cat roles/some_role/tasks/main.yml
---
debug:
  var: r__java_home

متغيرات دور البادئة

سيئة: استخدم المتغير العالمي.

# cat roles/some_role/defaults/main.yml
---
db_port: 5432

جيد: في أدوار المتغيرات، استخدم المتغيرات مسبوقة باسم الدور؛ وهذا، من خلال النظر في المخزون، سيجعل من السهل فهم ما يحدث.

# cat roles/some_role/defaults/main.yml
---
some_role__db_port: 5432

استخدام متغير التحكم في الحلقة

سيئة: استخدم المتغير القياسي في الحلقات item، إذا تم تضمين هذه المهمة/دليل التشغيل في مكان ما، فقد يؤدي ذلك إلى سلوك غير متوقع

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item }}"
      loop:
        - item1
        - item2

جيد: إعادة تعريف متغير في حلقة عبر loop_var.

---
- hosts: localhost
  tasks:
    - debug:
        msg: "{{ item_name }}"
      loop:
        - item1
        - item2
      loop_control:
        loop_var: item_name

التحقق من متغيرات الإدخال

لقد اتفقنا على استخدام البادئات المتغيرة؛ ولن يكون من الضروري التحقق من أنها محددة كما نتوقع، وعلى سبيل المثال، لم يتم تجاوزها بقيمة فارغة

جيد: التحقق من المتغيرات.

- name: "Verify that required string variables are defined"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} needs to be set for the role to work "
    success_msg: "Required variables {{ ahs_var }} is defined"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

تجنب قواميس التجزئة، واستخدم البنية المسطحة

إذا كان الدور يتوقع وجود تجزئة/قاموس في إحدى معلماته، فإذا أردنا تغيير إحدى المعلمات الفرعية، فسنحتاج إلى تجاوز التجزئة/القاموس بأكمله، مما سيزيد من تعقيد التكوين.

سيئة: استخدم التجزئة/القاموس.

---
user:
  name: admin
  group: admin

جيد: استخدم بنية متغيرة مسطحة.

---
user_name: admin
user_group: "{{ user_name }}"

إنشاء قواعد اللعب والأدوار العاجزة

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

تجنب استخدام وحدات shell الأوامر

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

اختبر أدوارك عبر الجزيء

الجزيء هو شيء مرن للغاية، دعونا نلقي نظرة على بعض السيناريوهات.

جزيء حالات متعددة

В molecule.yml في قسم platforms يمكنك وصف العديد من الأجهزة المضيفة التي يمكنك نشرها.

---
    driver:
      name: docker
    platforms:
      - name: postgresql-instance
        hostname: postgresql-instance
        image: registry.example.com/postgres10:latest
        pre_build_image: true
        override_command: false
        network_mode: host
      - name: app-instance
        hostname: app-instance
        pre_build_image: true
        image: registry.example.com/docker_centos_ansible_tests
        network_mode: host

وفقا لذلك، يمكن بعد ذلك أن يكون هؤلاء المضيفين converge.yml يستخدم:

---
- name: Converge all
  hosts: all
  vars:
    ansible_user: root
  roles:
    - role: some_role

- name: Converge db
  hosts: db-instance
  roles:
    - role: some_db_role

- name: Converge app
  hosts: app-instance
  roles:
    - role: some_app_role

مدقق غير قابل للتنفيذ

في الجزيء، من الممكن استخدام ansible للتحقق من تكوين المثيل بشكل صحيح، علاوة على ذلك، كان هذا هو الإعداد الافتراضي منذ الإصدار 3. إنه ليس مرنًا مثل testinfra/inspec، لكن يمكننا التحقق من أن محتويات الملف تتوافق مع توقعاتنا:

---
- name: Verify
  hosts: all
  tasks:
    - name: copy config
      copy:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        mode: "0644"
        owner: root
        group: root
      register: config_copy_result

    - name: Certify that standalone.conf changed
      assert:
        that: not config_copy_result.changed

أو قم بنشر الخدمة وانتظر حتى تصبح متاحة وقم بإجراء اختبار الدخان:

---
  - name: Verify
    hosts: solr
    tasks:
      - command: /blah/solr/bin/solr start -s /solr_home -p 8983 -force
      - uri:
          url: http://127.0.0.1:8983/solr
          method: GET
          status_code: 200
        register: uri_result
        until: uri_result is not failed
        retries: 12
        delay: 10
      - name: Post documents to solr
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

ضع المنطق المعقد في الوحدات والمكونات الإضافية

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

تلخيص النصائح والحيل

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

اختتام

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

روابط

UPD1 2020.05.01 20:30 — للتوصيف الأساسي لكتب اللعب التي يمكنك استخدامها callback_whitelist = profile_tasks لفهم ما يعمل بالضبط لفترة طويلة. ثم نمر كلاسيكيات التسارع غير القابل للتنفيذ. يمكنك أيضًا المحاولة ميتوجين
UPD2 2020.05.03 16:34 - النسخة الإنجليزية

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

كيف تبدأ اختبار Ansible، وتعيد بناء المشروع خلال عام ولا تصاب بالجنون