🥇چگونه تست Ansible را شروع کنیم، یک پروژه را در یک سال بازسازی کنیم و دیوانه نشویم

این رونوشت است اجراها بر DevOps-40 2020-03-18:

با شروع از commit دوم، هر کدی به میراث تبدیل می شود، زیرا ایده های اولیه شروع به دور شدن از واقعیت خشن می کنند. این نه خوب است و نه بد، این امری است که بحث کردن با آن دشوار است و باید با آن زندگی کرد. بخشی از این فرآیند بازسازی است. بازسازی زیرساخت به عنوان کد. بگذارید داستان درباره اینکه چگونه Ansible را در یک سال بازسازی کنیم و دیوانه نشویم شروع شود.

تولد میراث

روز اول: بیمار صفر

روزی روزگاری یک پروژه مشروط وجود داشت. یک تیم توسعه 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 که در ابتدا تصور و اجرا شد، دیگر نیازهای کاربران / کسب و کار / تیم های دیگر را برآورده نمی کند و زمان ایجاد تغییرات در زیرساخت قابل قبول نیست. در این لحظه، درک می شود که زمان اقدام فرا رسیده است.

بازسازی IaC

روز شماره 139: آیا واقعاً به بازسازی مجدد نیاز دارید؟

قبل از عجله برای Refactor، باید به تعدادی از سوالات مهم پاسخ دهید:

چرا به این همه نیاز دارید؟
وقت داری؟
آیا دانش کافی است؟

