🥇Hvernig á að byrja að prófa Ansible, endurgera verkefni á einu ári og ekki klikka

Þetta er afritið sýningar á DevOps-40 2020-03-18:

Frá og með annarri skuldbindingunni verður hvaða kóða sem er arfleifð, vegna þess að upphaflegar hugmyndir fara að víkja frá erfiðum veruleika. Þetta er hvorki gott né slæmt, þetta er gefið sem erfitt er að rífast við og verður að lifa við. Hluti af þessu ferli er endurnýjun. Refactoring Infrastructure sem kóða. Leyfðu sögunni að byrja á því hvernig á að endurgera Ansible á einu ári og ekki verða brjálaður.

Fæðing arfleifðar

Dagur #1: Sjúklingur Zero

Einu sinni var skilyrt verkefni. Það var með Dev þróunarteymi og Ops verkfræðinga. Þeir voru að leysa sama vandamálið: hvernig á að dreifa netþjónum og keyra forrit. Vandamálið var að hvert lið leysti þetta vandamál á sinn hátt. Í verkefninu var ákveðið að nota Ansible til að samstilla þekkingu á milli Dev og Ops teymanna.

Dagur #89: Fæðing arfleifðar

Án þess að taka eftir því sjálfir vildu þeir gera það sem best, en það reyndist arfleifð. Hvernig gerist þetta?

Við höfum brýnt verkefni hér, við skulum gera óhreint hakk og laga það síðan.
Þú þarft ekki að skrifa skjöl og allt er ljóst hvað er að gerast hér.
Ég þekki Ansible/Python/Bash/Terraform! Sjáðu hvernig ég get forðast!
Ég er Full Stack Overflow Developer og afritaði þetta úr stackoverflow, ég veit ekki hvernig það virkar, en það lítur flott út og leysir vandamálið.

Fyrir vikið geturðu fengið óskiljanlega tegund kóða sem engin skjöl eru fyrir, það er ekki ljóst hvað það gerir, hvort það er þörf, en vandamálið er að þú þarft að þróa hann, breyta honum, bæta við hækjum og styðja , sem gerir ástandið enn verra.

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

Dagur #109: Meðvitund um vandamálið

Upphaflega hugsaða og innleidda IaC líkanið uppfyllir ekki lengur kröfur notenda / fyrirtækja / annarra teyma og tíminn til að gera breytingar á innviðum hættir að vera ásættanlegt. Á þessari stundu kemur sá skilningur að það sé kominn tími til að grípa til aðgerða.

IaC endurnýjun

Dagur #139: Þarftu virkilega endurnýjun?

Áður en þú flýtir þér að endurnýta verður þú að svara nokkrum mikilvægum spurningum:

Af hverju þarftu þetta allt?
Hefur þú tíma?
Er þekking nóg?

Ef þú veist ekki hvernig á að svara spurningunum, þá lýkur endurmynduninni áður en hún byrjar, eða hún gæti bara versnað. Vegna þess að hafði reynslu ( Það sem ég lærði af því að prófa 200 línur af innviðakóða), þá fékk verkefnið beiðni um aðstoð við að laga hlutverkin og hylja þau með prófum.

Dagur #149: Undirbúningur endurnýjunar

Það fyrsta er að undirbúa. Ákveða hvað við gerum. Til að gera þetta höfum við samskipti, finnum vandamálasvæði og finnum leiðir til að leysa þau. Við skráum hugtökin sem myndast á einhvern hátt, til dæmis grein í samruna, þannig að þegar spurningin vaknar "hvað er best?" eða "hvað er rétt?" Við höfum ekki villst af leið. Í okkar tilviki héldum við okkur við hugmyndina deila og drottna: við brjótum upp innviðina í litla bita/múrsteina. Þessi nálgun gerir þér kleift að taka einangrað stykki af innviði, skilja hvað það gerir, hylja það með prófum og breyta því án þess að óttast að brjóta neitt.

Það kemur í ljós að innviðaprófanir verða hornsteinninn og hér er rétt að minnast á innviðaprófunarpýramídann. Nákvæmlega sama hugmyndin og er í þróun, en fyrir innviði: við erum að færa okkur frá ódýrum skyndiprófum sem athuga einfalda hluti, eins og inndrætti, yfir í dýrar fullgildar prófanir sem nota allan innviðina.

Ánægjulegar prófanir

