Ansible тестин кантип баштоо керек, долбоорду бир жылдан кийин рефакторлоо жана жинди болбо

Бул стенограмма аткаруулар боюнча DevOps-40 2020:

Экинчи милдеттенмеден баштап, каалаган код мураска айланат, анткени баштапкы идеялар катаал чындыктан алыстап баштайт. Бул жакшы да, жаман да эмес, бул талашуу кыйын жана аны менен жашаш керек берилген нерсе. Бул процесстин бир бөлүгү рефакторинг болуп саналат. Код катары инфраструктураны рефакторинг. Окуяны бир жылдын ичинде Ansible'ди кантип рефакциялоо жана жинди болуп калбоо жөнүндө баштайлы.

мурастын төрөлүшү

№1 күн: Пациент нөл

Бир жолу шарттуу долбоор болгон. Анда Dev иштеп чыгуу тобу жана Ops инженерлери бар болчу. Алар бир эле маселени чечип жатышты: серверлерди кантип жайгаштыруу жана тиркемени иштетүү. Маселе бул маселени ар бир коллектив ез алдынча чечкендигинде болду. Долбоордо Dev жана Ops командаларынын ортосунда билимди синхрондоштуруу үчүн Ansible колдонуу чечими кабыл алынды.

№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-күн: Сизге чындап рефакторинг керекпи?

Рефакторго шашыла электе, бир катар маанилүү суроолорго жооп беришиңиз керек:

1. Мунун баары сага эмне үчүн керек?
2. Убактыңыз барбы?
3. Билим жетиштүүбү?

Эгерде сиз суроолорго кантип жооп берүүнү билбесеңиз, анда рефакторинг али баштала электе бүтөт, же андан да начарлап кетиши мүмкүн. Анткени тажрыйбасы бар ( 200 000 линия инфраструктуралык кодду сынап көрүүдөн эмнени билдим), андан кийин долбоор ролдорду оңдоого жана аларды тесттер менен жабууга жардам сурап кайрылды.

№149-күн: Рефакторингди даярдоо

Биринчи нерсе - даярдоо. Эмне кылаарыбызды чечиңиз. Бул үчүн биз баарлашабыз, көйгөйлүү жерлерди таап, аларды чечүүнүн жолдорун аныктайбыз. Биз пайда болгон концепцияларды кандайдыр бир жол менен жазабыз, мисалы, макаланы бириктирип, “эмнеси жакшы?” деген суроо жаралганда. же "кайсысы туура?" Биз жолубуздан адашкан жокпуз. Биздин учурда биз идеяга жабышып калдык бөлүү жана башкаруу: биз инфраструктураны майда бөлүктөргө/кирпичтерге бөлөбүз. Бул ыкма сизге инфраструктуранын обочолонгон бөлүгүн алып, анын эмне кыларын түшүнүүгө, аны тесттер менен жабууга жана эч нерсени бузуп алуудан коркпостон өзгөртүүгө мүмкүндүк берет.

Көрсө, инфраструктуралык тестирлөө негизи болуп калат жана бул жерде инфраструктураны тестирлөө пирамидасы жөнүндө сөз кылуу керек. Дал ушул эле идея иштелип чыгууда, бирок инфраструктура үчүн: биз жөнөкөй нерселерди текшерген арзан тез тесттерден, мисалы, чегинүүлөрдү, бүт инфраструктураны жайылткан кымбат толук кандуу сыноолорго өтүп жатабыз.

Акылдуу сыноо аракеттери

Долбоор боюнча Ansible тесттерин кантип өткөргөнүбүздү сүрөттөөгө барардан мурун, мен кабыл алынган чечимдердин контекстин түшүнүү үчүн мурда колдонууга мүмкүнчүлүк болгон аракеттерди жана ыкмаларды сүрөттөп берем.

Күн № -997: SDS менен камсыз кылуу

Мен Ansibleди биринчи жолу SDS (Программалык камсыздоо аныкталган сактагыч) иштеп чыгуу долбоорунда сынап көрдүм. Бул тема боюнча өзүнчө макала бар
Бөлүштүрүүнү сынап жатканда балдактардын үстүнөн велосипеддерди кантип сындырса болот, бирок кыскасы, биз тескери тестирлөө пирамидасы менен аяктадык жана тестирлөө биз бир ролго 60-90 мүнөт жумшадык, бул көп убакыт. Негизги e2e тесттери болгон, б.а. биз толук кандуу орнотууну орнотуп, анан аны сынап көрдүк. Андан да оорлогон нерсе - өзүнүн велосипедин ойлоп тапканы. Бирок моюнга алышым керек, бул чечим иштеген жана туруктуу чыгарууга мүмкүндүк берген.