اگر نمی‌دانید چگونه به سؤالات پاسخ دهید، آنگاه بازسازی قبل از شروع به پایان می‌رسد یا ممکن است بدتر شود. زیرا تجربه داشتم( آنچه از آزمایش 200 خط کد زیرساخت آموختم، سپس پروژه درخواست کمک برای تعمیر نقش ها و پوشش آنها با آزمایش دریافت کرد.

روز 149: آماده سازی بازسازی

اولین چیز این است که آماده شوید. تصمیم بگیریم که چه کنیم. برای انجام این کار، ما ارتباط برقرار می کنیم، مناطق مشکل را پیدا می کنیم و راه هایی برای حل آنها پیدا می کنیم. ما مفاهیم به دست آمده را به نحوی ضبط می کنیم، به عنوان مثال یک مقاله در تلاقی، به طوری که وقتی این سوال مطرح می شود که "چه چیزی بهتر است؟" یا "کدام درست است؟" ما راه خود را گم نکرده ایم در مورد ما، ما به این ایده پایبند بودیم تفرقه بینداز و حکومت کن: ما زیرساخت را به قطعات کوچک/آجر تقسیم می کنیم. این رویکرد به شما این امکان را می دهد که یک زیرساخت جدا شده را بردارید، بفهمید چه کاری انجام می دهد، آن را با آزمایش بپوشانید و بدون ترس از شکستن چیزی آن را تغییر دهید.

به نظر می رسد که تست زیرساخت سنگ بنا می شود و در اینجا لازم به ذکر است هرم تست زیرساخت. دقیقاً همان ایده ای که در حال توسعه است، اما برای زیرساخت: ما از تست های سریع ارزان قیمت که موارد ساده را بررسی می کند، مانند تورفتگی، به آزمایش های تمام عیار گران قیمت که کل زیرساخت را مستقر می کند، حرکت می کنیم.

تلاش‌های آزمایشی

قبل از اینکه به توضیح چگونگی پوشش تست‌های Ansible روی پروژه بپردازیم، تلاش‌ها و رویکردهایی را شرح خواهم داد که قبلاً فرصت استفاده از آنها را داشتم تا زمینه تصمیمات اتخاذ شده را درک کنم.

روز شماره -997: ارائه SDS

اولین باری که Ansible را آزمایش کردم در پروژه ای برای توسعه SDS (نرم افزار تعریف شده ذخیره سازی) بود. مقاله جداگانه ای در این زمینه وجود دارد
نحوه شکستن دوچرخه ها روی عصا هنگام آزمایش توزیع، اما به طور خلاصه، ما در نهایت به یک هرم تست معکوس رسیدیم و برای آزمایش 60-90 دقیقه برای یک نقش وقت گذاشتیم که زمان زیادی است. اساس تست های e2e بود، یعنی. ما یک نصب کامل اجرا کردیم و سپس آن را آزمایش کردیم. چیزی که بدتر از این بود اختراع دوچرخه خودش بود. اما باید اعتراف کنم، این راه حل کار کرد و اجازه انتشار پایدار را داد.

روز # -701: آشپزخونه قابل تست و تست

توسعه ایده تست Ansible استفاده از ابزارهای آماده، یعنی تست آشپزخانه / آشپزخانه-ci و inspect بود. انتخاب با دانش روبی تعیین شد (برای جزئیات بیشتر به مقاله Habré مراجعه کنید: آیا برنامه نویسان YML رویای آزمایش Ansible را دارند؟) سریعتر کار کرد، حدود 40 دقیقه برای 10 نقش. ما بسته ای از ماشین های مجازی ایجاد کردیم و تست هایی را در داخل آن انجام دادیم.

به طور کلی، محلول کار کرد، اما به دلیل ناهمگونی، مقداری رسوب وجود داشت. هنگامی که تعداد افراد مورد آزمایش به 13 نقش اصلی و 2 نقش متا با ترکیب نقش های کوچکتر افزایش یافت، ناگهان آزمایش ها به مدت 70 دقیقه شروع شد که تقریباً 2 برابر طولانی تر است. صحبت در مورد روش های XP (برنامه نویسی شدید) دشوار بود زیرا ... هیچ کس نمی خواهد 70 دقیقه صبر کند. این دلیل تغییر رویکرد بود

روز # -601: انسیبل و مولکول

از نظر مفهومی، این شبیه به آشپزخانه آزمایشی است، فقط ما تست نقش را به داکر منتقل کردیم و پشته را تغییر دادیم. در نتیجه زمان به 20-25 دقیقه ثابت برای 7 نقش کاهش یافت.

با افزایش تعداد نقش های تست شده به 17 و لینتینگ 45 نقش، این کار را در 28 دقیقه روی 2 jenkins slave اجرا کردیم.

روز شماره 167: افزودن تست های Ansible به پروژه

به احتمال زیاد، انجام کار بازسازی با عجله امکان پذیر نخواهد بود. کار باید قابل اندازه گیری باشد تا بتوانید آن را به قطعات کوچک تقسیم کنید و تکه تکه فیل را با قاشق چایخوری بخورید. باید درک درستی وجود داشته باشد که آیا در مسیر درستی حرکت می کنید، تا چه زمانی باید ادامه دهید.

به طور کلی، مهم نیست که چگونه انجام می شود، می توانید روی یک تکه کاغذ بنویسید، می توانید برچسب ها را روی کمد قرار دهید، می توانید وظایف را در Jira ایجاد کنید، یا می توانید Google Docs را باز کنید و وضعیت فعلی را یادداشت کنید. آنجا. پاها از این واقعیت رشد می کنند که این روند فوری نیست، طولانی و خسته کننده خواهد بود. بعید به نظر می رسد که کسی بخواهد که شما در جریان بازسازی ایده ها خسته شوید، و خسته شوید.

بازسازی مجدد ساده است:

خوردن
خواب.
کد
تست IaC
تکرار

و این کار را تا رسیدن به هدف مورد نظر تکرار می کنیم.

ممکن است نتوان فوراً همه چیز را آزمایش کرد، بنابراین اولین کار ما شروع با لینتینگ و بررسی نحو بود.

روز 181: استاد ساختمان سبز

لینتینگ اولین قدم کوچک به سمت Green Build Master است. این تقریباً هیچ چیز را خراب نمی کند، اما به شما امکان می دهد فرآیندها را اشکال زدایی کنید و در Jenkins بیلدهای سبز ایجاد کنید. ایده این است که عادات را در بین تیم ایجاد کنید:

تست های قرمز بد هستند.
اومدم یه چیزی رو درست کنم و در عین حال کد رو کمی بهتر از قبل کنم.

روز شماره 193: از پرده زدن تا تست واحد

پس از ساختن فرآیند دریافت کد به استاد، می توانید روند بهبود گام به گام را آغاز کنید - جایگزینی پرده با نقش های راه اندازی، حتی می توانید آن را بدون ناتوانی انجام دهید. شما باید بدانید که چگونه نقش ها را اعمال کنید و چگونه کار می کنند.

روز 211: از آزمون واحد تا ادغام

وقتی بیشتر نقش‌ها با تست‌های واحد پوشانده می‌شوند و همه چیز پر شده است، می‌توانید به اضافه کردن تست‌های ادغام بروید. آن ها آزمایش نه یک آجر در زیرساخت، بلکه ترکیبی از آنها، به عنوان مثال، یک پیکربندی نمونه کامل.

با استفاده از جنکین، مراحل بسیاری را ایجاد کردیم که نقش‌ها/کتاب‌های بازی را به صورت موازی پر می‌کردند، سپس تست‌های واحد در کانتینرها و در نهایت تست‌های ادغام.

Jenkins + Docker + Ansible = تست

مخزن را بررسی کنید و مراحل ساخت را ایجاد کنید.
مراحل lint playbook را به صورت موازی اجرا کنید.
مراحل نقش پرز را به صورت موازی اجرا کنید.
مراحل بررسی نقش دستوری را به صورت موازی اجرا کنید.
مراحل نقش تست را به صورت موازی اجرا کنید.
1. نقش پرز.
2. وابستگی به نقش های دیگر را بررسی کنید.
3. نحو را بررسی کنید
4. ایجاد نمونه docker
5. molecule/default/playbook.yml را اجرا کنید.
6. ناتوانی را بررسی کنید
تست های ادغام را اجرا کنید
پایان

روز 271: اتوبوس فاکتور

در ابتدا، بازسازی مجدد توسط یک گروه کوچک دو یا سه نفره انجام می شد. کد را در استاد بررسی کردند. با گذشت زمان، تیم دانش نحوه نوشتن کد و بررسی کد را توسعه داد که به انتشار دانش در مورد زیرساخت و نحوه عملکرد آن کمک کرد. نکته قابل توجه در اینجا این بود که داوران یک به یک بر اساس یک برنامه زمان بندی انتخاب شدند، یعنی. با درجاتی از احتمال، به یک زیرساخت جدید صعود خواهید کرد.

و اینجا باید راحت باشد. انجام یک بررسی، دیدن در چارچوب کاری که انجام شده و تاریخچه بحث ها راحت است. ما jenkins + bitbucket + jira را یکپارچه کرده ایم.

اما به این ترتیب، بررسی یک نوشدارویی نیست؛ به نوعی وارد کد اصلی شدیم که ما را وادار به تست فلاپ کرد:

- 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 جایگزین کردیم تا تعداد ابزارهای مورد استفاده را کاهش دهیم.

به طور دقیق، مجموعه ای از اقدامات وجود داشت:

به داکر تغییر دهید.
تست نقش را که به دلیل وابستگی ها تکراری است حذف کنید.
تعداد بردگان را افزایش دهید.
دستور اجرای آزمایشی
قابلیت پرز زدن همه به صورت محلی با یک دستور

در نتیجه، خط لوله روی جنکینز نیز متحد شد

مراحل ساخت را ایجاد کنید.
همه را به صورت موازی پرز کنید.
مراحل نقش تست را به صورت موازی اجرا کنید.
به پایان برسد.

درس های آموخته شده

از متغیرهای سراسری اجتناب کنید

Ansible از متغیرهای سراسری استفاده می کند، یک راه حل جزئی در فرم وجود دارد خصوصی_نقش_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

خوب: V 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

از دیکشنری های هش خودداری کنید، از ساختار مسطح استفاده کنید

اگر نقشی در یکی از پارامترهای خود انتظار هش/دیکشنری را داشته باشد، اگر بخواهیم یکی از پارامترهای فرزند را تغییر دهیم، باید کل هش/دیکشنری را نادیده بگیریم، که پیچیدگی پیکربندی را افزایش می‌دهد.

بد: از hash/dictionary استفاده کنید.

---
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 از یک رویکرد اعلامی حمایت می کند، بنابراین وقتی شما انشعاب کد، تبدیل داده ها، ماژول های پوسته را انجام می دهید، خواندن کد دشوار می شود. برای مبارزه با این و ساده نگه داشتن آن برای درک، مبارزه با این پیچیدگی با ایجاد ماژول های خود اضافی نخواهد بود.

نکات و ترفندها را خلاصه کنید

از متغیرهای سراسری اجتناب کنید.
متغیرهای نقش پیشوند.
از متغیر کنترل حلقه استفاده کنید.
متغیرهای ورودی را بررسی کنید.
از دیکشنری های هش خودداری کنید، از ساختار مسطح استفاده کنید.
کتاب‌های بازی و نقش‌های بی‌توان ایجاد کنید.
از استفاده از ماژول های پوسته فرمان خودداری کنید.
نقش های خود را از طریق مولکول آزمایش کنید.
منطق پیچیده را در ماژول ها و افزونه ها قرار دهید.

نتیجه

حتی اگر IaC داشته باشید، نمی‌توانید به سادگی به زیرساخت یک پروژه بروید. این یک فرآیند طولانی است که به صبر، زمان و دانش نیاز دارد.

لینک

UPD1 2020.05.01 20:30 - برای نمایه سازی اولیه کتاب های بازی می توانید استفاده کنید callback_whitelist = profile_tasks برای درک اینکه دقیقا چه چیزی برای مدت طولانی کار می کند. سپس عبور می کنیم کلاسیک شتاب غیر قابل تحمل. شما همچنین می توانید امتحان کنید میتوژن
UPD2 2020.05.03 16:34 - نسخه انگلیسی

منبع: www.habr.com

چگونه می توان تست Ansible را شروع کرد، پروژه را در یک سال بازسازی کنید و دیوانه نشوید