Mengotomatiskan penggantian disk dengan Ansible

Halo semuanya. Saya bekerja sebagai administrator sistem terkemuka di OK dan saya bertanggung jawab untuk operasi portal yang stabil. Saya ingin berbicara tentang bagaimana kami membangun proses penggantian disk otomatis, dan kemudian, ketika seorang administrator dikeluarkan dari proses ini dan menggantinya dengan bot.

Artikel ini adalah semacam transliterasi kinerja di HighLoad + 2018

Membangun proses penggantian disk

Pertama beberapa angka

OK adalah layanan raksasa yang digunakan oleh jutaan orang. Ini dilayani oleh sekitar 7 ribu server, yang berlokasi di 4 pusat data yang berbeda. Server harganya lebih dari 70 ribu drive. Jika Anda menumpuknya di atas satu sama lain, Anda mendapatkan menara dengan ketinggian lebih dari 1 km.

Hard drive adalah komponen dari server yang paling sering crash. Dengan volume seperti itu, kami harus mengubah sekitar 30 disc per minggu, dan prosedur ini telah menjadi rutin yang tidak menyenangkan.

Insiden

Kami telah memperkenalkan manajemen insiden lengkap di perusahaan kami. Setiap kejadian kami rekam di Jira, lalu kami pecahkan dan bongkar. Jika kejadian itu berpengaruh bagi pengguna, maka kita pasti akan berpikir tentang bagaimana merespons lebih cepat dalam kasus seperti itu, bagaimana mengurangi efeknya dan tentu saja bagaimana mencegah terulangnya.

Drive tidak terkecuali. Status mereka dipantau oleh Zabbix. Kami memantau pesan dalam Syslog untuk kesalahan tulis / baca, menganalisis status serangan HW / SW, memantau SMART, dan menghitung keausan untuk SSD.

Bagaimana cakram berubah sebelumnya

Ketika pemicu menyala di Zabbix, sebuah insiden dibuat di Jira dan secara otomatis dimasukkan ke insinyur yang tepat di pusat data. Kami melakukan ini dengan semua insiden HW, yaitu yang membutuhkan semacam pekerjaan fisik dengan peralatan di pusat data.
Seorang insinyur dari pusat data adalah orang yang memecahkan masalah yang terkait dengan perangkat keras, bertanggung jawab untuk instalasi, pemeliharaan, pembongkaran server. Setelah menerima tiket, insinyur mulai bekerja. Di rak disk, ia mengganti disk sendiri. Tetapi jika dia tidak memiliki akses ke perangkat yang diinginkan, insinyur beralih ke administrator sistem yang bertugas untuk membantu. Pertama-tama, Anda perlu menghapus disk dari rotasi. Untuk melakukan ini, Anda perlu membuat perubahan yang diperlukan di server, menghentikan aplikasi, unmount disk.

Administrator sistem yang bertugas selama shift bertanggung jawab atas pengoperasian seluruh portal. Dia menyelidiki insiden, perbaikan, membantu pengembang melakukan tugas-tugas kecil. Dia tidak hanya berurusan dengan hard drive.

Sebelumnya, para insinyur pusat data mengobrol dengan administrator sistem. Para insinyur mengirim tautan ke tiket Jira, administrator memeriksa, menyimpan catatan pekerjaan di beberapa buku catatan. Tetapi obrolan tidak nyaman untuk tugas-tugas seperti itu: informasi di sana tidak terstruktur dan cepat hilang. Dan administrator hanya bisa menjauh dari komputer dan untuk beberapa waktu tidak menanggapi permintaan, dan insinyur berdiri di server dengan sekelompok disk dan menunggu.

Tetapi yang terburuk adalah bahwa administrator tidak melihat seluruh gambar: insiden disk apa yang ada, di mana masalah tersebut berpotensi muncul. Ini karena fakta bahwa kami memberikan semua insiden HW kepada para insinyur. Ya, itu mungkin untuk menampilkan semua insiden di dasbor admin. Tetapi ada banyak dari mereka, dan administrator hanya terlibat dalam beberapa dari mereka.

