How to start testing Ansible, refactor a project in a year, and not lose your mind.

See on tõlgendus esinemisest järgnevaga DevOps-40 2020-03-18:

Alates teisest commit'ist muutub iga kood legacy'ks, kuna algsed ideed hakkavad lahknema karmist reaalsusest. See ei ole hea ega halb, see on fakt, millega on raske vaielda ja millega on vaja koos eksisteerida. Osana sellest protsessist on refaktooring. Refaktooring infrastruktuuri kui koodi. Alustame lugu, kuidas refaktoerida Ansible aasta jooksul ja mitte vaimselt alla jääda.

Legacy tekkimine

Päev № 1: Null patsient

Olid üks projekt. Sellel oli Dev arendusmeeskond ja Ops insenerid. Nad lahendasid sama ülesande: kuidas servereid üles seada ja rakendust käivitada. Probleem oli selles, et iga meeskond lahendas seda ülesannet omamoodi. Projektil otsustati kasutada Ansible'i teadmiste sünkroniseerimiseks Dev ja Ops meeskondade vahel.

Päev № 89: Legacy tekkimine

Ilma et me seda märkaksime, soovisime teha nii hästi kui võimalik, kuid tulemuseks oli legacy. Kuidas see nii juhtub?

• Meil on siin kiire ülesanne, teeme räpaste nipiga — hiljem parandame.
• Dokumentatsiooni ei pea kirjutama, ja nii on kõik selge, mis siin toimub.
• Ma tean Ansible'it / Pythonit / Bashi / Terraformi! Vaata, kuidas ma suudan ennast kokku võtta!
• Ma Full Stack Overflow arendaja kopeerisin selle stackoverflow'ist, ei tea, kuidas see töötab, aga see näeb äge välja ja lahendab ülesande.

Lõpuks võib saada arusaamatut koodi, mille kohta ei ole dokumentatsiooni, ei ole selge, mida see teeb, kas see on vajalik, kuid probleem on see, et peate seda arendama, täiendama, lisama tugistruktuure, halvendades olukorda veel rohkem.

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

Päev № 109: Probleemi teadvustamine

Alguses kavandatud ja ellu viidud IaC mudel lõpetab vastamast kasutajate / äri / teiste meeskondade nõudmistele, aeg, mis kulub infrastruktuuri muutmiseks, ei ole enam vastuvõetav. Sellel hetkel saab selgeks, et on aeg samme astuda.

IaC refaktoreerimine

Päev № 139: Kas teil on tõesti vaja refaktoreerimist?

Enne refaktoreerimisse hüppamist peate vastama mitmele olulisele küsimusele:

1. Miks te seda kõike vajate?
2. Kas teil on aega?
3. Kas teadmised on piisavad?

Kui te ei oska küsimustele vastata, siis lõppeb refaktoreerimine algamata või võib see ainult hullemaks minna. Kuna kokemused on olnud. Mida ma õppisin, testides 200 000 rida infrastruktuuri koodi), siis tuli projektilt abi küsimine rollide korrigeerimiseks ja nende katmiseks testidega.

Päev nr 149: Refaktoreerimise ettevalmistamine

Esimene samm on valmistuda. Määrata, mida me teeme. Selleks suhtleme, leiame probleemsed kohad ja kaalume lahendusviise. Saadud kontseptide kohta fikseerime midagi, näiteks artikli confluence'is, et kui tekib küsimus "kuidas paremini?" või "kuidas õigesti?" ei kaotaks me kurssi. Meie puhul järgisime ideed jaga ja valitse: jagame infrastruktuuri väikesteks tükkideks / tellisteks. Selline lähenemine võimaldab võtta isoleeritud infrastruktuuri osa, mõista, mida see teeb, katab selle testidega ja muuta seda kartmata, et midagi katki läheb.

Seega muutub infrastruktuuri testimine sillaks, ja siin tasub mainida infrastruktuuri testimise püramiidi. Just sama idee nagu arenduses, kuid infrastruktuuri jaoks: liigume odavatelt kiirtestidest, mis kontrollivad lihtsaid asju, näiteks vahemaid, kallimatele täistekstidele, mis juurutavad terviklikku infrastruktuuri.

Ansible'i testimise katsed

Enne kui hakkame kirjeldama, kuidas katsetasime Ansible'it projektis, räägin katsetustest ja lähenemistest, mida varem kasutasin, et mõista otsuste konteksti.

Päev № -997: SDS provision

Esimest korda tuli Ansible'it testida SDS (Software Defined Storage) arendusprojektis. Sellel teemal on eraldi artikkel.
Kuidas katsetada oma distributsiooni saamata samal ajal jalgrataste purunemist, kuid lühidalt öeldes saime pöördepaadi testimise, milleks kulutasime ühe rolli testimisele 60-90 minutit, mis on liiga kaua. Aluseks olid e2e testid, st seadistasime täieliku paigalduse ja seejärel testisime seda. Lisaks raskendas meie enda lahenduse väljamõtlemine. Kuid tuleb tunnistada, et see lahendus töötas ja võimaldas stabiilselt välja anda.

