Kuidas Ansible testimist alustada, projekt aasta pärast ümber ja mitte hulluks minna

See on ärakiri etendused edasi DevOps-40 2020:

Alates teisest sissekandmisest saab iga kood pärandvaraks, sest esialgsed ideed hakkavad karmist tegelikkusest erinema. See ei ole hea ega halb, see on antud, millele on raske vastu vaielda ja millega tuleb elada. Osa sellest protsessist on refaktoreerimine. Infrastruktuuri ümberkujundamine koodina. Lugu algab sellest, kuidas Ansible aastaga ümber kujundada ja mitte hulluks minna.

Pärandi sünd

Päev nr 1: patsient null

Kunagi oli tinglik projekt. Sellel oli Devi arendusmeeskond ja Opsi insenerid. Nad lahendasid sama probleemi: kuidas servereid juurutada ja rakendusi käivitada. Probleem oli selles, et iga meeskond lahendas selle probleemi omal moel. Projektis otsustati kasutada Ansiblet teadmiste sünkroonimiseks Dev ja Ops meeskondade vahel.

Päev #89: Pärandi sünd

Ise märkamata taheti seda teha võimalikult hästi, kuid see osutus pärandiks. Kuidas see juhtub?

• Meil on siin kiire ülesanne, teeme räpase häkkimise ja siis parandame selle ära.
• Te ei pea dokumente kirjutama ja kõik on selge, mis siin toimub.
• Ma tean Ansible/Python/Bash/Terraform! Vaata, kuidas ma saan kõrvale hiilida!
• Olen Full Stack Overflow Developer ja kopeerisin selle stackoverflow'st, ma ei tea, kuidas see töötab, kuid see näeb lahe välja ja lahendab probleemi.

Selle tulemusena võite saada arusaamatut tüüpi koodi, mille kohta pole dokumentatsiooni, pole selge, mida see teeb, kas seda on vaja, kuid probleem on selles, et peate seda arendama, muutma, lisama kargud ja toed , muutes olukorra veelgi hullemaks.

- 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

Algselt väljamõeldud ja juurutatud IaC-mudel ei vasta enam kasutajate / ettevõtte / muude meeskondade nõuetele ning taristu muudatuste tegemiseks kuluv aeg ei ole enam vastuvõetav. Sel hetkel saabub arusaam, et on aeg tegutseda.

IaC refaktoreerimine

Päev 139: kas vajate tõesti ümbertöötlust?

Enne kui kiirustate refaktorisse, peate vastama mitmele olulisele küsimusele:

1. Miks sa seda kõike vajad?
2. Kas teil on aega?
3. Kas teadmistest piisab?

Kui te ei tea, kuidas küsimustele vastata, siis refaktoreerimine lõpeb enne selle algust või võib see ainult hullemaks minna. Sest kogemus oli ( Mida ma õppisin 200 000 infrastruktuuri koodirea testimisel), siis sai projekti abipalve rollide fikseerimiseks ja testidega katmiseks.

Päev #149: Refaktoreerimise ettevalmistamine

Esimene asi on ette valmistada. Otsustage, mida me teeme. Selleks suhtleme, leiame probleemsed kohad ja mõtleme välja võimalusi nende lahendamiseks. Saadud mõisted salvestame kuidagi, näiteks artikkel kokku, nii et kui tekib küsimus "mis on parim?" või "mis on õige?" Me pole teed eksinud. Meie puhul jäime idee juurde jaga ja valitse: jagame infrastruktuuri väikesteks tükkideks/tellisteks. See lähenemine võimaldab teil võtta eraldatud osa infrastruktuurist, mõista, mida see teeb, katta see testidega ja muuta seda, kartmata midagi lõhkuda.

Selgub, et nurgakiviks saab infrastruktuuri testimine ja siinkohal tasub mainida infrastruktuuri testimise püramiidi. Täpselt sama idee, mis on arenduses, aga taristu jaoks: liigume odavatelt kiirtestidelt, mis kontrollivad lihtsaid asju, näiteks taandumist, kallite täisväärtuslike testide juurde, mis juurutavad kogu infrastruktuuri.

Võimalikud testimiskatsed

Enne kui hakkame kirjeldama, kuidas me projekti Ansible teste hõlmasime, kirjeldan katseid ja lähenemisviise, mida mul oli võimalus varem kasutada, et mõista tehtud otsuste konteksti.

