Kuinka aloittaa Ansiblen testaus, heijasta projekti vuoden sisällä ja älä mene hulluksi

Tämä on transkriptio esitykset päälle DevOps-40, 2020:

Toisesta toimituksesta alkaen mistä tahansa koodista tulee perinnöllistä, koska alkuperäiset ajatukset alkavat poiketa ankarasta todellisuudesta. Tämä ei ole hyvä eikä huono, se on itsestäänselvyys, jonka kanssa on vaikea väitellä ja jonka kanssa on elettävä. Osa tätä prosessia on refaktorointi. Infrastruktuurin muokkaaminen koodiksi. Anna tarinan alkaa siitä, kuinka Ansible palautetaan vuodessa ja ei tule hulluksi.

Perinnön syntymä

Päivä 1: Potilas nolla

Olipa kerran ehdollinen projekti. Siinä oli Dev-kehitystiimi ja Ops-insinöörit. He ratkaisivat saman ongelman: kuinka palvelimet otetaan käyttöön ja sovellus suoritetaan. Ongelmana oli, että jokainen joukkue ratkaisi tämän ongelman omalla tavallaan. Projektissa päätettiin käyttää Ansiblea tiedon synkronointiin Dev- ja Ops-tiimien välillä.

Päivä #89: Perinnön syntymä

Sitä itse huomaamatta he halusivat tehdä sen mahdollisimman hyvin, mutta se osoittautui perinnöksi. Miten tämä tapahtuu?

• Meillä on kiireellinen tehtävä täällä, tehdään likainen hakkerointi ja sitten korjataan se.
• Sinun ei tarvitse kirjoittaa asiakirjoja ja kaikki on selvää, mitä täällä tapahtuu.
• Tiedän Ansiblen/Pythonin/Bashin/Terraformin! Katso kuinka voin väistää!
• Olen Full Stack Overflow -kehittäjä ja kopioin tämän stackoverflowsta, en tiedä miten se toimii, mutta se näyttää siistiltä ja ratkaisee ongelman.

Tämän seurauksena voit saada käsittämättömän tyyppisen koodin, josta ei ole dokumentaatiota, ei ole selvää mitä se tekee, tarvitaanko sitä, mutta ongelmana on, että sinun täytyy kehittää sitä, muokata sitä, lisätä kainalosauvoja ja tukia , mikä pahentaa tilannetta entisestään.

- 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äivä #109: Tietoisuus ongelmasta

Alun perin suunniteltu ja toteutettu IaC-malli ei enää täytä käyttäjien/yritysten/muiden tiimien vaatimuksia, eikä infrastruktuurin muutosten tekemiseen tarvittava aika ole enää hyväksyttävä. Tällä hetkellä tulee ymmärrys, että on aika ryhtyä toimiin.

IaC-refaktorointi

Päivä #139: Tarvitsetko todella uudelleenmuodostusta?

Ennen kuin ryntäät refaktoriin, sinun on vastattava useisiin tärkeisiin kysymyksiin:

1. Miksi tarvitset tätä kaikkea?
2. Onko sinulla aikaa?
3. Riittääkö tieto?

Jos et osaa vastata kysymyksiin, niin refaktorointi loppuu ennen kuin se edes alkaa tai se voi vain pahentua. Koska oli kokemusta ( Mitä opin testaamalla 200 000 riviä infrastruktuurikoodia), sitten projekti sai avunpyynnön roolien korjaamiseen ja niiden kattamiseen testeillä.

Päivä #149: Refaktoroinnin valmistelu

Ensimmäinen asia on valmistautua. Päätä, mitä teemme. Tätä varten kommunikoimme, etsimme ongelmakohtia ja keksimme tapoja ratkaista ne. Tallennamme syntyneet käsitteet jotenkin, esimerkiksi artikkelin yhtymäkohtana, niin että kun herää kysymys "mikä on parasta?" tai "kumpi on oikein?" Emme ole eksyneet. Meidän tapauksessamme pysyimme ajatuksessa hajoita ja hallitse: hajotamme infrastruktuurin pieniksi paloiksi/tiileiksi. Tämän lähestymistavan avulla voit ottaa yksittäisen infrastruktuurin, ymmärtää, mitä se tekee, peittää sen testeillä ja muuttaa sitä pelkäämättä rikkoa mitään.

Osoittautuu, että infrastruktuurin testauksesta tulee kulmakivi ja tässä on syytä mainita infrastruktuurin testauspyramidi. Täsmälleen sama idea, joka on kehitteillä, mutta infrastruktuurille: siirrymme halvoista pikatesteistä, jotka tarkistavat yksinkertaisia ​​asioita, kuten sisennystä, kalliisiin täysimittaisiin testeihin, jotka ottavat käyttöön koko infrastruktuurin.