Päev № -701: Ansible ja test kitchen

Ansible'i testimise idee edasiarenduseks sai valmis tööriistade kasutamine, nimelt test kitchen / kitchen-ci ja inspec. Valik põhines Ruby teadmisel (täiendavalt artiklis habras): Kas YML programmeerijad unistavad Ansible'i testimisest?) töötas kiiremini umbes 40 minutit 10 rolli jaoks. Loodime hunniku virtuaalmasinaid ja jooksutasime testid sees.

Kokkuvõttes lahendus töötas, kuid jäi ebamugav tunne segaduse tõttu. Kui suurendasime testitavate hulka 13 põhiteemale ja 2 meta-rolli, mis kombineerisid väiksemaid rolle, hakkasid testid järsku töötama 70 minutit, mis on peaaegu kaks korda kauem. XP (Extreme Programming) praktikate osas oli keeruline rääkida, kuna keegi ei taha 70 minutit oodata. See muutus lähenemise muutmise põhjuseks.

Päev № -601: Ansible ja molecule

Kontseptuaalselt sarnaneb see testkitcheniga, ainult et me viisime rollide testimise dockerisse ja vahetasime stäkki. Tulemusena vähenes aeg stabiilseteks 20-25 minutiks 7 rolli jaoks.

Suurendades testitavate rollide arvu 17-ni ja lintimise 45 rollile, jooksutasime selle 28 minutiga 2 jenkins slave'i peal.

Päev № 167: Lisame projekti Ansible testid

Käigult ülesande refaktoreerimist tõenäoliselt ei õnnestu teha. Ülesanne peab olema mõõdetav, et saaksite selle tükkideks jagada ja elevanti teelusikaga tükkideks süüa. Peab olema arusaam, kas liikute õiges suunas ja kui kaua on veel minna.

Üldiselt pole oluline, kuidas see tehtud saab, võid kirjutada paberile, kleepida post-it märkmeid kapile, luua ülesandeid Jira's, või alustada Google Docs'i ja sinna kirjutada praegune staatus. Probleem on selles, et protsess ei ole hetkeline, see tuleb pikk ja vaevarikas. Vähe tõenäoline, et keegi tahab, et refaktoreerimise ajal kaotaksid sa oma ideed, väsiksid ja loobuksid.

Refaktoreerimine on lihtne:

• Söö.
• Uni.
• Koodi.
• IaC test.
• Korrata.

Ja nii me kordame, kuni saavutame seatud eesmärgid.

Kõike korraga testida ei pruugi õnnestuda, seetõttu oli meie esimeseks ülesandeks alustada lintimise ja süntaksi kontrollimisega.

Päev № 181: Roheline Build Master

Lintimine on väike esimene samm Roheline Build Master'ini. See ei riku suurt midagi, kuid võimaldab protsesse viia paika ja saavutada rohelisi ehitusi Jenkinsis. Idee on arendada meeskonnas harjumusi:

• Punased testid on halvad.
• Kui tuled midagi parandama, tee kood natuke paremaks, kui see oli enne sind.

Päev № 193: Lintimisest unit testideni

Koodi viimisprotsessi seadistamisega saab alustada järk-järgult parandamist – asendada lintimise rollide käivitamisega, isegi ilma idempotentsuseta. Oluline on mõista, kuidas rolle rakendada ja kuidas need töötavad.

Päev № 211: Üksuse testidest integreerimistestide juurde

Kui enamik rolle on kaetud üksustestidega ja kõik on lintitud, saab alustada integreerimistestide lisamisega. See tähendab mitte ainult üksikute komponentide testimist infrastruktuuris, vaid nende kombinatsioonide testimist, näiteks terve instantsi konfiguratsiooni.

Jenkinsis genereerisime palju etappe, mis paralleelselt lintisid rolle / mängubaase, seejärel üksustestid konteinerites ja lõpuks integreerimistestid.

Jenkins + Docker + Ansible = Testid

1. Koormuse kontrollimine ja ehitusetappide genereerimine.
2. Käivitage lintimise mängubaasi etapid paralleelselt.
3. Käivitage lintimise rollide etapid paralleelselt.
4. Käivitage sünteesi kontrollimise rollide etapid paralleelselt.
5. Käivitage testimise rollide etapid paralleelselt.
   1. Lintige roll.
   2. Kontrollige sõltuvust muudest rollidest.
   3. Kontrollige sünteesi.
   4. Looge docker instants.
   5. Käivitage molecule/default/playbook.yml.
   6. Kontrollige idempotentsust.
