איך להתחיל לבדוק את Ansible, לשחזר את הפרויקט בעוד שנה ולא להשתגע

זה התמליל הופעות על DevOps-40 2020-03-18:

החל מה-commit השני, כל קוד הופך למורשת, כי רעיונות ראשוניים מתחילים לסטות מהמציאות הקשה. זה לא טוב ולא רע, זה נתון שקשה להתווכח איתו וצריך לחיות איתו. חלק מתהליך זה הוא עיבוד מחדש. Refactoring תשתית כקוד. שיתחיל הסיפור על איך לחדש את אנסיבל בעוד שנה ולא להשתגע.

הולדת המורשת

יום מס' 1: מטופל אפס

פעם היה פרויקט מותנה. היה לו צוות פיתוח של Dev ומהנדסי Ops. הם פתרו את אותה בעיה: כיצד לפרוס שרתים ולהפעיל אפליקציה. הבעיה הייתה שכל צוות פתר את הבעיה הזו בדרכו שלו. בפרויקט הוחלט להשתמש ב-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 שהוקם והיושם בתחילה אינו עומד עוד בדרישות המשתמשים/עסקים/צוותים אחרים, והזמן לביצוע שינויים בתשתית מפסיק להיות מקובל. ברגע זה מגיעה ההבנה שהגיע הזמן לעשות מעשה.

Refactoring של IaC

יום מס' 139: האם אתה באמת צריך ריפקטור?

לפני שאתה ממהר לחדש, עליך לענות על מספר שאלות חשובות:

1. למה אתה צריך את כל זה?
2. יש לך זמן?
3. האם ידע מספיק?

אם אתה לא יודע איך לענות על השאלות, הריפקטורינג יסתיים עוד לפני שהוא מתחיל, או שהוא עלול רק להחמיר. כי היה ניסיון( מה שלמדתי מבדיקת 200 שורות של קוד תשתית), ואז הפרויקט קיבל בקשה לעזרה לתקן את התפקידים ולכסות אותם במבחנים.

יום מס' 149: הכנת השחזור

הדבר הראשון הוא להכין. תחליט מה נעשה. לשם כך, אנו מתקשרים, מוצאים אזורים בעייתיים ומוצאים דרכים לפתור אותם. אנו רושמים את המושגים המתקבלים איכשהו, למשל מאמר במפגש, כך שכאשר עולה השאלה "מה עדיף?" או "מה נכון?" לא איבדנו את הדרך. במקרה שלנו, דבקנו ברעיון להפריד ולשלוט: אנו מפרקים את התשתית לחתיכות קטנות/לבנים. גישה זו מאפשרת לקחת חלק מבודדת של תשתית, להבין מה היא עושה, לכסות אותה בבדיקות ולשנות אותה מבלי לחשוש לשבור דבר.

מסתבר שבדיקות תשתית הופכות לאבן היסוד וכאן ראוי להזכיר את פירמידת בדיקות התשתית. בדיוק אותו רעיון שנמצא בפיתוח, אבל לתשתית: אנחנו עוברים מבדיקות מהירות זולות שבודקות דברים פשוטים, כמו הזחה, לבדיקות יקרות מן המניין שפורסות את כל התשתית.

ניסיונות בדיקה אפשריים

לפני שנלך לתאר כיצד כיסינו מבחני Ansible בפרויקט, אתאר את הניסיונות והגישות שהייתה לי ההזדמנות להשתמש בהם קודם לכן על מנת להבין את ההקשר של ההחלטות שהתקבלו.

יום מס' -997: מתן SDS

הפעם הראשונה שבדקתי את Ansible הייתה בפרויקט לפיתוח SDS (Software Defined Storage). יש מאמר נפרד בנושא זה
כיצד לשבור אופניים על קביים בעת בדיקת ההפצה שלך, אבל בקיצור, סיימנו עם פירמידת בדיקה הפוכה ובבדיקות הקדשנו 60-90 דקות על תפקיד אחד, שזה הרבה זמן. הבסיס היה מבחני e2e, כלומר. פרסנו התקנה מלאה ולאחר מכן בדקנו אותה. מה שהחמיר עוד יותר היה המצאת האופניים שלו. אבל אני חייב להודות, הפתרון הזה עבד ואפשר שחרור יציב.

יום מס' -701: מטבח אנסיבל ומבחן