Mahdollisia testausyrityksiä

Ennen kuin alamme kuvailemaan, kuinka käsitimme Ansible-testejä projektissa, kuvailen yrityksiä ja lähestymistapoja, joita minulla oli mahdollisuus käyttää aiemmin ymmärtääkseni tehtyjen päätösten kontekstia.

Päivä nro -997: SDS-toimitus

Ensimmäisen kerran testasin Ansiblea SDS:n (Software Defined Storage) kehittämisprojektissa. Tästä aiheesta on erillinen artikkeli
Kuinka rikkoa polkupyöriä kainalosauvoilla testattaessa jakeluasi, mutta lyhyesti sanottuna päädyimme käänteiseen testauspyramidiin ja testaamiseen käytimme 60-90 minuuttia yhteen rooliin, mikä on pitkä aika. Lähtökohtana olivat e2e-testit, ts. otimme käyttöön täysimittaisen asennuksen ja testasimme sen. Vielä pahempaa oli hänen oman polkupyöränsä keksiminen. Mutta minun on myönnettävä, että tämä ratkaisu toimi ja mahdollisti vakaan julkaisun.

Päivä # -701: Ansible ja koekeittiö

Ansible-testausidean kehitystyönä oli valmiiden työkalujen käyttö, eli testikeittiö/keittiö-ci ja inspec. Valinnan määräsi Rubyn tuntemus (lisätietoja on Habrén artikkelissa: Haaveilevatko YML-ohjelmoijat Ansiblen testaamisesta?) toimi nopeammin, noin 40 minuuttia 10 roolia kohti. Loimme paketin virtuaalikoneita ja suoritimme testejä sisällä.

Yleensä ratkaisu toimi, mutta heterogeenisuudesta johtuen sedimenttiä oli jonkin verran. Kun testattavien määrä nostettiin 13 perusrooliin ja 2 metarooliin yhdistäen pienempiä rooleja, niin yhtäkkiä testit alkoivat kestää 70 minuuttia, mikä on lähes 2 kertaa pidempi. XP:n (extreme programming) käytännöistä oli vaikea puhua, koska... kukaan ei halua odottaa 70 minuuttia. Tämä oli syy lähestymistavan muuttamiseen

Päivä # -601: Ansible ja molekyyli

Käsitteellisesti tämä on samanlainen kuin testkitchen, vain siirsimme roolitestauksen dockeriin ja muutimme pinon. Tämän seurauksena aika lyheni vakaaksi 20-25 minuuttiin 7 rooliin.

Nostamalla testattujen roolien määrän 17:een ja 45 roolia, suoritimme tämän 28 minuutissa kahdella Jenkins-orjalla.

Päivä #167: Ansible-testien lisääminen projektiin

Todennäköisesti uudelleenjärjestelytehtävää ei voida suorittaa kiireessä. Tehtävän tulee olla mitattavissa, jotta voit pilkkoa sen pieniksi paloiksi ja syödä elefantin pala palalta teelusikalla. On oltava ymmärrys siitä, oletko menossa oikeaan suuntaan, kuinka kauan on matkaa.

Yleensä ei ole väliä miten se tehdään, voit kirjoittaa paperille, voit laittaa tarroja kaappiin, voit luoda tehtäviä Jirassa tai voit avata Google Docsin ja kirjoittaa nykyisen tilan. siellä. Jalat kasvavat siitä, että prosessi ei ole välitön, se on pitkä ja ikävä. On epätodennäköistä, että kukaan haluaisi sinun palavan loppuun ideoistasi, väsyvän ja ylikuormittuvan uudelleenjärjestelyn aikana.

Refaktorointi on yksinkertainen:

• Syödä.
• Nuku.
• Koodi.
• IaC testi.
• Toisto:

ja toistamme tätä, kunnes saavutamme aiotun tavoitteen.

Kaiken testaamisen aloittaminen ei ehkä ole mahdollista heti, joten ensimmäinen tehtävämme oli aloittaa linssiminen ja syntaksin tarkistaminen.

Päivä #181: Green Build Master

Linting on pieni ensimmäinen askel kohti Green Build Masteria. Tämä ei riko melkein mitään, mutta sen avulla voit korjata prosesseja ja tehdä vihreitä koontiversioita Jenkinsissä. Ideana on kehittää tottumuksia joukkueen kesken:

• Punaiset testit ovat huonoja.
• Tulin korjaamaan jotain ja samalla tekemään koodista hieman paremman kuin se oli ennen sinua.

Päivä #193: Nukkaamisesta yksikkötesteihin

Kun olet rakentanut koodin saamisprosessin isäntäkoneeseen, voit aloittaa vaiheittaisen parantamisprosessin - korvaamalla nukkauksen käynnistämisrooleilla, voit jopa tehdä sen ilman idempotenssia. Sinun on ymmärrettävä, miten rooleja sovelletaan ja miten ne toimivat.

