🥇Kaip pradėti testuoti Ansible, per metus pertvarkyti projektą ir neišprotėti

Tai yra nuorašas spektakliai apie DevOps-40 2020-03-18:

Pradedant nuo antrojo įsipareigojimo, bet koks kodas tampa palikimu, nes pradinės idėjos pradeda skirtis nuo atšiaurios realybės. Tai nėra nei gerai, nei blogai, tai duotybė, su kuria sunku ginčytis ir su juo reikia gyventi. Dalis šio proceso yra pertvarkymas. Infrastruktūros pertvarkymas kaip kodas. Prasideda istorija apie tai, kaip per metus atkurti Ansible ir neišprotėti.

Palikimo gimimas

1 diena: pacientas nulis

Kažkada buvo sąlyginis projektas. Jame buvo „Dev“ kūrimo komanda ir „Ops“ inžinieriai. Jie sprendė tą pačią problemą: kaip įdiegti serverius ir paleisti programą. Problema ta, kad kiekviena komanda šią problemą išsprendė savaip. Projekte buvo nuspręsta naudoti „Ansible“ žinioms sinchronizuoti tarp „Dev“ ir „Ops“ komandų.

89 diena: palikimo gimimas

Patys to nepastebėdami, norėjosi tai padaryti kuo geriau, bet tai pasirodė palikimas. Kaip tai atsitinka?

Turime skubią užduotį, padarykime nešvarų įsilaužimą ir tada sutvarkykime.
Nereikia rašyti dokumentų ir viskas aišku, kas čia vyksta.
Žinau Ansible/Python/Bash/Terraform! Pažiūrėk, kaip aš galiu išsisukti!
Esu Full Stack Overflow Developer ir nukopijavau tai iš stackoverflow, nežinau, kaip tai veikia, bet atrodo šauniai ir išsprendžia problemą.

Dėl to galite gauti nesuprantamo tipo kodą, kuriam nėra dokumentacijos, neaišku, ką jis daro, ar jo reikia, bet problema ta, kad reikia jį sukurti, modifikuoti, pridėti ramentus ir atramas. , dar labiau pablogindamas situaciją.

- 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 diena: problemos suvokimas

Iš pradžių sumanytas ir įgyvendintas IaC modelis nebeatitinka vartotojų/verslo/kitų komandų reikalavimų, o laikas keisti infrastruktūrą nustoja būti priimtinas. Šiuo metu ateina supratimas, kad laikas imtis veiksmų.

IaC pertvarkymas

139 diena: ar jums tikrai reikia pertvarkymo?

Prieš skubėdami į refaktorių, turite atsakyti į keletą svarbių klausimų:

Kam tau viso to reikia?
Ar turi laiko?
Ar pakanka žinių?

Jei nežinote, kaip atsakyti į klausimus, tada pertvarkymas baigsis jam net neprasidėjęs arba gali tik pablogėti. Nes turėjau patirties ( Ką sužinojau išbandęs 200 000 infrastruktūros kodo eilučių), tada projektas sulaukė pagalbos prašymo sutvarkyti vaidmenis ir padengti juos testais.

149 diena: Pasiruošimas pertvarkymui

Pirmas dalykas yra pasiruošimas. Nuspręskite, ką darysime. Norėdami tai padaryti, bendraujame, randame problemines sritis ir sugalvojame jų sprendimo būdus. Gautas sąvokas kažkaip įrašome, pavyzdžiui, straipsnį susiliejant, kad iškilus klausimui „kas yra geriausia? arba "kas teisinga?" Mes nepasiklydome. Mūsų atveju mes laikėmės idėjos skaldyk ir valdyk: suskaidome infrastruktūrą į mažus gabalėlius/plytas. Šis metodas leidžia paimti izoliuotą infrastruktūros dalį, suprasti, ką ji daro, padengti ją testais ir pakeisti, nebijant nieko sugadinti.

Pasirodo, kertiniu akmeniu tampa infrastruktūros testavimas ir čia verta paminėti infrastruktūros testavimo piramidę. Lygiai ta pati idėja, kuri yra kuriama, bet skirta infrastruktūrai: pereiname nuo pigių greitųjų testų, kurie tikrina paprastus dalykus, pavyzdžiui, įdubimą, prie brangių pilnaverčių testų, kurie diegia visą infrastruktūrą.

Galimi bandymai

Prieš pradėdamas apibūdinti, kaip atlikome projekto Ansible testus, aprašysiu bandymus ir metodus, kuriuos turėjau anksčiau panaudoti, kad suprasčiau priimtų sprendimų kontekstą.

