Hogyan kezdjük el az Ansible tesztelését, egy éven belül alakítsuk újra a projektet, és ne őrüljünk meg

Ez az átirat előadások on DevOps-40 2020-03-18:

A második véglegesítéstől kezdve minden kód örökölt lesz, mert a kezdeti elképzelések kezdenek eltérni a rideg valóságtól. Ez se nem jó, se nem rossz, ez olyan adottság, amivel nehéz vitatkozni, és élni kell vele. Ennek a folyamatnak a része a refaktorálás. Az infrastruktúra újrafaktorálása kódként. Kezdődjön a történet azzal, hogy hogyan lehet Ansible-t egy év alatt átformálni, és nem kell megőrülni.

Az örökség születése

1. nap: Nulladik beteg

Volt egyszer egy feltételes projekt. Volt benne egy Dev fejlesztőcsapat és az Ops mérnökei. Ugyanazt a problémát oldották meg: hogyan kell telepíteni a szervereket és futtatni egy alkalmazást. A probléma az volt, hogy minden csapat a maga módján oldotta meg ezt a problémát. A projekt során úgy döntöttek, hogy az Ansible segítségével szinkronizálják a tudást a Dev és az Ops csapatok között.

89. nap: Az örökség születése

Anélkül, hogy maguk észrevették volna, a lehető legjobban akarták csinálni, de kiderült, hogy örökség. Hogyan történik ez?

• Sürgős dolgunk van itt, csináljunk egy piszkos feltörést, majd javítsuk ki.
• Nem kell dokumentációt írnia, és minden világos, mi folyik itt.
• Ismerem az Ansible/Python/Bash/Terraformot! Nézd, hogyan tudok kitérni!
• Full Stack Overflow fejlesztő vagyok, és ezt a stackoverflow-ból másoltam, nem tudom, hogyan működik, de jól néz ki, és megoldja a problémát.

Ennek eredményeként egy olyan értelmezhetetlen típusú kódot kaphat, amelyhez nincs dokumentáció, nem világos, hogy mit csinál, szükség van-e rá, de a probléma az, hogy fejleszteni kell, módosítani kell, mankókat és támasztékokat kell hozzáadni. , ami még rosszabbá teszi a helyzetet.

- 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. nap: A probléma tudatosítása

Az eredetileg kigondolt és megvalósított IaC-modell már nem felel meg a felhasználók/üzleti/más csapatok követelményeinek, és az infrastruktúra változtatásának ideje már nem elfogadható. Ebben a pillanatban jön a megértés, hogy ideje cselekedni.

IaC refaktorálás

139. nap: Valóban szükséged van a refaktorálásra?

Mielőtt nekivágna a refaktornak, meg kell válaszolnia néhány fontos kérdést:

1. Miért van szüksége mindezekre?
2. Van időd?
3. Elég a tudás?

Ha nem tudja, hogyan válaszoljon a kérdésekre, akkor a refaktorálás véget ér, mielőtt elkezdődne, vagy csak rosszabb lesz. Mert volt tapasztalat ( Amit 200 000 infrastruktúra-kódsor teszteléséből tanultam), majd a projekthez segítségkérés érkezett a szerepek rögzítéséhez és tesztekkel való lefedéséhez.

149. nap: A refaktorálás előkészítése

Az első dolog az előkészítés. Döntse el, mit fogunk tenni. Ennek érdekében kommunikálunk, megtaláljuk a problémás területeket és kitaláljuk a megoldási módokat. Az így kapott fogalmakat valahogy rögzítjük, például egy cikkben egybefolyóan, hogy amikor felmerül a kérdés, hogy „mi a legjobb?” vagy "melyik a helyes?" Nem tévedtünk el. A mi esetünkben ragaszkodtunk a gondolathoz Oszd meg és uralkodj: apró darabokra/téglákra bontjuk az infrastruktúrát. Ez a megközelítés lehetővé teszi, hogy egy elszigetelt infrastruktúra-darabot vegyen fel, megértse, mit csinál, tesztelje le, és változtassa meg anélkül, hogy félne attól, hogy bármi is elromlik.

Kiderült, hogy az infrastruktúra tesztelése válik a sarokkővé, és itt érdemes megemlíteni az infrastruktúra tesztelési piramist. Pontosan ugyanaz az ötlet, ami fejlesztés alatt van, de az infrastruktúrára: az olcsó, egyszerű dolgokat, például a behúzást ellenőrző gyorstesztekről áttérünk a költséges, teljes értékű tesztekre, amelyek a teljes infrastruktúrát telepítik.