Päev nr -997: SDS-i pakkumine

Esimest korda katsetasin Ansible'i SDS-i (Software Defined Storage) arendamise projekti raames. Sellel teemal on eraldi artikkel
Kuidas oma jaotuse testimisel jalgratast karkude abil lõhkuda, aga kokkuvõttes saime otsapidi tagurpidi testimispüramiidi ja testimisel kulutasime ühe rolli peale 60-90 minutit, mis on pikk aeg. Aluseks olid e2e testid, st. võtsime kasutusele täisväärtusliku installatsiooni ja seejärel testisime seda. Veelgi raskem oli tema enda jalgratta leiutamine. Kuid pean tunnistama, et see lahendus töötas ja võimaldas stabiilset vabastamist.

Päev # -701: Ansible ja katseköök

Ansible testimise idee arenduseks oli valmis tööriistade, nimelt testköök / köök-ci ja inspec kasutamine. Valiku määras Ruby tundmine (lisateavet leiate Habré artiklist: Kas YML-i programmeerijad unistavad Ansible testimisest?) töötas kiiremini, umbes 40 minutit 10 rolli jaoks. Lõime virtuaalmasinate paketi ja tegime sees teste.

Üldiselt lahendus töötas, kuid heterogeensuse tõttu tekkis veidi setteid. Kui testitavate inimeste arv suurendati 13 põhirolli ja 2 metarolli kombineerides väiksemaid rolle, siis järsku hakkasid testid kestma 70 minutit, mis on peaaegu 2 korda pikem. XP (äärmuslik programmeerimine) praktikatest oli raske rääkida, sest... keegi ei taha 70 minutit oodata. See oli põhjus lähenemisviisi muutmiseks

Päev # -601: Ansible ja molekul

Põhimõtteliselt sarnaneb see testkitcheniga, ainult et me kolisime rollitestimise dokkerisse ja muutsime pinu. Selle tulemusena vähenes aeg stabiilselt 20-25 minutini 7 rolli jaoks.

Suurendades testitud rollide arvu 17-ni ja lisades 45 rolli, käivitasime selle 28 minutiga 2 Jenkinsi orja peal.

Päev #167: Ansible testide lisamine projekti

Tõenäoliselt ei ole võimalik kiirelt ümbertöötamise ülesannet täita. Ülesanne peab olema mõõdetav, et saaksid selle väikesteks tükkideks murda ja teelusikaga elevanti tükkhaaval ära süüa. Peab olema arusaam, kas liigud õiges suunas, kui kaua minna.

Üldiselt ei ole vahet, kuidas seda tehakse, võite kirjutada paberile, võite panna kleebised kapile, saate luua ülesandeid Jiras või saate avada Google Docsi ja kirjutada hetkeseisu. seal. Jalad kasvavad sellest, et protsess pole kohene, see on pikk ja tüütu. On ebatõenäoline, et keegi soovib, et te ideedest läbi põleksite, väsiks ja muutuksite ümbertöötamise ajal ülekoormatuks.

Refaktoreerimine on lihtne:

• Sööma.
• Magada.
• Kood.
• IaC test.
• kordus

ja kordame seda seni, kuni saavutame kavandatud eesmärgi.

Kõike ei pruugi kohe katsetama hakata, seega oli meie esimene ülesanne alustada lintimisest ja süntaksi kontrollimisest.

Päev #181: Green Build Master

Linting on väike esimene samm Green Build Masteri poole. See ei riku peaaegu midagi, kuid võimaldab teil Jenkinsis protsesse siluda ja teha rohelisi ehitusi. Idee on arendada meeskonnas harjumusi:

• Punased testid on halvad.
• Tulin midagi parandama ja samal ajal koodi natuke paremaks muutma, kui see oli enne sind.

Päev #193: ebemetest kuni ühikutestideni

Kui olete koodi juhtseadmesse viimise protsessi üles ehitanud, saate alustada samm-sammult täiustamise protsessi - asendades lintide käivitamise rollidega, saate seda teha isegi ilma idempotentsuseta. Peate mõistma, kuidas rolle rakendada ja kuidas need töötavad.

Päev 211: üksusest integratsioonitestideni