Selain itu, insinyur tidak dapat memprioritaskan dengan benar, karena ia tidak tahu apa-apa tentang tujuan server tertentu, tentang distribusi informasi lintas drive.

Prosedur penggantian baru

Hal pertama yang kami lakukan adalah mengambil semua insiden disk menjadi tipe "HW-disk" yang terpisah dan menambahkan bidang "blok nama perangkat", "ukuran" dan "tipe disk" ke dalamnya sehingga informasi ini akan disimpan dalam tiket dan tidak harus terus mengobrol.


Kami juga sepakat bahwa dalam kerangka satu insiden kami hanya akan mengubah satu disk. Ini sangat menyederhanakan proses otomatisasi, pengumpulan statistik, dan pekerjaan.

Selain itu, bidang "administrator yang bertanggung jawab" telah ditambahkan. Administrator sistem secara otomatis diganti di sana. Ini sangat nyaman, karena sekarang insinyur selalu melihat siapa yang bertanggung jawab. Tidak perlu pergi ke kalender dan mencari. Bidang inilah yang memungkinkan menempatkan tiket di dasbor administrator, di mana, mungkin, bantuannya akan dibutuhkan.


Untuk memastikan bahwa semua peserta menerima manfaat maksimal dari inovasi, kami membuat filter dan dasbor, memberi tahu orang-orang tentang mereka. Ketika orang memahami perubahan, mereka tidak menjauhkan diri dari mereka sebagai sesuatu yang tidak perlu. Penting bagi seorang insinyur untuk mengetahui nomor rak di mana server berada, ukuran dan jenis disk. Administrator perlu, pertama-tama, untuk memahami apa jenis grup server ini, apa efeknya ketika mengganti disk.

Kehadiran bidang dan tampilan mereka nyaman, tetapi ini tidak menyelamatkan kita dari kebutuhan untuk menggunakan obrolan. Untuk melakukan ini, saya harus mengubah alur kerja.

Dulu seperti ini:


Saat ini, para insinyur terus bekerja seperti ini ketika mereka tidak membutuhkan bantuan administrator.

Hal pertama yang kami lakukan adalah memperkenalkan status Investigate baru. Tiket berada dalam status ini ketika insinyur belum memutuskan apakah dia akan membutuhkan administrator atau tidak. Melalui status ini, insinyur dapat meneruskan tiket ke administrator. Selain itu, kami menandai tiket dengan status ini saat penggantian disk diperlukan, tetapi tidak ada disk itu sendiri di situs. Ini terjadi dengan CDN dan situs jarak jauh.

Kami juga menambahkan status Siap . Tiket ditransfer ke sana setelah mengganti disk. Artinya, semuanya sudah dilakukan, tetapi HW / SW RAID disinkronkan di server. Ini bisa sangat memakan waktu.

Jika seorang administrator terlibat, skema ini sedikit lebih rumit.


Dari status Terbuka , tiket dapat ditransfer oleh administrator sistem dan insinyur. Dalam status Dalam proses , administrator menghapus disk dari rotasi sehingga insinyur dapat menghapusnya: itu menyalakan lampu latar, meng-unmount disk, dan menghentikan aplikasi, tergantung pada kelompok server tertentu.

Kemudian tiket dikonversi ke Siap untuk berubah : ini adalah sinyal kepada insinyur bahwa disk dapat ditarik keluar. Semua bidang di Jira sudah diisi, insinyur tahu apa jenis dan ukuran disk. Data ini ditempelkan pada status sebelumnya secara otomatis atau oleh administrator.

Setelah mengganti disk, tiket ditransfer ke status Berubah . Diperiksa bahwa disk yang benar telah dimasukkan, markup dilakukan, aplikasi diluncurkan, dan beberapa tugas pemulihan data dilakukan. Juga, tiket dapat ditransfer ke status Siap , dalam hal ini administrator akan tetap bertanggung jawab, karena ia memulai disk secara bergiliran. Garis besar terlihat seperti ini.