Päivä #211: Yksiköstä integraatiotesteihin

Kun useimmat roolit on peitetty yksikkötesteillä ja kaikki on nukkaa, voit siirtyä integrointitestien lisäämiseen. Nuo. ei testata yhtä lohkoa infrastruktuurissa, vaan niiden yhdistelmää, esimerkiksi koko ilmentymän kokoonpano.

Jenkinsin avulla loimme monia vaiheita, joissa rooleja/leikkikirjoja linjottiin rinnakkain, sitten yksikkötestejä konteissa ja lopuksi integraatiotestejä.

Jenkins + Docker + Ansible = Testit

1. Tarkista repo ja luo rakennusvaiheet.
2. Suorita lint playbook -vaiheita rinnakkain.
3. Suorita nukkaroolivaiheet rinnakkain.
4. Suorita syntaksin tarkistuksen roolivaiheet rinnakkain.
5. Suorita testiroolivaiheet rinnakkain.
   1. Nukka rooli.
   2. Tarkista riippuvuus muista rooleista.
   3. Tarkista syntaksi.
   4. Luo Docker-esiintymä
   5. Suorita molecule/default/playbook.yml.
   6. Tarkista idempotenssi.
6. Suorita integraatiotestejä
7. Suorittaa loppuun

Päivä #271: Bus Factor

Aluksi refaktorointia suoritti pieni kahden tai kolmen hengen ryhmä. He tarkistivat koodin masterissa. Ajan myötä tiimi kehitti tietoa koodin kirjoittamisesta ja koodin tarkistus auttoi levittämään tietoa infrastruktuurista ja sen toiminnasta. Kohokohta tässä oli, että arvostelijat valittiin yksitellen, aikataulun mukaan, ts. jollain todennäköisyydellä kiipeät uuteen infrastruktuuriin.

Ja täällä pitäisi olla mukavaa. On kätevää tehdä katsaus, nähdä, minkä tehtävän puitteissa se tehtiin, ja keskustelujen historiaa. Meillä on integroitu jenkins + bitbucket + jira.

Mutta sellaisenaan arvostelu ei ole ihmelääke, jotenkin pääsimme pääkoodiin, joka sai meidät tekemään floppitestejä:

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

Sitten he korjasivat sen, mutta jäännös 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äivä #311: Testien nopeuttaminen

Ajan myötä testejä tuli enemmän, koontiversiot sujuivat hitaammin, pahimmassa tapauksessa jopa tunnin. Yhdessä retrossa oli lause "on hyvä, että testejä on, mutta ne ovat hitaita". Tämän seurauksena hylkäsimme virtuaalikoneiden integraatiotestit ja mukautimme ne Dockeriin nopeuttaaksemme sitä. Korvasimme myös testinfran mahdollisella todentajalla vähentääksemme käytettyjen työkalujen määrää.

Tarkkaan ottaen oli joukko toimenpiteitä:

1. Vaihda telakkaan.
2. Poista roolitestaus, joka on päällekkäinen riippuvuuksien vuoksi.
3. Lisää orjien määrää.
4. Koekäyttöjärjestys.
5. Kyky nukkaa KAIKKI paikallisesti yhdellä komennolla.

Tämän seurauksena myös Pipeline on jenkins yhtenäistettiin

1. Luo rakennusvaiheita.
2. Nukkaa kaikki rinnakkain.
3. Suorita testiroolivaiheet rinnakkain.
4. Valmis.

Saadut kokemukset

Vältä globaaleja muuttujia

Ansible käyttää globaaleja muuttujia, muodossa on osittainen kiertotapa private_role_vars, mutta tämä ei ole ihmelääke.

Annan sinulle esimerkin. Anna meidän 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}}

Hassua on, että leikkikirjojen tulos riippuu asioista, jotka eivät aina ole ilmeisiä, kuten roolien listausjärjestys. Valitettavasti tämä on Ansiblen luonne ja parasta mitä voidaan tehdä, on käyttää jonkinlaista sopimusta, esimerkiksi roolin sisällä käyttää vain tässä roolissa kuvattua muuttujaa.

BAD: käytä globaalia muuttujaa.

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

HYVÄ: V defaults Määritä tarvittavat muuttujat ja käytä myöhemmin vain niitä.

# 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

Etuliitteen roolimuuttujat

BAD: käytä globaalia muuttujaa.

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

HYVÄ: Käytä muuttujien rooleissa muuttujia, joiden etuliitteenä on roolin nimi; tämä helpottaa inventaariota tarkastelemalla ymmärtämistä, mitä tapahtuu.

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

Käytä silmukan ohjausmuuttujaa