Lehetséges tesztelési kísérletek

Mielőtt leírnánk, hogy miként dolgoztuk fel az Ansible teszteket a projektben, leírom azokat a próbálkozásokat és megközelítéseket, amelyeket korábban alkalmam volt alkalmazni a meghozott döntések kontextusának megértése érdekében.

-997. sz. nap: SDS rendelkezés

Az Ansible-t először egy SDS (Software Defined Storage) fejlesztési projekten teszteltem. Erről a témáról van egy külön cikk
Hogyan törje össze a kerékpárokat mankóval az elosztás tesztelésekor, de röviden egy fordított tesztelési piramis lett a vége, és a tesztelés során 60-90 percet töltöttünk egy szerepre, ami hosszú idő. Az alap e2e tesztek voltak, i.e. teljes értékű telepítést telepítettünk, majd teszteltük. Ami még súlyosabb volt, az a saját kerékpár feltalálása. De be kell vallanom, ez a megoldás működött, és lehetővé tette a stabil megjelenést.

# -701. nap: Alkalmas és tesztkonyha

Az Ansible tesztelési ötlet kidolgozása kész eszközök, azaz tesztkonyha/konyha-ci és inspec felhasználása volt. A választást a Ruby ismerete határozta meg (további részletekért lásd a Habréról szóló cikket: Az YML programozók álmodoznak az Ansible teszteléséről?) gyorsabban működött, körülbelül 40 percet 10 szerepre. Létrehoztunk egy csomagot virtuális gépekből, és teszteket futtattunk benne.

Általában az oldat működött, de a heterogenitás miatt volt némi üledék. Amikor a teszteltek számát 13 alapszerepre és 2 kisebb szerepkört kombináló metaszerepre növeltük, akkor hirtelen 70 percig kezdtek futni a tesztek, ami majdnem 2-szer hosszabb. Nehéz volt XP (extrém programozási) gyakorlatokról beszélni, mert... senki sem akar 70 percet várni. Ez volt az oka a szemléletváltásnak

# -601. nap: Ansible és molekula

Elvileg ez hasonló a testkitchenhez, csak a szereptesztelést áthelyeztük a dockerbe, és megváltoztattuk a veremet. Ennek eredményeként az idő stabilan 20-25 percre csökkent 7 szerepre.

A tesztelt szerepkörök számát 17-re növelve és 45 szereppel kiegészítve ezt 28 perc alatt lefuttattuk 2 jenkins rabszolgán.

167. nap: Ansible tesztek hozzáadása a projekthez

Valószínűleg nem lehet sietve elvégezni a refaktorálási feladatot. A feladatnak mérhetőnek kell lennie, hogy apró darabokra bontsa, és egy teáskanállal darabonként meg tudja enni az elefántot. Meg kell értened, hogy jó irányba haladsz-e, meddig kell elmenned.

Általában nem mindegy, hogy hogyan készül, írhatsz egy papírra, matricákat tehetsz a szekrényre, készíthetsz feladatokat a Jira-ban, vagy megnyithatod a Google Dokumentumokat és felírhatod az aktuális állapotot ott. A lábak attól nőnek, hogy a folyamat nem azonnali, hosszú és fárasztó lesz. Nem valószínű, hogy valaki azt akarja, hogy kiégjen az ötletekből, elfáradjon, és túlterheltté váljon a refaktorálás során.

A refaktorálás egyszerű:

• Eszik.
• Aludj.
• Kód.
• IaC teszt.
• ismétlés

és ezt addig ismételjük, amíg el nem érjük a kitűzött célt.

Lehet, hogy nem lehet mindent azonnal elkezdeni tesztelni, ezért az első feladatunk az volt, hogy a lintinggel és a szintaxis ellenőrzésével kezdjük.

181. nap: Green Build Master

A Linting egy kis első lépés a Green Build Master felé. Ezzel szinte semmit nem tönkretesz, de lehetővé teszi a folyamatok hibakeresését és zöld buildek készítését a Jenkinsben. Az ötlet a szokások kialakítása a csapatban:

• A piros tesztek rosszak.
• Azért jöttem, hogy kijavítsak valamit, és egyúttal egy kicsit jobbá tegyem a kódot, mint korábban volt.

193. nap: A szöszöléstől az egységtesztekig

Miután felépítette a kód mesterbe kerülésének folyamatát, megkezdheti a lépésről lépésre történő fejlesztést - a lintinget elindító szerepekkel helyettesítve, akár idempotencia nélkül is megteheti. Meg kell értenie, hogyan alkalmazza a szerepeket és hogyan működik.

