Hoe om Ansible te begin toets, herfaktor die projek oor 'n jaar en moenie mal raak nie

Dit is die transkripsie optredes op DevOps-40 2020-03-18:

Vanaf die tweede commit, word enige kode nalatenskap, want aanvanklike idees begin afwyk van die harde werklikheid. Dit is nie goed of sleg nie, dit is 'n gegewe wat moeilik is om mee te argumenteer en mee geleef moet word. Deel van hierdie proses is herfaktorering. Herfaktorering van infrastruktuur as kode. Laat die storie begin oor hoe om Ansible oor 'n jaar te herfaktoreer en nie mal te word nie.

Die geboorte van nalatenskap

Dag #1: Pasiënt Zero

Eens op 'n tyd was daar 'n voorwaardelike projek. Dit het 'n Dev-ontwikkelingspan en Ops-ingenieurs gehad. Hulle het dieselfde probleem opgelos: hoe om bedieners te ontplooi en 'n toepassing te laat loop. Die probleem was dat elke span hierdie probleem op sy eie manier opgelos het. By die projek is besluit om Ansible te gebruik om kennis tussen die Dev- en Ops-spanne te sinchroniseer.

Dag #89: Die geboorte van nalatenskap

Sonder dat hulle dit self agtergekom het, wou hulle dit so goed moontlik doen, maar dit blyk nalatenskap te wees. Hoe gebeur dit?

• Ons het 'n dringende taak hier, kom ons doen 'n vuil hack en maak dit dan reg.
• Jy hoef nie dokumentasie te skryf nie en alles is duidelik wat hier aangaan.
• Ek ken Ansible/Python/Bash/Terraform! Kyk hoe kan ek ontduik!
• Ek is 'n Full Stack Overflow Developer en het dit vanaf stackoverflow gekopieer, ek weet nie hoe dit werk nie, maar dit lyk cool en los die probleem op.

As gevolg hiervan kan u 'n onverstaanbare tipe kode kry waarvoor daar geen dokumentasie is nie, dit is nie duidelik wat dit doen nie, of dit nodig is nie, maar die probleem is dat u dit moet ontwikkel, wysig, krukke en ondersteunings moet byvoeg. , wat die situasie nog erger maak.

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

Dag #109: Bewustheid van die probleem

Die aanvanklik ontwerpte en geïmplementeerde IaC-model voldoen nie meer aan die vereistes van gebruikers / besigheid / ander spanne nie, en die tyd om veranderinge aan die infrastruktuur aan te bring, is nie meer aanvaarbaar nie. Op hierdie oomblik kom die begrip dat dit tyd is om aksie te neem.

IaC herfaktorering

Dag #139: Het jy regtig herfaktorering nodig?

Voordat jy na herfaktor gaan jaag, moet jy 'n aantal belangrike vrae beantwoord:

1. Hoekom het jy dit alles nodig?
2. Het jy tyd?
3. Is kennis genoeg?

As jy nie weet hoe om die vrae te beantwoord nie, sal die herfaktorering eindig voordat dit eers begin, of dit kan net erger word. Omdat ondervinding gehad ( Wat ek geleer het uit die toets van 200 000 reëls infrastruktuurkode), toe het die projek 'n versoek om hulp ontvang om die rolle reg te maak en dit met toetse te dek.

Dag #149: Voorbereiding van die herfaktorering

Die eerste ding is om voor te berei. Besluit wat ons gaan doen. Om dit te doen, kommunikeer ons, vind probleemareas en vind maniere uit om dit op te los. Ons teken die gevolglike konsepte op een of ander manier aan, byvoorbeeld 'n artikel in samevloeiing, sodat wanneer die vraag ontstaan ​​"wat is die beste?" of "wat is korrek?" Ons het nie ons pad verloor nie. In ons geval het ons by die idee gehou verdeel en heers: ons breek die infrastruktuur op in klein stukkies/stene. Hierdie benadering laat jou toe om 'n geïsoleerde stuk infrastruktuur te neem, te verstaan ​​wat dit doen, dit met toetse te bedek en dit te verander sonder om bang te wees om iets te breek.

Dit blyk dat infrastruktuurtoetsing die hoeksteen word en hier is dit die moeite werd om die infrastruktuurtoetspiramide te noem. Presies dieselfde idee wat in ontwikkeling is, maar vir infrastruktuur: ons beweeg van goedkoop vinnige toetse wat eenvoudige dinge nagaan, soos inkeping, na duur volwaardige toetse wat die hele infrastruktuur ontplooi.

