🥇Ako začať testovať Ansible, zrefaktorovať projekt za rok a nezblázniť sa

Toto je prepis výkony na DevOps-40 2020-03-18:

Počnúc druhým odovzdaním sa akýkoľvek kód stane dedičstvom, pretože počiatočné predstavy sa začínajú rozchádzať s drsnou realitou. To nie je dobré ani zlé, je to danosť, s ktorou sa ťažko polemizuje a treba s ňou žiť. Súčasťou tohto procesu je refaktoring. Refaktoring Infrastructure as Code. Nech sa začne príbeh o tom, ako zrefaktorovať Ansible za rok a nezblázniť sa.

Zrodenie dedičstva

Deň #1: Pacient nula

Bol raz jeden podmienený projekt. Mal vývojový tím Dev a inžinierov Ops. Riešili rovnaký problém: ako nasadiť servery a spustiť aplikáciu. Problém bol v tom, že každý tím riešil tento problém po svojom. V projekte sa rozhodlo použiť Ansible na synchronizáciu znalostí medzi tímami Dev a Ops.

Deň #89: Zrodenie dedičstva

Bez toho, aby si to sami všimli, chceli to urobiť čo najlepšie, ale ukázalo sa, že je to dedičstvo. Ako sa to stane?

Máme tu naliehavú úlohu, urobme špinavý hack a potom to opravíme.
Nemusíte písať dokumentáciu a všetko je jasné, čo sa tu deje.
Poznám Ansible/Python/Bash/Terraform! Pozrite sa, ako sa môžem vyhnúť!
Som Full Stack Overflow Developer a skopíroval som to zo stackoverflow, neviem, ako to funguje, ale vyzerá to dobre a rieši to problém.

Výsledkom je, že môžete získať nezrozumiteľný typ kódu, pre ktorý neexistuje žiadna dokumentácia, nie je jasné, čo robí, či je potrebný, ale problém je, že ho musíte vyvinúť, upraviť, pridať barličky a podpery , čím sa situácia ešte zhoršuje.

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

Deň č. 109: Uvedomenie si problému

Pôvodne koncipovaný a implementovaný IaC model už nezodpovedá požiadavkám používateľov / biznisu / iných tímov a čas na zmeny v infraštruktúre prestáva byť akceptovateľný. V tejto chvíli prichádza pochopenie, že je čas konať.

IaC refaktoring

Deň č. 139: Naozaj potrebujete refaktoring?

Predtým, ako sa vrhnete na refaktor, musíte odpovedať na niekoľko dôležitých otázok:

Prečo toto všetko potrebujete?
Máš čas?
Sú vedomosti dostatočné?

Ak neviete, ako odpovedať na otázky, potom sa refaktoring skončí skôr, ako vôbec začne, alebo sa môže len zhoršiť. Pretože mal skúsenosti ( Čo som sa naučil pri testovaní 200 000 riadkov kódu infraštruktúry), potom projekt dostal žiadosť o pomoc pri oprave rolí a ich pokrytí testami.

Deň #149: Príprava refaktoringu

Prvá vec je pripraviť sa. Rozhodnite sa, čo budeme robiť. Aby sme to dosiahli, komunikujeme, nachádzame problémové oblasti a hľadáme spôsoby, ako ich vyriešiť. Výsledné koncepty nejako zaznamenáme, napríklad článok v konfluencii, takže keď vyvstane otázka „čo je najlepšie?“ alebo "čo je správne?" Nezablúdili sme. V našom prípade sme sa držali myšlienky rozdeľuj a panuj: rozbijeme infraštruktúru na malé kúsky/tehly. Tento prístup vám umožňuje vziať izolovanú časť infraštruktúry, pochopiť, čo robí, pokryť ju testami a zmeniť ju bez strachu, že niečo rozbijete.

Ukazuje sa, že základným kameňom sa stáva testovanie infraštruktúry a tu stojí za zmienku pyramída testovania infraštruktúry. Presne tá istá myšlienka, ktorá je vo vývoji, ale pre infraštruktúru: prechádzame od lacných rýchlych testov, ktoré kontrolujú jednoduché veci, ako je odsadenie, k drahým plnohodnotným testom, ktoré nasadzujú celú infraštruktúru.

