Како започети тестирање Ансибле-а, рефакторисати пројекат за годину дана и не полудети

Ово је транскрипт представе на ДевОпс-40 2020-03-18:

Почевши од другог урезивања, сваки код постаје наслеђе, јер почетне идеје почињу да одступају од сурове стварности. Ово није ни добро ни лоше, то је датост са којом се тешко расправљати и са којом се мора живети. Део овог процеса је рефакторинг. Рефакторинг инфраструктуре као код. Нека прича почне о томе како рефакторисати Ансибле за годину дана и не полудети.

Рођење наслеђа

Дан #1: Нулти пацијент

Некада је постојао условни пројекат. Имао је развојни тим за програмере и оперативне инжењере. Решавали су исти проблем: како поставити сервере и покренути апликацију. Проблем је био што је сваки тим решавао овај проблем на свој начин. На пројекту је одлучено да се користи Ансибле за синхронизацију знања између Дев и Опс тимова.

Дан #89: Рођење наслеђа

Не примећујући то сами, желели су да то ураде што боље, али се испоставило да је то наслеђе. Како се ово дешава?

• Имамо хитан задатак овде, хајде да урадимо прљави хак па да то поправимо.
• Не морате да пишете документацију и све је јасно шта се овде дешава.
• Знам Ансибле/Питхон/Басх/Терраформ! Види како могу да избегнем!
• Ја сам Фулл Стацк Оверфлов програмер и копирао сам ово са стацковерфлов-а, не знам како то функционише, али изгледа кул и решава проблем.

Као резултат, можете добити неразумљив тип кода за који нема документације, није јасно шта ради, да ли је потребан, али проблем је што га морате развити, модификовати, додати штаке и носаче , чинећи ситуацију још гором.

- 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: Свест о проблему

Првобитно замишљен и имплементиран ИаЦ модел више не испуњава захтеве корисника/пословних/других тимова, а време за измене инфраструктуре престаје да буде прихватљиво. У овом тренутку долази до разумевања да је време за акцију.

ИаЦ рефакторинг

Дан #139: Да ли вам је заиста потребно рефакторисање?

Пре него што пожурите са рефактором, морате одговорити на неколико важних питања:

1. Зашто ти све ово треба?
2. Имате времена?
3. Да ли је знање довољно?

Ако не знате како да одговорите на питања, онда ће се рефакторисање завршити пре него што и почне, или ће се само погоршати. Јер имао искуства ( Шта сам научио тестирањем 200 линија инфраструктурног кода), тада је пројекат добио захтев за помоћ да поправи улоге и покрије их тестовима.

Дан #149: Припрема рефакторинга

Прва ствар је да се припремите. Одлучите шта ћемо урадити. Да бисмо то урадили, комуницирамо, проналазимо проблематична подручја и проналазимо начине да их решимо. Резултујуће концепте некако бележимо, на пример чланак у сразу, тако да када се постави питање „шта је најбоље?“ или "шта је тачно?" Нисмо залутали. У нашем случају, остали смо при идеји завади па владај: разбијамо инфраструктуру на мале комаде/цигле. Овај приступ вам омогућава да узмете изоловани комад инфраструктуре, разумете шта ради, покријете га тестовима и промените без страха да ћете било шта покварити.

Испоставило се да тестирање инфраструктуре постаје камен темељац и овде је вредно поменути пирамиду испитивања инфраструктуре. Потпуно иста идеја која је у развоју, али за инфраструктуру: прелазимо са јефтиних брзих тестова који проверавају једноставне ствари, као што је увлачење, на скупе пуноправне тестове који постављају целу инфраструктуру.

Ансибле покушаји тестирања

Пре него што пређемо на опис како смо покрили Ансибле тестове на пројекту, описаћу покушаје и приступе које сам раније имао прилике да користим како бих разумео контекст донетих одлука.

Дан бр. -997: Одредба СДС-а

Први пут када сам тестирао Ансибле био је на пројекту развоја СДС-а (Софтваре Дефинед Стораге). На ову тему постоји посебан чланак
Како разбити бицикле преко штака када тестирате своју дистрибуцију, али укратко, завршили смо са обрнутом пирамидом тестирања и на тестирање смо потрошили 60-90 минута на једну улогу, што је доста времена. Основа су били е2е тестови, тј. применили смо комплетну инсталацију и потом је тестирали. Оно што је још више отежавало је проналазак сопственог бицикла. Али морам признати да је ово решење функционисало и омогућило стабилно издање.