211. nap: Az egységtől az integrációs tesztekig

Ha a legtöbb szerepkört egységtesztek fedik le, és minden hibás, akkor továbbléphet az integrációs tesztek hozzáadására. Azok. nem egyetlen téglát tesztelünk az infrastruktúrában, hanem ezek kombinációját, például egy teljes példánykonfigurációt.

A jenkins segítségével számos szakaszt generáltunk, amelyek párhuzamosan sorakoztak a szerepkörökben/játékkönyvekben, majd egységteszteket konténerekben, végül pedig integrációs teszteket.

Jenkins + Docker + Ansible = Tesztek

1. Ellenőrizze a repót, és hozzon létre összeállítási szakaszokat.
2. Futtassa párhuzamosan a lint játékkönyv szakaszait.
3. Futtassa párhuzamosan a szöszszerep-szakaszokat.
4. Futtassa párhuzamosan a szintaktikai ellenőrzés szerepkör szakaszait.
5. Futtassa párhuzamosan a teszt szerepkör szakaszait.
   1. Lint szerep.
   2. Ellenőrizze a függőséget más szerepköröktől.
   3. Ellenőrizze a szintaxist.
   4. Docker példány létrehozása
   5. Futtassa a molecule/default/playbook.yml fájlt.
   6. Ellenőrizze az idempotenciát.
6. Futtasson integrációs teszteket
7. befejez

271. nap: Bus Factor

A refaktorálást eleinte két-három fős kis csoport végezte. Átnézték a kódot a masterben. Idővel a csapat kifejlesztette a kódírási ismereteket, és a kód áttekintése hozzájárult az infrastruktúrával és annak működésével kapcsolatos ismeretek terjesztéséhez. A kiemelés itt az volt, hogy a bírálókat egyenként, ütemezés szerint választották ki, i.e. bizonyos fokú valószínűséggel egy új infrastruktúra-elembe fog mászni.

És itt kényelmesnek kell lennie. Kényelmes áttekintést készíteni, megnézni, milyen feladat keretein belül végezték el, és a megbeszélések történetét. Integráltunk jenkins + bitbucket + jira.

De mint ilyen, az áttekintés nem csodaszer, valahogy bejutottunk a mesterkódba, amitől flop tesztek lettünk:

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

Aztán megjavították, de az üledék megmaradt.

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. nap: A tesztek felgyorsítása

Idővel több teszt volt, a buildek lassabban futottak, a legrosszabb esetben akár egy órát is. Az egyik retrón egy olyan mondat volt, hogy „jó, hogy vannak tesztek, de lassúak”. Ennek eredményeként elhagytuk a virtuális gépeken végzett integrációs teszteket, és a Dockerhez adaptáltuk, hogy gyorsabbá tegyük. A testinfra helyére is lecseréltük a megfelelő hitelesítőt, hogy csökkentsük a felhasznált eszközök számát.

Szigorúan véve volt egy sor intézkedés:

1. Váltás dockerre.
2. Távolítsa el a szerepkör tesztelését, amely a függőségek miatt duplikált.
3. Növelje a rabszolgák számát.
4. Próbaüzemi sorrend.
5. Szöszképződés képessége ÖSSZES helyileg egy paranccsal.

Ennek eredményeként a jenkins Pipeline is egységes lett

1. Építési szakaszok létrehozása.
2. Lint mindent párhuzamosan.
3. Futtassa párhuzamosan a teszt szerepkör szakaszait.
4. Befejezés.

Tanulságok

Kerülje a globális változókat

Az Ansible globális változókat használ, az űrlapban van egy részleges megoldás private_role_vars, de ez nem csodaszer.

Hadd mondjak egy példát. Hagyjuk 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}}

A vicces az, hogy a játékkönyvek eredménye olyan dolgoktól függ, amelyek nem mindig nyilvánvalóak, például a szerepek felsorolásának sorrendjétől. Sajnos ez az Ansible természete, és a legjobb, amit tehetünk, ha valamilyen megállapodást használunk, például egy szerepkörön belül csak az ebben a szerepkörben leírt változót használjuk.

BAD: globális változó használata.

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

JÓ: V. defaults definiálja a szükséges változókat, és később csak azokat használja.

# 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

Előtag szerepváltozók

BAD: globális változó használata.

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

JÓ: A változók szerepeiben használjon változókat a szerep nevével; ez a leltár megtekintése révén könnyebben megértheti, mi történik.

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

Használjon hurokvezérlő változót

