Artikel ini adalah yang keenam dari serangkaian artikel yang berjudul “Bagaimana Mengambil Infrastruktur Jaringan Di Bawah Kontrol Anda”. Isi semua artikel dalam seri dan tautan dapat ditemukan di sini .
Meninggalkan beberapa topik di belakang, saya memutuskan untuk memulai bab baru.
Saya akan kembali ke tempat yang aman nanti. 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. Ini akan tentang penggunaan template. Pada akhirnya adalah daftar proyek saya, di mana Anda dapat melihat bagaimana semua yang dijelaskan di sini bekerja.
DevOps untuk web
Membuat konfigurasi dengan skrip, menggunakan GIT untuk mengontrol perubahan dalam infrastruktur TI, "isi" jauh - ide-ide ini muncul terlebih dahulu ketika Anda berpikir tentang implementasi teknis dari pendekatan DevOps. Nilai tambahnya jelas. Tapi sayangnya, ada juga kelemahannya.
Ketika lebih dari 5 tahun yang lalu, pengembang kami mendatangi kami, ke penggiat jejaring, dengan penawaran ini, kami tidak antusias.
Saya harus mengatakan bahwa kami mewarisi jaringan yang agak beraneka ragam yang terdiri dari peralatan sekitar 10 vendor yang berbeda. Ada sesuatu yang nyaman untuk dikonfigurasi melalui cli favorit kami, tetapi di suatu tempat kami lebih suka menggunakan GUI. Selain itu, pekerjaan panjang pada peralatan "langsung" diajarkan untuk kontrol waktu nyata. Misalnya, ketika melakukan perubahan, saya merasa jauh lebih nyaman bekerja langsung melalui klien. Jadi saya dapat dengan cepat melihat bahwa ada yang tidak beres dan "memutar balik" perubahannya. Semua ini bertentangan dengan ide-ide mereka.
Pertanyaan lain muncul, misalnya, dari versi ke versi perangkat lunak antarmuka mungkin sedikit berbeda. Ini, pada akhirnya, akan menyebabkan skrip Anda membuat "konfigurasi" yang salah. Saya tidak ingin menggunakan produksi untuk pembobolan.
Atau, bagaimana memahami bahwa perintah konfigurasi diterapkan dengan benar dan apa yang harus dilakukan jika terjadi kesalahan?
Saya tidak ingin mengatakan bahwa semua masalah ini tidak dapat diselesaikan. Hanya dengan mengatakan "A", mungkin bijaksana untuk mengatakan "B", dan jika Anda ingin menggunakan proses yang sama untuk kontrol perubahan seperti dalam pengembangan, Anda perlu memiliki lingkungan dev dan pementasan di samping produksi. Maka pendekatan ini tampaknya lengkap. Tetapi berapa biayanya?
Tetapi ada satu situasi di mana kontra hampir diratakan, dan hanya pro tetap. Saya berbicara tentang pekerjaan desain.
Proyek
Selama dua tahun terakhir, saya telah berpartisipasi dalam proyek untuk membangun pusat data untuk satu penyedia utama. Saya bertanggung jawab atas F5 dan Palo Alto dalam proyek ini. Dari sudut pandang Cisco itu adalah "peralatan pihak ke-3".
Bagi saya pribadi, ada dua tahap berbeda dalam proyek ini.
Tahap pertama
Tahun pertama saya sibuk tanpa henti, saya bekerja di malam hari dan di akhir pekan. Saya tidak bisa mengangkat kepala. Tekanan dari manajemen dan pelanggan kuat dan berkelanjutan. Dalam rutinitas yang konstan, saya bahkan tidak bisa mencoba mengoptimalkan proses. Itu tidak hanya dan tidak begitu banyak konfigurasi peralatan sebagai persiapan dokumentasi desain.
Jadi tes pertama dimulai, dan saya akan kagum betapa banyak kesalahan kecil dan ketidakakuratan dibuat. Tentu saja, semuanya bekerja, tetapi surat dalam nama itu hilang, garis di tim hilang di sini ... Tes terus dan berlanjut, dan saya sudah dalam perjuangan, konstan setiap hari dengan kesalahan, tes dan dokumentasi.
Ini berlangsung selama satu tahun. Proyek itu, seperti yang saya mengerti, tidak mudah untuk semua orang, tetapi secara bertahap klien menjadi lebih dan lebih puas, dan ini memungkinkan untuk mengambil insinyur tambahan yang dapat mengambil bagian dari rutinitas.
Sekarang mungkin untuk melihat-lihat sedikit.
Dan itu adalah awal dari tahap kedua.
Tahap kedua
Saya memutuskan untuk mengotomatiskan prosesnya.
Apa yang saya pahami dari komunikasi dengan para pengembang pada waktu itu (dan kami harus membayar upeti, kami memiliki tim yang kuat) adalah bahwa format teks, walaupun pada awalnya tampak sesuatu dari dunia sistem operasi DOS, memiliki sejumlah properti berharga .
Misalnya, format teks akan berguna jika Anda ingin memanfaatkan sepenuhnya GIT dan semua turunannya. Saya ingin.
Ya, sepertinya Anda hanya bisa menyimpan konfigurasi atau daftar perintah, tetapi membuat perubahan agak tidak nyaman. Selain itu, saat mendesain, ada tugas penting lainnya. Anda harus memiliki dokumentasi yang menjelaskan keseluruhan desain Anda (Desain Tingkat Rendah) dan implementasi spesifik (Rencana Implementasi Jaringan). Dan dalam hal ini, penggunaan templat tampaknya menjadi pilihan yang sangat cocok.
Jadi, ketika menggunakan YAML dan Jinja2, file YAML dengan parameter konfigurasi, seperti alamat IP, angka BGP AS, ... sempurna memenuhi peran NIP, sementara templat Jinja2 menyertakan sintaks yang sesuai dengan desain, yaitu, sebenarnya, merupakan cerminan dari LLD.
Butuh dua hari untuk belajar bahasa YAML dan Jinja2. Beberapa contoh yang baik sudah cukup untuk memahami cara kerjanya. Kemudian butuh sekitar dua minggu untuk membuat semua templat yang sesuai dengan desain kami: satu minggu untuk Palo Alto dan satu minggu lagi untuk F5. Semua ini diposting di githab perusahaan.
Sekarang proses perubahan adalah sebagai berikut:
- mengubah file yaml
- membuat file konfigurasi menggunakan templat (Jinja2)
- disimpan ke repositori jarak jauh
- mengunggah konfigurasi yang dibuat ke peralatan
- melihat kesalahan
- mengubah file YAML atau template Jinja2
- membuat file konfigurasi menggunakan templat (Jinja2)
- ...
Jelas bahwa pada awalnya banyak waktu dihabiskan untuk mengedit, tetapi setelah satu atau dua minggu sudah lebih jarang.
Tes yang bagus dan kemampuan untuk men-debug semuanya adalah keinginan klien untuk mengubah konvensi penamaan. Yang bekerja dengan F5 memahami kesedihan situasi. Tetapi bagi saya itu cukup sederhana. Saya mengubah nama dalam file YAML, menghapus seluruh konfigurasi dari peralatan, menghasilkan yang baru dan mengunggahnya. Semuanya, dengan mempertimbangkan perbaikan bug akun, membutuhkan waktu 4 hari: dua hari untuk setiap teknologi. Setelah itu, saya siap untuk langkah selanjutnya, yaitu membuat pusat data DEV dan Staging.
Dev dan Pementasan
Pementasan sebenarnya mengulangi produksi sepenuhnya. Dev adalah salinan yang dilucuti berat yang dibangun terutama pada perangkat keras virtual. Situasi ideal untuk pendekatan baru. Jika saya mengisolasi waktu yang saya habiskan dari proses umum, maka pekerjaan itu, saya pikir, tidak lebih dari 2 minggu. Waktu utama adalah waktu menunggu pihak lain, dan pencarian bersama untuk masalah. Implementasi pihak ke-3 hampir tidak terlihat oleh orang lain. Bahkan ada waktu untuk mengajar sesuatu dan menulis beberapa artikel tentang Habré :)
Untuk meringkas
Jadi apa yang saya miliki di garis bawah?
- semua yang diperlukan bagi saya untuk mengubah konfigurasi adalah memodifikasi file YAML yang sederhana dan terstruktur dengan parameter konfigurasi. Saya tidak pernah mengubah skrip python dan sangat jarang (hanya jika ada kesalahan) saya mengubah Jinja2
- dari sudut pandang dokumentasi, diperoleh situasi yang hampir ideal. Anda mengubah dokumentasi (file YAML bertindak sebagai NIP) dan mengunggah konfigurasi ini ke peralatan. Dengan demikian, dokumentasi Anda selalu terbarui.
Semua ini mengarah pada kenyataan itu
- persentase kesalahan menurun hingga hampir 0
- butuh 90 persen dari rutinitas
- kecepatan implementasi telah meningkat secara signifikan
MEMBAYAR, F5Y, ACY
Saya katakan beberapa contoh sudah cukup untuk memahami bagaimana ini bekerja.
Ini adalah versi singkat (dan tentu saja dimodifikasi) dari apa yang telah dibuat dalam proses pekerjaan saya.
MEMBAYAR = penyebaran
P ao
A lto dari
Y aml = Palo Alto dari Yaml
F5Y = penyebaran
F5 dari
Y aml =
F5 dari
Y aml (segera hadir)
ACY = penyebaran
AC i dari
Y aml =
F5 dari
Y aml
Saya akan menambahkan beberapa kata tentang ACY (jangan bingung dengan ACI).
Mereka yang bekerja dengan ACI tahu bahwa mukjizat ini (dan dalam cara yang baik juga) diciptakan bukan oleh penggiat jejaring :). Lupakan semua yang Anda ketahui tentang jaringan - itu tidak akan berguna bagi Anda!
Agak berlebihan, tapi kira-kira menyampaikan perasaan yang terus-menerus saya alami selama 3 tahun sekarang, bekerja dengan ACI.
Dan dalam hal ini, ACY tidak hanya kesempatan untuk membangun proses kontrol perubahan (yang sangat penting dalam kasus ACI, karena diasumsikan bahwa ini adalah bagian pusat dan paling penting dari pusat data Anda), tetapi juga memberi Anda antarmuka yang ramah untuk membuat konfigurasi.
Para insinyur dalam proyek ini menggunakan Excel untuk menggunakan ACI bukan YAML untuk tujuan yang persis sama. Ada beberapa keuntungan menggunakan Excel, tentu saja:
- gigitan Anda dalam satu file
- tanda-tanda indah bahwa klien senang melihatnya
- Anda dapat menggunakan beberapa alat excel
Tapi ada satu kelemahan, dan menurut saya itu melebihi kelebihannya. Mengontrol perubahan dan mengoordinasikan kerja tim menjadi jauh lebih sulit.
ACY sebenarnya menerapkan pendekatan yang sama yang saya gunakan untuk pihak ke-3 untuk mengkonfigurasi ACI.