Дан # -701: Ансибле и тестна кухиња

Развој идеје за тестирање Ансибле-а била је употреба готових алата, односно тест кухиња / кухиња-ци и инспек. Избор је одређен познавањем Руби (за више детаља погледајте чланак на Хабре: Да ли ИМЛ програмери сањају да тестирају Ансибле?) радио брже, око 40 минута за 10 улога. Направили смо пакет виртуелних машина и извршили тестове унутра.

Генерално, решење је функционисало, али је било мало талога због хетерогености. Када је број тестираних људи повећан на 13 основних улога и 2 мета улоге које комбинују мање улоге, онда су одједном тестови почели да трају 70 минута, што је скоро 2 пута дуже. Било је тешко говорити о КСП (екстремном програмирању) пракси јер... нико не жели да чека 70 минута. То је био разлог за промену приступа

Дан # -601: Ансибле и молекул

Концептуално, ово је слично тесткитцхен-у, само што смо преместили тестирање улога на доцкер и променили стек. Као резултат тога, време је смањено на стабилних 20-25 минута за 7 улога.

Повећањем броја тестираних улога на 17 и додавањем 45 улога, извршили смо ово за 28 минута на 2 роба Џенкинса.

Дан #167: Додавање Ансибле тестова у пројекат

Највероватније, задатак рефакторисања неће бити могуће обавити на брзину. Задатак треба да буде мерљив тако да можете да га разбијете на мале комаде и да кашичицом поједете слона комад по део. Мора постојати разумевање да ли се крећете у правом смеру, колико још треба да идете.

Генерално, није битно како ће се то урадити, можете писати на комаду папира, можете ставити налепнице на ормар, можете креирати задатке у Јира, или можете отворити Гоогле документе и записати тренутни статус тамо. Ноге расту од чињенице да процес није непосредан, биће дуг и досадан. Мало је вероватно да неко жели да изгорите од идеја, уморите се и будете преоптерећени током преправљања.

Рефакторисање је једноставно:

• Еат.
• Слееп.
• Код.
• ИаЦ тест.
• понављање

и то понављамо док не дођемо до циљаног циља.

Можда неће бити могуће одмах започети тестирање, па је наш први задатак био да почнемо са линтингом и провером синтаксе.

Дан #181: Мајстор зелене градње

Линтинг је мали први корак ка Греен Буилд Мастер-у. Ово неће сломити скоро ништа, али ће вам омогућити да отклањате грешке у процесима и правите зелене верзије у Јенкинсу. Идеја је развијање навика међу тимом:

• Црвени тестови су лоши.
• Дошао сам да поправим нешто и да у исто време учиним код мало бољим него што је био пре тебе.

Дан #193: Од линтинга до јединичних тестова

Након што сте изградили процес преузимања кода у мастер, можете започети процес побољшања корак по корак - замењујући линтинг улогама за покретање, чак можете то учинити без идемпотенције. Морате да разумете како да примените улоге и како оне функционишу.

Дан #211: Од јединичних до интеграцијских тестова

Када је већина улога покривена јединичним тестовима и све је попуњено, можете прећи на додавање тестова интеграције. Оне. тестирање не једне цигле у инфраструктури, већ њихове комбинације, на пример, пуну конфигурацију инстанце.

Користећи јенкинс, генерисали смо многе фазе које су паралелно повезивале улоге/приручнике, затим тестове јединица у контејнерима и на крају интеграцијске тестове.

Јенкинс + Доцкер + Ансибле = Тестови

1. Наплатите репо и генеришете фазе израде.
2. Паралелно покрените фазе у вези са линт плаибоок-ом.
3. Паралелно покрените фазе улога длачица.
4. Покрени паралелно фазе провере синтаксе.
5. Покрените фазе тестних улога паралелно.
   1. Линт роле.
   2. Проверите зависност од других улога.
   3. Проверите синтаксу.
   4. Креирајте доцкер инстанцу
   5. Покрените молецуле/дефаулт/плаибоок.имл.
   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: Убрзавање тестова