Menambahkan bidang baru membuat hidup kita lebih mudah. Orang-orang mulai bekerja dengan informasi terstruktur, menjadi jelas apa dan pada tahap apa yang harus dilakukan. Prioritas menjadi jauh lebih relevan karena sekarang ditetapkan oleh administrator.

Kebutuhan akan obrolan telah menghilang. Tentu saja, administrator dapat menulis kepada insinyur "Anda harus mengganti lebih cepat di sini," atau "sudah malam, apakah Anda punya waktu untuk mengganti?". Tapi kami tidak lagi mengobrol setiap hari tentang masalah ini.

Disk mulai berubah dalam paket. Jika administrator datang untuk bekerja sedikit lebih awal, ia memiliki waktu luang, dan tidak ada yang terjadi, ia dapat menyiapkan sejumlah server untuk penggantian: meletakkan bidang, menghapus disk dari rotasi dan mentransfer tugas ke insinyur. Seorang insinyur kemudian tiba di pusat data, melihat tugas, mengambil drive yang diperlukan dari gudang dan segera mengubahnya. Akibatnya, kecepatan penggantian telah meningkat.

Pelajaran yang Dipetik dalam Membangun Alur Kerja

• Saat membuat prosedur, Anda perlu mengumpulkan informasi dari berbagai sumber.
  Beberapa administrator kami tidak tahu bahwa insinyur mengubah disk sendiri. Beberapa orang berpikir bahwa para insinyur memantau sinkronisasi MD RAID, meskipun beberapa dari mereka bahkan tidak memiliki akses ke ini. Beberapa insinyur terkemuka melakukan ini, tetapi tidak selalu, karena prosesnya tidak dijelaskan di mana pun.
• Prosedurnya harus sederhana dan mudah.
  Sulit bagi seseorang untuk menyimpan banyak langkah di kepalanya. Status tetangga yang paling penting di Jira perlu ditampilkan di layar utama. Anda dapat mengubah nama mereka, misalnya, Dalam proses kami memanggil Siap untuk berubah. Dan status yang tersisa dapat disembunyikan di menu drop-down sehingga mereka tidak memanggil mata. Tetapi lebih baik tidak membatasi orang, untuk memberikan kesempatan untuk melakukan transisi.
  Jelaskan nilai inovasi. Ketika orang mengerti, mereka lebih baik menerima prosedur baru. Sangat penting bagi kami bahwa orang tidak memanggil keseluruhan proses, tetapi mengikutinya. Kemudian kami membangun otomatisasi ini.
• Tunggu, analisis, pahami.
  Kami membutuhkan waktu sekitar satu bulan untuk membangun prosedur, implementasi teknis, pertemuan dan diskusi. Dan untuk implementasi - lebih dari tiga bulan. Saya melihat bagaimana orang perlahan mulai menggunakan inovasi. Pada tahap awal, ada banyak hal negatif. Tetapi dia benar-benar independen dari prosedur itu sendiri, implementasi teknisnya. Misalnya, satu administrator tidak menggunakan Jira, tetapi plugin Jira di Confluence, dan beberapa hal tidak tersedia baginya. Menunjukkan kepadanya Jira, administrator telah meningkatkan produktivitas dan tugas secara keseluruhan, dan untuk mengganti disk.

Otomasi Pengganti Drive

Kami pergi ke otomatisasi mengganti disk beberapa kali. Kami sudah memiliki waktu operasi, skrip, tetapi semuanya bekerja baik secara interaktif atau dalam mode manual, mereka membutuhkan peluncuran. Dan hanya setelah pengenalan prosedur baru, kami menyadari bahwa itu hanya karena kami hilang.

Karena sekarang proses penggantian dibagi menjadi beberapa tahap, yang masing-masing memiliki pelaksana dan daftar tindakan, kita dapat mengaktifkan otomatisasi secara bertahap, dan tidak semuanya sekaligus. Misalnya, langkah paling sederhana - Siap (memeriksa RAID / sinkronisasi data) dapat dengan mudah didelegasikan ke bot. Saat bot sedikit belajar, Anda bisa memberikannya tugas yang lebih bertanggung jawab - menempatkan disk dalam rotasi, dll.