Možné pokusy o testovanie

Predtým, ako prejdeme k popisu toho, ako sme na projekte pokrývali testy Ansible, opíšem pokusy a prístupy, ktoré som mal možnosť použiť skôr, aby som pochopil kontext prijatých rozhodnutí.

Deň č. -997: Poskytnutie SDS

Prvýkrát som testoval Ansible na projekte vývoja SDS (Software Defined Storage). Na túto tému existuje samostatný článok
Ako rozbiť bicykle cez barly pri testovaní vašej distribúcie, no skrátka sme skončili pri obrátenej testovacej pyramíde a testovaním sme na jednej úlohe strávili 60-90 minút, čo je dlhá doba. Základom boli testy e2e, t.j. nasadili sme plnohodnotnú inštaláciu a následne otestovali. Čo bolo ešte horšie, bol vynález vlastného bicykla. Ale musím priznať, že toto riešenie fungovalo a umožnilo stabilné vydanie.

Deň # -701: Povolená a testovacia kuchyňa

Rozvinutím myšlienky testovania Ansible bolo použitie hotových nástrojov, konkrétne test kitchen / kitchen-ci a inspec. Výber bol určený znalosťou Ruby (podrobnejšie v článku o Habrém: Snívajú programátori YML o testovaní Ansible?) pracoval rýchlejšie, asi 40 minút pre 10 rolí. Vytvorili sme balík virtuálnych strojov a spustili sme testy vo vnútri.

Vo všeobecnosti roztok fungoval, ale kvôli heterogenite tam bol nejaký sediment. Keď sa počet testovaných ľudí zvýšil na 13 základných rolí a 2 meta roly kombinujúce menšie roly, zrazu začali testy bežať 70 minút, čo je takmer 2-krát dlhšie. Bolo ťažké hovoriť o postupoch XP (extrémne programovanie), pretože... nikto nechce čakať 70 minút. To bol dôvod na zmenu prístupu

Deň # -601: Ansible a molekula

Koncepčne je to podobné ako testkitchen, len sme testovanie rolí presunuli do dockeru a zmenili sme zásobník. Vďaka tomu sa čas skrátil na stabilných 20-25 minút pre 7 rolí.

Zvýšením počtu testovaných rolí na 17 a lintovaním 45 rolí sme to spustili za 28 minút na 2 otrokoch Jenkins.

Deň #167: Pridanie testov Ansible do projektu

S najväčšou pravdepodobnosťou nebude možné vykonať úlohu refaktorovania v zhone. Úloha musí byť merateľná, aby ste ju mohli rozlámať na malé kúsky a slona zjesť po kúskoch lyžičkou. Musí existovať pochopenie, či idete správnym smerom, ako dlho máte ísť.

Vo všeobecnosti je jedno, ako sa to bude robiť, môžete písať na papier, môžete nalepiť nálepky na skriňu, môžete vytvárať úlohy v Jira alebo môžete otvoriť Dokumenty Google a zapísať si aktuálny stav tam. Nohy rastú zo skutočnosti, že proces nie je okamžitý, bude dlhý a únavný. Je nepravdepodobné, že by od vás niekto chcel, aby ste vyhoreli z nápadov, boli unavení a zahltení počas refaktorizácie.

Refaktoring je jednoduchý:

Jesť.
Sleep.
Kód.
IaC test.
opakovať

a toto opakujeme, kým nedosiahneme zamýšľaný cieľ.

Možno nie je možné začať všetko hneď testovať, takže našou prvou úlohou bolo začať s lintingom a kontrolou syntaxe.

Deň #181: Majster zelenej stavby

Lining je prvým malým krokom k Green Build Master. To nepokazí takmer nič, ale umožní vám to ladiť procesy a vytvárať zelené zostavy v Jenkins. Cieľom je rozvíjať návyky v tíme:

Červené testy sú zlé.
Prišiel som niečo opraviť a zároveň urobiť kód o niečo lepším, ako bol pred vami.