Kui enamik rolle on üksusetestidega kaetud ja kõik on risustatud, saate jätkata integratsioonitestide lisamisega. Need. testides mitte ühte taristu tellist, vaid nende kombinatsiooni, näiteks eksemplari täielikku konfiguratsiooni.

Jenkinsi kasutades genereerisime palju etappe, mis lõigasid paralleelselt rollid/näiteraamatud, seejärel ühikutestid konteinerites ja lõpuks integratsioonitestid.

Jenkins + Docker + Ansible = testid

1. Kontrollige repot ja looge ehitusetapid.
2. Käivitage lint mänguraamatu etappe paralleelselt.
3. Käivitage ebeme rollietapid paralleelselt.
4. Käivitage süntaksikontrolli rollietapid paralleelselt.
5. Käivitage testrolli etapid paralleelselt.
   1. Lint roll.
   2. Kontrollige sõltuvust teistest rollidest.
   3. Kontrollige süntaksit.
   4. Dockeri eksemplari loomine
   5. Käivitage molekule/default/playbook.yml.
   6. Kontrollige idempotentsust.
6. Käivitage integratsioonitestid
7. lõpp

Päev #271: Bussitegur

Alguses viis ümbertöötlemist läbi väike kahe- või kolmeliikmeline grupp. Nad vaatasid koodi masteris üle. Aja jooksul arenes meeskond välja teadmisi koodi kirjutamise kohta ja koodi ülevaade aitas kaasa teadmiste levitamisele infrastruktuuri ja selle toimimise kohta. Tipphetk oli siin see, et retsensente valiti ükshaaval, ajakava järgi, s.o. teatud tõenäosusega ronite uude infrastruktuuri.

Ja siin peaks olema mugav. Mugav on teha ülevaadet, vaadata, millise ülesande raames see tehti, ja arutelude ajalugu. Meil on integreeritud jenkins + bitbucket + jira.

Kuid sellisena pole ülevaade imerohi, millegipärast jõudsime põhikoodini, mis pani meid flopi testima:

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

Siis parandati ära, aga jääk jäi alles.

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 311: testide kiirendamine

Aja jooksul oli teste rohkem, ehitused jooksid aeglasemalt, halvimal juhul kuni tund. Ühel retropildil oli lause "hea, et testid on, aga need on aeglased." Seetõttu loobusime virtuaalmasinate integratsioonitestidest ja kohandasime need Dockeri jaoks kiiremaks muutmiseks. Samuti asendasime testinfra võimaliku verifitseerijaga, et vähendada kasutatavate tööriistade arvu.

Rangelt võttes oli meetmete komplekt:

1. Lülituge dokkerile.
2. Eemaldage rollitestimine, mis on sõltuvuste tõttu dubleeritud.
3. Suurendage orjade arvu.
4. Testimise järjekord.
5. Ebestamisvõime KÕIK kohapeal ühe käsuga.

Selle tulemusel ühendati ka jenkinsi Pipeline

1. Loo ehitusetapid.
2. Lint kõik paralleelselt.
3. Käivitage testrolli etapid paralleelselt.
4. Valmis.

Õppetunnid

Vältige globaalseid muutujaid

Ansible kasutab globaalseid muutujaid, vormis on osaline lahendus privaatsed_rolli_vars, kuid see pole imerohi.

Lubage mul tuua teile näide. Laske meil olla 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}}

Naljakas on see, et mänguraamatute tulemus sõltub asjadest, mis ei ole alati ilmsed, näiteks rollide loetlemise järjekord. Kahjuks on see Ansible'i olemus ja parim, mida saab teha, on kasutada mingit kokkulepet, näiteks rolli sees kasutada ainult selles rollis kirjeldatud muutujat.

BAD: kasuta globaalset muutujat.

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

HEA: V defaults defineerida 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

Eesliite rollimuutujad

BAD: kasuta globaalset muutujat.

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

HEA: Kasutage muutujate rollides muutujaid, mille eesliide on rolli nimi; see hõlbustab laoseisu vaadates toimuvat paremini mõista.

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

Kasutage silmuse juhtmuutujat

BAD: Kasutage tsüklites standardmuutujat item, kui see ülesanne/näiteraamat on kuskil kaasas, võib see kaasa tuua ootamatu käitumise

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

