Carane miwiti testing Ansible, refactor project ing taun lan ora dadi edan

Iki transkrip pagelaran ing DevOps-40 2020-03-18:

Wiwit saka komit kapindho, kode apa wae dadi warisan, amarga gagasan awal wiwit diverge saka kasunyatan atos. Iki ora apik utawa ala, iku diwenehi sing angel kanggo mbantah lan kudu urip. Bagéyan saka proses iki yaiku refactoring. Infrastruktur Refactoring minangka Kode. Ayo crita diwiwiti babagan cara refactor Ansible sajrone setaun lan ora dadi edan.

Lair Warisan

Dina # 1: Pasien Zero

Biyen ana proyek bersyarat. Dheweke duwe tim pangembangan Dev lan insinyur Ops. Dheweke ngrampungake masalah sing padha: carane nyebarake server lan mbukak aplikasi. Masalahe yaiku saben tim ngrampungake masalah iki kanthi cara dhewe. Ing proyek kasebut, diputusake nggunakake Ansible kanggo nyinkronake kawruh antarane tim Dev lan Ops.

Dina # 89: Lair saka Warisan

Tanpa nggatekake dhewe, dheweke kepengin nindakake kanthi paling apik, nanging dadi warisan. Kepiye kedadeyan iki?

• Kita duwe tugas urgent kene, ayo padha hack reged lan banjur ndandani.
• Sampeyan ora kudu nulis dokumentasi lan kabeh wis jelas apa sing kedadeyan ing kene.
• Aku ngerti Ansible/Python/Bash/Terraform! Delengen carane aku bisa ngindari!
• Aku Full Stack Overflow Developer lan disalin saka stackoverflow, Aku ora ngerti cara kerjane, nanging katon kelangan lan solves masalah.

Akibaté, sampeyan bisa entuk jinis kode sing ora bisa dingerteni sing ora ana dokumentasi, ora jelas apa sing ditindakake, apa perlu, nanging masalahe sampeyan kudu ngembangake, ngowahi, nambah crutches lan ndhukung. , nggawe kahanan luwih elek.

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

Dina # 109: Kesadaran babagan masalah

Model IaC sing wiwitane disusun lan dileksanakake ora nyukupi syarat pangguna / bisnis / tim liyane, lan wektu kanggo ngganti infrastruktur ora bisa ditampa. Ing wayahe, pangerten teka yen wektune kanggo tumindak.

refactoring IaC

Dina # 139: Apa sampeyan pancene mbutuhake refactoring?

Sadurunge cepet-cepet refactor, sampeyan kudu mangsuli sawetara pitakonan penting:

1. Napa sampeyan butuh kabeh iki?
2. Apa sampeyan duwe wektu?
3. Apa kawruh cukup?

Yen sampeyan ora ngerti carane mangsuli pitakonan, banjur refactoring bakal mungkasi sadurunge malah diwiwiti, utawa mung bisa dadi luwih elek. Amarga wis pengalaman ( Apa Aku Sinau saka Nguji 200 Baris Kode Infrastruktur), banjur proyek kasebut njaluk bantuan kanggo ndandani peran lan nutupi tes.

Dina # 149: Nyiapake refactoring

Sing pertama yaiku nyiyapake. Temtokake apa sing bakal kita lakoni. Kanggo nindakake iki, kita komunikasi, nemokake wilayah masalah lan nemtokake cara kanggo ngatasi. Kita ngrekam konsep sing diasilake, umpamane artikel ing confluence, supaya nalika ana pitakonan "apa sing paling apik?" utawa "sing bener?" Kita ora kesasar. Ing kasus kita, kita macet ing idea dibagi lan aturan: kita break munggah infrastruktur menyang bêsik cilik / bata. Pendekatan iki ngidini sampeyan njupuk prasarana sing terisolasi, ngerti apa sing ditindakake, nutupi tes lan ngganti tanpa wedi ngrusak apa-apa.

Pranyata tes infrastruktur dadi landasan lan ing kene kudu dicritakake piramida tes infrastruktur. Persis ide sing padha ing pembangunan, nanging kanggo infrastruktur: kita pindhah saka tes cepet murah sing mriksa barang-barang sing prasaja, kayata indentasi, menyang tes lengkap sing larang sing nyebarake kabeh infrastruktur.

Uji coba sing bisa ditindakake

