🥇Paano simulan ang pagsubok sa Ansible, i-refactor ang isang proyekto sa isang taon at hindi mabaliw

Ito ang transcript mga pagtatanghal sa DevOps-40 2020-03-18:

Simula sa pangalawang commit, ang anumang code ay nagiging legacy, dahil ang mga paunang ideya ay nagsisimulang maghiwalay sa malupit na katotohanan. Ito ay hindi mabuti o masama, ito ay isang ibinigay na mahirap makipagtalo at dapat isabuhay. Bahagi ng prosesong ito ang refactoring. Refactoring Infrastructure bilang Code. Hayaang magsimula ang kwento kung paano i-refactor ang Ansible sa isang taon at hindi mabaliw.

Ang Kapanganakan ng Legacy

Araw #1: Pasyente Zero

Noong unang panahon ay may kondisyong proyekto. Mayroon itong Dev development team at mga Ops engineer. Nilulutas nila ang parehong problema: kung paano mag-deploy ng mga server at magpatakbo ng isang application. Ang problema ay nalutas ng bawat koponan ang problemang ito sa sarili nitong paraan. Sa proyekto, napagpasyahan na gamitin ang Ansible upang i-synchronize ang kaalaman sa pagitan ng mga koponan ng Dev at Ops.

Araw #89: Ang Kapanganakan ng Legacy

Nang hindi napapansin mismo, gusto nilang gawin ito hangga't maaari, ngunit ito ay naging pamana. Paano ito nangyayari?

Mayroon tayong apurahang gawain dito, gawin natin ang isang dirty hack at pagkatapos ay ayusin ito.
Hindi mo kailangang magsulat ng dokumentasyon at malinaw ang lahat kung ano ang nangyayari dito.
Alam ko ang Ansible/Python/Bash/Terraform! Tingnan mo kung paano ako makakaiwas!
Isa akong Full Stack Overflow Developer at kinopya ito mula sa stackoverflow, hindi ko alam kung paano ito gumagana, ngunit mukhang cool ito at nalulutas ang problema.

Bilang isang resulta, maaari kang makakuha ng isang hindi maintindihan na uri ng code kung saan walang dokumentasyon, hindi malinaw kung ano ang ginagawa nito, kung kinakailangan, ngunit ang problema ay kailangan mong bumuo nito, baguhin ito, magdagdag ng mga saklay at suporta. , na nagpapalala pa sa sitwasyon.

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

Araw #109: Kamalayan sa problema

Hindi na nakakatugon sa mga kinakailangan ng mga user/negosyo/iba pang mga team ang unang naisip at ipinatupad na modelo ng IaC, at ang oras para gumawa ng mga pagbabago sa imprastraktura ay hindi na katanggap-tanggap. Sa sandaling ito, dumating ang pag-unawa na oras na para kumilos.

refactoring ng IaC

Araw #139: Kailangan mo ba talagang refactoring?

Bago ka magmadali sa refactor, dapat mong sagutin ang ilang mahahalagang tanong:

Bakit kailangan mo ang lahat ng ito?
May oras ka ba?
Sapat na ba ang kaalaman?

Kung hindi mo alam kung paano sasagutin ang mga tanong, pagkatapos ay matatapos ang refactoring bago pa man ito magsimula, o maaari lamang itong lumala. kasi nagkaroon ng karanasan ( Ang Natutuhan Ko sa Pagsubok sa 200 Linya ng Infrastructure Code), pagkatapos ay nakatanggap ang proyekto ng isang kahilingan para sa tulong upang ayusin ang mga tungkulin at masakop ang mga ito sa mga pagsubok.

Araw #149: Paghahanda ng refactoring