Pengaturan kebun binatang

Sebelum berbicara tentang bot, kami akan melakukan perjalanan singkat ke kebun binatang instalasi kami. Pertama-tama, itu karena ukuran infrastruktur kami yang sangat besar. Kedua, untuk setiap layanan kami mencoba memilih konfigurasi besi yang optimal. Kami memiliki sekitar 20 model RAID perangkat keras, terutama LSI dan Adaptec, tetapi ada versi HP dan DELL yang berbeda. Setiap pengontrol RAID memiliki utilitas manajemennya sendiri. Serangkaian perintah dan penerbitannya mungkin berbeda dari versi ke versi masing-masing pengontrol RAID. Di mana HW-RAID tidak digunakan, mungkin takut.

Hampir semua instalasi baru kami lakukan tanpa cadangan disk. Kami mencoba untuk tidak lagi menggunakan perangkat keras dan perangkat lunak RAID, karena kami memesan sistem kami di tingkat pusat data, bukan server. Tetapi tentu saja ada banyak server lama yang perlu didukung.

Di suatu tempat, disk di pengendali RAID membuang perangkat mentah, di suatu tempat, mereka menggunakan JBOD. Ada konfigurasi dengan satu drive sistem di server, dan jika Anda perlu menggantinya, Anda harus memformat ulang server dengan instalasi OS dan aplikasi, dengan versi yang sama, lalu menambahkan file konfigurasi, meluncurkan aplikasi. Ada juga banyak kelompok server di mana redundansi dilakukan bukan pada tingkat subsistem disk, tetapi langsung di aplikasi itu sendiri.

Secara total, kami memiliki lebih dari 400 grup server unik yang menjalankan sekitar 100 aplikasi berbeda. Untuk mencakup sejumlah besar opsi, kami membutuhkan alat otomatisasi multifungsi. Disarankan dengan DSL sederhana, sehingga tidak hanya orang yang menulis ini dapat mendukungnya.

Kami memilih Ansible karena tanpa agen: tidak perlu menyiapkan infrastruktur, mulai cepat. Selain itu, ditulis dalam Python, yang diterima sebagai standar dalam tim.

Skema umum

Mari kita lihat skema otomatisasi umum menggunakan satu kejadian sebagai contoh. Zabbix mendeteksi bahwa drive sdb rusak, pemicu menyala, tiket dibuat di Jira. Administrator melihatnya, menyadari bahwa ini bukan duplikat dan bukan false positive, yaitu, Anda perlu mengubah disk, dan menerjemahkan tiket sedang berlangsung.


Aplikasi DiskoBot ditulis dengan Python secara berkala polling Jira untuk tiket baru. Ia memperhatikan bahwa tiket In progress baru telah muncul, utas terkait dipicu, yang meluncurkan buku pedoman dalam Ansible (ini dilakukan untuk setiap status di Jira). Dalam hal ini, Persiapan2 mulai.

Kemungkinan pergi ke host, menghapus disk dari rotasi, dan melaporkan status ke aplikasi melalui Panggilan Balik.


Menurut hasil, bot secara otomatis mentransfer tiket ke Siap untuk berubah. Insinyur menerima pemberitahuan dan pergi untuk mengganti disk, setelah itu ia mentransfer tiket ke Changed.


Menurut skema di atas, tiket kembali ke bot, meluncurkan playbook lain, pergi ke tuan rumah dan memasukkan disk ke dalam rotasi. Bot menutup tiket. Hore!


Sekarang mari kita bicara tentang beberapa komponen sistem.

Diskobot

Aplikasi ini ditulis dengan Python. Ini memilih tiket dari Jira menurut JQL . Tergantung pada status tiket, yang terakhir sampai ke penangan yang sesuai, yang pada gilirannya meluncurkan status Playbook yang sesuai.

Interval JQL dan polling didefinisikan dalam file konfigurasi aplikasi.

jira_states: investigate: jql: '… status = Open and "Disk Size" is EMPTY' interval: 180 inprogress: jql: '… and "Disk Size" is not EMPTY and "Device Name" is not EMPTY' ready: jql: '… and (labels not in ("dbot_ignore") or labels is EMPTY)' interval: 7200 

