Ansible-ni sinab ko'rishni qanday boshlash kerak, loyihani bir yil ichida qayta ko'rib chiqing va aqldan ozmang

Bu transkript spektakllar haqida DevOps-40 2020:

Ikkinchi majburiyatdan boshlab, har qanday kod meros bo'lib qoladi, chunki dastlabki g'oyalar qattiq haqiqatdan uzoqlasha boshlaydi. Bu yaxshi ham, yomon ham emas, u bilan bahslashish qiyin va u bilan yashash kerak bo'lgan berilgan. Ushbu jarayonning bir qismi refaktoringdir. Infratuzilmani kod sifatida qayta tiklash. Hikoya bir yil ichida Ansibleni qanday qayta tiklash va aqldan ozmaslik haqida boshlasin.

Merosning tug'ilishi

1-kun: Bemor nol

Bir vaqtlar shartli loyiha bor edi. Unda Dev ishlab chiqish guruhi va Ops muhandislari bor edi. Ular bir xil muammoni hal qilishdi: serverlarni qanday joylashtirish va dasturni ishga tushirish. Muammo shundaki, har bir jamoa bu muammoni o'ziga xos tarzda hal qildi. Loyihada Dev va Ops guruhlari o'rtasida bilimlarni sinxronlashtirish uchun Ansible-dan foydalanishga qaror qilindi.

№89 kun: merosning tug'ilishi

Ular buni o'zlari sezmasdan, iloji boricha yaxshiroq qilishni xohlashdi, ammo bu meros bo'lib chiqdi. Bu qanday sodir bo'ladi?

• Bu yerda bizda shoshilinch vazifa bor, keling, iflos hack qilamiz va keyin uni tuzatamiz.
• Hujjatlarni yozishingiz shart emas va bu erda nima sodir bo'layotgani hamma narsa aniq.
• Men Ansible/Python/Bash/Terraformni bilaman! Qarang, men qanday qochishim mumkin!
• Men Full Stack Overflow dasturchisiman va buni stackoverflow'dan ko'chirib oldim, u qanday ishlashini bilmayman, lekin u ajoyib ko'rinadi va muammoni hal qiladi.

Natijada, siz tushunarsiz turdagi kodni olishingiz mumkin, buning uchun hujjatlar yo'q, u nima qilishi, kerakmi yoki yo'qligi aniq emas, lekin muammo shundaki, siz uni ishlab chiqishingiz, o'zgartirishingiz, tayoqchalar va tayanchlarni qo'shishingiz kerak. , vaziyatni yanada yomonlashtiradi.

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

109-kun: Muammodan xabardorlik

Dastlab o'ylab topilgan va amalga oshirilgan IaC modeli endi foydalanuvchilar / biznes / boshqa jamoalar talablariga javob bermaydi va infratuzilmaga o'zgartirish kiritish vaqti qabul qilinishini to'xtatadi. Ayni damda harakat qilish vaqti kelgani tushuniladi.

IaC refaktoring

139-kun: Sizga haqiqatan ham refaktoring kerakmi?

Qayta tiklashga shoshilmasdan oldin siz bir qator muhim savollarga javob berishingiz kerak:

1. Bularning barchasi nega kerak?
2. Vaqtingiz bormi?
3. Bilim yetarlimi?

Agar siz savollarga qanday javob berishni bilmasangiz, refaktoring hali boshlanishidan oldin tugaydi yoki u faqat yomonlashishi mumkin. Chunki tajribaga ega edi ( 200 000 qator infratuzilma kodini sinab ko'rishdan nimani o'rgandim), keyin loyiha rollarni tuzatish va ularni testlar bilan qoplash uchun yordam so'rovini oldi.

№149 kun: Refaktoringni tayyorlash

Birinchi narsa - tayyorgarlik. Nima qilishimizni hal qiling. Buning uchun biz muloqot qilamiz, muammoli joylarni topamiz va ularni hal qilish yo'llarini aniqlaymiz. Olingan tushunchalarni qandaydir tarzda yozamiz, masalan, qo'shilishdagi maqola, shunda "nima yaxshi?" Degan savol tug'ilganda. yoki "qaysi biri to'g'ri?" Biz yo‘limizni adashganimiz yo‘q. Bizning holatda, biz g'oyaga yopishib oldik bo'ling va boshqaring: biz infratuzilmani kichik qismlarga / g'ishtlarga ajratamiz. Ushbu yondashuv sizga infratuzilmaning ajratilgan qismini olish, nima qilishini tushunish, uni sinovlar bilan qoplash va hech narsani buzishdan qo'rqmasdan o'zgartirish imkonini beradi.

