Si të filloni testimin e Ansible, rifaktoroni projektin brenda një viti dhe të mos çmendeni

Ky është transkripti shfaqje mbi DevOps-40 2020-03-18:

Duke filluar nga kryerja e dytë, çdo kod bëhet trashëgimi, sepse idetë fillestare fillojnë të ndryshojnë nga realiteti i ashpër. Kjo nuk është as e mirë as e keqe, është një e dhënë me të cilën është e vështirë të debatohet dhe duhet jetuar. Një pjesë e këtij procesi është rifaktorimi. Rifaktorimi i Infrastrukturës si Kod. Le të fillojë historia se si të rifaktosh Ansible brenda një viti dhe të mos çmendesh.

Lindja e Trashëgimisë

Dita #1: Pacienti Zero

Njëherë e një kohë ishte një projekt i kushtëzuar. Kishte një ekip zhvillimi Dev dhe inxhinierë të Ops. Ata po zgjidhnin të njëjtin problem: si të vendosnin serverët dhe të ekzekutonin një aplikacion. Problemi ishte se çdo ekip e zgjidhte këtë problem në mënyrën e vet. Në projekt, u vendos që të përdoret Ansible për të sinkronizuar njohuritë midis ekipeve Dev dhe Ops.

Dita #89: Lindja e Trashëgimisë

Pa e vënë re vetë, donin ta bënin sa më mirë, por rezultoi se ishte trashëgimi. Si ndodh kjo?

• Këtu kemi një detyrë urgjente, le të bëjmë një hak të pistë dhe pastaj ta rregullojmë.
• Ju nuk keni nevojë të shkruani dokumentacion dhe gjithçka është e qartë se çfarë po ndodh këtu.
• Unë e njoh Ansible/Python/Bash/Terraform! Shiko si mund t'i shmangem!
• Unë jam një Zhvillues i Full Stack Overflow dhe e kopjova këtë nga stackoverflow, nuk e di se si funksionon, por duket e lezetshme dhe e zgjidh problemin.

Si rezultat, ju mund të merrni një lloj kodi të pakuptueshëm për të cilin nuk ka dokumentacion, nuk është e qartë se çfarë bën, nëse është e nevojshme, por problemi është se ju duhet ta zhvilloni, modifikoni, shtoni paterica dhe mbështetëse , duke e përkeqësuar edhe më shumë situatë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")

Dita #109: Ndërgjegjësimi për problemin

Modeli IaC i konceptuar dhe zbatuar fillimisht nuk i plotëson më kërkesat e përdoruesve/biznesit/skuadrave të tjera dhe koha për të bërë ndryshime në infrastrukturë pushon së qeni e pranueshme. Në këtë moment, kuptohet se është koha për të ndërmarrë veprime.

Rifaktorimi IaC

Dita #139: A keni vërtet nevojë për rifaktorim?

Para se të nxitoni për të rifaktoruar, duhet t'i përgjigjeni një numri pyetjesh të rëndësishme:

1. Pse keni nevojë për të gjitha këto?
2. A keni kohe?
3. A mjafton njohuria?

Nëse nuk dini si t'u përgjigjeni pyetjeve, atëherë rifaktorimi do të përfundojë para se të fillojë, ose mund të përkeqësohet. Sepse kishte përvojë ( Çfarë mësova nga testimi i 200 linjave të kodit të infrastrukturës), më pas projekti mori një kërkesë për ndihmë për të rregulluar rolet dhe për t'i mbuluar ato me teste.

Dita #149: Përgatitja e rifaktorimit

Gjëja e parë është përgatitja. Vendosni se çfarë do të bëjmë. Për ta bërë këtë, ne komunikojmë, gjejmë zonat problematike dhe gjejmë mënyra për t'i zgjidhur ato. Ne i regjistrojmë konceptet që rezultojnë disi, për shembull një artikull në kombinim, në mënyrë që kur të lind pyetja "çfarë është më e mira?" ose "cila është e saktë?" Nuk e kemi humbur rrugën. Në rastin tonë, ne i qëndruam idesë nda dhe sundo: ne ndajmë infrastrukturën në copa/tulla të vogla. Kjo qasje ju lejon të merrni një pjesë të izoluar të infrastrukturës, të kuptoni se çfarë bën, ta mbuloni atë me teste dhe ta ndryshoni atë pa frikë se mos prishni asgjë.

Rezulton se testimi i infrastrukturës bëhet gur themeli dhe këtu vlen të përmendet piramida e testimit të infrastrukturës. Pikërisht e njëjta ide që është në zhvillim, por për infrastrukturën: ne po kalojmë nga teste të shpejta të lira që kontrollojnë gjëra të thjeshta, si p.sh. dhëmbëzimi, në teste të shtrenjta të plota që shpërndajnë të gjithë infrastrukturën.