Ang unang bagay ay ang paghahanda. Magpasya kung ano ang ating gagawin. Upang gawin ito, nakikipag-usap kami, naghahanap ng mga lugar ng problema at nag-iisip ng mga paraan upang malutas ang mga ito. Itinatala namin ang mga resultang konsepto sa anumang paraan, halimbawa isang artikulo sa pagsasama-sama, upang kapag lumitaw ang tanong na "ano ang pinakamahusay?" o "alin ang tama?" Hindi kami naliligaw ng landas. Sa aming kaso, kami ay nananatili sa ideya hatiin at tuntunin: hinahati namin ang imprastraktura sa maliliit na piraso/mga ladrilyo. Ang diskarte na ito ay nagbibigay-daan sa iyo na kumuha ng isang nakahiwalay na piraso ng imprastraktura, maunawaan kung ano ang ginagawa nito, takpan ito ng mga pagsubok at baguhin ito nang walang takot na masira ang anuman.

Lumalabas na ang pagsubok sa imprastraktura ang nagiging pundasyon at dito ito ay nagkakahalaga ng pagbanggit sa pyramid ng pagsubok sa imprastraktura. Eksakto ang parehong ideya na nasa pag-unlad, ngunit para sa imprastraktura: lumilipat kami mula sa murang mabilisang pagsubok na sumusuri sa mga simpleng bagay, tulad ng indentation, patungo sa mga mamahaling ganap na pagsubok na nagde-deploy ng buong imprastraktura.

Magagawang pagsubok na pagsubok

Bago natin ilarawan kung paano namin sinakop ang mga Ansible na pagsubok sa proyekto, ilalarawan ko ang mga pagtatangka at diskarte na nagkaroon ako ng pagkakataong gamitin nang mas maaga upang maunawaan ang konteksto ng mga desisyong ginawa.

Araw Blg. -997: Probisyon ng SDS

Ang unang pagkakataon na sinubukan ko ang Ansible ay nasa isang proyekto upang bumuo ng SDS (Software Defined Storage). Mayroong isang hiwalay na artikulo sa paksang ito
Paano masira ang mga bisikleta sa mga saklay kapag sinusubukan ang iyong pamamahagi, ngunit sa madaling salita, napunta kami sa isang baligtad na pagsubok na pyramid at pagsubok na ginugol namin ng 60-90 minuto sa isang tungkulin, na isang mahabang panahon. Ang batayan ay e2e tests, i.e. nag-deploy kami ng ganap na pag-install at pagkatapos ay sinubukan ito. Ang lalong nagpalubha ay ang pag-imbento ng sarili niyang bisikleta. Ngunit dapat kong aminin, ang solusyon na ito ay nagtrabaho at pinapayagan para sa isang matatag na paglabas.

Araw # -701: Ansible at pagsubok na kusina

Ang pagbuo ng ideya sa pagsubok ng Ansible ay ang paggamit ng mga yari na tool, katulad ng pagsubok sa kusina / kusina-ci at inspec. Ang pagpili ay tinutukoy ng kaalaman tungkol kay Ruby (para sa higit pang mga detalye, tingnan ang artikulo sa Habré: Nangangarap ba ang mga programmer ng YML na subukan ang Ansible?) nagtrabaho nang mas mabilis, mga 40 minuto para sa 10 mga tungkulin. Gumawa kami ng isang pakete ng mga virtual machine at nagpatakbo ng mga pagsubok sa loob.

Sa pangkalahatan, gumana ang solusyon, ngunit mayroong ilang sediment dahil sa heterogeneity. Nang ang bilang ng mga taong nasubok ay nadagdagan sa 13 pangunahing tungkulin at 2 meta na tungkulin na pinagsasama ang mas maliliit na tungkulin, biglang nagsimulang tumakbo ang mga pagsusulit sa loob ng 70 minuto, na halos 2 beses na mas mahaba. Mahirap pag-usapan ang tungkol sa XP (extreme programming) practices dahil... walang gustong maghintay ng 70 minuto. Ito ang dahilan ng pagbabago ng diskarte

Araw # -601: Ansible at molekula

Sa konsepto, ito ay katulad ng testkitchen, inilipat lamang namin ang pagsubok sa tungkulin sa docker at binago ang stack. Bilang resulta, ang oras ay nabawasan sa isang matatag na 20-25 minuto para sa 7 mga tungkulin.

Sa pamamagitan ng pagtaas ng bilang ng mga nasubok na tungkulin sa 17 at paglilipat ng 45 na tungkulin, pinatakbo namin ito sa loob ng 28 minuto sa 2 jenkins na alipin.