6. Käivitage integreerimistestid
7. Lõpeta

Päev № 271: Bussifaktor

Alguses tegeles refaktoreerimisega väike inimeste grupp, paar-kolm inimest. Nad tegid koodi ülevaateid masteris. Aja jooksul kujunes meeskonnas välja teadmine, kuidas kirjutada koodi, ning koodide ülevaatus aitas levitada teadmisi infrastruktuuri ja selle toimimise kohta. Erakordne oli see, et ülevaatajad valiti vaheldumisi, graafiku alusel, see tähendab, et teatud tõenäosusega jõudsid sa uude infrastruktuuri ossa.

Siin peab olema mugav. Mugav teha ülevaateid, näha, millise ülesande raames need on tehtud, arutelude ajalugu. Integreerisime jenkins + bitbucket + jira.

Kuid koodide ülevaatus iseenesest ei ole imerohi. Näiteks tuli meil masterisse kood, mis tekitas meile kohati ebausaldusväärseid teste:

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

Kuid see sai hiljem parandatud, kuid mulje jäi.

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

Päev nr 311: Kiirendame teste

Testide aeg on kasvanud, buildid käivad halva juhtumi korral kuni tunni. Ühes tagasivaates oli lause, nagu: "hea, et testid on olemas, aga need on aeglased". Lõpuks loobusime integreerimistest virtuaalmasinatel ning kohandasime need dockerile, et oleks kiirem. Asendasime ka testinfra ansible verifikaatoriga, et vähendada kasutatavate tööriistade arvu.

Rangelt öeldes oli siin kompleks meetmeid:

1. Üleminek dockerile.
2. Eemaldada rollide testimine, mis dubleeritakse sõltuvuste tõttu.
3. Slaidide arvu suurendamine.
4. Testide käivitamise järjekord.
5. Võimalus lintida KÕIK kohalikult ühe käsuga.

Kokkuvõttes ühtlustus ka Jenkins'i Pipeline.

1. Käivita buildi etapid.
2. Lintida kõik paralleelselt.
3. Käivitage testimise rollide etapid paralleelselt.
4. Lõpetada.

Õpitud õppetunnid

Vältida globaalsete muutujate kasutamist

Ansible kasutab globaalseid muutujaid, osaline lahendus on private_role_vars, aga see ei ole imerohi.

Tõin näite. Oletame, et meil on role_a ja 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: tere
  roles:
    - role: role_a
    - role: role_b
  tasks:
    - debug:
        msg: play={{msg}}

Naljakas asjaolu on see, et plaanide tulemus sõltub mitmetest mitte alati ilmsetest asjadest, näiteks rollide loetlemise järjekorrast. Kahjuks on see Ansible'i loomuses ja parim, mida teha saab, on kasutada teatud kokkuleppeid, näiteks kasutada rolli sees ainult neid muutujaid, mis on selles rollis kirjeldatud.

HALB: kasutada globaalseid muutujaid.

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

HEA: A defaults : määrata vajalikud muutujad ja hiljem kasutada ainult neid.

# 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

Eelneva rolli muutujad

HALB: kasutada globaalseid muutujaid.

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

HEA: Rooli sees muutujaid kasutades kasutada muutujad, millel on rolli nime eesliide, et oleks lihtsam aru saada, mis toimub, vaadates inventuuri.

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

Kasuta tsüklit control muutuja

HALB: Kasutada tsüklites standardset muutujat elemendi, kui see ülesanne/plaan on kuskil kaasatud, võib see põhjustada ootamatut käitumist

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

HEA: Ümber määrata muutuja tsüklis läbi loop_var.

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

Kontrolli sisendi muutujad

Oleme kokku leppinud, et kasutame muutujate eeliseid; oleks hea kontrollida, et need on määratletud nagu ootame ja näiteks, et need ei ole tühjaks väärtuseks üle kirjutatud.

HEA: Kontrollige muutujaid.

- name: "Kontrollige, et nõutavad stringimuutujad on määratletud"
  assert:
    that: ahs_var is defined and ahs_var | length > 0 and ahs_var != None
    fail_msg: "{{ ahs_var }} tuleb määrata, et roll töötaks"
    success_msg: "Nõutavad muutujad {{ ahs_var }} on määratletud"
  loop_control:
    loop_var: ahs_var
  with_items:
    - ahs_item1
    - ahs_item2
    - ahs_item3

Vältige hash-dictionary, kasutage tasapinnalist struktuuri.

Kui roll ootab hash/dictionary ühes parameetris, siis kui me soovime muuta ühte alamparameetrit, tuleb meil ümber määrata kogu hash/dictionary, mis suurendab konfigureerimise keerukust.

HALB: Kasutage hash/dictionary.

---
user:
  name: admin
  group: admin

HEA: Kasutage tasapinnalist muutuja struktuuri.

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

