Ansible-ı sınamağa necə başlamaq lazımdır, bir il ərzində layihəni yenidən nəzərdən keçirin və dəli olmayın

Budur transkript Göstəriləcək tamaşalar haqqında DevOps-40 2020:

İkinci öhdəlikdən başlayaraq istənilən kod miras olur, çünki ilkin fikirlər sərt reallıqdan uzaqlaşmağa başlayır. Bu, nə yaxşı, nə də pisdir, mübahisə etmək çətin və yaşamaq lazım olan bir verilmişdir. Bu prosesin bir hissəsi refaktorinqdir. İnfrastrukturun Kod kimi Refaktorinqi. Hekayə bir il ərzində Ansible-i necə refaktor etmək və dəli olmamaq barədə başlasın.

Mirasın doğulması

Gün # 1: Xəstə Sıfır

Bir vaxtlar şərti layihə var idi. Onun Dev inkişaf komandası və əməliyyat mühəndisləri var idi. Onlar eyni problemi həll edirdilər: serverləri necə yerləşdirmək və tətbiqi işə salmaq. Problem onda idi ki, hər komanda bu problemi özünəməxsus şəkildə həll edirdi. Layihədə, Dev və Ops komandaları arasında bilikləri sinxronlaşdırmaq üçün Ansible-dan istifadə etmək qərara alındı.

89-cu gün: Mirasın doğulması

Özləri də fərqinə varmadan bunu mümkün qədər yaxşı etmək istədilər, amma miras qaldı. Bu necə baş verir?

• Burada təcili bir işimiz var, gəlin bir çirkli hack edək və sonra onu düzəldək.
• Sənədlər yazmağa ehtiyac yoxdur və burada nə baş verdiyi hər şey aydındır.
• Mən Ansible/Python/Bash/Terraform-u bilirəm! Görün necə qaça bilərəm!
• Mən Full Stack Overflow Developerəm və bunu stackoverflow-dan köçürdüm, onun necə işlədiyini bilmirəm, lakin o, gözəl görünür və problemi həll edir.

Nəticədə, heç bir sənədi olmayan anlaşılmaz bir kod növü əldə edə bilərsiniz, bunun nə etdiyi, lazım olub-olmadığı aydın deyil, amma problem ondadır ki, onu inkişaf etdirməli, dəyişdirməli, qoltuq və dayaqlar əlavə etməlisiniz. , vəziyyəti daha da pisləşdirir.

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

Gün # 109: Problemin fərqindəlik

Əvvəlcə düşünülmüş və tətbiq edilmiş IaC modeli artıq istifadəçilərin / biznesin / digər komandaların tələblərinə cavab vermir və infrastrukturda dəyişiklik etmək üçün vaxt artıq məqbul deyil. Bu anda hərəkətə keçməyin vaxtı olduğu anlayışı gəlir.

IaC refaktorinqi

Gün # 139: Həqiqətən refaktorinq lazımdırmı?

Refaktora tələsməzdən əvvəl bir sıra vacib suallara cavab verməlisiniz:

1. Bütün bunlar sənə niyə lazımdır?
2. Vaxtın var?
3. Bilik kifayətdirmi?

Əgər suallara necə cavab verəcəyinizi bilmirsinizsə, o zaman refaktorinq hələ başlamamış bitəcək və ya daha da pisləşə bilər. Çünki təcrübəsi var idi( 200 İnfrastruktur Kodunu Sınaqdan Öyrəndiklərim), sonra layihə rolları düzəltmək və onları testlərlə əhatə etmək üçün kömək tələbi aldı.

Gün # 149: Refaktorinqin hazırlanması

İlk şey hazırlamaqdır. Nə edəcəyimizə qərar verin. Bunun üçün biz ünsiyyət qururuq, problemli sahələri tapırıq və onların həlli yollarını müəyyənləşdiririk. Nəticədə ortaya çıxan anlayışları bir şəkildə qeyd edirik, məsələn, bir məqaləni bir araya gətiririk ki, sual yarandıqda "ən yaxşı nədir?" və ya "hansı doğrudur?" Biz yolumuzu azmamışıq. Bizim vəziyyətimizdə biz ideyaya sadiq qaldıq bölmək və idarə etmək: infrastrukturu kiçik parçalara/kərpiclərə parçalayırıq. Bu yanaşma sizə infrastrukturun təcrid olunmuş hissəsini götürməyə, onun nə etdiyini başa düşməyə, onu sınaqlarla əhatə etməyə və heç nəyi pozmaqdan qorxmadan dəyişdirməyə imkan verir.