BAD: Käytä vakiomuuttujaa silmukoissa item, jos tämä tehtävä/pelikirja on sisällytetty johonkin, tämä voi johtaa odottamattomaan toimintaan

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

HYVÄ: Määritä muuttuja uudelleen silmukassa via loop_var.

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

Tarkista syöttömuuttujat

Sovimme muuttuvien etuliitteiden käyttämisestä; ei olisi tarpeetonta tarkistaa, että ne on määritelty odotetulla tavalla ja että niitä ei esimerkiksi ohitettu tyhjällä arvolla

HYVÄ: Tarkista muuttujat.

- 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ältä hajautussanakirjoja, käytä tasaista rakennetta

Jos rooli odottaa tiivistettä/sanakirjaa jossakin parametrissaan, niin jos haluamme muuttaa yhtä aliparametreista, meidän on ohitettava koko hash/sanakirja, mikä lisää määrityksen monimutkaisuutta.

BAD: Käytä tiivistettä/sanakirjaa.

---
user:
  name: admin
  group: admin

HYVÄ: Käytä tasaista muuttujarakennetta.

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

Luo idempotentteja leikkikirjoja ja rooleja

Roolien ja leikkikirjojen on oltava idempotentteja, koska vähentää kokoonpanon ajautumista ja pelkoa rikkoa jotain. Mutta jos käytät molekyyliä, tämä on oletuskäyttäytyminen.

Vältä komentotulkkimoduulien käyttöä

Shell-moduulin käyttö johtaa pakolliseen kuvausparadigmaan deklaratiivisen sijasta, joka on Ansiblen ydin.

Testaa roolisi molekyylin avulla

Molekyyli on erittäin joustava asia, katsotaanpa muutamia skenaarioita.

Molekyyli Useita esiintymiä

В molecule.yml osiossa platforms voit kuvata monia isäntiä, jotka voit ottaa käyttöön.

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

Vastaavasti nämä isännät voivat olla converge.yml käyttää:

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

Mahdollinen todentaja

Molekyylissä on mahdollista käyttää ansiblea tarkistamaan, että ilmentymä on konfiguroitu oikein, lisäksi tämä on ollut oletusarvo julkaisusta 3 lähtien. Se ei ole yhtä joustava kuin testinfra/inspec, mutta voimme tarkistaa, että tiedoston sisältö vastaa odotuksiamme:

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

Tai ota palvelu käyttöön, odota, että se tulee saataville ja tee savutesti:

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

Laita monimutkaista logiikkaa moduuleihin ja laajennuksiin

Ansible kannattaa deklaratiivista lähestymistapaa, joten kun teet koodin haaroittamisen, datan muunnoksen tai shell-moduuleita, koodista tulee vaikea lukea. Tämän torjumiseksi ja sen ymmärtämiseksi yksinkertaiseksi ei olisi tarpeetonta torjua tätä monimutkaisuutta luomalla omia moduuleja.

Tee yhteenveto vinkeistä ja temppuista

1. Vältä globaaleja muuttujia.
2. Etuliitteen roolimuuttujat.
3. Käytä silmukan ohjausmuuttujaa.
4. Tarkista syöttömuuttujat.
5. Vältä hajautussanakirjoja, käytä tasaista rakennetta.
6. Luo idempotentteja leikkikirjoja ja rooleja.
7. Vältä komentotulkkimoduulien käyttöä.
8. Testaa roolisi molekyylin avulla.
9. Laita monimutkaista logiikkaa moduuleihin ja laajennuksiin.

Johtopäätös

Et voi vain mennä ja muuttaa infrastruktuuria projektissa, vaikka sinulla olisi IaC. Tämä on pitkä prosessi, joka vaatii kärsivällisyyttä, aikaa ja tietoa.

Linkit

• Diat Kuinka testata Ansible ja älä mene hulluksi
• Video Kuinka testata Ansible ja älä mene hulluksi
• Mitä opin testaamalla 200 000 riviä infrastruktuurikoodia
• Mahdollinen: 120 VM-kokoonpanon siirto Coreosta Centosiin 18 kuukaudessa
• Kuinka rikkoa polkupyöriä kainalosauvoilla testattaessa jakeluasi
• Testaa minua, voitko vai haaveilevatko YML-ohjelmoijat Ansiblen testaamisesta?
• Luettelo mahtavista IaC-testausartikkeleista, puheista ja linkeistä
• ristiposti
• Englanti versio

UPD1 2020.05.01 klo 20:30 — Voit käyttää leikkikirjojen ensisijaiseen profilointiin callback_whitelist = profile_tasks ymmärtää, mikä tarkalleen toimii pitkään. Sitten mennään läpi Ansible kiihtyvyys klassikoita. Voit myös kokeilla mitogeeni
UPD2 2020.05.03 klo 16:34 - Englanti versio

Lähde: will.com