Mempercepatkan Ansible

Mempercepatkan Ansible
Bukan rahsia lagi bahawa dengan tetapan lalai Ansible tidak boleh melakukan tugasnya dengan cepat. Dalam artikel itu saya akan menunjukkan beberapa sebab untuk ini dan menawarkan tetapan minimum yang berguna yang, agak mungkin, sebenarnya akan meningkatkan kelajuan projek anda.

Di sini dan di bawah kita membincangkan Ansible 2.9.x, yang dipasang dalam virtualenv yang baru dibuat dengan cara kegemaran anda.

Selepas pemasangan, buat fail "ansible.cfg" di sebelah buku main anda - lokasi ini akan membolehkan anda memindahkan tetapan ini bersama-sama dengan projek, serta ia akan dimuatkan secara automatik.

Kerja paip

Sesetengah mungkin telah mendengar tentang keperluan untuk menggunakan saluran paip, iaitu, tidak menyalin modul ke sistem fail sistem sasaran, tetapi memindahkan arkib zip yang dibungkus dalam Base64 terus ke stdin penterjemah Python, tetapi yang lain mungkin tidak, tetapi hakikatnya tetap menjadi fakta: tetapan ini masih dipandang remeh. Malangnya, beberapa pengedaran Linux yang popular digunakan untuk mengkonfigurasi sudo tidak begitu baik secara lalai - supaya arahan ini memerlukan tty (terminal), jadi Ansible membiarkan tetapan yang sangat berguna ini dilumpuhkan secara lalai.

pipelining = True

Mengumpul fakta

Tahukah anda bahawa dengan tetapan lalai, Ansible untuk setiap mainan memulakan pengumpulan fakta untuk semua hos yang menyertainya? Secara umum, jika anda tidak tahu, kini anda tahu. Untuk mengelakkan perkara ini daripada berlaku, anda perlu mendayakan sama ada mod permintaan eksplisit untuk mengumpul fakta (eksplisit) atau mod pintar. Di dalamnya, fakta akan dikumpulkan hanya daripada hos yang tidak ditemui dalam drama sebelumnya.
UPD. Semasa menyalin, anda perlu memilih salah satu tetapan ini.

gathering = smart|explicit

Menggunakan semula sambungan ssh

Jika anda pernah menjalankan Ansible dalam mod nyahpepijat (pilihan "v", diulang satu hingga sembilan kali), anda mungkin perasan bahawa sambungan ssh sentiasa dibuat dan terputus. Jadi, terdapat beberapa kehalusan di sini juga.

Anda boleh mengelakkan langkah mewujudkan semula sambungan ssh pada dua peringkat sekaligus: kedua-duanya secara langsung dalam klien ssh dan apabila memindahkan fail ke hos terurus daripada pengurus.
Untuk menggunakan semula sambungan ssh terbuka, hanya hantar kekunci yang diperlukan kepada klien ssh. Kemudian ia akan mula melakukan perkara berikut: apabila membuat sambungan ssh buat kali pertama, ia juga akan mencipta soket kawalan yang dipanggil, apabila pemasangan berikutnya, ia akan menyemak kewujudan soket ini, dan jika berjaya, gunakan semula sambungan ssh sedia ada. Dan untuk membuat semua ini masuk akal, mari tetapkan masa untuk mengekalkan sambungan apabila tidak aktif. Anda boleh membaca lebih lanjut dalam dokumentasi ssh, dan dalam konteks Ansible kami hanya menggunakan "memajukan" pilihan yang diperlukan kepada klien ssh.

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

Untuk menggunakan semula sambungan ssh yang sudah terbuka apabila memindahkan fail ke hos terurus, hanya nyatakan tetapan lain yang tidak diketahui ssh_tranfer_method. Dokumentasi mengenai subjek ini sangatlah tinggi kedekut dan mengelirukan, kerana pilihan ini berfungsi dengan baik! Tetapi membaca kod sumber membolehkan anda memahami apa sebenarnya yang akan berlaku: arahan dd akan dilancarkan pada hos terurus, secara langsung berfungsi dengan fail yang dikehendaki.

transfer_method = piped

Dengan cara ini, dalam cawangan "membangunkan" tetapan ini juga wujud tidak ke mana-mana.

Jangan takut pada pisau, takutlah pada garpu