Belə çıxır ki, infrastruktur sınaqları təməl daşı olur və burada infrastruktur sınaq piramidasını qeyd etmək lazımdır. İnkişafda olan eyni fikir, lakin infrastruktur üçün: biz girinti kimi sadə şeyləri yoxlayan ucuz sürətli testlərdən bütün infrastrukturu yerləşdirən bahalı tam hüquqlu testlərə keçirik.

Ansible test cəhdləri

Layihə üzrə Ansible testlərini necə əhatə etdiyimizi təsvir etməyə getməzdən əvvəl, qəbul edilmiş qərarların kontekstini başa düşmək üçün əvvəllər istifadə etmək imkanım olan cəhdləri və yanaşmaları təsvir edəcəyəm.

Gün № -997: SDS təminatı

Ansible-ı ilk dəfə SDS (Proqram təminatı ilə müəyyən edilmiş yaddaş) inkişaf etdirmək layihəsində sınaqdan keçirdim. Bu mövzuda ayrıca məqalə var
Dağıtımınızı sınaqdan keçirərkən, qoltuqaltılar üzərində velosipedləri necə sındırmaq olar, amma qısaca desək, ters çevrilmiş sınaq piramidası ilə nəticələndik və bir rola 60-90 dəqiqə sərf etdik ki, bu da uzun müddətdir. Əsas e2e testləri idi, yəni. tam hüquqlu bir quraşdırma yerləşdirdik və sonra sınaqdan keçirdik. Daha da ağırlaşdıran isə öz velosipedini ixtira etməsi idi. Ancaq etiraf etməliyəm ki, bu həll işlədi və sabit bir buraxılışa imkan verdi.

Gün # -701: Ansible və sınaq mətbəxi

Ansible test ideyasının inkişafı hazır alətlərdən, yəni test mətbəx / mətbəx-ci və inspec istifadəsindən ibarət idi. Seçim Ruby haqqında məlumatla müəyyən edildi (daha ətraflı məlumat üçün Habré haqqında məqaləyə baxın: YML proqramçıları Ansible-ı sınaqdan keçirmək arzusundadırlarmı?) daha sürətli işləyirdi, 40 rol üçün təxminən 10 dəqiqə. Biz virtual maşın paketi yaratdıq və içəridə testlər keçirdik.

Ümumiyyətlə, həll işlədi, lakin heterojenliyə görə bir az çöküntü var idi. Test edilən insanların sayı 13 əsas rola və daha kiçik rolları birləşdirən 2 meta rola qədər artırıldıqda, birdən testlər 70 dəqiqə davam etməyə başladı ki, bu da demək olar ki, 2 dəfə uzundur. XP (ekstremal proqramlaşdırma) təcrübələri haqqında danışmaq çətin idi, çünki... heç kim 70 dəqiqə gözləmək istəmir. Bu yanaşmanın dəyişdirilməsinə səbəb oldu

Gün # -601: Ansible və molekul

Konseptual olaraq bu, test mətbəxinə bənzəyir, yalnız biz rol testini docker-ə köçürdük və yığını dəyişdirdik. Nəticədə, vaxt 20 rol üçün sabit 25-7 dəqiqəyə endirildi.

Sınaqdan keçmiş rolların sayını 17-yə qədər artırmaq və 45 rolu sıralamaqla biz bunu 28 jenkins qulunda 2 dəqiqə ərzində icra etdik.

Gün # 167: Layihəyə Ansible testlərinin əlavə edilməsi

Çox güman ki, tələsik refaktorinq tapşırığını yerinə yetirmək mümkün olmayacaq. Tapşırıq ölçülə bilən olmalıdır ki, onu kiçik parçalara ayıra və bir çay qaşığı ilə fili parça-parça yeyə biləsən. Düzgün istiqamətdə hərəkət edib-etmədiyiniz, nə qədər davam edəcəyiniz barədə bir anlayış olmalıdır.