Ma'lum bo'lishicha, infratuzilmani sinovdan o'tkazish poydevorga aylanadi va bu erda infratuzilmani sinovdan o'tkazish piramidasini eslatib o'tish kerak. Aynan shu g'oya ishlab chiqilmoqda, lekin infratuzilma uchun: biz oddiy narsalarni tekshiradigan arzon tezkor testlardan, masalan, chekinishlarni, butun infratuzilmani joylashtiradigan qimmat to'liq huquqli testlarga o'tmoqdamiz.

Aniq sinov urinishlari

Loyiha bo'yicha Ansible testlarini qanday ko'rib chiqqanimizni tasvirlashga kirishdan oldin, men qabul qilingan qarorlar kontekstini tushunish uchun ilgari foydalanish imkoniyatiga ega bo'lgan urinishlar va yondashuvlarni tasvirlab beraman.

Kun raqami -997: SDS ta'minoti

Men birinchi marta Ansible-ni SDS (Software Defined Storage) ishlab chiqish loyihasida sinab ko'rdim. Ushbu mavzu bo'yicha alohida maqola mavjud
Tarqatishni sinab ko'rishda velosipedlarni tayoqchalar orqali qanday sindirish kerak, lekin qisqasi, biz teskari sinov piramidasi bilan yakunlandik va sinov biz bir rolga 60-90 daqiqa sarfladik, bu uzoq vaqt. Asos e2e testlari edi, ya'ni. biz to'liq huquqli o'rnatishni joylashtirdik va keyin uni sinab ko'rdik. Bundan ham og'irroq bo'lgan narsa o'z velosipedining ixtirosi edi. Ammo tan olishim kerakki, bu yechim ishladi va barqaror nashrga ruxsat berdi.

Kun # -701: Ansible va sinov oshxona