Sadurunge kita njlèntrèhaké carane kita nutupi tes Ansible ing project, Aku bakal njlèntrèhaké usaha lan pendekatan sing aku duwe kesempatan kanggo nggunakake sadurungé supaya ngerti konteks saka pancasan digawe.

Dina No.. -997: panentu SDS

Pisanan aku nyoba Ansible ana ing proyek kanggo ngembangake SDS (Software Defined Storage). Ana artikel kapisah babagan topik iki
Carane break pit liwat crutches nalika nyoba distribusi Panjenengan, nanging ing cendhak, kita rampung munggah karo piramida testing kuwalik lan testing kita nglampahi 60-90 menit ing siji peran, kang dangu. Basis ana tes e2e, yaiku. kita masang instalasi lengkap lan banjur dites. Sing luwih nggegirisi yaiku panemune sepedha dhewe. Nanging aku kudu ngakeni, solusi iki makarya lan diijini kanggo release stabil.

Dina # -701: Ansible lan pawon test

Pangrembakane ide uji Ansible yaiku nggunakake piranti sing wis siap, yaiku pawon uji/pawon-ci lan inspec. Pilihan kasebut ditemtokake dening kawruh babagan Ruby (kanggo rincian liyane, deleng artikel babagan Habré: Apa programer YML ngimpi nguji Ansible?) bisa luwih cepet, kira-kira 40 menit kanggo 10 peran. Kita nggawe paket mesin virtual lan nglakokake tes ing njero.

Umumé, solusi kasebut bisa digunakake, nanging ana sawetara endapan amarga heterogenitas. Nalika jumlah wong sing dites ditambah dadi 13 peran dhasar lan 2 peran meta sing nggabungake peran sing luwih cilik, banjur dumadakan tes wiwit mlaku nganti 70 menit, sing meh 2 kaping luwih suwe. Iku angel ngomong babagan praktik XP (pemrograman ekstrem) amarga ... ora ana sing pengin ngenteni 70 menit. Iki minangka alesan kanggo ngganti pendekatan

Dina # -601: Ansible lan molekul

Conceptually, iki padha testkitchen, mung kita dipindhah testing peran kanggo docker lan ngganti tumpukan. Akibaté, wektu suda dadi stabil 20-25 menit kanggo 7 peran.

Kanthi nambah nomer dites peran kanggo 17 lan linting 45 peran, kita mlayu iki ing 28 menit ing 2 babu jenkins.

Dina # 167: Nambahake tes Ansible menyang proyek kasebut

Paling kamungkinan, ora bakal bisa nindakake tugas refactoring kanthi cepet. Tugas kasebut kudu bisa diukur supaya bisa dipecah dadi potongan-potongan cilik lan mangan potongan gajah kanthi sendok teh. Mesthi ana pangerten apa sampeyan pindhah menyang arah sing bener, suwene suwene.

Umumé, ora ketompo carane bakal ditindakake, sampeyan bisa nulis ing kertas, sampeyan bisa masang stiker ing lemari, sampeyan bisa nggawe tugas ing Jira, utawa sampeyan bisa mbukak Google Docs lan nulis status saiki. ing kono. Sikil tuwuh saka kasunyatan manawa proses kasebut ora langsung, bakal dawa lan mboseni. Ora mungkin ana sing pengin sampeyan ngobong ide, kesel, lan kewalahan sajrone refactoring.

Refactoring punika prasaja:

• Mangan.
• Turu.
• Kode
• tes IaC.
• Baleni

lan kita mbaleni iki nganti kita tekan goal dimaksudaké.

Sampeyan bisa uga ora bisa langsung nyoba kabeh, mula tugas pisanan kita yaiku miwiti linting lan mriksa sintaksis.

Dina # 181: Ijo Mbangun Master

Linting minangka langkah pisanan cilik menyang Green Build Master. Iki ora bakal ngrusak meh kabeh, nanging ngidini sampeyan debug pangolahan lan nggawe bangunan ijo ing Jenkins. Ide kasebut yaiku ngembangake kabiasaan ing antarane tim:

• Tes abang ora apik.
• Aku teka kanggo ndandani soko lan ing wektu sing padha nggawe kode luwih apik tinimbang sadurunge sampeyan.

Dina # 193: Saka linting nganti tes unit