Күн # -701: Ansible жана сыноо ашкана

Ansible тестирлөө идеясын иштеп чыгуу даяр шаймандарды колдонуу болду, тактап айтканда, ашкана / ашкана-ci жана текшерүү. Тандоо Ruby билими менен аныкталды (көбүрөөк маалымат алуу үчүн Habré жөнүндө макаланы караңыз: YML программисттери Ansible сынап көрүүнү кыялданабы?) тезирээк, 40 ролго 10 мүнөттөй иштеген. Виртуалдык машиналардын пакетин түзүп, ичинде тесттерди өткөрдүк.

Жалпысынан алганда, чечим иштеген, бирок гетерогендиктен улам бир аз чөкмө бар. Сыналган адамдардын саны 13 негизги ролго жана кичирээк ролдорду бириктирген 2 мета ролго чейин көбөйгөндө, күтүлбөгөн жерден тесттер 70 мүнөткө иштей баштады, бул дээрлик 2 эсе көп. XP (экстремалдуу программалоо) практикалары жөнүндө айтуу кыйын болду, анткени... эч ким 70 мүнөт күткүсү келбейт. Бул мамилени өзгөртүүгө себеп болгон

Күн # -601: Ansible жана молекула

Концепция боюнча, бул testkitchenге окшош, болгону биз ролдук тестирлөөнү докерге өткөрүп, стекти өзгөрттүк. Жыйынтыгында 20 роль үчүн убакыт туруктуу 25-7 мүнөткө чейин кыскарган.

Сыналган ролдордун санын 17ге чейин көбөйтүү жана 45 ролду кошуу менен биз муну 28 Дженкинс кулунда 2 мүнөттө аткардык.

№167 күн: Долбоорго Ansible тесттерин кошуу

Кыязы, рефакторинг тапшырмасын шашылыш аткаруу мүмкүн эмес. Тапшырма өлчөөчү болушу керек, аны майда бөлүктөргө бөлүп, пилди чай кашык менен бөлүк-бөлүк жей аласыз. Сиз туура багытта бара жатасызбы, канча убакыт барыш керек деген түшүнүк болушу керек.

Вообще кандай жасалат эч кандай мааниге ээ эмес, кагазга жазып койсонуз болот, шкафка стикерлер чаптасаныз болот, Жирада тапшырмаларды тузсонуз болот же Google Docs ачып азыркы абалын жазып койсонуз болот. ошол жерде. Процесс дароо болбогондуктан буттар өсөт, ал узак жана түйшүктүү болот. Рефакторинг учурунда сиздин идеяларыңыз түгөнүп, чарчап, чөгүп кетишиңизди эч ким каалабашы күмөн.

Рефакторинг жөнөкөй:

• Жегиле.
• Уйку.
• Code.
• IaC тести.
• кайтолоо

жана биз көздөгөн максатка жеткенче муну кайталайбыз.

Баарын дароо сынап баштоо мүмкүн эмес болушу мүмкүн, андыктан биздин биринчи милдетибиз синтаксисти текшерүүдөн баштоо болду.

№181 күн: Жашыл курулуш мастери

Linting Green Build Master карай кичинекей биринчи кадам болуп саналат. Бул дээрлик эч нерсени бузбайт, бирок процесстерди оңдоого жана Дженкинсте жашыл курулуштарды жасоого мүмкүндүк берет. Идея команда арасында адаттарды өнүктүрүү болуп саналат:

• Кызыл тесттер жаман.
• Мен бир нерсени оңдоп, ошол эле учурда кодду сизге чейинкиден бир аз жакшыраак кылуу үчүн келдим.

№193 күн: линтингден бирдик сыноолорго чейин

Кодду мастерге алуу процессин куруп, сиз этап-этабы менен өркүндөтүү процессин баштасаңыз болот - линтингди ишке киргизүүчү ролдор менен алмаштыруу, сиз аны идемпотентсиз эле жасай аласыз. Сиз ролдорду кантип колдонууну жана алар кантип иштээрин түшүнүшүңүз керек.

№211-күн: Бирдиктен интеграциялык тесттерге

Көпчүлүк ролдор бирдик тесттери менен камтылганда жана бардыгы сызылганда, сиз интеграциялык тесттерди кошууга өтсөңүз болот. Ошол. инфраструктурада бир кирпичти эмес, алардын комбинациясын, мисалы, толук инстанция конфигурациясын сыноо.