Ansible test g'oyasining rivojlanishi tayyor asboblardan foydalanish edi, ya'ni test oshxona / oshxona-ci va inspec. Tanlov Ruby haqidagi bilimlar bilan aniqlandi (batafsilroq, Habré haqidagi maqolaga qarang: YML dasturchilari Ansible-ni sinab ko'rishni orzu qiladimi?) tezroq ishladi, 40 ta rol uchun taxminan 10 daqiqa. Biz virtual mashinalar to'plamini yaratdik va ichkarida testlarni o'tkazdik.

Umuman olganda, eritma ishladi, lekin heterojenlik tufayli bir oz cho'kindi bor edi. Sinovdan o'tganlar soni 13 ta asosiy rolga va kichikroq rollarni birlashtirgan 2 meta rolga ko'paytirilganda, to'satdan testlar 70 daqiqa davom eta boshladi, bu deyarli 2 baravar ko'p. XP (ekstremal dasturlash) amaliyotlari haqida gapirish qiyin edi, chunki... hech kim 70 daqiqa kutishni xohlamaydi. Bu yondashuvni o'zgartirishga sabab bo'ldi

Kun # -601: Ansible va molekula

Kontseptual jihatdan bu testkitchen-ga o'xshaydi, faqat biz rol testini docker-ga o'tkazdik va stekni o'zgartirdik. Natijada, vaqt 20 ta rol uchun barqaror 25-7 daqiqaga qisqartirildi.

Sinovdan o'tgan rollar sonini 17 taga ko'paytirish va 45 ta rolni belgilash orqali biz buni 28 jenkins qulida 2 daqiqada bajardik.

№167 kun: Loyihaga Ansible testlarini qo'shish

Katta ehtimol bilan, shoshilinch ravishda refaktoring vazifasini bajarib bo'lmaydi. Vazifani o'lchash mumkin bo'lishi kerak, shunda siz uni mayda bo'laklarga bo'lishingiz va filni choy qoshig'i bilan parcha-parcha yeyishingiz mumkin. To'g'ri yo'nalishda harakat qilyapsizmi, qancha vaqt ketishi kerakligi haqida tushuncha bo'lishi kerak.

Umuman, qanday bo'lishi muhim emas, siz qog'ozga yozishingiz mumkin, shkafga stikerlar qo'yishingiz mumkin, siz Jirada vazifalar yaratishingiz mumkin yoki Google Docsni ochib, hozirgi holatni yozishingiz mumkin. U yerda. Oyoqlar jarayonning darhol emasligidan o'sadi, u uzoq va zerikarli bo'ladi. Hech kim sizni g'oyalaringizdan chiqib ketishingizni, charchashingizni va refaktoring paytida to'lib ketishingizni xohlashi dargumon.

Refaktoring oddiy:

• Yemoq.
• Kutish.
• Kod.
• IaC testi.
• Takrorlash

va biz ko'zlangan maqsadga erishgunimizcha buni takrorlaymiz.

Hamma narsani darhol sinab ko'rishni boshlashning iloji bo'lmasligi mumkin, shuning uchun bizning birinchi vazifamiz sintaksisni liniyalash va tekshirishdan boshlash edi.

181-kun: Yashil qurilish ustasi

Linting Green Build Master sari kichik birinchi qadamdir. Bu deyarli hech narsani buzmaydi, lekin bu sizga jarayonlarni disk raskadrovka qilish va Jenkinsda yashil tuzilmalarni yaratish imkonini beradi. G'oya jamoada odatlarni rivojlantirishdir:

• Qizil testlar yomon.
• Men biror narsani tuzatish va shu bilan birga kodni sizdan oldingidan biroz yaxshiroq qilish uchun keldim.

193-kun: Lintingdan birlik sinovlarigacha

Magistrga kodni olish jarayonini qurgandan so'ng, siz bosqichma-bosqich takomillashtirish jarayonini boshlashingiz mumkin - lintingni ishga tushirish rollari bilan almashtirish, siz buni kuchsiz holda ham qilishingiz mumkin. Rollarni qanday qo'llashni va ular qanday ishlashini tushunishingiz kerak.

211-kun: Birlikdan integratsiya testlarigacha

Ko'pgina rollar birlik testlari bilan qoplangan va hamma narsa chizilgan bo'lsa, siz integratsiya testlarini qo'shishga o'tishingiz mumkin. Bular. infratuzilmada bitta g'ishtni emas, balki ularning kombinatsiyasini, masalan, to'liq misol konfiguratsiyasini sinab ko'rish.

Jenkins-dan foydalanib, biz parallel ravishda rollar/o'yin kitoblari bo'lgan ko'plab bosqichlarni yaratdik, keyin konteynerlarda birlik testlari va nihoyat integratsiya testlari.

Jenkins + Docker + Ansible = Testlar

1. Repo-ni tekshiring va qurish bosqichlarini yarating.
2. Lint playbook bosqichlarini parallel ravishda bajaring.
3. Lint roli bosqichlarini parallel ravishda bajaring.
4. Sintaksisni tekshirish roli bosqichlarini parallel ravishda bajaring.
5. Sinov roli bosqichlarini parallel ravishda bajaring.
   1. Lint roli.
   2. Boshqa rollarga bog'liqlikni tekshiring.
   3. Sintaksisni tekshiring.
   4. Docker misolini yarating
   5. Molecule/default/playbook.yml faylini ishga tushiring.
   6. Identifikatorni tekshiring.
6. Integratsiya testlarini o'tkazing
7. tugatmoq

271-kun: Avtobus omili

Dastlab, refaktoring ikki yoki uch kishidan iborat kichik guruh tomonidan amalga oshirildi. Ular masterdagi kodni ko'rib chiqdilar. Vaqt o'tishi bilan jamoa kodni qanday yozish bo'yicha bilimlarni rivojlantirdi va kodni ko'rib chiqish infratuzilma va uning qanday ishlashi haqidagi bilimlarning tarqalishiga hissa qo'shdi. Bu erda e'tiborga molik jihat shundaki, taqrizchilar birma-bir, jadval bo'yicha tanlab olindi, ya'ni. ma'lum bir ehtimollik darajasi bilan siz infratuzilmaning yangi qismiga ko'tarilasiz.

Va bu erda qulay bo'lishi kerak. Ko'rib chiqish, qanday vazifa bajarilganligini va muhokamalar tarixini ko'rish qulay. Bizda jenkins + bitbucket + jira o'rnatilgan.

Shunday qilib, sharh panatseya emas; qandaydir tarzda biz master kodga kirdik, bu esa bizni flop testlariga majbur qildi:

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

Keyin uni tuzatdilar, ammo qoldiq qoldi.

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

311-kun: Testlarni tezlashtirish

Vaqt o'tishi bilan ko'proq sinovlar bo'ldi, qurilishlar sekinroq, eng yomon holatda bir soatgacha davom etdi. Retrolardan birida "sinovlar borligi yaxshi, lekin ular sekin" kabi ibora bor edi. Natijada, biz virtual mashinalarda integratsiya testlaridan voz kechdik va ularni tezroq qilish uchun Docker uchun moslashtirdik. Biz, shuningdek, ishlatiladigan asboblar sonini kamaytirish uchun testinfra-ni ansible verifier bilan almashtirdik.

To'g'ri aytganda, bir qator chora-tadbirlar mavjud edi:

1. Docker-ga o'tish.
2. Bog'liqlik tufayli takrorlanadigan rol testini olib tashlang.
3. Qullar sonini ko'paytiring.
4. Sinovni ishga tushirish tartibi.
5. Tuklar olish qobiliyati HAMMA bitta buyruq bilan mahalliy.

Natijada, Jenkinsdagi Pipeline ham birlashtirildi

1. Qurilish bosqichlarini yarating.
2. Barchasini parallel ravishda to'kib tashlang.
3. Sinov roli bosqichlarini parallel ravishda bajaring.
4. Tugatish.

O'rgangan darslar

Global o'zgaruvchilardan saqlaning

Ansible global o'zgaruvchilardan foydalanadi, shaklda qisman vaqtinchalik yechim mavjud private_role_vars, lekin bu panatseya emas.

Sizga bir misol keltiraman. Kelinglar 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}}