Satu lagi tetapan berguna ialah garpu. Ia menentukan bilangan proses pekerja yang akan menyambung ke hos dan melaksanakan tugas secara serentak. Disebabkan keistimewaan Python sebagai bahasa, proses digunakan, bukan utas, kerana Ansible masih menyokong Python 2.7 - tiada asyncio untuk anda, tiada gunanya memperkenalkan tingkah laku tak segerak di sini! Secara lalai Ansible berjalan lima pekerja, tetapi jika ditanya dengan betul, ia akan melancarkan lebih banyak:

forks = 20

Saya hanya memberi amaran kepada anda dengan segera bahawa mungkin terdapat beberapa kesukaran di sini berkaitan dengan jumlah memori yang tersedia pada mesin kawalan. Dalam erti kata lain, anda boleh, sudah tentu, menetapkan garpu=100500, tetapi siapa kata ia akan berfungsi?

Menyatukan semuanya

Akibatnya, untuk ansible.cfg (format ini), tetapan yang diperlukan mungkin kelihatan seperti ini:

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

Dan jika anda ingin menyembunyikan segala-galanya dalam YaML-inventori biasa orang yang sihat, maka ia boleh kelihatan seperti ini:

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

Malangnya, ini tidak akan berfungsi dengan tetapan "gathering = smart/explicit" dan "forks = 20": setara YaML mereka tidak wujud. Sama ada kami menetapkannya dalam ansible.cfg, atau kami menghantarnya melalui pembolehubah persekitaran ANSIBLE_GATHERING dan ANSIBLE_FORKS.

Mengenai Mitogen
- Di manakah ini tentang Mitogen? - anda mempunyai hak untuk bertanya, pembaca yang dihormati. Tiada dalam artikel ini. Tetapi jika anda benar-benar bersedia untuk membaca kodnya dan mengetahui sebab buku main anda ranap dengan Mitogen, tetapi berfungsi dengan baik dengan vanilla Ansible, atau mengapa buku main yang sama berfungsi dengan baik sebelum ini, tetapi selepas kemas kini mula melakukan perkara yang pelik - baiklah, Mitogen berpotensi menjadi alat anda. Terapkan, fahami, tulis artikel - Saya akan membacanya dengan penuh minat.

Mengapa saya tidak menggunakan Mitogen secara peribadi? Kerana Gladiolus berfungsi hanya selagi tugasnya benar-benar mudah dan semuanya baik-baik saja. Walau bagaimanapun, jika anda membelok sedikit ke kiri atau kanan - itu sahaja, kami telah tiba: sebagai tindak balas, segelintir pengecualian yang tidak jelas terbang kepada anda, dan untuk melengkapkan gambar, yang hilang hanyalah frasa biasa “terima kasih semua , semua orang bebas.” Secara umum, saya tidak mahu membuang masa untuk mengetahui sebab "ketukan bawah tanah" seterusnya.

Beberapa tetapan ini ditemui semasa proses membaca kod sumber pemalam sambungan di bawah nama penjelasan sendiri "ssh.py". Saya berkongsi hasil pembacaan dengan harapan ia akan memberi inspirasi kepada orang lain untuk melihat sumber, membacanya, menyemak pelaksanaannya, bandingkan dengan dokumentasi - lagipun, lambat laun semua ini akan membawa anda hasil yang positif. Semoga berjaya!

Hanya pengguna berdaftar boleh mengambil bahagian dalam tinjauan. Log masuk, Sama-sama.

Antara tetapan Ansible berikut, yang manakah anda gunakan untuk mempercepatkan projek anda?

  • 69,6% saluran paip=benar32

  • 34,8% berhimpun = pandai/jelas16

  • 52,2% ssh_args = "-o ControlMaster=auto -o ControlPersist=..."24

  • 17,4% kaedah_pindah = paip8

  • 63,0% garpu = XXX29

  • 6,5% Tiada satu pun daripada ini, hanya Mitogen3

  • 8,7% Mitogen + Saya akan perhatikan yang mana antara tetapan ini4

46 pengguna mengundi. 21 pengguna berpantang.

Inginkan lebih banyak perkara tentang Ansible?

  • 78,3% ya, sudah tentu54

  • 21,7% ya, saya cuma mahukan lebih banyak barangan tegar!15

  • 0,0% tidak, dan ia tidak perlu untuk apa-apa0

  • 0,0% tidak, ianya rumit!!!0

69 pengguna mengundi. 7 pengguna berpantang.

Sumber: www.habr.com

Tambah komen