Looge idempotentsed mängud ja rollid.

Rollid ja mängud peavad olema idempotentsed, kuna see vähendab konfiguratsiooni hälvet ja hirmu midagi rikkuda. Kuid kui kasutate molecule'i, on see vaikimisi käitumine.

Vältige käsu shell moodulite kasutamist.

Shell mooduli kasutamine viib imperatiivse kirjeldusparadigmini, selle asemel, et deklaratiivne, mis on Ansible'i põhiolemus.

Testige oma rolle via molecule.

Molecule on paindlik lahendus; vaatame mõningaid stsenaariume.

Molecule mitmed instantsid

V molecule.yml jaotises platvormid saab kirjeldada mitmeid hoste, mida turvata.

---
    draiver:
      nimi: docker
    platvormid:
      - nimi: postgresql-instance
        hostinimi: postgresql-instance
        pilt: registry.example.com/postgres10:latest
        eelnevalt_loodud_pilt: jah
        ülekirjutamise_käsk: vale
        võrgu_režiim: host
      - nimi: app-instance
        hostinimi: app-instance
        eelnevalt_loodud_pilt: jah
        pilt: registry.example.com/docker_centos_ansible_tests
        võrgu_režiim: host

Seega neid hoste saab hiljem converge.yml kasutada:

---
- nimi: Ühenda kõik
  hostid: kõik
  muutujad:
    ansible_kasutaja: root
  rollid:
    - roll: some_role

- nimi: Ühenda db
  hostid: db-instance
  rollid:
    - roll: some_db_role

- nimi: Ühenda rakendus
  hostid: app-instance
  rollid:
    - roll: some_app_role

Ansible'i verifikaator

Molecule'is on võimalik kasutada ansible'i, et kontrollida, kas instants on õigesti seadistatud; see on alates 3. versioonist vaikesätetes. See ei ole nii paindlik kui testinfra/inspec, kuid saab kontrollida, kas faili sisu vastab meie ootustele:

---
- nimi: Kinnita
  hostid: kõik
  ülesanded:
    - nimi: kopeeri konfi
      kopeeri:
        src: expected_standalone.conf
        dest: /root/wildfly/bin/standalone.conf
        režiim: "0644"
        omanik: root
        grupp: root
      registreeri: config_copy_result

    - nimi: Kinnita, et standalone.conf muutus
      kinnita:
        et: mitte config_copy_result.changed

Või käivitada teenuse, oodata selle saadavust ja teha smoke test:

---
  - name: Kontrolli
    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: Postita dokumendid solr'i
        command: /blah/solr/bin/post -c master /exampledocs/books.csv

Pane keeruline loogika moodulitesse ja pistikprogrammidesse

Ansible propageerib deklaratiivset lähenemist, seega kui teete koodis harukäike, andmete transformatsioone, shell mooduleid, siis kood muutub raskesti loetavaks. Et selle vastu võidelda ja muuta see arusaadavamaks, on hea praktika seda keerukust ületada oma moodulite loomisega.

Kokkuvõte näpunäidetest ja nippidest

1. Vältige globaalmuutujate kasutamist.
2. Eelista rollimuutujatele eesliiteid.
3. Kasutage tsükli juhtimismuutujat.
4. Kontrollige sisendmuutujaid.
5. Vältige hash-sõnastikke, kasutage staatilist struktuuri.
6. Looge idempotentsed mängukavad ja rollid.
7. Vältige käsurea moodulite kasutamist.
8. Testige oma rolle molekuliga.
9. Pane keeruline loogika moodulitesse ja pistikprogrammidesse.

Kokkuvõte

Ei saa lihtsalt võtta ja refaktoreerida infrastruktuuri projektis, isegi kui teil on IaC. See on pikk protsess, mis nõuab kannatlikkust, aega ja teadmisi.

Lingid

• Esitlused Kuidas testida Ansible't ja mitte hulluks minna
• Video Kuidas testida Ansible't ja mitte hulluks minna
• Mida ma õppisin, testides 200 000 rida infrastruktuuri koodi
• Ansible: Konfiguratsiooni migreerimine 120 VM Coreoselt Centos'ele 18 kuuga
• Kuidas katsetada oma distributsiooni saamata samal ajal jalgrataste purunemist
• Test me if you can, or do YML programmers dream of testing ansible?
• Loetelu suurepärastest IaC testimise artiklitest, kõnelekstidest ja linkidest
• krossipost
• Inglise versioon

UPD1 2020.05.01 20:30 — Esimese plaanide profileerimise jaoks saab kasutada callback_whitelist = profile_tasks et mõista, mis täpselt kaua kestab. Seejärel vaatame üle ansible'i kiirusmeetodid. Saame proovida mitogen
UPD2 2020.05.03 16:34 — Inglise versioon

Allikas: habr.com