הפיתוח של רעיון הבדיקות של Ansible היה שימוש בכלים מוכנים, כלומר test kitchen / kitchen-ci ו-inspect. הבחירה נקבעה על ידי הכרת רובי (לפרטים נוספים, ראה מאמר על Habré: האם מתכנתי YML חולמים לבדוק את Ansible?) עבד מהר יותר, בערך 40 דקות עבור 10 תפקידים. יצרנו חבילה של מכונות וירטואליות והרצנו בפנים בדיקות.

באופן כללי, הפתרון עבד, אבל היה קצת משקעים בגלל הטרוגניות. כאשר מספר האנשים שנבדקו הוגדל ל-13 תפקידים בסיסיים ו-2 תפקידי מטא בשילוב תפקידים קטנים יותר, אז פתאום הבדיקות החלו לרוץ במשך 70 דקות, שזה כמעט פי 2 יותר. היה קשה לדבר על שיטות XP (תכנות קיצוניות) כי... אף אחד לא רוצה לחכות 70 דקות. זו הייתה הסיבה לשינוי הגישה

יום מס' -601: Ansible ומולקולה

מבחינה רעיונית, זה דומה ל-testkitchen, רק שהעברנו את בדיקת התפקידים ל-docker ושינינו את הערימה. כתוצאה מכך, הזמן הצטמצם ליציבות של 20-25 דקות עבור 7 תפקידים.

על ידי הגדלת מספר התפקידים שנבדקו ל-17 והצבת 45 תפקידים, הרצנו את זה תוך 28 דקות על 2 עבדי ג'נקינס.

יום מס' 167: הוספת מבחני Ansible לפרויקט

סביר להניח שלא ניתן יהיה לבצע את משימת החזרה במהירות. המשימה צריכה להיות ניתנת למדידה כדי שתוכלו לשבור אותה לחתיכות קטנות ולאכול את הפיל חלק אחר חלק עם כפית. חייבת להיות הבנה האם אתה מתקדם בכיוון הנכון, כמה עוד צריך ללכת.

באופן כללי, לא משנה איך זה יתבצע, אפשר לכתוב על פיסת נייר, אפשר לשים מדבקות על הארון, אפשר ליצור משימות בג'ירה, או לפתוח גוגל דוקס ולרשום את הסטטוס הנוכחי שם. הרגליים צומחות מהעובדה שהתהליך אינו מיידי, הוא יהיה ארוך ומייגע. אין זה סביר שמישהו רוצה שתשרוף את הרעיונות, תתעייף ותהיה המום במהלך העיבוד מחדש.

השחזור הוא פשוט:

• לאכול.
• לישון.
• לקודד
• מבחן IaC.
• לחזור על

ואנו חוזרים על כך עד שנגיע ליעד המיועד.

אולי לא ניתן להתחיל לבדוק הכל מיד, אז המשימה הראשונה שלנו הייתה להתחיל עם מוך ובדיקת התחביר.

יום מס' 181: Green Build Master

מוך הוא צעד ראשון קטן לקראת Green Build Master. זה לא ישבור כמעט שום דבר, אבל זה יאפשר לך לנפות באגים בתהליכים וליצור בנייה ירוקה בג'נקינס. הרעיון הוא לפתח הרגלים בקרב הצוות:

• בדיקות אדומות זה רע.
• באתי לתקן משהו ובמקביל להפוך את הקוד לקצת יותר טוב ממה שהיה לפניכם.

יום מס' 193: ממוך לבדיקות יחידה

לאחר שבנית את תהליך קבלת הקוד למאסטר, אתה יכול להתחיל בתהליך של שיפור שלב אחר שלב - החלפת מוך בתפקידי השקה, אתה יכול אפילו לעשות את זה ללא אימפוטנציה. אתה צריך להבין איך ליישם תפקידים ואיך הם עובדים.

יום מס' 211: מיחידה למבחני אינטגרציה

כאשר רוב התפקידים מכוסים במבחני יחידה והכל מכוסה מוך, ניתן לעבור להוספת מבחני אינטגרציה. הָהֵן. בדיקת לא לבנה אחת בתשתית, אלא שילוב שלהן, למשל, תצורת מופע מלא.

באמצעות ג'נקינס, יצרנו שלבים רבים שחיברו תפקידים/ספרי משחק במקביל, אחר כך בדיקות יחידות במיכלים, ולבסוף מבחני אינטגרציה.

Jenkins + Docker + Ansible = מבחנים