Sawise nggawe proses njupuk kode menyang master, sampeyan bisa miwiti proses dandan langkah-langkah - ngganti linting kanthi peran peluncuran, sampeyan bisa nindakake tanpa idempotensi. Sampeyan kudu ngerti carane ngetrapake peran lan cara kerjane.

Dina # 211: Saka unit nganti tes integrasi

Nalika paling peran dijamin karo tes unit lan kabeh wis lint, sampeyan bisa nerusake kanggo nambah tes integrasi. Sing. testing ora bata siji ing infrastruktur, nanging kombinasi mau, Contone, konfigurasi Kayata lengkap.

Nggunakake jenkins, kita kui akeh orane tumrap sekolah sing lited peran / playbooks ing podo karo, banjur unit test ing kontaner, lan pungkasanipun tes integrasi.

Jenkins + Docker + Ansible = Tes

1. Priksa repo lan ngasilake tahapan mbangun.
2. Jalanake tahapan playbook lint kanthi paralel.
3. Jalanake tahapan peran lint kanthi paralel.
4. Mbukak sintaks mriksa tataran peran ing podo karo.
5. Jalanake tahapan peran uji kanthi podo karo.
   1. Peran linting.
   2. Priksa katergantungan ing peran liyane.
   3. Priksa sintaks.
   4. Nggawe conto docker
   5. Mlaku molecule/default/playbook.yml.
   6. Priksa idempotensi.
6. Jalanake tes integrasi
7. Rampung

Dina # 271: Faktor Bus

Ing wiwitan, refactoring ditindakake dening sekelompok cilik loro utawa telu wong. Dheweke mriksa kode ing master. Sajrone wektu, tim ngembangake kawruh babagan carane nulis kode lan review kode nyumbang kanggo nyebarake kawruh babagan infrastruktur lan cara kerjane. Sorotan ing kene yaiku para pamawas dipilih siji-siji, miturut jadwal, yaiku. karo sawetara jurusan kamungkinan sampeyan bakal menek menyang Piece anyar saka infrastruktur.

Lan kudu nyaman ing kene. Iku trep kanggo nindakake review, ndeleng ing framework apa tugas wis rampung, lan sajarah diskusi. Kita wis nggabungake jenkins + bitbucket + jira.

Nanging kaya ngono, review dudu panacea; piye wae, kita entuk kode master, sing nggawe tes gagal:

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

Banjur padha ndandani, nanging turahan tetep.

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

Dina #311: Nyepetake tes

Sajrone wektu, ana luwih akeh tes, mbangun luwih alon, nganti sejam ing kasus sing paling ala. Ing salah sawijining retro ana tembung kaya "iku apik yen ana tes, nanging alon." Akibaté, kita nilar tes integrasi ing mesin virtual lan dicocogake kanggo Docker supaya luwih cepet. Kita uga ngganti testinfra karo verifier ansible kanggo nyuda jumlah alat sing digunakake.

Tegese, ana sawetara langkah:

1. Ngalih menyang docker.
2. Mbusak pangujian peran, sing diduplikasi amarga dependensi.
3. Tambah cacahe batur tukon.
4. Urutan test run.
5. Kemampuan kanggo lint KABEH lokal karo siji printah.

Akibaté, Pipeline ing jenkins uga manunggal

1. Nggawe tahapan mbangun.
2. Lint kabeh ing podo karo.
3. Jalanake tahapan peran uji kanthi podo karo.
4. Rampung.

Pawulangan sinau

Ngindhari variabel global

Ansible nggunakake variabel global, ana solusi parsial ing formulir kasebut private_role_vars, nanging iki dudu panacea.

Ayo kula menehi conto. Ayo kita duwe 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}}

Sing lucu yaiku asil playbook bakal gumantung marang perkara-perkara sing ora mesthi jelas, kayata urutan peran kasebut. Sayange, iki sifat Ansible lan sing paling apik sing bisa ditindakake yaiku nggunakake sawetara persetujuan, umpamane, ing peran, mung nggunakake variabel sing diterangake ing peran iki.

BAD: nggunakake variabel global.

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

GOOD: V defaults nemtokake variabel sing perlu lan mung nggunakake.

# 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

Variabel peran awalan

BAD: nggunakake variabel global.

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

GOOD: Ing peran kanggo variabel, gunakake variabel sing diawali karo jeneng peran; iki, kanthi ndeleng inventaris, bakal luwih gampang ngerti apa sing kedadeyan.

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