BAD: Szabványos változó használata ciklusokban item, ha ez a feladat/játékkönyv szerepel valahol, az váratlan viselkedéshez vezethet

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

JÓ: Változó újradefiniálása egy ciklusban via loop_var.

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

Ellenőrizze a bemeneti változókat

Megállapodtunk abban, hogy változó előtagokat használunk; nem lenne felesleges ellenőrizni, hogy azok az elvárásoknak megfelelően vannak-e definiálva, és például nem írták-e felül üres értékkel

JÓ: Változók ellenőrzése.

- 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

Kerülje a hash szótárakat, használjon lapos szerkezetet

Ha egy szerepkör az egyik paraméterében hash-t/szótárt vár, akkor ha valamelyik gyermekparamétert meg akarjuk változtatni, akkor a teljes hash/szótárt felül kell bírálnunk, ami növeli a konfiguráció bonyolultságát.

BAD: hash/szótár használata.

---
user:
  name: admin
  group: admin

JÓ: Használjon lapos változó szerkezetet.

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

Idempotens játékkönyvek és szerepek létrehozása

A szerepeknek és a játékkönyveknek idempotensnek kell lenniük, mert csökkenti a konfigurációs sodródást és a félelmet, hogy valami eltörik. De ha molekulát használ, akkor ez az alapértelmezett viselkedés.

Kerülje a parancshéjmodulok használatát

A shell modul használata imperatív leírási paradigmát eredményez, a deklaratív helyett, amely az Ansible magja.

Teszteld a szerepeidet molekulán keresztül

A molekula nagyon rugalmas dolog, nézzünk meg néhány forgatókönyvet.

Molekula Több példány

В molecule.yml szakaszban platforms sok olyan gazdagépet írhat le, amelyet telepíthet.

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

Ennek megfelelően ezek a házigazdák lehetnek converge.yml használat:

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

Lehetséges hitelesítő

A molekulában az ansible segítségével ellenőrizhető, hogy a példány megfelelően van-e konfigurálva, ráadásul a 3. kiadás óta ez az alapértelmezett. Nem olyan rugalmas, mint a testinfra/inspec, de ellenőrizhetjük, hogy a fájl tartalma megfelel-e az elvárásainknak:

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

Vagy telepítse a szolgáltatást, várja meg, amíg elérhetővé válik, és végezzen füsttesztet:

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

Helyezzen összetett logikát modulokba és bővítményekbe

Az Ansible a deklaratív megközelítést támogatja, így amikor kódelágazást, adatátalakítást vagy shell-modulokat végez, a kód nehezen olvashatóvá válik. Ennek leküzdéséhez és az egyszerű megértéshez nem lenne felesleges saját modulok létrehozásával leküzdeni ezt a bonyolultságot.

Tippek és trükkök összefoglalása

1. Kerülje a globális változókat.
2. Előtag szerepváltozók.
3. Használjon hurokvezérlő változót.
4. Ellenőrizze a bemeneti változókat.
5. Kerülje a hash szótárakat, használjon lapos szerkezetet.
6. Idempotens játékkönyvek és szerepek létrehozása.
7. Kerülje a parancshéjmodulok használatát.
8. Teszteld a szerepeidet molekulán keresztül.
9. Helyezzen összetett logikát modulokba és bővítményekbe.

Következtetés

Nem lehet csak úgy menni, és újraépíteni az infrastruktúrát egy projektben, még akkor sem, ha rendelkezik IaC-vel. Ez egy hosszú folyamat, amely türelmet, időt és tudást igényel.

Linkek

• Diák Hogyan teszteljük az Ansible-t, és ne őrülj meg
• videó Hogyan teszteljük az Ansible-t, és ne őrülj meg
• Amit 200 000 infrastruktúra-kódsor teszteléséből tanultam
• Lehetséges: 120 virtuális gép konfiguráció migrációja Coreosról Centosra 18 hónap alatt
• Hogyan törje össze a kerékpárokat mankóval az elosztás tesztelésekor
• Tesztelj, ha tudsz, vagy álmodoznak az YML-programozók az Ansible tesztelésről?
• Fantasztikus IaC-tesztelési cikkek, beszédek és linkek listája
• keresztposta
• angol verzió

UPD1 2020.05.01 20:30 — A játékkönyvek elsődleges profilalkotásához használható callback_whitelist = profile_tasks hogy hosszú ideig megértsük, mi is működik pontosan. Aztán átmegyünk Ansible gyorsulási klasszikusok. Meg is próbálhatod mitogén
UPD2 2020.05.03 16:34 - angol verzió

Forrás: will.com