🥇Ansible'ı Hızlandırıyoruz

Hamıya məlumdur ki, "defolt" parametrlərlə Ansible öz işini çox sürətli etmir. Bu məqalədə bunun bir neçə səbəbini göstərəcəm və layihənizin işləmə sürətini artıra biləcək faydalı minimum parametrlər təqdim edəcəyəm.

Burada və daha sonrasında 2.9.x versiyasını müzakirə edəcəyik, bu da sevimli yolunuzla yaradılmış virtualenv-də qurulub.

Quraşdırıldıqdan sonra, playbook-unuzun yanına "ansible.cfg" adlı bir fayl yaradın — bu yerleşim parametrləri layihənizlə birlikdə daşımağa imkan tanıyacaq, üstəlik, onlar tam avtomatik yüklənəcək.

Kanalizasiya

Pipelining-in istifadə edilməsinin vacib olduğu, yəni modulları məqsəd sisteminin fayl sisteminə kopyalamaq əvəzinə, Base64 zip arxivinin Python interpretatorunun stdin-ə birbaşa göndərilməsi barədə kimlərinsə eşitmiş ola biləcəyini unutmayın. Ancaq fakt budur ki, bu parametr hələ də aşağı qiymətləndirilir. Təəssüf ki, bəzi populyar Linux distrosları əvvəllər sudo-nu çox yaxşı tənzimləmirdi - elə ki, bu əmrin tty (terminal) olması tələb olunurdu, buna görə də Ansible-da bu çox faydalı parametri defolt olaraq söndürülmüş şəkildə saxlayırdılar.

pipelining = True

Faktların toplanması

Defolt parametrlərlə Ansible hər play üçün iştirak edən bütün hostlarda faktların toplanmasını başladıb? Bilirdinizmi? Ümumiyyətlə, əgər bilmirdinizsə, indi bilirsiniz. Bunun baş verməməsi üçün ya açıq fakt toplanma (explicit), ya da smart rejimini aktiv etmək lazımdır. Bu rejimdə faktlar, əvvəlki play-lərdə rast gəlinməyən hostlardan yalnız toplanacaq.
Yeniləmə. Köçürdüyünüz zaman bu parametrlərdən birini seçməlisiniz.

gathering = smart|explicit

ssh bağlantalarının yenidən istifadə edilməsi

Əgər bir vaxtlar Ansible-i debug çıxarış rejimində ("v" seçimini bir ilə doqquz dəfə təkrarladığınızda) çalışdırmısınızsa, bəlkə də ssh bağlantılarının davamlı olaraq qurulub, kəsildiyini görmüsünüz. Beləliklə, burada da bir neçə nüans mövcuddur.

Yenidən ssh bağlantısı qurma mərhələsindən qaçmaq olar, həm ssh müştəri, həm də idarəedici hosta faylların ötürülməsi səviyyəsində.
Açıq ssh bağlantısını istifadə etmək üçün, müştəriyə lazım olan açarları ötürməniz kifayətdir. Beləliklə, o, ssh bağlantısını ilk dəfə qurduqda, xüsusi control socket yaratmağa başlayacaq, və sonrakılarda bu socketin mövcudluğunu yoxlayaraq, uğur nəticəsində mövcud ssh bağlantısını yenidən istifadə edəcək. Bunun mənası olması üçün, aktiv olmama müddətində bağlantının saxlanma vaxtını təyin edək. Daha ətraflı məlumat üçün ssh dokumentasiyasınabaxın, Ansible kontekstində isə sadəcə müştəriyə lazım olan ssh parametrlərinin "ötürülməsindən" istifadə edirik.

ssh_args = "-o ControlMaster=auto -o ControlPersist=15m"

Artırılmış SSH bağlantısını istifadə edərək, idarə olunan host'a fayllar ötürmək üçün yalnız bir əlavə bilinməyən ssh_transfer_method parametresini qeyd etmək kifayətdir. Bu məsələ ilə bağlı sənədçilik olduqca sıqdır və sizi yanıltır, çünki bu seçim tamamilə işləkdir! Amma oxumaq mənbə kodundan nə baş verəcəyini anlamağa kömək edir: idarə olunan hostda düzgün fayl ilə birbaşa işləyən dd komandası işə salınacaq.