Áður en við förum að lýsa því hvernig við fórum yfir Ansible próf í verkefninu, mun ég lýsa tilraunum og aðferðum sem ég hafði tækifæri til að nota áður til að skilja samhengi ákvarðana sem teknar voru.

Dagur nr -997: SDS ákvæði

Fyrsta skiptið sem ég prófaði Ansible var í verkefni til að þróa SDS (Software Defined Storage). Það er sérstök grein um þetta efni
Hvernig á að brjóta reiðhjól yfir hækjur þegar þú prófar dreifingu þína, en í stuttu máli þá enduðum við með öfugan prófunarpýramída og prófun eyddum við 60-90 mínútum í eitt hlutverk, sem er langur tími. Grunnurinn var e2e próf, þ.e. við settum upp fullgilda uppsetningu og prófuðum hana síðan. Það sem var enn alvarlegra var uppfinningin á eigin reiðhjóli. En ég verð að viðurkenna að þessi lausn virkaði og leyfði stöðugri útgáfu.

Dagur # -701: Ansible og próf eldhús

Þróun Ansible prófunarhugmyndarinnar var notkun á tilbúnum verkfærum, nefnilega próf eldhús / eldhús-ci og inspec. Valið var ákvarðað af þekkingu Ruby (fyrir frekari upplýsingar, sjá grein um Habré: Dreymir YML forritara um að prófa Ansible?) virkaði hraðar, um 40 mínútur fyrir 10 hlutverk. Við bjuggum til pakka af sýndarvélum og keyrðum próf inni.

Almennt séð virkaði lausnin, en það var nokkuð af seti vegna misleitni. Þegar fjöldi þeirra sem prófaðir voru var aukinn í 13 grunnhlutverk og 2 metahlutverk sem sameinuðu smærri hlutverk, þá fóru prófin skyndilega að standa í 70 mínútur, sem er næstum 2 sinnum lengur. Það var erfitt að tala um XP (extreme programming) venjur vegna þess að... enginn vill bíða í 70 mínútur. Þetta var ástæðan fyrir breyttri nálgun

Dagur # -601: Ansible og sameind

Hugmyndalega er þetta svipað og testkitchen, aðeins við fluttum hlutverkaprófun í docker og breyttum stafla. Fyrir vikið var tíminn styttur í stöðugar 20-25 mínútur fyrir 7 hlutverk.

Með því að fjölga prófuðum hlutverkum upp í 17 og fóðra 45 hlutverk, keyrðum við þetta á 28 mínútum á 2 jenkins þrælum.

Dagur #167: Bætir Ansible prófum við verkefnið

Líklegast mun ekki vera hægt að gera endurvinnsluverkefnið í flýti. Verkefnið þarf að vera mælanlegt þannig að hægt sé að brjóta það í litla bita og borða fílinn bita fyrir bita með teskeið. Það verður að vera skilningur á því hvort þú sért að fara í rétta átt, hversu lengi á að fara.

Almennt séð er sama hvernig það verður gert, þú getur skrifað á blað, þú getur sett límmiða á skápinn, þú getur búið til verkefni í Jira eða þú getur opnað Google Docs og skrifað niður núverandi stöðu þar. Fæturnir vaxa af því að ferlið er ekki strax, það verður langt og leiðinlegt. Það er ólíklegt að einhver vilji að þú brennir út af hugmyndum, þreytist og verði óvart við endurvinnslu.

Endurnýjunin er einföld:

Borðaðu.
Sleep.
Kóði.
IaC próf.
Endurtaka

og við endurtökum þetta þar til við náum ætluðu markmiði.

Það er kannski ekki hægt að byrja að prófa allt strax, þannig að fyrsta verkefni okkar var að byrja á linting og athuga setningafræði.

Dagur #181: Green Build Master

Linting er lítið fyrsta skref í átt að Green Build Master. Þetta mun ekki brjóta nánast neitt, en það gerir þér kleift að kemba ferla og búa til grænar byggingar í Jenkins. Hugmyndin er að þróa venjur meðal teymisins:

Rauð próf eru slæm.
Ég kom til að laga eitthvað og um leið gera kóðann aðeins betri en hann var á undan þér.

Dagur #193: Frá fóðri til einingaprófa