Временом је било више тестова, градње је текло спорије, до сат времена у најгорем случају. На једном од ретро модела била је фраза попут „добро је што постоје тестови, али су спори“. Као резултат тога, напустили смо интеграцијске тестове на виртуелним машинама и прилагодили их за Доцкер да би били бржи. Такође смо заменили тестинфра са ансибле верификатором да бисмо смањили број коришћених алата.

Строго говорећи, постојао је сет мера:

1. Пребаците се на Доцкер.
2. Уклоните тестирање улога, које се дуплира због зависности.
3. Повећајте број робова.
4. Редослед пробног рада.
5. Способност длачица СВЕ локално са једном командом.

Као резултат тога, Пипелине он Јенкинс је такође уједињен

1. Генеришите фазе изградње.
2. Линт све паралелно.
3. Покрените фазе тестних улога паралелно.
4. Финисх.

Научене лекције

Избегавајте глобалне варијабле

Ансибле користи глобалне променљиве, постоји делимично решење у форми привате_роле_варс, али ово није панацеја.

Дозволите ми да вам дам пример. Пустите нас 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}}

Смешно је то што ће резултат књига за игру зависити од ствари које нису увек очигледне, као што је редослед којим су улоге наведене. Нажалост, ово је природа Ансибле-а и најбоља ствар која се може учинити је да се користи нека врста договора, на пример, унутар улоге, користите само променљиву описану у овој улози.

ЛОШЕ: користи глобалну променљиву.

# 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 }}"

Креирајте идемпотентне књиге и улоге

Улоге и игре морају бити идемпотентне, јер смањује померање конфигурације и страх од ломљења нечега. Али ако користите молекул, онда је ово подразумевано понашање.

Избегавајте коришћење модула командне шкољке

Коришћење љуске модула резултира парадигмом императивног описа, уместо декларативне, која је срж Ансибле-а.

Тестирајте своје улоге путем молекула

Молекул је веома флексибилна ствар, хајде да погледамо неколико сценарија.

Молецуле Мултипле инстанцес

В 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

Ансибле верификатор

У молекулу је могуће користити ансибле да проверите да ли је инстанца исправно конфигурисана, штавише, ово је подразумевано од издања 3. Није тако флексибилан као тестинфра/инспец, али можемо да проверимо да ли садржај датотеке одговара нашим очекивањима:

---
- 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

Ставите сложену логику у модуле и додатке

Ансибле заговара декларативни приступ, тако да када радите гранање кода, трансформацију података, модуле љуске, код постаје тежак за читање. Да бисте се борили против овога и да би било једноставно за разумевање, не би било сувишно борити се против ове сложености креирањем сопствених модула.

Сажети савете и трикове

1. Избегавајте глобалне варијабле.
2. Променљиве улоге префикса.
3. Користите контролну променљиву петље.
4. Проверите улазне варијабле.
5. Избегавајте хеш речнике, користите равну структуру.
6. Креирајте идемпотентне књиге и улоге.
7. Избегавајте коришћење модула командне шкољке.
8. Тестирајте своје улоге путем молекула.
9. Ставите сложену логику у модуле и додатке.

Закључак

Не можете једноставно отићи и рефакторирати инфраструктуру на пројекту, чак и ако имате ИаЦ. Ово је дуг процес који захтева стрпљење, време и знање.

линкови

• Слајдови Како тестирати Ансибле и не полудети
• видео Како тестирати Ансибле и не полудети
• Шта сам научио тестирањем 200 линија инфраструктурног кода
• Ансибле: Миграција 120 ВМ конфигурације са Цореос на Центос за 18 месеци
• Како разбити бицикле преко штака када тестирате своју дистрибуцију
• Тестирајте ме да ли можете или да ли ИМЛ програмери сањају да тестирају Ансибле?
• Листа сјајних ИаЦ чланака о тестирању, говора и линкова
• попречни стуб
• Енглеска верзија

УПД1 2020.05.01 20:30 — За примарно профилисање свезака које можете да користите callback_whitelist = profile_tasks да би разумели шта тачно ради дуго времена. Онда пролазимо Класика Ансибле убрзања. Такође можете покушати митоген
УПД2 2020.05.03 16:34 - Енглеска верзија

Извор: ввв.хабр.цом