Qizig'i shundaki, o'yin kitoblarining natijasi har doim ham aniq bo'lmagan narsalarga, masalan, rollarni ro'yxatga olish tartibiga bog'liq bo'ladi. Afsuski, bu Ansiblening tabiati va amalga oshirilishi mumkin bo'lgan eng yaxshi narsa - bu qandaydir kelishuvdan foydalanish, masalan, rol doirasida, faqat ushbu rolda tasvirlangan o'zgaruvchidan foydalanish.

BAD: global o'zgaruvchidan foydalaning.

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

gOOD: V. defaults kerakli o'zgaruvchilarni aniqlang va keyin faqat ulardan foydalaning.

# 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 roli o'zgaruvchilari

BAD: global o'zgaruvchidan foydalaning.

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

gOOD: O'zgaruvchilar uchun rollarda rol nomi bilan prefiksli o'zgaruvchilardan foydalaning; bu inventarizatsiyani ko'rib chiqish orqali nima sodir bo'layotganini tushunishni osonlashtiradi.

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

Loop nazorat o'zgaruvchisidan foydalaning

BAD: Looplarda standart o'zgaruvchidan foydalaning item, agar bu vazifa/o'yin kitobi biror joyga kiritilgan bo'lsa, bu kutilmagan xatti-harakatlarga olib kelishi mumkin

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

gOOD: orqali sikldagi oʻzgaruvchini qayta aniqlang loop_var.

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

Kiritilgan o'zgaruvchilarni tekshiring

Biz o'zgaruvchan prefikslardan foydalanishga kelishib oldik; ular biz kutgandek aniqlanganligini va, masalan, bo'sh qiymat bilan bekor qilinmaganligini tekshirish ortiqcha bo'lmaydi.

gOOD: O'zgaruvchilarni tekshiring.

- 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

Xeshli lug'atlardan saqlaning, tekis tuzilishdan foydalaning

Agar rol o'z parametrlaridan birida xesh/lug'atni kutayotgan bo'lsa, u holda biz bolalar parametrlaridan birini o'zgartirmoqchi bo'lsak, butun xesh/lug'atni bekor qilishimiz kerak bo'ladi, bu esa konfiguratsiya murakkabligini oshiradi.

BAD: Xesh/lug'atdan foydalaning.

---
user:
  name: admin
  group: admin

gOOD: Yassi o'zgaruvchan strukturadan foydalaning.

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