Diena Nr. -997: SDS teikimas

Pirmą kartą išbandžiau Ansible vykdydamas SDS (programinės įrangos apibrėžtą saugyklą) kūrimo projektą. Šia tema yra atskiras straipsnis
Kaip sulaužyti dviračius per ramentus bandant savo paskirstymą, bet trumpai tariant, mes gavome apverstą testavimo piramidę ir testuodami vienam vaidmeniui skyrėme 60-90 minučių, o tai yra ilgas laikas. Pagrindas buvo e2e testai, t.y. įdiegėme visavertį įrenginį ir tada jį išbandėme. Dar labiau apsunkino jo paties dviračio išradimas. Tačiau turiu pripažinti, kad šis sprendimas veikė ir leido stabiliai išleisti.

Diena # -701: Galimybė ir bandomoji virtuvė

Ansible testavimo idėja buvo sukurta naudojant paruoštus įrankius, būtent bandomąją virtuvę / virtuvę-ci ir insp. Pasirinkimą lėmė Ruby žinios (daugiau informacijos rasite straipsnyje apie Habré: Ar YML programuotojai svajoja išbandyti Ansible?) dirbo greičiau, apie 40 minučių 10 vaidmenų. Sukūrėme virtualių mašinų paketą ir atlikome testus.

Apskritai tirpalas veikė, tačiau dėl nevienalytiškumo buvo šiek tiek nuosėdų. Kai testuojamų žmonių skaičius buvo padidintas iki 13 pagrindinių vaidmenų ir 2 meta vaidmenų derinant mažesnius vaidmenis, tada staiga testai pradėjo trukti 70 minučių, tai yra beveik 2 kartus ilgiau. Buvo sunku kalbėti apie XP (ekstremalaus programavimo) praktikas, nes... niekas nenori laukti 70 minučių. Tai buvo priežastis pakeisti požiūrį

Diena # -601: Ansible ir molekulė

Konceptualiai tai panašu į testkitchen, tik mes perkėlėme vaidmenų testavimą į docker ir pakeitėme krūvą. Dėl to laikas sutrumpėjo iki stabilių 20-25 minučių 7 vaidmenims.

Padidinę išbandytų vaidmenų skaičių iki 17 ir sukūrę 45 vaidmenis, tai atlikome per 28 minutes su 2 jenkinų vergais.

167 diena: Ansible testų įtraukimas į projektą

Greičiausiai nebus įmanoma atlikti pertvarkymo užduoties paskubomis. Užduotis turi būti išmatuojama, kad galėtumėte ją susmulkinti į mažus gabalėlius ir šaukšteliu po gabalėlį suvalgyti dramblį. Turi būti supratimas, ar judate teisinga linkme, kiek laiko eiti.

Apskritai nesvarbu, kaip tai bus daroma, galite rašyti ant popieriaus, galite lipdukus užklijuoti ant spintos, galite kurti užduotis „Jira“ arba galite atidaryti „Google“ dokumentus ir užsirašyti esamą būseną ten. Kojos auga nuo to, kad procesas vyksta ne iš karto, jis bus ilgas ir varginantis. Mažai tikėtina, kad kas nors norės, kad pertvarkydami perdegtumėte idėjas, pavargtumėte ir pervargtumėte.

Pertvarkymas yra paprastas:

Valgyk.
Miegoti.
Kodas.
IaC testas.
Pakartoti

ir tai kartojame tol, kol pasieksime numatytą tikslą.

Galbūt nepavyks iš karto pradėti visko testuoti, todėl pirmoji mūsų užduotis buvo pradėti nuo linijavimo ir sintaksės patikrinimo.

181 diena: Green Build Master

Linting yra mažas pirmas žingsnis link Green Build Master. Tai beveik nieko nesugadins, bet leis derinti procesus ir kurti žaliąsias Jenkins versijas. Idėja yra ugdyti komandoje įpročius:

Raudoni testai yra blogi.
Atėjau kažko pataisyti ir tuo pačiu padaryti kodą šiek tiek geresnį nei buvo prieš jus.

193 diena: nuo pūkavimo iki vienetų bandymų

Sukūrę kodo įvedimo į pagrindinį įrenginį procesą, galite pradėti žingsnis po žingsnio tobulinimo procesą - pakeisdami pūkelius paleidimo vaidmenimis, netgi galite tai padaryti be idempotencijos. Turite suprasti, kaip taikyti vaidmenis ir kaip jie veikia.