Përpjekje të pandërprera testimi

Përpara se të shkojmë të përshkruajmë se si kemi mbuluar testet e Ansible në projekt, unë do të përshkruaj përpjekjet dhe qasjet që pata mundësinë të përdor më herët për të kuptuar kontekstin e vendimeve të marra.

Dita Nr. -997: Sigurimi i SDS

Hera e parë që testova Ansible ishte në një projekt për të zhvilluar SDS (Software Defined Storage). Ekziston një artikull i veçantë për këtë temë
Si të thyeni biçikletat mbi paterica kur testoni shpërndarjen tuaj, por me pak fjalë, përfunduam me një piramidë testimi të përmbysur dhe testimit kaluam 60-90 minuta për një rol, që është një kohë e gjatë. Baza ishin testet e2e, d.m.th. ne vendosëm një instalim të plotë dhe më pas e testuam atë. Ajo që ishte edhe më rënduese ishte shpikja e biçikletës së tij. Por duhet të pranoj, kjo zgjidhje funksionoi dhe lejoi një çlirim të qëndrueshëm.

Dita # -701: Kuzhinë e sigurt dhe testuese

Zhvillimi i idesë së testimit të Ansible ishte përdorimi i mjeteve të gatshme, përkatësisht testi i kuzhinës / kuzhinës-ci dhe inspec. Zgjedhja u përcaktua nga njohuritë e Ruby (për më shumë detaje, shihni artikullin në Habré: A ëndërrojnë programuesit YML të testojnë Ansible?) ka punuar më shpejt, rreth 40 minuta për 10 role. Ne krijuam një paketë makinash virtuale dhe bëmë teste brenda.

Në përgjithësi, zgjidhja funksionoi, por kishte disa sedimente për shkak të heterogjenitetit. Kur numri i personave të testuar u rrit në 13 role bazë dhe 2 meta role duke kombinuar role më të vogla, atëherë befas testet filluan të zgjasin për 70 minuta, që është pothuajse 2 herë më e gjatë. Ishte e vështirë të flisje për praktikat XP (programim ekstrem), sepse... askush nuk dëshiron të presë 70 minuta. Kjo ishte arsyeja e ndryshimit të qasjes

Dita # -601: Ansible dhe molekula

Konceptualisht, kjo është e ngjashme me kuzhinën e testimit, vetëm ne e zhvendosëm testimin e roleve në doker dhe ndryshuam stivën. Si rezultat, koha u reduktua në 20-25 minuta të qëndrueshme për 7 role.

Duke rritur numrin e roleve të testuara në 17 dhe duke vendosur 45 role, ne e realizuam këtë në 28 minuta në 2 skllevër jenkins.

Dita #167: Shtimi i testeve Ansible në projekt

Me shumë mundësi, nuk do të jetë e mundur të kryeni detyrën e rifaktorimit me nxitim. Detyra duhet të jetë e matshme në mënyrë që ta copëtoni në copa të vogla dhe ta hani elefantin pjesë-pjesë me një lugë çaji. Duhet të ketë një kuptim nëse po lëvizni në drejtimin e duhur, sa kohë duhet të shkoni.

Në përgjithësi, nuk ka rëndësi se si do të bëhet, mund të shkruani në një copë letër, mund të vendosni ngjitëse në dollap, mund të krijoni detyra në Jira, ose mund të hapni Google Docs dhe të shkruani statusin aktual atje. Këmbët rriten nga fakti se procesi nuk është i menjëhershëm, do të jetë i gjatë dhe i lodhshëm. Nuk ka gjasa që dikush të dëshirojë që ju të digjeni nga idetë, të lodheni dhe të mbingarkoheni gjatë rifaktorimit.

Rifaktorimi është i thjeshtë:

• Hani.
• Fle.
• Kodin
• Testi IaC.
• Përsëritje

dhe këtë e përsërisim derisa të arrijmë qëllimin e synuar.

Mund të mos jetë e mundur të fillojmë të testojmë gjithçka menjëherë, kështu që detyra jonë e parë ishte të fillonim me linting dhe kontrollimin e sintaksës.

Dita #181: Master Build Green

Linting është një hap i parë i vogël drejt Green Build Master. Kjo nuk do të prishë pothuajse asgjë, por do t'ju lejojë të korrigjoni proceset dhe të bëni ndërtime jeshile në Jenkins. Ideja është që të zhvillohen zakone midis ekipit:

• Testet e kuqe janë të këqija.
• Erdha për të rregulluar diçka dhe në të njëjtën kohë për ta bërë kodin pak më të mirë se sa ishte para jush.

Dita #193: Nga garnitura deri te testet e njësisë

Pasi të keni ndërtuar procesin e marrjes së kodit në master, mund të filloni procesin e përmirësimit hap pas hapi - duke zëvendësuar lirimin me role nisëse, madje mund ta bëni pa idempotencë. Ju duhet të kuptoni se si të aplikoni rolet dhe si funksionojnë ato.