Deň č. 193: Od žmolkov po jednotkové testy

Po vybudovaní procesu získavania kódu do hlavného servera môžete začať proces postupného zlepšovania - nahradenie lintingu spúšťacími rolami, dokonca to môžete urobiť bez idempotencie. Musíte pochopiť, ako aplikovať roly a ako fungujú.

Deň #211: Od jednotky k integračným testom

Keď je väčšina rolí pokrytá jednotkovými testami a všetko je podložené, môžete prejsť k pridávaniu integračných testov. Tie. testovanie nie jednej tehly v infraštruktúre, ale ich kombinácie, napríklad konfigurácie plnej inštancie.

Pomocou jenkins sme vygenerovali mnoho fáz, ktoré paralelne prepojili roly/zošity, potom testy jednotiek v kontajneroch a nakoniec integračné testy.

Jenkins + Docker + Ansible = Testy

Pokladňa repo a generovanie fáz zostavovania.
Spustite paralelne fázy lint playbooku.
Spustite paralelne fázy rolovania vlákien.
Paralelne spustite fázy kontroly syntaxe.
Spustite paralelne fázy testovacej roly.
1. Lint role.
2. Skontrolujte závislosť od iných rolí.
3. Skontrolujte syntax.
4. Vytvorte inštanciu dockeru
5. Spustite molekulu/default/playbook.yml.
6. Skontrolujte idempotenciu.
Spustite integračné testy
úprava

Deň č. 271: Autobusový faktor

Spočiatku refaktorovanie vykonávala malá skupina dvoch alebo troch ľudí. Skontrolovali kód v predlohe. Postupom času tím vyvinul znalosti o tom, ako písať kód a kontrola kódu prispela k šíreniu vedomostí o infraštruktúre a jej fungovaní. Vrcholom tu bolo, že recenzenti boli vyberaní jeden po druhom, podľa harmonogramu, t.j. s istou mierou pravdepodobnosti vleziete do novej časti infraštruktúry.

A tu by malo byť pohodlne. Je vhodné urobiť recenziu, vidieť v rámci toho, aká úloha bola vykonaná, a históriu diskusií. Máme integrované jenkins + bitbucket + jira.

Ale ako taká recenzia nie je všeliekom; nejako sme sa dostali do hlavného kódu, čo nás prinútilo prepadnúť testom:

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

Potom to opravili, ale sediment zostal.

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

Deň #311: Urýchlenie testov

Postupom času pribúdalo testov, zostavovania prebiehali pomalšie, v najhoršom prípade až o hodinu. Na jednom z retro filmov bola veta ako „je dobré, že existujú testy, ale sú pomalé“. V dôsledku toho sme opustili integračné testy na virtuálnych počítačoch a upravili sme ich pre Docker, aby bol rýchlejší. Tiež sme nahradili testinfra za ansible verifikátor, aby sme znížili počet používaných nástrojov.

Presne povedané, existoval súbor opatrení:

Prepnúť na dokovaciu stanicu.
Odstráňte testovanie rolí, ktoré je duplikované kvôli závislostiam.
Zvýšte počet otrokov.
Poradie skúšobnej prevádzky.
Schopnosť žmolkovať VŠETKY lokálne jedným príkazom.

Výsledkom bolo zjednotenie Pipeline na jenkins

Vytvorte fázy výstavby.
Lint všetko paralelne.
Spustite paralelne fázy testovacej roly.
Dokončiť.

Ponaučenie

Vyhnite sa globálnym premenným

Ansible používa globálne premenné, vo formulári je čiastočné riešenie private_role_vars, ale toto nie je všeliek.

Uvediem príklad. Nechaj nás mať 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}}

Vtipné je, že výsledok playbookov bude závisieť od vecí, ktoré nie sú vždy zrejmé, ako napríklad poradie, v ktorom sú role uvedené. Bohužiaľ, taká je povaha Ansible a najlepšie, čo sa dá urobiť, je použiť nejaký druh dohody, napríklad v rámci roly použite len premennú opísanú v tejto úlohe.

BAD: použite globálnu premennú.

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

GOOD: V defaults definovať potrebné premenné a neskôr použiť len ich.