Araw #167: Pagdaragdag ng mga Ansible na pagsubok sa proyekto

Malamang, hindi posibleng gawin ang refactoring task nang nagmamadali. Ang gawain ay dapat na masusukat upang maaari mong hatiin ito sa maliliit na piraso at kainin ang elepante sa bawat piraso na may isang kutsarita. Dapat mayroong isang pag-unawa kung ikaw ay gumagalaw sa tamang direksyon, kung gaano katagal upang pumunta.

Sa pangkalahatan, hindi mahalaga kung paano ito gagawin, maaari kang magsulat sa isang piraso ng papel, maaari kang maglagay ng mga sticker sa closet, maaari kang lumikha ng mga gawain sa Jira, o maaari mong buksan ang Google Docs at isulat ang kasalukuyang katayuan doon. Ang mga binti ay lumalaki mula sa katotohanan na ang proseso ay hindi kaagad, ito ay magiging mahaba at nakakapagod. Hindi malamang na may gustong mawalan ka ng mga ideya, mapagod, at mabigla sa panahon ng refactoring.

Ang refactoring ay simple:

Kumain.
Matulog.
Code
pagsubok sa IaC.
Ulitin

at inuulit natin ito hanggang sa maabot natin ang nilalayon na layunin.

Maaaring hindi posible na simulan ang pagsubok ng lahat kaagad, kaya ang una naming gawain ay magsimula sa linting at pagsuri sa syntax.

Araw #181: Green Build Master

Ang linting ay isang maliit na unang hakbang patungo sa Green Build Master. Hindi nito masisira ang halos anumang bagay, ngunit magbibigay-daan ito sa iyong i-debug ang mga proseso at gumawa ng mga berdeng build sa Jenkins. Ang ideya ay bumuo ng mga gawi sa pangkat:

Ang mga pulang pagsusulit ay masama.
Dumating ako upang ayusin ang isang bagay at kasabay nito ay gawing mas mahusay ang code kaysa sa nauna sa iyo.

Araw #193: Mula sa linting hanggang sa mga unit test

Ang pagkakaroon ng pagbuo ng proseso ng pagkuha ng code sa master, maaari mong simulan ang proseso ng sunud-sunod na pagpapabuti - pagpapalit ng linting sa paglulunsad ng mga tungkulin, maaari mo ring gawin ito nang walang idempotency. Kailangan mong maunawaan kung paano ilapat ang mga tungkulin at kung paano gumagana ang mga ito.

Araw #211: Mula sa unit hanggang sa mga integration test

Kapag ang karamihan sa mga tungkulin ay sakop ng mga unit test at lahat ay nakalagay, maaari kang magpatuloy sa pagdaragdag ng mga integration test. Yung. pagsubok hindi isang solong brick sa imprastraktura, ngunit isang kumbinasyon ng mga ito, halimbawa, isang buong pagsasaayos ng halimbawa.

Gamit ang jenkins, nakabuo kami ng maraming yugto na naglalagay ng mga tungkulin/playbook nang magkatulad, pagkatapos ay ang mga unit test sa mga container, at panghuli ang mga integration test.

Jenkins + Docker + Ansible = Mga Pagsubok

Mag-checkout ng repo at bumuo ng mga yugto ng pagbuo.
Patakbuhin ang mga yugto ng lint playbook nang magkatulad.
Patakbuhin ang mga yugto ng lint role nang magkatulad.
Patakbuhin ang syntax check na mga yugto ng tungkulin nang magkatulad.
Patakbuhin ang mga yugto ng tungkulin sa pagsubok nang magkatulad.
1. Lint na papel.
2. Suriin ang dependency sa iba pang mga tungkulin.
3. Suriin ang syntax.
4. Lumikha ng instance ng docker
5. Patakbuhin ang molecule/default/playbook.yml.
6. Suriin ang idempotency.
Magpatakbo ng mga pagsubok sa pagsasama
Tapusin

Araw #271: Bus Factor