Dita #211: Nga njësia në testet e integrimit

Kur shumica e roleve janë të mbuluara me teste njësie dhe çdo gjë është e mbuluar, mund të vazhdoni te shtimi i testeve të integrimit. Ato. duke testuar jo një tullë të vetme në infrastrukturë, por një kombinim të tyre, për shembull, një konfigurim të plotë të shembullit.

Duke përdorur jenkins, ne krijuam shumë faza që lidhnin role/libra lojërash paralelisht, më pas testet e njësive në kontejnerë dhe në fund testet e integrimit.

Jenkins + Docker + Ansible = Teste

1. Kontrolloni depon dhe gjeneroni fazat e ndërtimit.
2. Ekzekutoni paralelisht fazat e librit të luajtjes me garzë.
3. Drejtoni paralelisht fazat e roleve të garzës.
4. Ekzekutoni paralelisht fazat e rolit të kontrollit të sintaksës.
5. Drejtoni paralelisht fazat e roleve të testit.
   1. Roli i garzës.
   2. Kontrolloni varësinë nga rolet e tjera.
   3. Kontrollo sintaksën.
   4. Krijo shembull docker
   5. Run molecule/default/playbook.yml.
   6. Kontrolloni idempotencën.
6. Kryeni testet e integrimit
7. Fund

Dita #271: Autobus Factor

Në fillim, rifaktorimi u krye nga një grup i vogël prej dy ose tre personash. Ata rishikuan kodin në master. Me kalimin e kohës, ekipi zhvilloi njohuri se si të shkruhet kodi dhe rishikimi i kodit kontribuoi në shpërndarjen e njohurive rreth infrastrukturës dhe se si funksionon ajo. Pika kryesore këtu ishte se recensentët u përzgjodhën një nga një, sipas një plani, d.m.th. me një farë probabiliteti do të ngjiteni në një pjesë të re të infrastrukturës.

Dhe këtu duhet të jetë e rehatshme. Është i përshtatshëm për të bërë një rishikim, për të parë në kuadrin e asaj detyre që është bërë dhe historinë e diskutimeve. Ne kemi integruar jenkins + bitbucket + jira.

Por si i tillë, një rishikim nuk është një ilaç; disi, ne u futëm në kodin kryesor, i cili na bëri teste flop:

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

Më pas e rregulluan, por sedimenti mbeti.

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

Dita #311: Përshpejtimi i testeve

Me kalimin e kohës, pati më shumë teste, ndërtimet u zhvilluan më ngadalë, deri në një orë në rastin më të keq. Në një nga retrot kishte një frazë si "është mirë që ka teste, por ato janë të ngadalta". Si rezultat, ne braktisëm testet e integrimit në makinat virtuale dhe i përshtatëm ato për Docker për ta bërë atë më të shpejtë. Ne gjithashtu zëvendësuam testinfra me verifikues ansible për të zvogëluar numrin e mjeteve të përdorura.

Në mënyrë të rreptë, kishte një sërë masash:

1. Kalo në docker.
2. Hiq testimin e roleve, i cili është i dyfishuar për shkak të varësive.
3. Rritja e numrit të skllevërve.
4. Rendi i ekzekutimit të testit.
5. Aftësia për të garzë TE GJITHA lokalisht me një komandë.

Si rezultat, Pipeline mbi jenkins u unifikua gjithashtu

1. Gjeneroni fazat e ndërtimit.
2. Linto të gjitha paralelisht.
3. Drejtoni paralelisht fazat e roleve të testit.
4. Finish.

Mësimet e nxjerra

Shmangni variablat globale

Ansible përdor variabla globale, ka një zgjidhje të pjesshme në formë role_private, por kjo nuk është një ilaç.

Më lejoni t'ju jap një shembull. Le të kemi 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}}

Gjëja qesharake është se rezultati i librave të lojërave do të varet nga gjëra që nuk janë gjithmonë të dukshme, siç është radha në të cilën renditen rolet. Fatkeqësisht, kjo është natyra e Ansible dhe gjëja më e mirë që mund të bëhet është të përdorni një lloj marrëveshjeje, për shembull, brenda një roli, përdorni vetëm variablin e përshkruar në këtë rol.

KEQ: përdorni variablin global.

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

MIRA: V defaults përcaktoni variablat e nevojshme dhe më vonë përdorni vetëm ato.

# 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

Variablat e rolit të prefiksit

KEQ: përdorni variablin global.

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

MIRA: Në rolet për variabla, përdorni variabla të prefiksuara me emrin e rolit; kjo, duke parë inventarin, do ta bëjë më të lehtë për të kuptuar se çfarë po ndodh.

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

Përdorni variablin e kontrollit të ciklit