211 diena: nuo padalinio iki integracijos testų

Kai dauguma vaidmenų yra padengti vienetų testais ir viskas yra sugadinta, galite pereiti prie integravimo testų pridėjimo. Tie. tikrinant ne vieną infrastruktūros plytą, o jų derinį, pavyzdžiui, pilną egzemplioriaus konfigūraciją.

Naudodami jenkins sugeneravome daugybę etapų, kurie lygiagrečiai sujungė vaidmenis / žaidimo knygas, tada vienetų testus konteineriuose ir galiausiai integravimo testus.

Jenkins + Docker + Ansible = testai

Patikrinkite atpirkimą ir generuokite kūrimo etapus.
Lygiagrečiai vykdykite pūkelių knygelės etapus.
Lygiagrečiai vykdykite pūkelių vaidmens etapus.
Lygiagrečiai vykdykite sintaksės tikrinimo vaidmens etapus.
Lygiagrečiai vykdykite bandomuosius vaidmens etapus.
1. Pūkuotuko vaidmuo.
2. Patikrinkite priklausomybę nuo kitų vaidmenų.
3. Patikrinkite sintaksę.
4. Sukurkite docker egzempliorių
5. Paleiskite molecule/default/playbook.yml.
6. Patikrinkite idempotenciją.
Vykdykite integravimo testus
apdaila

271 diena: Autobusų faktorius

Iš pradžių refaktorizavimą atliko nedidelė dviejų ar trijų žmonių grupė. Jie peržiūrėjo kodą pagrindiniame kompiuteryje. Laikui bėgant komanda įgijo žinių, kaip rašyti kodą, ir kodo peržiūra prisidėjo prie žinių apie infrastruktūrą ir jos veikimo sklaidos. Svarbiausia čia buvo tai, kad recenzentai buvo atrenkami po vieną, pagal grafiką, t.y. su tam tikra tikimybe pateksite į naują infrastruktūros dalį.

Ir čia turėtų būti patogu. Patogu atlikti apžvalgą, pamatyti, kokios užduoties rėmuose ji buvo atlikta, ir diskusijų istoriją. Mes turime integruotą jenkins + bitbucket + jira.

Tačiau peržiūra nėra panacėja; kažkaip patekome į pagrindinį kodą, kuris privertė mus atlikti flopo testus:

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

Tada jie sutvarkė, bet likučiai liko.

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 diena: bandymų paspartinimas

Laikui bėgant buvo daugiau bandymų, kūrimas vyko lėčiau, blogiausiu atveju iki valandos. Ant vieno iš retro buvo tokia frazė kaip „gerai, kad yra bandymų, bet jie lėti“. Dėl to mes atsisakėme virtualių mašinų integravimo testų ir pritaikėme juos „Docker“, kad jis būtų greitesnis. Taip pat testinfra pakeitėme įmanomu tikrintuvu, kad sumažintume naudojamų įrankių skaičių.

Griežtai tariant, buvo priemonių rinkinys:

Perjungti į dokerį.
Pašalinkite vaidmenų testavimą, kuris pasikartoja dėl priklausomybių.
Padidinkite vergų skaičių.
Bandomojo paleidimo tvarka.
Gebėjimas pūkuoti VISKAS vietoje su viena komanda.

Dėl to „Pupeline on jenkins“ taip pat buvo suvienodintas

Generuokite kūrimo etapus.
Linijuokite viską lygiagrečiai.
Lygiagrečiai vykdykite bandomuosius vaidmens etapus.
Baigti.

Įgyta patirtis

Venkite visuotinių kintamųjų

Ansible naudoja visuotinius kintamuosius, formoje yra dalinis sprendimas private_role_vars, bet tai nėra panacėja.

Pateiksiu pavyzdį. Leiskite mums 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}}

Juokingiausia, kad žaidimų knygelių rezultatas priklausys nuo dalykų, kurie ne visada yra akivaizdūs, pavyzdžiui, vaidmenų išvardijimo tvarka. Deja, tokia yra Ansible prigimtis ir geriausia, ką galima padaryti, yra naudoti tam tikrą susitarimą, pavyzdžiui, vaidmenyje naudoti tik šiame vaidmenyje aprašytą kintamąjį.

BLOGAS: naudokite visuotinį kintamąjį.

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

GERAS: V. defaults apibrėžti reikiamus kintamuosius ir vėliau naudoti tik juos.

# 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

Priešdėlio vaidmens kintamieji