Sa una, ang refactoring ay isinasagawa ng isang maliit na grupo ng dalawa o tatlong tao. Sinuri nila ang code sa master. Sa paglipas ng panahon, ang koponan ay nakabuo ng kaalaman kung paano magsulat ng code at pagsusuri ng code ay nag-ambag sa pagpapalaganap ng kaalaman tungkol sa imprastraktura at kung paano ito gumagana. Ang highlight dito ay ang mga reviewer ay napili nang isa-isa, ayon sa isang iskedyul, i.e. na may ilang antas ng posibilidad na aakyat ka sa isang bagong piraso ng imprastraktura.

At dapat maging komportable dito. Maginhawang gumawa ng pagsusuri, tingnan sa loob ng balangkas kung anong gawain ang ginawa nito, at ang kasaysayan ng mga talakayan. Pinagsama namin ang jenkins + bitbucket + jira.

Ngunit dahil dito, ang isang pagsusuri ay hindi isang panlunas sa lahat; kahit papaano, nakuha namin ang master code, na gumawa sa amin ng mga flop test:

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

Pagkatapos ay inayos nila ito, ngunit nanatili ang sediment.

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

Araw #311: Pagpapabilis ng mga pagsusulit

Sa paglipas ng panahon, nagkaroon ng higit pang mga pagsubok, ang mga build ay tumakbo nang mas mabagal, hanggang sa isang oras sa pinakamasamang kaso. Sa isa sa mga retro ay mayroong pariralang tulad ng "mabuti na may mga pagsubok, ngunit mabagal ang mga ito." Bilang resulta, inabandona namin ang mga pagsubok sa pagsasama sa mga virtual machine at inangkop ang mga ito para sa Docker na gawin itong mas mabilis. Pinalitan din namin ang testinfra ng ansible verifier para bawasan ang bilang ng mga tool na ginamit.

Sa mahigpit na pagsasalita, mayroong isang hanay ng mga hakbang:

Lumipat sa docker.
Alisin ang pagsubok sa tungkulin, na nadoble dahil sa mga dependency.
Palakihin ang bilang ng mga alipin.
Test run order.
Kakayahang mag-lint LAHAT lokal na may isang utos.

Dahil dito, pinag-isa rin ang Pipeline sa jenkins

Bumuo ng mga yugto ng pagbuo.
Lint lahat sa parallel.
Patakbuhin ang mga yugto ng tungkulin sa pagsubok nang magkatulad.
Matapos.

Aralin natutunan

Iwasan ang mga global variable

Ang Ansible ay gumagamit ng mga pandaigdigang variable, mayroong isang bahagyang workaround sa form private_role_vars, ngunit hindi ito isang panlunas sa lahat.

Bigyan kita ng isang halimbawa. Hayaan na natin 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}}

Ang nakakatuwang bagay ay ang resulta ng mga playbook ay depende sa mga bagay na hindi palaging halata, tulad ng pagkakasunud-sunod kung saan nakalista ang mga tungkulin. Sa kasamaang palad, ito ang katangian ng Ansible at ang pinakamagandang bagay na maaaring gawin ay ang gumamit ng ilang uri ng kasunduan, halimbawa, sa loob ng isang tungkulin, gamitin lamang ang variable na inilalarawan sa tungkuling ito.

Masama: gumamit ng global variable.

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

Mabuti: V defaults tukuyin ang mga kinakailangang variable at pagkatapos ay gamitin lamang ang mga ito.

# 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

Mga variable ng tungkulin ng prefix

Masama: gumamit ng global variable.

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

Mabuti: Sa mga tungkulin para sa mga variable, gumamit ng mga variable na may prefix na pangalan ng tungkulin; ito, sa pamamagitan ng pagtingin sa imbentaryo, ay gagawing mas madaling maunawaan kung ano ang nangyayari.

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

Gumamit ng loop control variable

Masama: Gumamit ng karaniwang variable sa mga loop item, kung ang gawain/playbook na ito ay kasama sa isang lugar, maaari itong humantong sa hindi inaasahang pag-uugali

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

Mabuti: Muling tukuyin ang isang variable sa isang loop sa pamamagitan ng loop_var.

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