transfer_method = piped

Bu arada, "develop" şöbəsində bu konfiqurasiya da mövcuddur və heç bir yerə getməyib.

Bıçaqdan qorxma, çəngəldən qorx

Başqa bir faydalı parametri — forks. Bu, eyni anda hostlara qoşulub və vəzifələri yerinə yetirəcək işçi proseslərinin sayını müəyyən edir. Python-un proqramlaşdırma dili olması səbəbi ilə məhz proseslərdən istifadə olunur, çünki Ansible hələ də Python 2.7-i dəstəkləyir — heç bir asyncio, asinxronluq burada lazım deyil! İdarə olunan Ansible beş işçi prosesini başlayır, amma düzgün istəsən daha çoxunu başlayacaq:

forks = 20

Amma burada idarəetmə maşınında olan yaddaş həcmi ilə bağlı bəzi çətinliklər yarana bilər. Yəni, forks=100500 təyin etmək mümkündür, amma kim dedi ki, bu işləyəcək?

Hər şeyi birləşdirək

Nəticədə ansible.cfg (ini formatında) üçün lazım olan konfiqurasiyalar belə görünə bilər:

[defaults]
gathering = smart|explicit
forks = 20
[ssh_connection]
pipelining = True
ssh_args = -o ControlMaster=auto -o ControlPersist=15m
transfer_method = piped

Əgər sən düzəlişləri normal bir YaML-inventory-də gizlətmək istəyirsənsə, o, belə görünə bilər:

---
all:
  vars:
    ansible_ssh_pipelining: true
    ansible_ssh_transfer_method: piped
    ansible_ssh_args: -o ControlMaster=auto -o ControlPersist=15m

Təəssüf ki, "gathering = smart/explicit" və "forks = 20" parametrləri üçün bu baş tutmayacaq: onların YaML ekvivalentləri yoxdur. Ya ansible.cfg-də yerləşdiririk, ya da ANSIBLE_GATHERING və ANSIBLE_FORKS mühit dəyişənləri vasitəsilə ötürürük.

Mitogen haqqında
— Burada Mitogen haqqında harada? — soruşa bilərsən, hörmətli oxucu. Bu məqalədə — heç bir yerdə. Amma əgər həqiqətən onun kodunu oxumağa və niyə playbook-un Mitogen ilə düşdüyünü, amma vanil Ansible ilə normal çalışdığını anlamağa hazırsansa, ya da niyə bu playbook daha əvvəl problemsiz işləyirdi, lakin yeniləmədən sonra qəribə hala gəldi — nə isə, Mitogen sizin alətiniz ola bilər. İstifadə et, dərk et, məqalələr yaz — maraqla oxuyacağam.

Niyə mən şəxsən Mitogen istifadə etmirəm? Çünki gladyolus işləmir, yalnız tapşırıqlar gerçəkdən sadə olduğu müddətdə və hər şey yaxşıdır. Amma bir az sola ya da sağa döndüyündə - hər şey bitdi: cavab olaraq sizə bir sıra mənasız istisnalar yağılır və mənzərəni tamamlamaq üçün yalnız "hər kəsə təşəkkürlər, hər kəs sərbəstdir" ifadəsi çatmır. Başqa sözlə, mən sadəcə daha bir "yeraltı səsin" səbəbini araşdırmağa vaxt sərf etmək istəmirəm.

Bu parametrlərin bəziləri oxuyarkən aşkar edilmişdir mənbə kodundan «ssh.py» adlı bir bağlantı eklentisini paylaşıyorum. Okuma sonucunu, birilerinin kaynak kodlarına bakmasına, onları okumasına, uygulamayı kontrol etmesine ve belgelerle karşılaştırmasına ilham vermesini umarak paylaşıyorum; çünkü tüm bunlar bir gün size olumlu sonuçlar getirecektir. Bol şans!

Yalnız qeydiyyatdan keçmiş istifadəçilər sorğuda iştirak edə bilərlər. Daxil olun, xahiş edirəm.