BLOGAS: naudokite visuotinį kintamąjį.

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

GERAS: kintamųjų vaidmenyse naudokite kintamuosius su priešdėliu vaidmens pavadinimu; tai, peržiūrėjus inventorių, padės lengviau suprasti, kas vyksta.

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

Naudokite kilpos valdymo kintamąjį

BLOGAS: kilpose naudokite standartinį kintamąjį item, jei ši užduotis / žaidimų knygelė yra kažkur įtraukta, tai gali sukelti netikėtą elgesį

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

GERAS: iš naujo apibrėžkite kintamąjį cikle per loop_var.

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

Patikrinkite įvesties kintamuosius

Sutikome naudoti kintamuosius priešdėlius; nebūtų nereikalinga patikrinti, ar jie apibrėžti taip, kaip tikimės, ir, pavyzdžiui, ar jų nepaiso tuščia reikšmė

GERAS: Patikrinkite kintamuosius.

- 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

Venkite maišos žodynų, naudokite plokščią struktūrą

Jei vaidmuo tikisi maišos / žodyno viename iš savo parametrų, tada, jei norime pakeisti vieną iš antrinių parametrų, turėsime nepaisyti viso maišos / žodyno, o tai padidins konfigūracijos sudėtingumą.

BLOGAS: Naudokite maišą / žodyną.

---
user:
  name: admin
  group: admin

GERAS: Naudokite plokščią kintamą struktūrą.

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

Kurkite idealias žaidimų knygas ir vaidmenis

Vaidmenys ir žaidimų knygelės turi būti idempotentiškos, nes sumažina konfigūracijos nukrypimą ir baimę ką nors sulaužyti. Bet jei naudojate molekulę, tai yra numatytasis elgesys.

Venkite naudoti komandų apvalkalo modulius

Naudojant apvalkalo modulį, vietoj deklaratyviosios, kuri yra Ansible esmė, atsiranda imperatyvioji aprašymo paradigma.

Išbandykite savo vaidmenis per molekulę

Molekulė yra labai lankstus dalykas, pažvelkime į keletą scenarijų.

Molekulė Keli egzemplioriai

В molecule.yml skyriuje platforms galite apibūdinti daugybę prieglobų, kuriuos galite įdiegti.

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

Atitinkamai, šie šeimininkai gali būti converge.yml naudoti:

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

Galimas tikrintojas

Molekulėje galima naudoti ansible patikrinti, ar egzempliorius sukonfigūruotas teisingai, be to, tai buvo numatytasis nuo 3 leidimo. Tai nėra tokia lanksti kaip testinfra/inspec, bet galime patikrinti, ar failo turinys atitinka mūsų lūkesčius:

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

Arba įdiekite paslaugą, palaukite, kol ji taps prieinama, ir atlikite dūmų testą:

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

Įdėkite sudėtingą logiką į modulius ir papildinius

Ansible pasisako už deklaratyvų požiūrį, todėl kai atliekate kodo šakojimą, duomenų transformavimą, apvalkalo modulius, kodas tampa sunkiai skaitomas. Norint su tuo kovoti ir nesudėtingai suprasti, nebūtų nereikalinga kovoti su šiuo sudėtingumu kuriant savo modulius.

Apibendrinkite patarimus ir gudrybes

Venkite visuotinių kintamųjų.
Priešdėlio vaidmens kintamieji.
Naudokite kilpos valdymo kintamąjį.
Patikrinkite įvesties kintamuosius.
Venkite maišos žodynų, naudokite plokščią struktūrą.
Kurkite idealias žaidimų knygas ir vaidmenis.
Venkite naudoti komandų apvalkalo modulius.
Išbandykite savo vaidmenis per molekulę.
Įdėkite sudėtingą logiką į modulius ir papildinius.

išvada

Negalite tiesiog eiti ir pertvarkyti projekto infrastruktūrą, net jei turite IaC. Tai ilgas procesas, reikalaujantis kantrybės, laiko ir žinių.

Nuorodos

UPD1 2020.05.01 20:30 val – Galite naudoti pirminiam žaidimų knygų profiliavimui callback_whitelist = profile_tasks suprasti, kas tiksliai veikia ilgą laiką. Tada pereiname Ansible pagreičio klasika. Taip pat galite pabandyti mitogenas
UPD2 2020.05.03 16:34 val - Anglų versija

Šaltinis: www.habr.com

Kaip pradėti testuoti Ansible, per metus pertvarkyti projektą ir neišprotėti