Ümumiyyətlə, necə olacağı fərq etməz, kağıza yaza bilərsiniz, şkafın üstünə stiker qoya bilərsiniz, Jira-da tapşırıqlar yarada bilərsiniz və ya Google Docs-u açıb cari statusu yaza bilərsiniz. orada. Ayaqlar prosesin ani olmadığından böyüyür, uzun və yorucu olacaq. Çətin ki, kimsə sizin ideyalarınızdan yanmağınızı, yorulmağınızı və refaktorinq zamanı əsəbləşməyinizi istəməz.

Refaktorinq sadədir:

• Yeyin.
• Yatmaq.
• Kod.
• IaC testi.
• Təkrarlamaq

və biz nəzərdə tutulan məqsədə çatana qədər bunu təkrarlayırıq.

Hər şeyi dərhal sınaqdan keçirməyə başlamaq mümkün olmaya bilər, ona görə də bizim ilk işimiz sintaksisi lintləmək və yoxlamaqdan başlamaq idi.

Gün # 181: Yaşıl Quraşdırma Ustası

Linting Green Build Master yolunda kiçik bir ilk addımdır. Bu, demək olar ki, heç bir şeyi pozmayacaq, ancaq prosesləri sazlamağa və Jenkins-də yaşıl quruluşlar yaratmağa imkan verəcəkdir. İdeya komanda arasında vərdişləri inkişaf etdirməkdir:

• Qırmızı testlər pisdir.
• Mən nəyisə düzəltməyə və eyni zamanda kodu sizdən əvvəlkindən bir az daha yaxşı etmək üçün gəldim.

Gün # 193: Lintingdən vahid sınaqlarına qədər

Kodu master-a daxil etmək prosesini qurduqdan sonra, addım-addım təkmilləşdirmə prosesinə başlaya bilərsiniz - lintingi işə salma rolları ilə əvəz edərək, hətta gücsüzlük olmadan da edə bilərsiniz. Rolları necə tətbiq edəcəyinizi və necə işlədiyini başa düşməlisiniz.

Gün # 211: Vahiddən inteqrasiya testlərinə qədər

Əksər rollar vahid testləri ilə əhatə olunduqda və hər şey tündləşdikdə, inteqrasiya testlərini əlavə etməyə davam edə bilərsiniz. Bunlar. infrastrukturda tək bir kərpici yox, onların birləşməsini, məsələn, tam nümunə konfiqurasiyasını sınaqdan keçirmək.

Jenkins-dən istifadə edərək, biz paralel olaraq rolları/oyun kitablarını birləşdirən bir çox mərhələlər, sonra konteynerlərdə vahid testləri və nəhayət inteqrasiya testləri yaratdıq.

Jenkins + Docker + Ansible = Testlər

1. Repo yoxlayın və tikinti mərhələlərini yaradın.
2. Lint playbook mərhələlərini paralel olaraq icra edin.
3. Lint rol mərhələlərini paralel olaraq yerinə yetirin.
4. Sintaksis yoxlama rolu mərhələlərini paralel olaraq işə salın.
5. Test rolu mərhələlərini paralel olaraq icra edin.
   1. Lint rolu.
   2. Digər rollardan asılılığı yoxlayın.
   3. Sintaksisi yoxlayın.
   4. Docker nümunəsi yaradın
   5. Molecula/default/playbook.yml proqramını işə salın.
   6. Qüsursuzluğu yoxlayın.
6. İnteqrasiya testlərini həyata keçirin
7. finiş

Gün # 271: Avtobus Faktoru

Əvvəlcə refaktorinq iki və ya üç nəfərdən ibarət kiçik qrup tərəfindən həyata keçirilirdi. Ustada kodu nəzərdən keçirdilər. Zaman keçdikcə komanda kodun necə yazılmasına dair bilikləri inkişaf etdirdi və kodun nəzərdən keçirilməsi infrastruktur və onun necə işləməsi haqqında biliklərin yayılmasına töhfə verdi. Burada diqqət çəkən məqam ondan ibarət idi ki, rəyçiləri bir-bir, qrafikə uyğun olaraq, yəni. müəyyən dərəcədə ehtimalla siz yeni bir infrastruktur parçasına dırmaşacaqsınız.