Misalnya, di antara tiket dalam status Dalam proses, hanya yang dengan ukuran Disk dan bidang Nama perangkat yang diisi. Nama perangkat adalah nama perangkat blok yang diperlukan untuk menjalankan playbook. Ukuran disk diperlukan agar insinyur mengetahui ukuran disk yang diperlukan.

Dan di antara tiket dengan status Siap, tiket dengan label dbot_ignore disaring. Ngomong-ngomong, kami menggunakan label Jira baik untuk penyaringan seperti itu, dan untuk menandai tiket rangkap, dan mengumpulkan statistik.

Jika playbook mogok, Jira memberikan label dbot_failed sehingga Anda dapat mengetahuinya nanti.

Interaksi dengan Ansible

Aplikasi berinteraksi dengan Ansible melalui Ansible Python API . Di playbook_executor, kami meneruskan nama file dan set variabel. Ini memungkinkan Anda untuk menyimpan proyek Ansible dalam bentuk file yml biasa, daripada menggambarkannya dalam kode Python.

Juga di Ansible melalui * extra_vars * nama perangkat blok, status tiket, serta callback_url, di mana kunci masalah disambungkan, digunakan - digunakan untuk panggilan balik dalam HTTP.

Untuk setiap peluncuran, inventaris sementara dihasilkan, terdiri dari satu host dan grup yang dimiliki host ini sehingga group_vars diterapkan.

Berikut adalah contoh tugas di mana HTTP callback diimplementasikan.

Hasil dari buku pedoman yang kami dapat menggunakan callaback (s). Ada dua jenis:

• Plugin callback yang memungkinkan , ini menyediakan data hasil playbook. Ini menjelaskan tugas yang diluncurkan, dilakukan dengan sukses atau tidak berhasil. Callback ini disebut di akhir buku pedoman.
• Callback HTTP untuk mendapatkan informasi saat memainkan buku pedoman. Dalam Ansible, kami melakukan permintaan POST / GET ke sisi aplikasi kami.

Melalui HTTP callback, variabel yang ditentukan selama eksekusi playbook dan yang ingin kita simpan dan gunakan dalam menjalankan selanjutnya ditransmisikan. Kami menulis data ini dalam sqlite.

Juga melalui HTTP callback kami meninggalkan komentar dan mengubah status tiket.


Seperti banyak jenis tugas yang sama, kami meletakkannya di file umum yang terpisah dan memasukkannya jika perlu, agar tidak berulang di buku pedoman. Callback_ url muncul di sini, di mana kunci masalah dan nama host dilindungi. Ketika Ansible mengeksekusi permintaan POST ini, bot menyadari bahwa itu datang sebagai bagian dari insiden semacam itu.

Dan berikut ini adalah contoh dari buku pedoman, di mana kami menampilkan disk dari perangkat MD:

  # Save mdadm configuration - include: common/callback.yml vars: callback_post_body: status: 'Ready to change' msg: "Removed disk from mdraid {{ mdadm_remove_disk.msg | comment_jira }}" data: mdadm_data: "{{ mdadm_remove_disk.removed }}" parted_info: "{{ parted_info | default() }}" when: - mdadm_remove_disk | changed - mdadm_remove_disk.removed 

Tugas ini menempatkan tiket Jira dalam status "Siap untuk berubah" dan menambahkan komentar. Juga, variabel mdam_data menyimpan daftar perangkat md dari mana disk dihapus, dan dump parted dari parted di parted_info.

Ketika insinyur memasukkan disk baru, kami akan dapat menggunakan variabel-variabel ini untuk mengembalikan dump partisi, serta memasukkan disk ke perangkat md dari mana itu dihapus.

Mode pemeriksaan yang dimungkinkan

Mengaktifkan otomatisasi menakutkan. Karena itu, kami memutuskan untuk menjalankan semua playbook dalam mode
dry run , di mana Ansible tidak melakukan tindakan apa pun di server, tetapi hanya meniru mereka.