1. בדוק ריפו ויצירת שלבי בנייה.
2. הפעל את שלבי ספרי המוך במקביל.
3. הפעל שלבי תפקידי מוך במקביל.
4. הפעל את שלבי תפקידי בדיקת התחביר במקביל.
5. הפעל שלבי תפקידי מבחן במקביל.
   1. תפקיד מוך.
   2. בדוק תלות בתפקידים אחרים.
   3. בדוק תחביר.
   4. צור מופע docker
   5. הפעל את molecule/default/playbook.yml.
   6. בדוק אימפוטנציה.
6. הפעל מבחני אינטגרציה
7. סיום

יום מס' 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 Verifier כדי להפחית את מספר הכלים בשימוש.

באופן קפדני, הייתה מערכת של אמצעים:

1. עבור אל docker.
2. הסר את בדיקת התפקידים, המוכפלת עקב תלות.
3. להגדיל את מספר העבדים.
4. סדר ריצת מבחן.
5. יכולת מוך ALL מקומית עם פקודה אחת.

כתוצאה מכך, גם צינור על ג'נקינס היה מאוחד

1. צור שלבי בנייה.
2. מוך הכל במקביל.
3. הפעל שלבי תפקידי מבחן במקביל.
4. סיום.

לקחים שהופק

הימנע ממשתנים גלובליים

Ansible משתמש במשתנים גלובליים, יש פיתרון חלקי בטופס תפקידים_פרטיים, אבל זו לא תרופת פלא.

תן לי לתת לך דוגמה. תן לנו 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

טוב: הגדר מחדש משתנה בלולאה via 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

הימנע ממילוני גיבוב, השתמש במבנה שטוח

אם תפקיד מצפה ל-hash/מילון באחד מהפרמטרים שלו, אז אם נרצה לשנות את אחד מפרמטרי הילד, נצטרך לעקוף את כל ה-hash/מילון, מה שיגדיל את מורכבות התצורה.

רע: השתמש ב-hash/מילון.

---
user:
  name: admin
  group: admin

טוב: השתמש במבנה משתנה שטוח.

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

צור ספרי משחק ותפקידים חסרי עוצמה

תפקידים וספרי משחק חייבים להיות אימפוטנטיים, כי מפחית סחיפה של תצורה ופחד לשבור משהו. אבל אם אתה משתמש במולקולה, אז זו התנהגות ברירת המחדל.

הימנע משימוש במודולים של מעטפת פקודה

שימוש במודול מעטפת מביא לפרדיגמת תיאור ציווי, במקום זו ההצהרתית, שהיא הליבה של 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 תומך בגישה הצהרתית, כך שכאשר אתה עושה הסתעפות קוד, טרנספורמציה של נתונים, מודולי מעטפת, הקוד הופך להיות קשה לקריאה. כדי להילחם בזה ולשמור על זה פשוט להבנה, זה לא יהיה מיותר להילחם במורכבות הזו על ידי יצירת מודולים משלך.

סיכום עצות וטריקים

1. הימנע משתנים גלובליים.
2. משתני תפקיד קידומת.
3. השתמש במשתנה בקרת לולאה.
4. בדוק משתני קלט.
5. הימנע ממילוני גיבוב, השתמש במבנה שטוח.
6. צור ספרי משחק ותפקידים חסרי עוצמה.
7. הימנע משימוש במודולים של מעטפת פקודה.
8. בדוק את התפקידים שלך באמצעות מולקולה.
9. הכנס היגיון מורכב למודולים ותוספים.

מסקנה

אתה לא יכול פשוט ללכת ולחדש את התשתית בפרויקט, גם אם יש לך IaC. זהו תהליך ארוך הדורש סבלנות, זמן וידע.

קישורים

• שקופיות איך לבדוק את Ansible ולא להשתגע
• וִידֵאוֹ איך לבדוק את Ansible ולא להשתגע
• מה שלמדתי מבדיקת 200 שורות של קוד תשתית
• Ansible: העברה של תצורת 120 VM מ-Coreos ל-Centos תוך 18 חודשים
• כיצד לשבור אופניים על קביים בעת בדיקת ההפצה שלך
• בדוק אותי אם אתה יכול או מתכנתי YML חולמים לבדוק את Ansible?
• רשימה של מאמרים, נאומים וקישורים מדהימים לבדיקות IaC
• עמוד צולב
• גרסה אנגלית

UPD1 2020.05.01 20:30 - עבור פרופיל ראשי של ספרי משחק אתה יכול להשתמש callback_whitelist = profile_tasks להבין מה בדיוק עובד לאורך זמן. ואז אנחנו עוברים קלאסיקות האצה אנסיבית. אתה יכול גם לנסות מיטוגן
UPD2 2020.05.03 16:34 - גרסה אנגלית

מקור: www.habr.com