Və burada rahat olmalıdır. Nəzarət etmək, hansı tapşırığın yerinə yetirildiyini və müzakirələrin tarixini görmək rahatdır. İnteqrasiya edilmiş jenkins + bitbucket + jira var.

Ancaq beləliklə, nəzərdən keçirmə dərdin dərmanı deyil; nədənsə biz master koduna daxil olduq, bu da bizi flop testlərinə məcbur etdi:

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

Sonra onu düzəltdilər, amma çöküntü qaldı.

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

Gün # 311: Testlərin sürətləndirilməsi

Vaxt keçdikcə daha çox sınaqlar var idi, tikinti daha yavaş, ən pis halda bir saata qədər davam etdi. Retroların birində “yaxşı ki, sınaqlar var, amma ləng gedir” kimi bir ifadə var idi. Nəticədə, biz virtual maşınlarda inteqrasiya testlərindən imtina etdik və onu daha sürətli etmək üçün Docker-ə uyğunlaşdırdıq. Biz həmçinin istifadə olunan alətlərin sayını azaltmaq üçün testinfra-nı ansible verifier ilə əvəz etdik.

Düzünü desək, bir sıra tədbirlər var idi:

1. Docker-ə keçin.
2. Asılılıqlara görə təkrarlanan rol testini silin.
3. Qulların sayını artırın.
4. Test işləmə qaydası.
5. Tük tökmə qabiliyyəti HAMISI bir komanda ilə yerli.

Nəticədə, Cenkins-də boru kəməri də birləşdirildi

1. Quraşdırma mərhələlərini yaradın.
2. Hamısını paralel olaraq silkələyin.
3. Test rolu mərhələlərini paralel olaraq icra edin.
4. Bitirin.

Öyrənilmiş dərslər

Qlobal dəyişənlərdən çəkinin

Ansible qlobal dəyişənlərdən istifadə edir, formada qismən həll yolu var özəl_rol_dəyişənlər, lakin bu panacea deyil.

Sizə bir misal deyim. Qoy bizdə olsun 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}}

Gülməli odur ki, oyun kitablarının nəticəsi həmişə açıq-aydın olmayan şeylərdən, məsələn, rolların sıralanmasından asılı olacaq. Təəssüf ki, bu, Ansible-ın xarakteridir və edilə biləcək ən yaxşı şey bir növ razılaşmadan istifadə etməkdir, məsələn, rol daxilində yalnız bu rolda təsvir olunan dəyişəni istifadə etməkdir.

BAD: qlobal dəyişəndən istifadə edin.

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

GOOD: V defaults Lazımi dəyişənləri müəyyənləşdirin və daha sonra yalnız onlardan istifadə edin.

# 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

Prefiks rol dəyişənləri

BAD: qlobal dəyişəndən istifadə edin.

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

GOOD: Dəyişənlər üçün rollarda rol adı ilə prefiks edilmiş dəyişənlərdən istifadə edin; bu, inventara baxmaqla nə baş verdiyini başa düşməyi asanlaşdıracaq.

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

Döngə nəzarət dəyişənindən istifadə edin

BAD: Döngələrdə standart dəyişəndən istifadə edin item, əgər bu tapşırıq/oyun kitabı hardasa daxil edilibsə, bu, gözlənilməz davranışa səbəb ola bilər

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

GOOD: Döngüdə dəyişəni yenidən təyin edin loop_var.

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

Giriş dəyişənlərini yoxlayın

Dəyişən prefikslərdən istifadə etməyə razılaşdıq; onların gözlədiyimiz kimi müəyyən edildiyini və məsələn, boş bir dəyərlə əvəz edilmədiyini yoxlamaq artıq olmaz.

GOOD: Dəyişənləri yoxlayın.

- 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

Hashes lüğətlərdən çəkinin, düz quruluşdan istifadə edin

Əgər rol öz parametrlərindən birində hash/lüğət gözləyirsə, o zaman uşaq parametrlərdən birini dəyişmək istəsək, bütün hash/lüğəti ləğv etməliyik ki, bu da konfiqurasiya mürəkkəbliyini artıracaq.