Eftir að hafa byggt upp ferlið við að koma kóðanum inn í meistarann geturðu byrjað skref-fyrir-skref umbótaferlið - skiptu um fóðrun fyrir upphafshlutverk, þú getur jafnvel gert það án getuleysis. Þú þarft að skilja hvernig á að beita hlutverkum og hvernig þau virka.

Dagur #211: Frá einingu til samþættingarprófa

Þegar flest hlutverk eru þakin einingaprófum og allt er fóðrað geturðu haldið áfram að bæta við samþættingarprófum. Þeir. að prófa ekki einn múrstein í innviðunum, heldur samsetningu þeirra, til dæmis fulla tilviksstillingu.

Með því að nota jenkins bjuggum við til mörg stig sem fóðruðu hlutverk/leikrit samhliða, síðan einingapróf í gámum og loks samþættingarpróf.

Jenkins + Docker + Ansible = Próf

Afritaðu endurgreiðslu og búðu til byggingarstig.
Keyra lína leikbókarstig samhliða.
Keyrðu línhlutverkastig samhliða.
Keyra hlutverkaþrep setningafræðiskoðunar samhliða.
Keyrðu prófunarhlutverkastig samhliða.
1. Lint hlutverk.
2. Athugaðu ósjálfstæði á öðrum hlutverkum.
3. Athugaðu setningafræði.
4. Búðu til docker dæmi
5. Keyra molecule/default/playbook.yml.
6. Athugaðu getuleysi.
Keyra samþættingarpróf
Ljúka

Dagur #271: Strætóþáttur

Í fyrstu var endurhitun framkvæmd af litlum hópi tveggja eða þriggja manna. Þeir skoðuðu kóðann í masternum. Með tímanum þróaði teymið þekkingu á því hvernig á að skrifa kóða og endurskoðun kóða stuðlaði að miðlun þekkingar um innviðina og hvernig þeir virka. Hápunkturinn hér var að gagnrýnendur voru valdir einn af öðrum, samkvæmt dagskrá, þ.e. með einhverjum líkum á að þú klifrar inn í nýjan innviði.

Og hér ætti að vera þægilegt. Það er þægilegt að gera endurskoðun, sjá innan ramma hvers verkefnis það var unnið og sögu umræðna. Við höfum samþætt jenkins + bitbucket + jira.

En sem slík er umsögn ekki töfralausn; einhvern veginn komumst við inn í aðalkóðann, sem gerði okkur flopppróf:

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

Síðan festu þeir það, en leifar varð eftir.

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

Dagur #311: Flýtir prófum

Með tímanum voru fleiri prófanir, smíðin gengu hægar, allt að klukkutíma í versta falli. Á einni af afturmyndunum var setning eins og „það er gott að það eru próf, en þau eru hæg.“ Fyrir vikið hættum við samþættingarprófum á sýndarvélum og aðlaguðum þær að Docker til að gera það hraðvirkara. Við skiptum einnig út testinfra fyrir sannprófunaraðila til að fækka verkfærum sem notuð eru.

Strangt til tekið var sett af ráðstöfunum:

Skiptu yfir í docker.
Fjarlægðu hlutverkaprófun, sem er afrituð vegna ósjálfstæðis.
Fjölga þrælum.
Prófunarröð.
Hæfni til að lóa ALLT á staðnum með einni skipun.

Fyrir vikið var leiðsla á jenkins einnig sameinuð

Búðu til byggingarstig.
Lóð allt samhliða.
Keyrðu prófunarhlutverkastig samhliða.
Klára.

Lessons lært

Forðastu alþjóðlegar breytur

Ansible notar alþjóðlegar breytur, það er að hluta til lausn í formi einka_hlutverk_vars, en þetta er engin lækning.

Leyfðu mér að gefa þér dæmi. Leyfðu okkur að hafa 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ð fyndna er að útkoman úr leikbókum mun ráðast af hlutum sem eru ekki alltaf augljósir, eins og í hvaða röð hlutverkin eru skráð. Því miður er þetta eðli Ansible og það besta sem hægt er að gera er að nota einhvers konar samkomulag, til dæmis innan hlutverks, nota aðeins þá breytu sem lýst er í þessu hlutverki.

BAD: nota alþjóðlega breytu.

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

GOTT: V defaults skilgreina nauðsynlegar breytur og nota þær síðar aðeins.

# 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

Forskeyti hlutverkabreytur

BAD: nota alþjóðlega breytu.

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