# 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

Predpona premenných rolí

BAD: použite globálnu premennú.

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

GOOD: V rolách pre premenné používajte premenné s predponou s názvom roly; pri pohľade na inventár to uľahčí pochopenie toho, čo sa deje.

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

Použite premennú riadenia slučky

BAD: Použite štandardnú premennú v slučkách item, ak je táto úloha/príručka niekde zahrnutá, môže to viesť k neočakávanému správaniu

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

GOOD: Predefinovanie premennej v slučke cez loop_var.

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

Skontrolujte vstupné premenné

Súhlasili sme s používaním prefixov premenných; nebolo by zbytočné kontrolovať, či sú definované tak, ako očakávame a či napríklad neboli prepísané prázdnou hodnotou

GOOD: Skontrolujte premenné.

- 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

Vyhnite sa hashovým slovníkom, používajte plochú štruktúru

Ak rola očakáva v jednom zo svojich parametrov hash/slovník, tak ak chceme zmeniť jeden z podradených parametrov, budeme musieť prepísať celý hash/slovník, čo zvýši zložitosť konfigurácie.

BAD: Použite hash/slovník.

---
user:
  name: admin
  group: admin

GOOD: Použite plochú variabilnú štruktúru.

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

Vytvárajte idempotentné príručky a role

Úlohy a zošity musia byť idempotentné, pretože znižuje posun konfigurácie a strach, že niečo pokazíte. Ale ak použijete molekulu, potom je to predvolené správanie.

Vyhnite sa používaniu modulov príkazového prostredia

Použitie shell modulu vedie k imperatívnej opisnej paradigme namiesto deklaratívnej, ktorá je jadrom Ansible.

Otestujte si svoje úlohy prostredníctvom molekuly

Molekula je veľmi flexibilná vec, pozrime sa na niekoľko scenárov.

Molekula Viacnásobné inštancie

В molecule.yml v sekcii platforms môžete opísať veľa hostiteľov, ktorých môžete nasadiť.

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

Podľa toho potom môžu byť títo hostitelia converge.yml použitie:

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

V molekule je možné pomocou ansible skontrolovať, či je inštancia správne nakonfigurovaná, navyše je to predvolené od vydania 3. Nie je to také flexibilné ako testinfra/inspec, ale môžeme skontrolovať, či obsah súboru zodpovedá našim očakávaniam:

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

Alebo nasaďte službu, počkajte, kým bude k dispozícii, a vykonajte test dymu:

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

Vložte komplexnú logiku do modulov a doplnkov

Ansible obhajuje deklaratívny prístup, takže keď robíte vetvenie kódu, transformáciu údajov, moduly shellu, kód sa stáva ťažko čitateľným. Aby sme tomu zabránili a aby to bolo jednoduché na pochopenie, nebolo by zbytočné bojovať proti tejto zložitosti vytváraním vlastných modulov.

Zhrňte tipy a triky

Vyhnite sa globálnym premenným.
Predpona premenných rolí.
Použite premennú riadenia slučky.
Skontrolujte vstupné premenné.
Vyhnite sa hashovým slovníkom, používajte plochú štruktúru.
Vytvárajte idempotentné príručky a role.
Vyhnite sa používaniu modulov príkazového prostredia.
Otestujte si svoje úlohy prostredníctvom molekuly.
Vložte komplexnú logiku do modulov a doplnkov.

Záver

Nemôžete jednoducho ísť a refaktorovať infraštruktúru na projekte, aj keď máte IaC. Je to dlhý proces, ktorý si vyžaduje trpezlivosť, čas a znalosti.

odkazy

UPD1 2020.05.01 20:30 — Na primárne profilovanie zošitov, ktoré môžete použiť callback_whitelist = profile_tasks aby ste pochopili, čo presne funguje po dlhú dobu. Potom prejdeme Klasika s povoleným zrýchlením. Môžete tiež vyskúšať mitogén
UPD2 2020.05.03 16:34 - Angielski verzia

Zdroj: hab.com

Ako začať testovať Ansible, zrefaktorovať projekt o rok a nezblázniť sa