Gunakake variabel kontrol loop

BAD: Gunakake variabel standar ing puteran item, yen tugas iki / playbook klebu nang endi wae, iki bisa mimpin kanggo prilaku sing ora dikarepke

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

GOOD: Redefine variabel ing daur ulang liwat loop_var.

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

Priksa variabel input

Kita sarujuk nggunakake awalan variabel; ora perlu kanggo mriksa manawa wis ditetepake kaya sing dikarepake lan, contone, ora diganti karo nilai kosong.

GOOD: Priksa variabel.

- 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

Ngindhari kamus hash, gunakake struktur sing rata

Yen peran ngarepake hash / kamus ing salah sawijining paramèter, banjur yen kita pengin ngganti salah sawijining parameter anak, kita kudu ngilangi kabeh hash / kamus, sing bakal nambah kerumitan konfigurasi.

BAD: Gunakake hash/kamus.

---
user:
  name: admin
  group: admin

GOOD: Gunakake struktur variabel flat.

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

Nggawe playbook idempoten & peran

Peran lan playbook kudu idempoten, amarga nyuda drift konfigurasi lan wedi bejat soko. Nanging yen sampeyan nggunakake molekul, banjur iki prilaku standar.

Aja nggunakake modul shell printah

Nggunakake modul cangkang ngasilake paradigma deskripsi imperatif, tinimbang sing deklaratif, sing dadi inti saka Ansible.

Tes peran sampeyan liwat molekul

Molekul minangka barang sing fleksibel, ayo ndeleng sawetara skenario.

Molekul Multiple kedadean

В molecule.yml ing bagean platforms sampeyan bisa njlèntrèhaké akeh sarwa dumadi sing bisa masang.

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

Patut, iki sarwa dumadi banjur bisa converge.yml nggunakake:

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

Verifier ansible

Ing molekul, sampeyan bisa nggunakake ansible kanggo mriksa manawa conto wis dikonfigurasi kanthi bener, luwih-luwih, iki minangka standar wiwit rilis 3. Ora fleksibel kaya testinfra/inspec, nanging kita bisa mriksa manawa isi file cocog karo pangarepan kita:

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

Utawa masang layanan kasebut, ngenteni kasedhiya lan tindakake tes kumelun:

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

Pasang logika kompleks menyang modul & plugin

Ansible nyengkuyung pendekatan deklaratif, mula nalika sampeyan nindakake percabangan kode, transformasi data, modul cangkang, kode kasebut dadi angel diwaca. Kanggo nglawan iki lan tetep gampang dingerteni, ora perlu kanggo nglawan kerumitan iki kanthi nggawe modul sampeyan dhewe.

Ringkesan Tips & Trik

1. Ngindhari variabel global.
2. Variabel peran awalan.
3. Gunakake variabel kontrol loop.
4. Priksa variabel input.
5. Ngindhari kamus hash, gunakake struktur sing rata.
6. Nggawe playbook idempotent & peran.
7. Aja nggunakake modul shell printah.
8. Tes peran sampeyan liwat molekul.
9. Pasang logika kompleks menyang modul & plugin.

kesimpulan

Sampeyan ora bisa mung pindhah lan refactor infrastruktur ing project, malah yen sampeyan duwe IaC. Iki minangka proses dawa sing mbutuhake kesabaran, wektu lan kawruh.

Links

• slides Kepiye cara nyoba Ansible lan aja kesusu
• Video Kepiye cara nyoba Ansible lan aja kesusu
• Apa Aku Sinau saka Nguji 200 Baris Kode Infrastruktur
• Ansible: Migrasi konfigurasi VM 120 saka Coreos menyang Centos sajrone 18 wulan
• Carane break pit liwat crutches nalika nyoba distribusi Panjenengan
• Coba aku yen sampeyan bisa utawa apa programer YML ngimpi nguji Ansible?
• Dhaptar artikel, pidato & tautan pengujian IaC sing apik tenan
• pos salib
• Versi Inggris

UPD1 2020.05.01 20:30 - Kanggo profil utama playbooks sampeyan bisa nggunakake callback_whitelist = profile_tasks kanggo ngerti apa persis bisa kanggo dangu. Banjur kita liwat Klasik akselerasi Ansible. Sampeyan uga bisa nyoba mitogen
UPD2 2020.05.03 16:34 - Versi Inggris

Source: www.habr.com