BAD: Hash/lüğətdən istifadə edin.

---
user:
  name: admin
  group: admin

GOOD: Düz dəyişən strukturdan istifadə edin.

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

İdempotent oyun kitabları və rollar yaradın

Rollar və oyun kitabları idempotent olmalıdır, çünki konfiqurasiya sürüşməsini və bir şeyi pozmaq qorxusunu azaldır. Ancaq molekuldan istifadə edirsinizsə, bu, standart davranışdır.

Komanda qabığı modullarından istifadə etməyin

Qabıq modulundan istifadə Ansible-ın əsasını təşkil edən deklarativ deyil, imperativ təsvir paradiqması ilə nəticələnir.

Rollarınızı molekul vasitəsilə sınayın

Molekul çox çevik bir şeydir, gəlin bir neçə ssenariyə baxaq.

Molekul Çoxsaylı Nümunələr

В molecule.yml bölməsində platforms yerləşdirə biləcəyiniz bir çox hostları təsvir edə bilərsiniz.

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

Buna görə, bu hostlar daha sonra ola bilər converge.yml istifadə edin:

---
- 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 yoxlayıcı

Molekulda nümunənin düzgün konfiqurasiya olunduğunu yoxlamaq üçün ansible istifadə etmək mümkündür, üstəlik, bu, buraxılış 3-dən bəri standartdır. O, testinfra/inspec kimi çevik deyil, lakin biz faylın məzmununun gözləntilərimizə uyğun olduğunu yoxlaya bilərik:

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

Və ya xidməti yerləşdirin, onun əlçatan olmasını gözləyin və tüstü testi edin:

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

Kompleks məntiqi modullara və plaginlərə yerləşdirin

Ansible deklarativ yanaşmanın tərəfdarıdır, ona görə də kodun budaqlanması, verilənlərin çevrilməsi, qabıq modulları etdikdə kodu oxumaq çətinləşir. Bununla mübarizə aparmaq və başa düşmək üçün sadə saxlamaq üçün öz modullarınızı yaratmaqla bu mürəkkəbliklə mübarizə aparmaq artıq olmaz.

Məsləhətləri və fəndləri ümumiləşdirin

1. Qlobal dəyişənlərdən çəkinin.
2. Prefiks rol dəyişənləri.
3. Döngə nəzarət dəyişənindən istifadə edin.
4. Giriş dəyişənlərini yoxlayın.
5. Hashes lüğətlərdən çəkinin, düz quruluşdan istifadə edin.
6. İdempotent oyun kitabları və rollar yaradın.
7. Komanda qabığı modullarından istifadə etməyin.
8. Rollarınızı molekul vasitəsilə sınayın.
9. Kompleks məntiqi modullara və plaginlərə yerləşdirin.

Nəticə

IaC-niz olsa belə, sadəcə gedib layihədə infrastrukturu yenidən düzəldə bilməzsiniz. Bu səbr, vaxt və bilik tələb edən uzun prosesdir.

Links

• Slaydlar Ansible-ı necə sınamaq olar və ağlını itirmə
• Video Ansible-ı necə sınamaq olar və ağlını itirmə
• 200 İnfrastruktur Kodunu Sınaqdan Öyrəndiklərim
• Ansible: 120 ayda 18 VM konfiqurasiyasının Coreos-dan Centos-a köçürülməsi
• Dağıtımınızı sınaqdan keçirərkən, qoltuqaltılar üzərində velosipedləri necə sındırmaq olar
• Məni sınayın, əgər YML proqramçıları Ansible-ı sınamağı xəyal edə bilirsinizmi?
• Möhtəşəm IaC test məqalələrinin, çıxışlarının və keçidlərinin siyahısı
• çarpaz post
• English version

UPD1 2020.05.01 20:30 — Oyun kitablarının əsas profili üçün istifadə edə bilərsiniz callback_whitelist = profile_tasks uzun müddət tam olaraq nəyin işlədiyini başa düşmək üçün. Sonra keçirik Ansible sürətləndirmə klassikləri. Siz də cəhd edə bilərsiniz mitogen
UPD2 2020.05.03 16:34 - English version

Mənbə: www.habr.com