🥇Mempercepat Kemungkinan

Bukan rahasia lagi bahwa dengan pengaturan default, Ansible tidak dapat 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.

Di sini dan di bawah ini kita membahas Ansible 2.9.x, yang diinstal di virtualenv yang baru dibuat dengan cara favorit Anda.

Setelah instalasi, buat file “ansible.cfg” di sebelah playbook Anda - lokasi ini memungkinkan Anda mentransfer pengaturan ini bersama dengan proyek, ditambah lagi pengaturan tersebut akan dimuat secara otomatis.

perpipaan

Beberapa orang mungkin pernah mendengar tentang perlunya menggunakan pipelining, yaitu, tidak menyalin modul ke sistem file sistem target, tetapi mentransfer arsip zip yang dibungkus Base64 langsung ke stdin penerjemah Python, tetapi yang lain mungkin tidak, tetapi faktanya tetap menjadi fakta: pengaturan ini masih dianggap remeh. Sayangnya, beberapa distribusi Linux populer yang digunakan untuk mengkonfigurasi sudo tidak terlalu baik secara default - sehingga perintah ini memerlukan tty (terminal), jadi Ansible membiarkan pengaturan yang sangat berguna ini dinonaktifkan secara default.

pipelining = True

Mengumpulkan fakta

Tahukah Anda bahwa dengan pengaturan default, Ansible untuk setiap permainan memulai pengumpulan fakta untuk 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-fakta akan dikumpulkan hanya dari host-host yang tidak ditemui dalam permainan sebelumnya.
UPD. Saat menyalin, Anda harus memilih salah satu pengaturan ini.

gathering = smart|explicit

Menggunakan kembali koneksi ssh

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

Anda dapat menghindari langkah membuat kembali koneksi ssh pada dua level sekaligus: baik secara langsung di klien ssh, dan saat mentransfer file ke host terkelola dari manajer.
Untuk menggunakan kembali koneksi ssh yang terbuka, cukup berikan kunci yang diperlukan ke klien ssh. Kemudian ia akan mulai melakukan hal berikut: ketika membuat koneksi ssh untuk pertama kalinya, ia juga akan membuat apa yang disebut soket kontrol, pada instalasi selanjutnya, ia akan memeriksa keberadaan soket ini, dan jika berhasil, gunakan kembali koneksi ssh yang ada. Dan agar semua ini masuk akal, mari kita atur waktu untuk menjaga koneksi saat tidak aktif. Anda dapat membaca lebih lanjut di dokumentasi ssh, dan dalam konteks Ansible kami cukup menggunakan "meneruskan" 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 yang dikelola, cukup tentukan pengaturan lain yang tidak diketahui ssh_tranfer_method. Dokumentasi mengenai hal ini sangat luar biasa pelit dan menyesatkan, karena opsi ini berfungsi dengan baik! Tapi membaca Kode sumber memungkinkan Anda memahami apa yang sebenarnya akan terjadi: perintah dd akan diluncurkan pada host yang dikelola, langsung bekerja dengan file yang diinginkan.

transfer_method = piped

Omong-omong, di cabang “pengembangan” pengaturan ini juga ada tidak kemana mana.

Jangan takut pada pisau, takutlah pada garpu

Pengaturan lain yang bermanfaat adalah fork. Ini menentukan jumlah proses pekerja yang secara bersamaan akan terhubung ke host dan melakukan tugas. Karena kekhasan Python sebagai bahasa, proses digunakan, bukan utas, karena Ansible masih mendukung Python 2.7 - tidak ada asyncio untuk Anda, tidak ada gunanya memperkenalkan perilaku asinkron di sini! Secara default, Ansible berjalan lima pekerja, tetapi jika ditanya dengan benar, ini akan meluncurkan lebih banyak:

forks = 20

Saya baru saja memperingatkan Anda bahwa mungkin ada beberapa kesulitan di sini terkait dengan jumlah memori yang tersedia pada mesin kontrol. Dengan kata lain, Anda tentu saja dapat menyetel forks=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 di inventaris YaML normal orang sehat, maka tampilannya akan 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/explicit” dan “forks = 20”: padanan YaML-nya tidak ada. Entah kita mengaturnya di ansible.cfg, atau kita meneruskannya melalui variabel lingkungan ANSIBLE_GATHERING dan ANSIBLE_FORKS.

Tentang Mitogen
- Dimana ini tentang Mitogen? - Anda berhak bertanya, pembaca yang budiman. Tidak ada tempat di artikel ini. Tetapi jika Anda benar-benar siap membaca kodenya dan mencari tahu mengapa buku pedoman Anda mogok dengan Mitogen, tetapi berfungsi baik dengan vanilla Ansible, atau mengapa buku pedoman yang sama berfungsi dengan baik sebelumnya, tetapi setelah pembaruan mulai melakukan hal-hal aneh - ya, Mitogen berpotensi menjadi alat Anda. Terapkan, pahami, tulis artikel - saya akan membacanya dengan penuh minat.

Mengapa saya pribadi tidak menggunakan Mitogen? Karena gladiol ini hanya berfungsi selama tugasnya benar-benar sederhana dan semuanya baik-baik saja. Namun, jika Anda berbelok sedikit ke kiri atau ke kanan - itu saja, kita telah sampai: sebagai tanggapan, beberapa pengecualian yang tidak jelas terbang ke arah Anda, dan untuk melengkapi gambarannya, yang hilang hanyalah frasa umum “terima kasih semuanya , semua orang bebas.” Secara umum, saya hanya tidak ingin membuang waktu mencari tahu alasan “ketuk bawah tanah” berikutnya.

Beberapa pengaturan ini ditemukan selama proses membaca Kode sumber plugin koneksi dengan nama yang cukup jelas “ssh.py”. Hasil bacaan saya bagikan dengan harapan dapat menginspirasi orang lain untuk melihat sumbernya, membacanya, mengecek implementasinya, membandingkannya dengan dokumentasi - lagi pula, cepat atau lambat semua ini akan membawa Anda hasil yang positif. Semoga beruntung!

Hanya pengguna terdaftar yang dapat berpartisipasi dalam survei. Masuk, silakan.

Manakah dari pengaturan Ansible berikut yang Anda gunakan untuk mempercepat proyek Anda?

69,6%pemipaan=true32
34,8%berkumpul = pintar/eksplisit16
52,2%ssh_args = "-o ControlMaster=otomatis -o ControlPersist=..."24
17,4%transfer_method = disalurkan8
63,0%garpu = XXX29
6,5%Semua ini tidak ada, hanya Mitogen3
8,7%Mitogen + Saya akan mencatat yang mana dari pengaturan ini4

46 pengguna memilih. 21 pengguna abstain.

Ingin lebih banyak informasi tentang Ansible?

78,3%ya, tentu saja54
21,7%ya, saya hanya ingin lebih banyak barang-barang hardcore!15
0,0%tidak, dan itu tidak perlu untuk apa pun0
0,0%tidak, ini rumit!!!0

69 pengguna memilih. 7 pengguna abstain.

Sumber: www.habr.com

Mempercepat Kemungkinan