Дженкиндерди колдонуп, биз параллелдүү ролдорду/ойнотуу китептерин камтыган көптөгөн этаптарды, андан кийин контейнерлерде бирдик тесттерин жана акырында интеграциялык тесттерди түздүк.

Дженкинс + Докер + Ansible = Тесттер

1. Репо текшерүү жана куруу этаптарын түзүү.
2. Линт оюн китебинин этаптарын параллелдүү иштетиңиз.
3. Линт ролунун этаптарын параллелдүү иштетиңиз.
4. Синтаксистин ролун текшерүү баскычтарын параллелдүү иштетиңиз.
5. Сыноо ролунун этаптарын параллелдүү иштетиңиз.
   1. Линт ролу.
   2. Башка ролдорго көз карандылыкты текшерүү.
   3. Синтаксисти текшерүү.
   4. Докер инстанциясын түзүү
   5. Run molecule/default/playbook.yml.
   6. Импотенцияны текшерүү.
6. Интеграция тесттерин иштетиңиз
7. бүтүрүү

№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 verifier менен алмаштырдык.

Тактап айтканда, бир катар чаралар бар:

1. Докерге которулуу.
2. Көз карандылыктан улам кайталанган ролду сыноону алып салыңыз.
3. кулдардын санын кебейтуу.
4. Сыноо жүргүзүү тартиби.
5. түктүү жөндөмдүүлүгү БААРЫ бир буйрук менен жергиликтүү.

Натыйжада, Jenkins боюнча Pipeline да бирдиктүү болду

1. Куруу этаптарын түзүү.
2. Бардык параллелдүү линт.
3. Сыноо ролунун этаптарын параллелдүү иштетиңиз.
4. Finish.

тажрыйба

Глобалдык өзгөрмөлөрдөн качыңыз

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

ЖАКШЫ: 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

Хэш сөздүктөрдөн качыңыз, жалпак түзүлүштү колдонуңуз

Эгерде роль анын параметрлеринин биринде хэш/сөздүктү күтсө, анда биз бала параметрлердин бирин өзгөрткүбүз келсе, анда биз бүт хэшти/сөздүктү жокко чыгарышыбыз керек, бул конфигурациянын татаалдыгын жогорулатат.

ЖАМАН: Хэш/сөздүктү колдонуңуз.

---
user:
  name: admin
  group: admin

ЖАКШЫ: Жалпак өзгөрмө түзүмүн колдонуңуз.

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

Идемпотенттүү ойноо китептерин жана ролдорду түзүңүз

Ролдор жана оюн китептери идемпотенттүү болушу керек, анткени конфигурациянын өзгөрүшүн жана бир нерсени бузуп алуу коркунучун азайтат. Бирок, эгер сиз молекуланы колдонсоңуз, анда бул демейки жүрүм-турум.

Команда кабыкчасынын модулдарын колдонуудан качыңыз

Shell модулун колдонуу Ansibleдин өзөгү болгон декларативдик эмес, императивдик сүрөттөмө парадигмасына алып келет.

Молекула аркылуу ролдоруңузду сынап көрүңүз

Молекула абдан ийкемдүү нерсе, келгиле, бир нече сценарийди карап көрөлү.

Molecule Көптөгөн инстанциялар

В 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 текшерүүчү

Молекулада инстанциянын туура конфигурацияланганын текшерүү үчүн 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 сынап көрүш керек жана жинди болбо
• Video Кантип Ansible сынап көрүш керек жана жинди болбо
• 200 000 линия инфраструктуралык кодду сынап көрүүдөн эмнени билдим
• Ansible: 120 айдын ичинде 18 VM конфигурациясынын Coreos'дон Centos'ка көчүрүлүшү
• Бөлүштүрүүнү сынап жатканда балдактардын үстүнөн велосипеддерди кантип сындырса болот
• Эгер мүмкүн болсо, мени сынап көрүңүз же YML программисттери Ansible сынап көрүүнү кыялданабы?
• IaC тестирлөө боюнча укмуштуудай макалалардын, баяндамалардын жана шилтемелердин тизмеси
• кайчылаш пост
• Кыргызча версия

UPD1 2020.05.01 20:30 — Оюн китептерин баштапкы профилдөө үчүн сиз колдоно аласыз callback_whitelist = profile_tasks так узак убакыт бою эмне иштээрин түшүнүү үчүн. Андан кийин өтүп кетебиз Классикалык акселерация. Сиз дагы аракет кылсаңыз болот митоген
UPD2 2020.05.03 16:34 - Кыргызча версия

Source: www.habr.com