Aanvanklike toetspogings

Voordat ons gaan beskryf hoe ons Ansible-toetse op die projek gedek het, sal ek die pogings en benaderings beskryf wat ek vroeër die geleentheid gehad het om te gebruik om die konteks van die besluite wat geneem is, te verstaan.

Dag No. -997: SDS voorsiening

Die eerste keer dat ek Ansible getoets het, was op 'n projek om SDS (Software Defined Storage) te ontwikkel. Daar is 'n aparte artikel oor hierdie onderwerp
Hoe om fietse oor krukke te breek wanneer jy jou verspreiding toets, maar in kort, ons het met 'n omgekeerde toetspiramide geëindig en toets het ons 60-90 minute aan een rol spandeer, wat 'n lang tyd is. Die basis was e2e toetse, m.a.w. ons het 'n volwaardige installasie ontplooi en dit toe getoets. Wat selfs meer verswarende was, was die uitvinding van sy eie fiets. Maar ek moet erken, hierdie oplossing het gewerk en 'n stabiele vrystelling moontlik gemaak.

Dag # -701: Ansible en toets kombuis

Die ontwikkeling van die Ansible-toetsidee was die gebruik van klaargemaakte gereedskap, naamlik toetskombuis / kombuis-ci en inspec. Die keuse is bepaal deur kennis van Ruby (vir meer besonderhede, sien die artikel oor Habré: Droom YML-programmeerders daarvan om Ansible te toets?) het vinniger gewerk, sowat 40 minute vir 10 rolle. Ons het 'n pak virtuele masjiene geskep en toetse binne uitgevoer.

Oor die algemeen het die oplossing gewerk, maar daar was 'n mate van sediment as gevolg van heterogeniteit. Toe die aantal mense wat getoets is, verhoog is tot 13 basiese rolle en 2 meta-rolle wat kleiner rolle kombineer, toe het die toetse skielik vir 70 minute begin duur, wat amper 2 keer langer is. Dit was moeilik om oor XP (ekstreme programmering) praktyke te praat, want... niemand wil 70 minute wag nie. Dit was die rede vir die verandering van die benadering

Dag # -601: Ansible en molekule

Konseptueel is dit soortgelyk aan testkitchen, net ons het roltoetsing na docker geskuif en die stapel verander. Gevolglik is die tyd vir 20 rolle tot 'n stabiele 25-7 minute verminder.

Deur die aantal getoetste rolle na 17 te verhoog en 45 rolle te pluis, het ons dit in 28 minute op 2 jenkins-slawe uitgevoer.

Dag #167: Voeg Ansible-toetse by die projek

Dit sal waarskynlik nie moontlik wees om die herfaktoreringstaak oorhaastig te doen nie. Die taak moet meetbaar wees sodat jy dit in klein stukkies kan breek en die olifant stukkie vir stukkie met ’n teelepel kan eet. Daar moet 'n begrip wees of jy in die regte rigting beweeg, hoe lank om te gaan.

Oor die algemeen maak dit nie saak hoe dit gedoen gaan word nie, jy kan op 'n stuk papier skryf, jy kan plakkers op die kas sit, jy kan take in Jira skep, of jy kan Google Docs oopmaak en die huidige status neerskryf daar. Die bene groei van die feit dat die proses nie onmiddellik is nie, dit sal lank en vervelig wees. Dit is onwaarskynlik dat enigiemand wil hê dat jy uit idees moet uitbrand, moeg word en oorweldig word tydens herfaktorering.

Die herfaktorering is eenvoudig:

• Eet nie.
• Slaap nie.
• Kode.
• IaC toets.
• Herhaal

en ons herhaal dit totdat ons die beoogde doel bereik.

Dit is dalk nie moontlik om alles dadelik te begin toets nie, so ons eerste taak was om met linting te begin en die sintaksis na te gaan.

Dag #181: Groenboumeester

Linting is 'n klein eerste stap na Green Build Master. Dit sal byna niks breek nie, maar dit sal jou toelaat om prosesse te ontfout en groen bouwerk in Jenkins te maak. Die idee is om gewoontes onder die span te ontwikkel:

• Rooi toetse is sleg.
• Ek het iets kom regmaak en terselfdertyd die kode 'n bietjie beter maak as wat dit voor jou was.

Dag #193: Van linting tot eenheidstoetse

Nadat u die proses ingebou het om die kode in die meester te kry, kan u die proses van stap-vir-stap verbetering begin - vervang linting met bekendstellingsrolle, u kan dit selfs doen sonder idempotensie. Jy moet verstaan ​​hoe om rolle toe te pas en hoe dit werk.