GOTT: Í hlutverkum fyrir breytur, notaðu breytur með forskeyti hlutverksheitisins; þetta, með því að skoða birgðahald, gerir það auðveldara að skilja hvað er að gerast.

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

Notaðu lykkjustýringarbreytu

BAD: Notaðu staðlaða breytu í lykkjum item, ef þetta verkefni/leikrit er innifalið einhvers staðar getur þetta leitt til óvæntar hegðunar

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

GOTT: Endurskilgreina breytu í lykkju via loop_var.

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

Athugaðu inntaksbreytur

Við samþykktum að nota breytileg forskeyti; það væri ekki óþarfi að athuga hvort þau séu skilgreind eins og við búumst við og td ekki hnekkt með tómu gildi

GOTT: Athugaðu breytur.

- 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

Forðastu kjötkássaorðabækur, notaðu flata uppbyggingu

Ef hlutverk býst við kjötkássa/orðabók í einni af færibreytunum sínum, þá þurfum við að hnekkja öllu kjötkássa/orðabókinni, ef við viljum breyta einni af undirfæribreytunum, sem eykur uppsetningarflókið.

BAD: Notaðu kjötkássa/orðabók.

---
user:
  name: admin
  group: admin

GOTT: Notaðu flata breytilega uppbyggingu.

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

Búðu til geðveikar leikbækur og hlutverk

Hlutverk og leikbækur verða að vera máttlausar, því dregur úr stillingardrifi og ótta við að brjóta eitthvað. En ef þú notar sameind, þá er þetta sjálfgefin hegðun.

Forðastu að nota stjórnskeljareiningar

Notkun skeljareiningarinnar leiðir til bráðnauðsynlegrar lýsingarfyrirmyndar, í stað hinnar yfirlýsandi, sem er kjarninn í Ansible.

Prófaðu hlutverk þín í gegnum sameind

Sameind er mjög sveigjanlegur hlutur, við skulum skoða nokkrar aðstæður.

Sameind Mörg tilvik

В molecule.yml í kafla platforms þú getur lýst mörgum gestgjöfum sem þú getur notað.

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

Samkvæmt því geta þessir gestgjafar þá verið converge.yml nota:

---
- 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 sannprófandi

Í sameind er hægt að nota ansible til að athuga hvort tilvikið hafi verið rétt stillt, þar að auki hefur þetta verið sjálfgefið frá útgáfu 3. Það er ekki eins sveigjanlegt og testinfra/inspec, en við getum athugað hvort innihald skrárinnar samsvari væntingum okkar:

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

Eða notaðu þjónustuna, bíddu eftir að hún verði tiltæk og gerðu reykpróf:

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

Settu flókna rökfræði í einingar og viðbætur

Ansible talar fyrir yfirlýsandi nálgun, þannig að þegar þú gerir kóðagrein, gagnaumbreytingu, skeljaeiningar, verður kóðinn erfiður að lesa. Til að berjast gegn þessu og hafa það einfalt að skilja, væri ekki óþarfi að berjast gegn þessum margbreytileika með því að búa til þínar eigin einingar.

Taktu saman ábendingar og brellur

Forðastu alþjóðlegar breytur.
Forskeyti hlutverkabreytur.
Notaðu lykkjustýringarbreytu.
Athugaðu inntaksbreytur.
Forðastu kjötkássaorðabækur, notaðu flata uppbyggingu.
Búðu til geðveikar leikbækur og hlutverk.
Forðastu að nota stjórnskeljareiningar.
Prófaðu hlutverk þín í gegnum sameind.
Settu flókna rökfræði í einingar og viðbætur.

Ályktun

Þú getur ekki bara farið og endurskipuleggja innviðina í verkefni, jafnvel þó þú hafir IaC. Þetta er langt ferli sem krefst þolinmæði, tíma og þekkingar.

Tenglar

UPD1 2020.05.01 20:30 — Fyrir aðalsniðsgreiningu á leikbókum sem þú getur notað callback_whitelist = profile_tasks að skilja hvað nákvæmlega virkar í langan tíma. Svo förum við í gegn Anible hröðunarklassík. Þú getur líka prófað mítógen
UPD2 2020.05.03 16:34 - ensk útgáfa

Heimild: www.habr.com

Hvernig á að byrja að prófa Ansible, endurskoða verkefnið á einu ári og ekki klikka