Mempercepat Mungkin

Bukan rahasia lagi bahwa dengan pengaturan default, Ansible mungkin tidak melakukan tugasnya dengan sangat cepat. Dalam artikel ini saya akan menunjukkan beberapa alasan untuk ini dan menawarkan pengaturan minimum yang berguna yang, sangat mungkin, akan benar-benar meningkatkan kecepatan proyek Anda.



Kami berdiskusi di sini dan selanjutnya Ansible 2.9.x, yang diinstal di virtualenv yang baru dibuat dengan cara favorit Anda.



Setelah penginstalan, kami membuat file "ansible.cfg" di sebelah playbook Anda - lokasi ini akan memungkinkan Anda untuk mentransfer pengaturan ini bersama dengan proyek, plus mereka akan dimuat secara otomatis.

Pipelining

Seseorang sudah bisa mendengar tentang perlunya menggunakan pipelining, yaitu, tidak menyalin modul ke FS dari sistem target, tetapi mentransfer arsip zip yang dibungkus Base64 langsung ke stdin interpreter Python, tetapi faktanya tetap : Setting ini masih diremehkan. Sayangnya, beberapa distribusi Linux populer yang digunakan untuk mengkonfigurasi sudo secara default tidak terlalu baik - sehingga perintah ini memerlukan tty (terminal), jadi di Ansible, pengaturan yang sangat berguna ini dibiarkan dinonaktifkan secara default.

pipelining = True

Mengumpulkan fakta

Tahukah Anda bahwa dengan pengaturan default, Ansible untuk setiap permainan akan memulai kumpulan fakta dari semua host yang berpartisipasi di dalamnya? Secara umum, jika Anda tidak tahu, sekarang Anda tahu. Untuk mencegah hal ini terjadi, Anda perlu mengaktifkan mode permintaan eksplisit untuk mengumpulkan fakta (eksplisit) atau mode pintar. Di dalamnya, fakta hanya akan dikumpulkan dari tuan rumah yang belum pernah ditemui dalam permainan sebelumnya.

UPD. Saat menyalin, Anda harus memilih salah satu dari pengaturan ini.

gathering = smart|explicit

Menggunakan kembali koneksi ssh

Jika Anda pernah memulai Ansible dalam mode debug (opsi "v" diulang satu hingga sembilan kali), Anda mungkin memperhatikan bahwa koneksi ssh terus dibuat dan diputus. Jadi, ada juga beberapa kehalusan di sini.



Anda dapat menghindari tahap membangun kembali koneksi ssh pada dua tingkat sekaligus: keduanya langsung di klien ssh, dan saat mentransfer file ke host terkelola dari manajer.

Untuk menggunakan kembali koneksi ssh terbuka, cukup teruskan kunci yang diperlukan ke klien ssh. Kemudian dia akan mulai melakukan hal berikut: ketika pertama kali membuat koneksi ssh, buat tambahan apa yang disebut soket kontrol, pada yang berikutnya - periksa keberadaan soket ini, dan, jika berhasil, gunakan kembali koneksi ssh yang ada. Dan agar semua ini masuk akal, kami akan menyetel waktu untuk menyimpan koneksi saat tidak aktif. Detail selengkapnya dapat ditemukan di dokumentasi ssh , dan dalam konteks Ansible, kami cukup menggunakan "penerusan" opsi yang diperlukan ke klien ssh.

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

Untuk menggunakan kembali koneksi ssh yang sudah terbuka saat mentransfer file ke host terkelola, Anda hanya perlu menentukan satu lagi pengaturan yang tidak dikenal ssh_tranfer_method. Dokumentasi tentang masalah ini sangat jarang dan menyesatkan, karena opsi ini berfungsi sendiri! Tetapi membaca kode sumber memungkinkan Anda memahami apa yang sebenarnya akan terjadi: perintah dd akan diluncurkan pada host yang dikelola, bekerja langsung dengan file yang diperlukan.

transfer_method = piped

Ngomong-ngomong, di cabang "kembangkan" pengaturan ini juga ada dan tidak kemana-mana .

Jangan takut dengan pisau, takut dengan garpu

Pengaturan berguna lainnya adalah garpu. Ini menentukan jumlah proses pekerja yang secara bersamaan akan terhubung ke host dan melakukan tugas. Karena kekhasan Python sebagai PL, yang digunakan adalah proses, bukan utas, karena Ansible masih mendukung Python 2.7 - tidak ada asinkron untuk Anda, tidak ada yang dapat berkembang biak asinkron di sini! Secara default, Ansible meluncurkan lima pekerja, tetapi jika ditanya dengan benar, ini akan berjalan lebih banyak:

forks = 20

Saya baru saja memperingatkan Anda bahwa mungkin ada beberapa kesulitan terkait dengan jumlah memori yang tersedia pada mesin pengontrol. Dengan kata lain, Anda dapat, tentu saja, meletakkan garpu = 100500, tetapi siapa bilang itu akan berhasil?

Menyatukan semuanya

Akibatnya, untuk ansible.cfg (format ini), pengaturan yang diperlukan mungkin terlihat 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 semuanya dalam inventaris YaML normal orang yang sehat, maka akan terlihat seperti ini:

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

Sayangnya, ini tidak akan berfungsi dengan pengaturan "gathering = smart / eksplisit" dan "forks = 20": tidak ada padanan YaML. Entah kita mengaturnya di ansible.cfg, atau kita meneruskannya melalui variabel lingkungan ANSIBLE_GATHERING dan ANSIBLE_FORKS.





Beberapa dari pengaturan ini ditemukan saat membaca kode sumber dari plugin koneksi di bawah nama jelas "ssh.py". Saya membagikan hasil bacaan dengan harapan akan menginspirasi orang lain untuk melihat sumbernya, membacanya, memeriksa pelaksanaannya, membandingkan dengan dokumentasinya - bagaimanapun, cepat atau lambat, semua ini akan memberi Anda hasil yang positif. Semoga berhasil!