Dag #211: Van eenheid tot integrasietoetse

Wanneer die meeste rolle met eenheidstoetse gedek word en alles is gevoer, kan jy voortgaan om integrasietoetse by te voeg. Dié. toets nie 'n enkele baksteen in die infrastruktuur nie, maar 'n kombinasie daarvan, byvoorbeeld 'n volledige instansie-konfigurasie.

Deur jenkins te gebruik, het ons baie stadiums gegenereer wat rolle/speelboeke in parallel gevoer het, dan eenheidstoetse in houers, en uiteindelik integrasietoetse.

Jenkins + Docker + Ansible = Toetse

1. Betaal repo en genereer boufases.
2. Begin pluis speelboek stadiums parallel.
3. Voer pluis rol stadiums parallel.
4. Voer sintaksiskontrole-rolfases parallel uit.
5. Voer toetsrolfases parallel uit.
   1. Lint rol.
   2. Gaan afhanklikheid van ander rolle na.
   3. Gaan sintaksis na.
   4. Skep docker-instansie
   5. Begin molecule/default/playbook.yml.
   6. Gaan idempotensie na.
6. Voer integrasietoetse uit
7. Voltooi

Dag #271: Busfaktor

Aanvanklik is herfaktorering deur 'n klein groepie van twee of drie mense uitgevoer. Hulle het die kode in die meester hersien. Met verloop van tyd het die span kennis ontwikkel van hoe om kode te skryf en kodehersiening het bygedra tot die verspreiding van kennis oor die infrastruktuur en hoe dit werk. Die hoogtepunt hier was dat die resensente een vir een gekies is, volgens 'n skedule, d.w.s. met 'n mate van waarskynlikheid sal jy in 'n nuwe stuk infrastruktuur klim.

En dit behoort gemaklik te wees hier. Dit is gerieflik om 'n resensie te doen, te sien binne die raamwerk van watter taak dit gedoen is, en die geskiedenis van besprekings. Ons het jenkins + bitbucket + jira geïntegreer.

Maar as sodanig is 'n resensie nie 'n wondermiddel nie; op een of ander manier het ons by die meesterkode ingekom, wat ons laat floptoetse gemaak het:

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

Toe het hulle dit reggemaak, maar die oorblyfsel het oorgebly.

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

Dag #311: Bespoediging van toetse

Met verloop van tyd was daar meer toetse, bouwerk het stadiger gehardloop, tot 'n uur in die ergste geval. Op een van die retros was daar 'n frase soos "dit is goed dat daar toetse is, maar hulle is stadig." Gevolglik het ons integrasietoetse op virtuele masjiene laat vaar en dit vir Docker aangepas om dit vinniger te maak. Ons het ook testinfra vervang met 'n moontlike verifieerder om die aantal gereedskap wat gebruik word te verminder.

Streng gesproke was daar 'n stel maatreëls:

1. Skakel oor na docker.
2. Verwyder roltoetsing, wat gedupliseer word as gevolg van afhanklikhede.
3. Verhoog die aantal slawe.
4. Toetsloopvolgorde.
5. Vermoë om te pluis ALMAL plaaslik met een opdrag.

Gevolglik is Pyplyn op jenkins ook verenig

1. Genereer boufases.
2. Vou alles in parallel.
3. Voer toetsrolfases parallel uit.
4. Voltooi.

Lesse geleer

Vermy globale veranderlikes

Ansible gebruik globale veranderlikes, daar is 'n gedeeltelike oplossing in die vorm private_role_vars, maar dit is nie 'n wondermiddel nie.

Kom ek gee vir jou 'n voorbeeld. Laat ons hê 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}}

Die snaakse ding is dat die resultaat van speelboeke sal afhang van dinge wat nie altyd voor die hand liggend is nie, soos die volgorde waarin rolle gelys word. Ongelukkig is dit die aard van Ansible en die beste ding wat gedoen kan word is om 'n soort ooreenkoms te gebruik, byvoorbeeld, binne 'n rol, gebruik slegs die veranderlike wat in hierdie rol beskryf word.

BAD: gebruik globale veranderlike.

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

GOEIE: V defaults definieer die nodige veranderlikes en gebruik later slegs hulle.

# 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

Voorvoegsel rol veranderlikes

BAD: gebruik globale veranderlike.

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

GOEIE: In rolle vir veranderlikes, gebruik veranderlikes wat met die rolnaam voorafgegaan word; dit, deur na voorraad te kyk, sal dit makliker maak om te verstaan ​​wat gebeur.

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