KEQ: Përdorni variabël standarde në sythe item, nëse kjo detyrë/libër lojërash përfshihet diku, kjo mund të çojë në sjellje të papritur

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

MIRA: Ridefinoni një variabël në një cikli via loop_var.

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

Kontrolloni variablat e hyrjes

Ne ramë dakord të përdorim parashtesa të variablave; nuk do të ishte e tepërt të kontrollonim që ato të përcaktohen siç presim dhe, për shembull, të mos jenë anashkaluar nga një vlerë boshe

MIRA: Kontrolloni variablat.

- 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

Shmangni fjalorët hash, përdorni strukturë të sheshtë

Nëse një rol pret një hash/fjalor në një nga parametrat e tij, atëherë nëse duam të ndryshojmë një nga parametrat fëmijë, do të na duhet të anashkalojmë të gjithë hash/fjalorin, gjë që do të rrisë kompleksitetin e konfigurimit.

KEQ: Përdorni hash/fjalor.

---
user:
  name: admin
  group: admin

MIRA: Përdorni një strukturë të ndryshueshme të sheshtë.

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

Krijo libra dhe role idempotente

Rolet dhe librat duhet të jenë të pafuqishëm, sepse zvogëlon zhvendosjen e konfigurimit dhe frikën për të thyer diçka. Por nëse përdorni molekulë, atëherë kjo është sjellja e paracaktuar.

Shmangni përdorimin e moduleve të guaskës së komandës

Përdorimi i një moduli shell rezulton në një paradigmë përshkrimi imperativ, në vend të asaj deklarative, e cila është thelbi i Ansible.

Testoni rolet tuaja nëpërmjet molekulës

Molekula është një gjë shumë fleksibël, le të shohim disa skenarë.

Molekula Raste të shumta

В molecule.yml në seksion platforms ju mund të përshkruani shumë hoste që mund të vendosni.

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

Në përputhje me rrethanat, këta pritës mund të jenë converge.yml përdorni:

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

Verifikues i përgjegjshëm

Në molekulë është e mundur të përdoret ansible për të kontrolluar nëse shembulli është konfiguruar saktë, për më tepër, ky ka qenë parazgjedhja që nga lëshimi 3. Nuk është aq fleksibël sa testinfra/inspec, por mund të kontrollojmë që përmbajtja e skedarit përputhet me pritjet tona:

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

Ose vendoseni shërbimin, prisni që ai të bëhet i disponueshëm dhe bëni një test tymi:

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

Vendos logjikë komplekse në module dhe shtojca

Ansible mbron një qasje deklarative, kështu që kur bëni degëzimin e kodit, transformimin e të dhënave, modulet e guaskës, kodi bëhet i vështirë për t'u lexuar. Për ta luftuar këtë dhe për ta mbajtur të thjeshtë për t'u kuptuar, nuk do të ishte e tepërt ta luftoni këtë kompleksitet duke krijuar modulet tuaja.

Përmblidhni këshilla dhe truket

1. Shmangni variablat globale.
2. Variablat e rolit të prefiksit.
3. Përdorni variablin e kontrollit të ciklit.
4. Kontrolloni variablat e hyrjes.
5. Shmangni fjalorët hash, përdorni strukturë të sheshtë.
6. Krijo libra dhe role idempotente.
7. Shmangni përdorimin e moduleve të guaskës së komandës.
8. Testoni rolet tuaja nëpërmjet molekulës.
9. Vendos logjikë komplekse në module dhe shtojca.

Përfundim

Ju nuk mund të shkoni thjesht dhe të rifaktoni infrastrukturën në një projekt, edhe nëse keni IaC. Ky është një proces i gjatë që kërkon durim, kohë dhe njohuri.

Lidhjet

• Slides Si të testoni Ansible dhe mos u çmendni
• Video Si të testoni Ansible dhe mos u çmendni
• Çfarë mësova nga testimi i 200 linjave të kodit të infrastrukturës
• Ansible: Migrimi i konfigurimit të 120 VM nga Coreos në Centos në 18 muaj
• Si të thyeni biçikletat mbi paterica kur testoni shpërndarjen tuaj
• Më testoni nëse mundeni apo programuesit YML ëndërrojnë të testojnë Ansible?
• Një listë e artikujve, fjalimeve dhe lidhjeve të mrekullueshme të testimit të IaC
• shtyllë kryq
• versioni anglisht

UPD1 2020.05.01 20:30 — Për profilizimin parësor të librave të lojërave mund të përdorni callback_whitelist = profile_tasks për të kuptuar se çfarë funksionon saktësisht për një kohë të gjatë. Pastaj kalojmë Klasikë të përshpejtimit të paanshëm. Ju gjithashtu mund të provoni mitogjen
UPD2 2020.05.03 16:34 - versioni anglisht

Burimi: www.habr.com