HEA: tsükli muutuja ümberdefineerimine via loop_var.

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

Kontrollige sisendmuutujaid

Leppisime kokku muutuvate eesliidete kasutamises; poleks üleliigne kontrollida, kas need on defineeritud nii, nagu me eeldame, ja näiteks neid ei alistaks tühi väärtus

HEA: Kontrollige muutujaid.

- 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

Vältige räsisõnastikke, kasutage lamedat struktuuri

Kui roll eeldab ühes oma parameetris räsi/sõnastikku, siis kui tahame üht alamparameetrit muuta, peame alistama kogu räsi/sõnastiku, mis suurendab konfiguratsiooni keerukust.

BAD: Kasutage räsi/sõnastikku.

---
user:
  name: admin
  group: admin

HEA: Kasutage lamedat muutuvat struktuuri.

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

Loo idempotentsed mänguraamatud ja rollid

Rollid ja mänguraamatud peavad olema idempotentsed, sest vähendab konfiguratsiooni triivi ja hirmu midagi lõhkuda. Kuid kui kasutate molekuli, on see vaikekäitumine.

Vältige käsukesta moodulite kasutamist

Shelli mooduli kasutamine annab deklaratiivse asemel imperatiivse kirjelduse paradigma, mis on Ansible tuum.

Testige oma rolle molekuli kaudu

Molekul on väga paindlik asi, vaatame mõnda stsenaariumi.

Molekul Mitu eksemplari

В molecule.yml jaotises platforms saate kirjeldada paljusid hoste, mida saate juurutada.

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

Vastavalt võivad need hostid olla converge.yml kasutada:

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

Võimalik tõendaja

Molekulis on võimalik kasutada ansible kontrollida, kas eksemplar on õigesti konfigureeritud, pealegi on see olnud vaikimisi alates 3. väljalaskest. See pole nii paindlik kui testinfra/inspec, kuid saame kontrollida, kas faili sisu vastab meie ootustele:

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

Või juurutage teenus, oodake, kuni see on saadaval, ja tehke suitsutest:

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

Pange moodulitesse ja pistikprogrammidesse keeruline loogika

Ansible pooldab deklaratiivset lähenemist, nii et kui teete koodi hargnemist, andmete teisendamist, shellmooduleid, muutub kood raskesti loetavaks. Selle vastu võitlemiseks ja arusaadavaks muutmiseks poleks üleliigne selle keerukusega võidelda oma moodulite loomisega.

Tehke näpunäidete ja nippide kokkuvõte

1. Vältige globaalseid muutujaid.
2. Eesliite rollimuutujad.
3. Kasutage silmuse juhtmuutujat.
4. Kontrollige sisendmuutujaid.
5. Vältige räsisõnastikke, kasutage lamedat struktuuri.
6. Loo idempotentsed mänguraamatud ja rollid.
7. Vältige käsukesta moodulite kasutamist.
8. Testige oma rolle molekuli kaudu.
9. Pange moodulitesse ja pistikprogrammidesse keeruline loogika.

Järeldus

Te ei saa lihtsalt minna ja projekti infrastruktuuri ümber kujundada, isegi kui teil on IaC. See on pikk protsess, mis nõuab kannatlikkust, aega ja teadmisi.

Lingid

• Slaidid Kuidas testida Ansiblet ja mitte hulluks minna
• Video Kuidas testida Ansiblet ja mitte hulluks minna
• Mida ma õppisin 200 000 infrastruktuuri koodirea testimisel
• Võimalik: 120 VM-i konfiguratsiooni migreerimine Coreost Centosesse 18 kuu jooksul
• Kuidas oma jaotuse testimisel jalgratast karkude abil lõhkuda
• Testige mind, kas saate või unistavad YML-i programmeerijad Ansible testimisest?
• Loend vingetest IaC testimise artiklitest, kõnedest ja linkidest
• ristipost
• Angielski versioon

UPD1 2020.05.01 kell 20:30 — Saate kasutada mänguraamatute esmaseks profileerimiseks callback_whitelist = profile_tasks et mõista, mis täpselt töötab pikka aega. Siis läheme läbi Võimalik kiirenduse klassika. Võite ka proovida mitogeen
UPD2 2020.05.03 kell 16:34 - Angielski versioon

Allikas: www.habr.com