Peluncuran semacam itu dijalankan melalui modul callback terpisah, dan hasil dari playbook disimpan di Jira sebagai komentar.



Pertama, itu diizinkan untuk memvalidasi karya bot dan buku pedoman. Kedua, itu meningkatkan kepercayaan administrator di bot.

Ketika kami melewati validasi dan menyadari bahwa Anda dapat menjalankan Ansible tidak hanya dalam mode dry run, kami membuat tombol Jalankan Diskobot di Jira untuk memulai buku pedoman yang sama dengan variabel yang sama pada host yang sama, tetapi dalam mode normal.

Selain itu, tombol ini digunakan untuk me-restart playbook jika terjadi kegagalan.

Struktur Playbook

Saya sudah menyebutkan bahwa tergantung pada status tiket Jira, bot meluncurkan buku pedoman yang berbeda.

Pertama, jauh lebih mudah untuk mengatur entri.
Kedua, dalam beberapa kasus itu hanya perlu.

Misalnya, saat mengganti disk sistem, pertama-tama Anda harus pergi ke sistem penyebaran, membuat tugas, dan setelah penyebaran yang benar, server akan dapat diakses melalui ssh, dan Anda dapat memasukkan aplikasi ke dalamnya. Jika kita melakukan semua ini dalam satu buku pedoman, Ansible tidak akan dapat menjalankannya karena tidak dapat diaksesnya host.

Kami menggunakan peran yang dimungkinkan untuk setiap grup server. Di sini Anda dapat melihat bagaimana buku pedoman disusun di salah satunya.



Ini nyaman, karena segera jelas di mana tugas-tugas apa yang berada. Di main.yml, yang merupakan input untuk peran Ansible, kami hanya dapat memasukkan berdasarkan status tiket atau tugas umum yang diperlukan untuk semua orang, misalnya, melewati identifikasi atau menerima token.

Investigasi.yml

Berlari untuk mendapatkan tiket dalam status Investigasi dan Terbuka. Yang paling penting untuk buku pedoman ini adalah nama perangkat blok. Informasi ini tidak selalu tersedia.

Untuk mendapatkannya, kami menganalisis ringkasan Jira, nilai terakhir dari pemicu Zabbix. Ini mungkin berisi nama perangkat blok - beruntung. Atau mungkin mengandung titik mount, - maka Anda harus pergi ke server, parsing dan hitung drive yang diinginkan. Juga, pemicu dapat mengirimkan alamat scsi atau informasi lainnya. Tetapi itu juga terjadi bahwa tidak ada petunjuk, dan Anda harus menganalisis.

Setelah menemukan nama perangkat blok, kami mengumpulkan informasi tentang jenis dan ukuran disk untuk mengisi kolom di Jira. Kami juga menghapus informasi tentang vendor, model, firmware, ID, SMART, dan memasukkan semua ini ke dalam komentar di tiket Jira. Administrator dan insinyur tidak perlu lagi mencari data ini. :)

prep2change.yml

Keluaran disk dari rotasi, persiapan untuk penggantian. Tahap yang paling sulit, sangat penting. Di sinilah Anda dapat menghentikan aplikasi saat tidak dapat dihentikan. Atau mengeluarkan disk yang tidak memiliki cukup replika, dan dengan demikian berpengaruh pada pengguna, kehilangan beberapa data. Di sini kami memiliki cek dan pemberitahuan terbanyak dalam obrolan.

Dalam kasus paling sederhana, kita berbicara tentang menghapus drive dari HW / MD RAID.

Dalam situasi yang lebih kompleks (dalam sistem penyimpanan kami), ketika cadangan dilakukan pada tingkat aplikasi, Anda harus pergi ke aplikasi menggunakan API, melaporkan output disk, menonaktifkannya dan memulai pemulihan.

Kami sekarang secara besar-besaran bermigrasi ke cloud , dan jika server berawan, maka Diskobot mengakses cloud API, mengatakan bahwa ia akan bekerja dengan antek ini - server tempat wadah berjalan - dan meminta "migrasi semua wadah dari antek ini". Dan pada saat yang sama itu menyalakan lampu latar sehingga insinyur segera melihat mana yang harus ditarik.

