Artikel ini ialah yang keenam dalam siri "Cara Mengambil Kawalan Infrastruktur Rangkaian Anda." Kandungan semua artikel dalam siri dan pautan boleh didapati .
Setelah meninggalkan beberapa topik, saya memutuskan untuk memulakan lembaran baru.
Saya akan kembali ke keselamatan sedikit kemudian. Di sini saya ingin membincangkan satu pendekatan yang mudah tetapi berkesan, yang saya pasti, dalam satu bentuk atau yang lain, boleh berguna kepada ramai. Ini lebih kepada cerita pendek tentang bagaimana automasi boleh mengubah kehidupan seorang jurutera. Kami akan bercakap tentang menggunakan templat. Pada akhirnya terdapat senarai projek saya di mana anda boleh melihat bagaimana semua yang diterangkan di sini berfungsi.
DevOps untuk rangkaian
Mencipta konfigurasi dengan skrip, menggunakan GIT untuk mengawal perubahan pada infrastruktur IT, "muat naik" jauh - idea ini datang dahulu apabila anda berfikir tentang pelaksanaan teknikal pendekatan DevOps. Kelebihannya jelas. Tetapi, malangnya, terdapat juga kelemahan.
Apabila lebih daripada 5 tahun yang lalu, pemaju kami datang kepada kami, rangkaian, dengan cadangan ini, kami tidak gembira.
Saya mesti mengatakan bahawa kami mewarisi rangkaian yang agak beraneka ragam, yang terdiri daripada peralatan daripada kira-kira 10 vendor yang berbeza. Ia adalah mudah untuk mengkonfigurasi beberapa perkara melalui cli kegemaran kami, tetapi dalam yang lain kami lebih suka menggunakan GUI. Di samping itu, kerja lama pada peralatan "hidup" telah mengajar kami untuk mengawal masa nyata. Sebagai contoh, apabila membuat perubahan, saya berasa lebih selesa bekerja secara langsung melalui cli. Dengan cara ini saya dapat melihat dengan cepat bahawa sesuatu telah berlaku dan mengembalikan perubahan tersebut. Semua ini bercanggah dengan idea mereka.
Soalan lain juga timbul, sebagai contoh, antara muka mungkin berubah sedikit dari versi ke versi perisian. Ini akhirnya akan menyebabkan skrip anda mencipta "konfigurasi" yang salah. Saya tidak mahu menggunakan pengeluaran untuk "lari masuk".
Atau, bagaimana untuk memahami bahawa arahan konfigurasi telah digunakan dengan betul dan apa yang perlu dilakukan sekiranya berlaku ralat?
Saya tidak mahu mengatakan bahawa semua isu ini tidak dapat diselesaikan. Hanya menyebut "A" mungkin masuk akal untuk menyebut "B" juga, dan jika anda ingin menggunakan proses yang sama untuk kawalan perubahan seperti dalam pembangunan, maka anda perlu mempunyai persekitaran pembangun dan pementasan sebagai tambahan kepada pengeluaran. Kemudian pendekatan ini kelihatan lengkap. Tetapi berapakah kosnya?
Tetapi terdapat satu keadaan apabila kelemahan secara praktikal diratakan, dan hanya kelebihan yang kekal. Saya bercakap tentang kerja reka bentuk.
Projek
Selama dua tahun yang lalu saya telah mengambil bahagian dalam projek untuk membina pusat data untuk pembekal yang besar. Saya bertanggungjawab untuk F5 dan Palo Alto dalam projek ini. Dari sudut pandangan Cisco, ini adalah "peralatan pihak ke-3".
Bagi saya secara peribadi, terdapat dua peringkat yang berbeza dalam projek ini.
Peringkat pertama
Tahun pertama saya sibuk tanpa henti, saya bekerja malam dan hujung minggu. Saya tidak dapat mengangkat kepala saya. Tekanan daripada pihak pengurusan dan pelanggan adalah kuat dan berterusan. Dalam rutin yang berterusan, saya tidak dapat cuba mengoptimumkan proses itu. Ia bukan sahaja dan bukan sahaja konfigurasi peralatan sebagai penyediaan dokumentasi reka bentuk.
Ujian pertama telah bermula, dan saya akan kagum dengan berapa banyak kesilapan kecil dan ketidaktepatan yang dibuat. Sudah tentu, semuanya berfungsi, tetapi terdapat huruf yang hilang dalam nama, terdapat baris yang hilang dalam arahan... Ujian berterusan dan berterusan, dan saya sudah berada dalam perjuangan harian yang berterusan dengan kesilapan, ujian dan dokumentasi .
Ini berlangsung selama setahun. Projek itu, setakat yang saya faham, tidak mudah untuk semua orang, tetapi secara beransur-ansur pelanggan menjadi lebih dan lebih berpuas hati, dan ini memungkinkan untuk mengupah jurutera tambahan yang dapat mengambil sebahagian daripada rutin itu sendiri.
Sekarang kita boleh melihat sekeliling sedikit.
Dan ini adalah permulaan peringkat kedua.
Peringkat kedua
Saya memutuskan untuk mengautomasikan proses.
Apa yang saya faham daripada komunikasi saya dengan pembangun pada masa itu (dan kita mesti memberi penghormatan, kita mempunyai pasukan yang kuat) ialah format teks, walaupun pada pandangan pertama kelihatan seperti sesuatu dari dunia sistem pengendalian DOS, mempunyai nombor daripada harta benda yang berharga.
Jadi, sebagai contoh, format teks akan berguna jika anda ingin memanfaatkan sepenuhnya GIT dan semua derivatifnya. Dan saya mahu.
Nah, nampaknya anda hanya boleh menyimpan konfigurasi atau senarai arahan, tetapi membuat perubahan agak menyusahkan. Di samping itu, terdapat satu lagi tugas penting semasa reka bentuk. Anda harus mempunyai dokumentasi yang menerangkan reka bentuk anda secara keseluruhan (Reka Bentuk Tahap Rendah) dan pelaksanaan khusus (Pelan Pelaksanaan Rangkaian). Dan dalam kes ini, penggunaan templat kelihatan seperti pilihan yang sangat sesuai.
Jadi, apabila menggunakan YAML dan Jinja2, fail YAML dengan parameter konfigurasi seperti alamat IP, nombor BGP AS, ... memenuhi peranan NIP dengan sempurna, manakala templat Jinja2 menyertakan sintaks yang sepadan dengan reka bentuk, iaitu, ia pada asasnya adalah refleksi LLD.
Ia mengambil masa dua hari untuk mempelajari YAML dan Jinja2. Beberapa contoh yang baik sudah cukup untuk memahami cara ini berfungsi. Kemudian mengambil masa kira-kira dua minggu untuk mencipta semua templat yang sepadan dengan reka bentuk kami: seminggu untuk Palo Alto dan seminggu lagi untuk F5. Semua ini telah disiarkan di githab korporat.
Sekarang proses perubahan kelihatan seperti ini:
- menukar fail YAML
- mencipta fail konfigurasi menggunakan templat (Jinja2)
- disimpan dalam repositori jauh
- memuat naik konfigurasi yang dibuat ke peralatan
- Saya nampak ralat
- menukar fail YAML atau templat Jinja2
- mencipta fail konfigurasi menggunakan templat (Jinja2)
- ...
Adalah jelas bahawa pada mulanya banyak masa dihabiskan untuk suntingan, tetapi selepas satu atau dua minggu ini menjadi agak jarang.
Ujian dan peluang yang baik untuk menyahpepijat segala-galanya ialah keinginan pelanggan untuk menukar konvensyen penamaan. Mereka yang bekerja dengan F5 memahami keseronokan keadaan. Tetapi bagi saya semuanya agak mudah. Saya menukar nama dalam fail YAML, memadam keseluruhan konfigurasi daripada peralatan, menghasilkan yang baharu dan memuat naiknya. Segala-galanya, termasuk pembetulan pepijat, mengambil masa 4 hari: dua hari untuk setiap teknologi. Selepas itu, saya bersedia untuk peringkat seterusnya iaitu penciptaan pusat data DEV dan Staging.
Dev dan Pementasan
Pementasan sebenarnya mereplikasi pengeluaran sepenuhnya. Dev ialah salinan yang banyak dilucutkan dibina terutamanya pada perkakasan maya. Situasi yang ideal untuk pendekatan baru. Jika saya mengasingkan masa yang saya habiskan daripada keseluruhan proses, maka saya rasa kerja itu mengambil masa tidak lebih daripada 2 minggu. Masa utama adalah menunggu pihak lain dan mencari masalah bersama-sama. Pelaksanaan pihak ketiga hampir tidak disedari oleh orang lain. Malah ada masa untuk mempelajari sesuatu dan menulis beberapa artikel tentang HabrΓ© :)
Ringkasnya
Jadi, apa yang saya ada di bahagian bawah?
- Apa yang saya perlu lakukan untuk menukar konfigurasi ialah menukar fail YAML yang ringkas dan jelas berstruktur dengan parameter konfigurasi. Saya tidak pernah menukar skrip python dan sangat jarang (hanya jika terdapat ralat) saya menukar pemanas Jinja2
- Dari sudut pandangan dokumentasi, ini adalah situasi yang hampir ideal. Anda menukar dokumentasi (fail YAML berfungsi sebagai NIP) dan memuat naik konfigurasi ini ke peralatan. Dengan cara ini dokumentasi anda sentiasa terkini
Semua ini membawa kepada fakta bahawa
- kadar ralat telah menurun kepada hampir 0
- 90 peratus daripada rutin itu hilang
- kelajuan pelaksanaan telah meningkat dengan ketara
BAYAR, F5Y, ACY
Saya berkata bahawa beberapa contoh sudah cukup untuk memahami cara ia berfungsi.
Berikut ialah versi pendek (dan sudah tentu diubah suai) tentang apa yang dibuat semasa saya bekerja.
= penempatan Palo Alto daripada Yaml = Palo Alto daripada Yaml
= penempatan F5 dari Yaml = F5 dari Yaml (akan datang)
= penempatan ACsaya dari Yaml = F5 dari Yaml
Saya akan menambah beberapa perkataan tentang ACY (jangan dikelirukan dengan ACI).
Mereka yang pernah bekerja dengan ACI tahu bahawa keajaiban ini (dan dengan cara yang baik juga) pastinya tidak dicipta oleh rangkaian :). Lupakan semua yang anda ketahui tentang rangkaian - ia tidak akan berguna kepada anda!
Ia agak dibesar-besarkan, tetapi secara kasarnya ia menyampaikan perasaan yang saya alami secara berterusan, selama 3 tahun yang lalu, bekerja dengan ACI.
Dan dalam kes ini, ACY bukan sahaja peluang untuk membina proses kawalan perubahan (yang amat penting dalam kes ACI, kerana ia sepatutnya menjadi bahagian tengah dan paling kritikal pusat data anda), tetapi juga memberi anda antara muka yang mesra pengguna untuk membuat konfigurasi.
Jurutera pada projek ini menggunakan Excel untuk mengkonfigurasi ACI dan bukannya YAML untuk tujuan yang sama. Terdapat, sudah tentu, kelebihan menggunakan Excel:
- NIP anda dalam satu fail
- tanda-tanda cantik yang sedap dipandang oleh klien
- anda boleh menggunakan beberapa alat excel
Tetapi ada satu tolak, dan pada pendapat saya ia mengatasi kebaikan. Mengawal perubahan dan menyelaraskan kerja pasukan menjadi lebih sukar.
ACY sebenarnya adalah aplikasi pendekatan yang sama yang saya gunakan untuk pihak ke-3 untuk mengkonfigurasi ACI.
Sumber: www.habr.com