Idempotent o'yin kitoblari va rollarni yarating

Rollar va o'yin kitoblari idempotent bo'lishi kerak, chunki konfiguratsiya o'zgarishini va biror narsani buzish qo'rquvini kamaytiradi. Ammo agar siz molekuladan foydalansangiz, bu odatiy xatti-harakatlardir.

Buyruqlar qobig'i modullaridan foydalanishdan saqlaning

Shell modulidan foydalanish Ansible-ning o'zagi bo'lgan deklarativ o'rniga imperativ tavsif paradigmasini keltirib chiqaradi.

Rollaringizni molekula orqali sinab ko'ring

Molekula juda moslashuvchan narsa, keling, bir nechta stsenariylarni ko'rib chiqaylik.

Molekula Ko'p misollar

В molecule.yml bo'limida platforms siz joylashtirishingiz mumkin bo'lgan ko'plab xostlarni tavsiflashingiz mumkin.

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

Shunga ko'ra, bu xostlar keyin bo'lishi mumkin converge.yml foydalanish:

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

Molekulada namunaning to'g'ri sozlanganligini tekshirish uchun ansible dan foydalanish mumkin, bundan tashqari, bu 3-chiqarishdan beri standart bo'lib kelgan. Bu testinfra/inspec kabi moslashuvchan emas, lekin fayl mazmuni bizning taxminlarimizga mos kelishini tekshirishimiz mumkin:

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

Yoki xizmatni o'rnating, uning mavjud bo'lishini kuting va tutun testini o'tkazing:

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

Murakkab mantiqni modullar va plaginlarga joylashtiring

Ansible deklarativ yondashuvni qo'llab-quvvatlaydi, shuning uchun siz kodni tarmoqlash, ma'lumotlarni o'zgartirish, qobiq modullarini amalga oshirsangiz, kodni o'qish qiyin bo'ladi. Bunga qarshi kurashish va tushunish oson bo'lishi uchun o'z modullaringizni yaratish orqali bu murakkablikka qarshi kurashish ortiqcha bo'lmaydi.

Maslahatlar va fokuslarni umumlashtiring

1. Global o'zgaruvchilardan saqlaning.
2. Prefiks roli o'zgaruvchilari.
3. Loop nazorat o'zgaruvchisidan foydalaning.
4. Kiritilgan o'zgaruvchilarni tekshiring.
5. Xeshli lug'atlardan saqlaning, tekis tuzilishdan foydalaning.
6. Idempotent o'yin kitoblari va rollarni yarating.
7. Buyruqlar qobig'i modullaridan foydalanishdan saqlaning.
8. Rollaringizni molekula orqali sinab ko'ring.
9. Murakkab mantiqni modullar va plaginlarga joylashtiring.

xulosa

Agar sizda IaC bo'lsa ham, siz shunchaki borib, loyihadagi infratuzilmani qayta tiklay olmaysiz. Bu sabr, vaqt va bilim talab qiladigan uzoq jarayon.

ishoratlar

• slaydlar Ansible-ni qanday sinab ko'rish kerak va aqldan ozmang
• Video Ansible-ni qanday sinab ko'rish kerak va aqldan ozmang
• 200 000 qator infratuzilma kodini sinab ko'rishdan nimani o'rgandim
• Ansible: 120 oy ichida 18 VM konfiguratsiyasini Coreos-dan Centos-ga o'tkazish
• Tarqatishni sinab ko'rishda velosipedlarni tayoqchalar orqali qanday sindirish kerak
• Meni sinab ko'ringmi yoki YML dasturchilari Ansibleni sinab ko'rishni orzu qila olasizmi?
• IaC sinovlari bo'yicha ajoyib maqolalar, nutqlar va havolalar ro'yxati
• o'zaro faoliyat post
• Ingliz versiyasi

UPD1 2020.05.01 20:30 - O'yin kitoblarining asosiy profilini yaratish uchun siz foydalanishingiz mumkin callback_whitelist = profile_tasks uzoq vaqt davomida aniq nima ishlayotganini tushunish uchun. Keyin biz o'tamiz Ansible tezlashtirish klassikasi. Siz ham sinab ko'rishingiz mumkin mitogen
UPD2 2020.05.03 16:34 - Ingliz versiyasi

Manba: www.habr.com