Artikel ini adalah bagian keenam dari seri “Cara Mengendalikan Infrastruktur Jaringan Anda.” Isi semua artikel dalam seri dan tautan dapat ditemukan .
Setelah meninggalkan beberapa topik, saya memutuskan untuk memulai babak baru.
Saya akan kembali ke keamanan sebentar lagi. Di sini saya ingin membahas satu pendekatan sederhana namun efektif, yang saya yakin, dalam satu atau lain bentuk, dapat bermanfaat bagi banyak orang. Ini lebih merupakan cerita pendek tentang bagaimana otomatisasi dapat mengubah kehidupan seorang insinyur. Kami akan berbicara tentang penggunaan template. Di bagian akhir ada daftar proyek saya di mana Anda dapat melihat cara kerja semua yang dijelaskan di sini.
DevOps untuk jaringan
Membuat konfigurasi dengan skrip, menggunakan GIT untuk mengontrol perubahan pada infrastruktur TI, “mengunggah” jarak jauh - ide-ide ini muncul pertama kali ketika Anda memikirkan implementasi teknis dari pendekatan DevOps. Keuntungannya jelas. Namun sayangnya, ada juga kekurangannya.
Ketika lebih dari 5 tahun yang lalu, pengembang kami, para penggiat jejaring, datang kepada kami dengan proposal ini, kami tidak senang.
Saya harus mengatakan bahwa kami mewarisi jaringan yang beraneka ragam, terdiri dari peralatan dari sekitar 10 vendor berbeda. Memang nyaman untuk mengkonfigurasi beberapa hal melalui cli favorit kami, tetapi di hal lain kami lebih suka menggunakan GUI. Selain itu, pengerjaan jangka panjang pada peralatan “langsung” telah mengajarkan kita untuk mengontrol secara real-time. Misalnya, ketika melakukan perubahan, saya merasa lebih nyaman bekerja langsung melalui cli. Dengan cara ini saya dapat dengan cepat melihat ada yang tidak beres dan mengembalikan perubahan. Semua ini bertentangan dengan gagasan mereka.
Pertanyaan lain juga muncul, misalnya antarmuka mungkin sedikit berubah dari versi ke versi perangkat lunak. Hal ini pada akhirnya akan menyebabkan skrip Anda membuat "konfigurasi" yang salah. Saya tidak ingin menggunakan produksi untuk "berlari".
Atau bagaimana memahami bahwa perintah konfigurasi diterapkan dengan benar dan apa yang harus dilakukan jika terjadi kesalahan?
Saya tidak ingin mengatakan bahwa semua permasalahan ini tidak dapat diselesaikan. Hanya mengatakan “A” mungkin masuk akal untuk mengatakan “B” juga, dan jika Anda ingin menggunakan proses yang sama untuk pengendalian perubahan seperti dalam pengembangan, maka Anda perlu memiliki lingkungan pengembangan dan pementasan selain produksi. Maka pendekatan ini terlihat lengkap. Tapi berapa biayanya?
Namun ada satu situasi ketika kerugiannya hampir bisa diratakan, dan hanya kelebihannya saja yang tersisa. Saya sedang berbicara tentang pekerjaan desain.
Proyek
Selama dua tahun terakhir saya telah berpartisipasi dalam proyek pembangunan pusat data untuk penyedia besar. Saya bertanggung jawab atas F5 dan Palo Alto dalam proyek ini. Dari sudut pandang Cisco, ini adalah “peralatan pihak ketiga”.
Bagi saya pribadi, ada dua tahapan berbeda dalam proyek ini.
Tahap pertama
Tahun pertama saya sibuk tanpa henti, saya bekerja malam dan akhir pekan. Saya tidak bisa mengangkat kepala. Tekanan dari manajemen dan pelanggan kuat dan berkelanjutan. Dalam rutinitas yang konstan, saya bahkan tidak dapat mencoba mengoptimalkan prosesnya. Ini bukan hanya tentang konfigurasi peralatan, tetapi juga persiapan dokumentasi desain.
Tes pertama telah dimulai, dan saya akan terkejut melihat banyaknya kesalahan kecil dan ketidakakuratan yang dibuat. Tentu saja, semuanya berfungsi, tetapi ada huruf yang hilang di namanya, ada baris yang hilang di perintah... Pengujian terus berlanjut, dan saya terus-menerus berjuang setiap hari dengan kesalahan, pengujian, dan dokumentasi .
Hal ini berlangsung selama satu tahun. Proyek ini, sejauh yang saya pahami, tidak mudah untuk semua orang, tetapi lambat laun klien menjadi semakin puas, dan ini memungkinkan untuk mempekerjakan insinyur tambahan yang mampu mengambil bagian dari rutinitas itu sendiri.
Sekarang kita bisa melihat-lihat sedikit.
Dan ini adalah awal dari tahap kedua.
Tahap kedua
Saya memutuskan untuk mengotomatiskan prosesnya.
Apa yang saya pahami dari komunikasi saya dengan para pengembang saat itu (dan kami harus memberi penghormatan, kami memiliki tim yang kuat) adalah bahwa format teks, meskipun sekilas tampak seperti sesuatu dari dunia sistem operasi DOS, memiliki sejumlah dari properti yang berharga.
Jadi, misalnya, format teks akan berguna jika Anda ingin memanfaatkan GIT dan semua turunannya secara maksimal. Dan saya ingin.
Tampaknya Anda cukup menyimpan konfigurasi atau daftar perintah, tetapi melakukan perubahan cukup merepotkan. Selain itu, ada tugas penting lainnya saat mendesain. Anda harus memiliki dokumentasi yang menjelaskan desain Anda secara keseluruhan (Desain Tingkat Rendah) dan implementasi spesifik (Rencana Implementasi Jaringan). Dan dalam hal ini, penggunaan template sepertinya merupakan pilihan yang sangat cocok.
Jadi, saat menggunakan YAML dan Jinja2, file YAML dengan parameter konfigurasi seperti alamat IP, nomor BGP AS, ... memenuhi peran NIP dengan sempurna, sedangkan templat Jinja2 menyertakan sintaksis yang sesuai dengan desain, yang pada dasarnya adalah a refleksi dari LLD.
Butuh dua hari untuk mempelajari YAML dan Jinja2. Beberapa contoh bagus sudah cukup untuk memahami cara kerjanya. Kemudian dibutuhkan waktu sekitar dua minggu untuk membuat semua template yang sesuai dengan desain kami: satu minggu untuk Palo Alto dan satu minggu lagi untuk F5. Semua ini diposting di githab perusahaan.
Sekarang proses perubahannya terlihat seperti ini:
- mengubah file YAML
- membuat file konfigurasi menggunakan template (Jinja2)
- disimpan dalam repositori jarak jauh
- mengunggah konfigurasi yang dibuat ke peralatan
- Saya melihat kesalahan
- mengubah file YAML atau template Jinja2
- membuat file konfigurasi menggunakan template (Jinja2)
- ...
Jelas bahwa pada awalnya banyak waktu dihabiskan untuk mengedit, tetapi setelah satu atau dua minggu hal ini menjadi jarang.
Tes yang bagus dan peluang untuk men-debug semuanya adalah keinginan klien untuk mengubah konvensi penamaan. Mereka yang bekerja dengan F5 memahami betapa gentingnya situasi ini. Tapi bagi saya itu semua cukup sederhana. Saya mengubah nama di file YAML, menghapus seluruh konfigurasi dari peralatan, membuat yang baru dan mengunggahnya. Semuanya, termasuk perbaikan bug, membutuhkan waktu 4 hari: dua hari untuk setiap teknologi. Setelah itu saya siap untuk tahap selanjutnya yaitu pembuatan DEV dan Staging data center.
Pengembangan dan Pementasan
Pementasan sebenarnya mereplikasi produksi sepenuhnya. Dev adalah salinan yang sangat sederhana yang dibuat terutama pada perangkat keras virtual. Situasi ideal untuk pendekatan baru. Jika saya memisahkan waktu yang saya habiskan dari keseluruhan proses, maka menurut saya pengerjaannya memakan waktu tidak lebih dari 2 minggu. Waktu utamanya adalah menunggu pihak lain dan mencari masalah bersama. Penerapan pihak ketiga hampir tidak diperhatikan oleh orang lain. Bahkan ada waktu untuk mempelajari sesuatu dan menulis beberapa artikel tentang Habré :)
untuk meringkas
Jadi, apa yang saya dapatkan?
- Yang harus saya lakukan untuk mengubah konfigurasi adalah mengubah file YAML yang sederhana dan terstruktur dengan jelas dengan parameter konfigurasi. Saya tidak pernah mengganti script python dan sangat jarang (hanya jika ada error) saya mengganti heatlate Jinja2
- Dari sudut pandang dokumentasi, ini merupakan situasi yang hampir ideal. Anda mengubah dokumentasi (file YAML berfungsi sebagai NIP) dan mengunggah konfigurasi ini ke peralatan. Dengan cara ini dokumentasi Anda selalu terkini
Semua ini mengarah pada fakta bahwa
- tingkat kesalahan telah turun hingga hampir 0
- 90 persen rutinitasnya hilang
- kecepatan implementasi telah meningkat secara signifikan
BAYAR, F5Y, ACY
Saya mengatakan bahwa beberapa contoh sudah cukup untuk memahami cara kerjanya.
Berikut adalah versi singkat (dan tentu saja dimodifikasi) dari apa yang dibuat selama saya bekerja.
= penyebaran Palo Adari Yaml = Palo Alto dari Yaml
= penyebaran F5 dari Yaml = F5 dari Yaml (segera hadir)
= penyebaran ACsaya dari Yaml = F5 dari Yaml
Saya akan menambahkan beberapa kata tentang ACY (jangan bingung dengan ACI).
Mereka yang pernah bekerja dengan ACI tahu bahwa keajaiban ini (dan dalam cara yang baik juga) jelas tidak diciptakan oleh para penggiat jejaring :). Lupakan semua yang Anda ketahui tentang jaringan - itu tidak akan berguna bagi Anda!
Memang sedikit berlebihan, tapi secara kasar ini menyampaikan perasaan yang selalu saya alami, selama 3 tahun terakhir, bekerja dengan ACI.
Dan dalam hal ini, ACY tidak hanya merupakan peluang untuk membangun proses pengendalian perubahan (yang sangat penting dalam kasus ACI, karena ACY seharusnya menjadi bagian sentral dan paling penting dari pusat data Anda), tetapi juga memberi Anda antarmuka yang ramah pengguna untuk membuat konfigurasi.
Para insinyur di proyek ini menggunakan Excel untuk mengonfigurasi ACI, bukan YAML, untuk tujuan yang persis sama. Tentu saja ada keuntungan menggunakan Excel:
- NIP Anda dalam satu file
- tanda-tanda indah yang menyenangkan untuk dilihat klien
- Anda dapat menggunakan beberapa alat excel
Tapi ada satu kekurangannya, dan menurut saya itu melebihi kelebihannya. Mengontrol perubahan dan mengkoordinasikan kerja tim menjadi jauh lebih sulit.
ACY sebenarnya adalah aplikasi dengan pendekatan yang sama yang saya gunakan pada pihak ketiga untuk mengkonfigurasi ACI.
Sumber: www.habr.com