Gebruik lusbeheerveranderlike

BAD: Gebruik standaard veranderlike in lusse item, as hierdie taak/speelboek iewers ingesluit is, kan dit tot onverwagte gedrag lei

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

GOEIE: Herdefinieer 'n veranderlike in 'n lus via loop_var.

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

Gaan insetveranderlikes na

Ons het ingestem om veranderlike voorvoegsels te gebruik; dit sal nie oorbodig wees om seker te maak dat hulle gedefinieer is soos ons verwag en byvoorbeeld nie deur 'n leë waarde oorheers is nie

GOEIE: Gaan veranderlikes na.

- 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

Vermy hashes woordeboeke, gebruik plat struktuur

As 'n rol 'n hash/woordeboek in een van sy parameters verwag, as ons een van die kindparameters wil verander, sal ons die hele hash/woordeboek moet ignoreer, wat konfigurasiekompleksiteit sal verhoog.

BAD: Gebruik hash/woordeboek.

---
user:
  name: admin
  group: admin

GOEIE: Gebruik 'n plat veranderlike struktuur.

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

Skep idempotente speelboeke en rolle

Rolle en speelboeke moet idempotent wees, want verminder konfigurasieverskuiwing en vrees om iets te breek. Maar as jy molekule gebruik, dan is dit die verstekgedrag.

Vermy die gebruik van opdragdop-modules

Die gebruik van 'n dopmodule lei tot 'n imperatiewe beskrywingsparadigma, in plaas van die verklarende een, wat die kern van Ansible is.

Toets jou rolle via molekule

Molekule is 'n baie buigsame ding, kom ons kyk na 'n paar scenario's.

Molekule Veelvuldige gevalle

В molecule.yml in afdeling platforms jy kan baie gashere beskryf wat jy kan ontplooi.

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

Gevolglik kan hierdie gashere dan wees converge.yml gebruik:

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

Ansible verificateur

In molekule is dit moontlik om ansible te gebruik om te kontroleer dat die instansie korrek gekonfigureer is, en dit was boonop die verstek sedert vrystelling 3. Dit is nie so buigsaam soos testinfra/inspec nie, maar ons kan seker maak dat die inhoud van die lêer ooreenstem met ons verwagtinge:

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

Of ontplooi die diens, wag totdat dit beskikbaar is en doen 'n rooktoets:

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

Plaas komplekse logika in modules en plugins

Ansible bepleit 'n verklarende benadering, so wanneer jy kodevertakking, datatransformasie, dopmodules doen, word die kode moeilik om te lees. Om dit te bekamp en dit eenvoudig te hou om te verstaan, sal dit nie oorbodig wees om hierdie kompleksiteit te bekamp deur jou eie modules te skep nie.

Som wenke en truuks op

1. Vermy globale veranderlikes.
2. Voorvoegsel rol veranderlikes.
3. Gebruik lusbeheerveranderlike.
4. Gaan insetveranderlikes na.
5. Vermy hashes woordeboeke, gebruik plat struktuur.
6. Skep idempotente speelboeke en rolle.
7. Vermy die gebruik van opdragdop-modules.
8. Toets jou rolle via molekule.
9. Plaas komplekse logika in modules en plugins.

Gevolgtrekking

Jy kan nie net die infrastruktuur op 'n projek gaan herfaktoreer nie, selfs al het jy IaC. Dit is 'n lang proses wat geduld, tyd en kennis verg.

verlaat

• Slides Hoe om Ansible te toets en nie mal te raak nie
• Video Hoe om Ansible te toets en nie mal te raak nie
• Wat ek geleer het uit die toets van 200 000 reëls infrastruktuurkode
• Ansible: Migrasie van 120 VM-konfigurasie van Coreos na Centos in 18 maande
• Hoe om fietse oor krukke te breek wanneer jy jou verspreiding toets
• Toets my of jy kan of droom YML-programmeerders daarvan om Ansible te toets?
• 'n Lys van ongelooflike IaC-toetsartikels, toesprake en skakels
• kruispaal
• Engelse weergawe

UPD1 2020.05.01 20:30 — Vir primêre profilering van speelboeke wat jy kan gebruik callback_whitelist = profile_tasks om te verstaan ​​wat presies werk vir 'n lang tyd. Dan gaan ons deur Ansible versnelling klassieke. Jy kan ook probeer mitogen
UPD2 2020.05.03 16:34 - Engelse weergawe

Bron: will.com