Suriin ang mga variable ng input

Sumang-ayon kaming gumamit ng mga variable na prefix; hindi magiging kalabisan na suriin kung tinukoy ang mga ito gaya ng inaasahan namin at, halimbawa, hindi na-override ng walang laman na halaga.

Mabuti: Suriin ang mga variable.

- 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

Iwasan ang mga diksyunaryo ng hash, gumamit ng flat structure

Kung inaasahan ng isang tungkulin ang isang hash/diksyonaryo sa isa sa mga parameter nito, kung gusto naming baguhin ang isa sa mga parameter ng bata, kakailanganin naming i-override ang buong hash/diksyonaryo, na magpapataas sa pagiging kumplikado ng configuration.

Masama: Gumamit ng hash/diksyonaryo.

---
user:
  name: admin
  group: admin

Mabuti: Gumamit ng flat variable structure.

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

Gumawa ng mga idempotent na playbook at tungkulin

Ang mga tungkulin at playbook ay dapat na idempotent, dahil binabawasan ang configuration drift at takot na masira ang isang bagay. Ngunit kung gumagamit ka ng molekula, kung gayon ito ang default na pag-uugali.

Iwasang gumamit ng command shell modules

Ang paggamit ng shell module ay nagreresulta sa isang mahalagang paradigm sa paglalarawan, sa halip na ang deklaratibo, na siyang ubod ng Ansible.

Subukan ang iyong mga tungkulin sa pamamagitan ng molekula

Ang Molecule ay isang napaka-flexible na bagay, tingnan natin ang ilang mga sitwasyon.

Molecule Maramihang mga pagkakataon

В molecule.yml sa seksyon platforms maaari mong ilarawan ang maraming mga host na maaari mong i-deploy.

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

Alinsunod dito, maaaring maging ang mga host na ito converge.yml gamitin:

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

Mahusay na verifier

Sa molekula posible na gumamit ng ansible upang suriin na ang instance ay na-configure nang tama, bukod dito, ito ang naging default mula noong release 3. Hindi ito kasing-flexible gaya ng testinfra/inspec, ngunit maaari naming suriin kung ang mga nilalaman ng file ay tumutugma sa aming mga inaasahan:

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

O i-deploy ang serbisyo, hintayin itong maging available at magsagawa ng smoke test:

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

Ilagay ang kumplikadong lohika sa mga module at plugin

Ang Ansible ay nagtataguyod ng isang deklaratibong diskarte, kaya kapag gumawa ka ng code branching, pagbabago ng data, shell module, nagiging mahirap basahin ang code. Upang labanan ito at panatilihin itong simple upang maunawaan, hindi magiging kalabisan upang labanan ang pagiging kumplikado sa pamamagitan ng paglikha ng iyong sariling mga module.

Ibuod ang Mga Tip at Trick

Iwasan ang mga global variable.
Mga variable ng tungkulin ng prefix.
Gumamit ng loop control variable.
Suriin ang mga variable ng input.
Iwasan ang mga diksyunaryo ng hash, gumamit ng flat structure.
Gumawa ng mga idempotent na playbook at tungkulin.
Iwasang gumamit ng command shell modules.
Subukan ang iyong mga tungkulin sa pamamagitan ng molekula.
Ilagay ang kumplikadong lohika sa mga module at plugin.

Konklusyon

Hindi ka basta-basta maaaring pumunta at refactor ang imprastraktura sa isang proyekto, kahit na mayroon kang IaC. Ito ay isang mahabang proseso na nangangailangan ng pasensya, oras at kaalaman.

Links

UPD1 2020.05.01 20:30 — Para sa pangunahing pag-profile ng mga playbook na magagamit mo callback_whitelist = profile_tasks upang maunawaan kung ano ang eksaktong gumagana sa mahabang panahon. Tapos dumaan kami Ansible acceleration classics. Maaari mo ring subukan mitogen
UPD2 2020.05.03 16:34 - Angielski bersiyon

Pinagmulan: www.habr.com

Paano simulan ang pagsubok sa Ansible, refactor ang proyekto sa isang taon at hindi mabaliw