berubah.yml

Setelah mengganti disk, pertama-tama kami memeriksa ketersediaannya.

Insinyur tidak selalu memasukkan disk baru, jadi kami menambahkan tanda centang untuk nilai-nilai SMART yang memuaskan kami.


Jika drive gagal dalam tes, insinyur akan diberitahu tentang penggantian. Jika semuanya beres, lampu latar mati, markup diterapkan dan disk dimasukkan ke dalam rotasi.

ready.yml

Kasus paling sederhana: memeriksa sinkronisasi serangan HW / SW atau mengakhiri sinkronisasi data dalam aplikasi.

API aplikasi

Saya menyebutkan beberapa kali bahwa bot sering mengakses API aplikasi. Tentu saja, tidak semua aplikasi memiliki metode yang diperlukan, jadi saya harus memperbaikinya. Berikut adalah metode paling penting yang kami gunakan:

• Status Status gugus atau disk untuk memahami apakah mungkin untuk bekerja dengannya;
  
• Mulai / hentikan. Aktivasi-penonaktifan disk;
  
• Bermigrasi / mengembalikan. Migrasi dan pemulihan data selama dan setelah penggantian.
  

Pelajaran dari Ansible

Saya sangat suka Ansible. Tetapi seringkali, ketika saya melihat berbagai proyek open source dan melihat bagaimana orang menulis buku pedoman, saya merasa sedikit takut. Tenunan logis yang kompleks dari saat / loop, kurangnya fleksibilitas dan idempotensi karena sering menggunakan shell / perintah.

Kami memutuskan untuk menyederhanakan semuanya sebanyak mungkin, mengambil keuntungan dari Ansible - modularity. Pada tingkat tertinggi adalah buku pedoman, mereka dapat ditulis oleh administrator mana pun, pengembang pihak ketiga yang tahu sedikit mungkin.

 - name: Blink disk become: True register: locate_action disk_locate: locate: '{{ locate }}' devname: '{{ devname }}' ids: '{{ locate_ids | default(pd_id) | default(omit) }}' 

Jika ada logika yang sulit diimplementasikan dalam buku pedoman, kami menempatkannya dalam modul atau filter Ansible. Skrip dapat ditulis dalam Python dan bahasa lain apa pun.

Mereka mudah dan cepat untuk ditulis. Sebagai contoh, modul highlight disk, contoh penggunaan yang diberikan di atas, terdiri dari 265 baris.



Pada tingkat terendah adalah perpustakaan. Untuk proyek ini, kami menulis aplikasi terpisah, semacam abstraksi atas perangkat keras dan perangkat lunak RAID yang melakukan permintaan yang sesuai.



Kekuatan terbesar Ansible adalah kesederhanaan dan buku pedoman yang dapat dipahami. Saya percaya bahwa Anda perlu menggunakan ini dan tidak menghasilkan file yaml yang menakutkan dan sejumlah besar kondisi, kode shell dan loop.

Jika Anda ingin mengulangi pengalaman kami dengan Ansible API, ingatlah dua hal:

• Playbook_executor dan umumnya playbook tidak dapat habis waktu. Ada batas waktu pada sesi ssh, tetapi tidak ada batas waktu di playbook. Jika kami mencoba meng-unmount drive yang belum ada di sistem, playbook akan berjalan tanpa batas waktu, jadi kami harus membungkusnya dalam pembungkus terpisah dan mematikannya dengan timeout.
  
• Kemungkinan bercabang, jadi API-nya tidak aman. Kami meluncurkan semua buku pedoman kami dan single-threaded.
  

Hasilnya, kami dapat mengotomatiskan penggantian sekitar 80% dari drive. Secara umum, tingkat penggantian meningkat dua kali lipat. Hari ini, administrator hanya melihat kejadian itu dan memutuskan apakah akan mengganti disk atau tidak, dan kemudian membuat satu klik.

Tetapi sekarang kita mulai menghadapi masalah lain: beberapa administrator baru tidak tahu cara mengganti drive. :)