Rilis Red Hat Ansible Engine 2.9 yang akan datang menunggu Anda dengan peningkatan yang mengesankan, beberapa di antaranya dijelaskan dalam artikel ini. Seperti biasa, kami mengembangkan peningkatan Ansible Network secara terbuka, dengan dukungan komunitas. Bergabunglah - Lihatlah papan tugas di GitHub dan pelajari rencana pengembangan untuk rilis Red Hat Ansible Engine 2.9 di halaman wiki untuk Ansible Network .
Seperti yang baru-baru ini kami umumkan, Platform Red Hat Ansible Automation sekarang mencakup Ansible Tower, Ansible Engine, dan semua konten Jaringan Ansible. Sekarang, sebagian besar platform jaringan populer diimplementasikan melalui modul Ansible. Sebagai contoh:
- Arista eos
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- Vyos
Daftar lengkap platform yang didukung penuh oleh Red Hat melalui Ansible Automation tersedia di sini .
Apa yang telah kita pelajari
Selama empat tahun terakhir, kami telah belajar banyak tentang pengembangan platform untuk otomatisasi jaringan. Kami juga belajar bagaimana pengguna akhir memainkan artefak platform di buku pedoman dan peran yang dimungkinkan. Dan inilah yang kami temukan:
- Organisasi mengotomatiskan perangkat tidak hanya satu, tetapi banyak vendor.
- Otomasi bukan hanya fenomena teknis, tetapi juga fenomena budaya.
- Otomatisasi jaringan berskala besar lebih rumit daripada yang terlihat, karena prinsip arsitektur mendasar dari desain otomasi.
Ketika kami mendiskusikan rencana pengembangan jangka panjang kami lebih dari setahun yang lalu, klien korporat kami meminta yang berikut:
- Pengumpulan fakta perlu distandarisasi dan diselaraskan dengan alur kerja otomatisasi untuk perangkat apa pun.
- Memperbarui konfigurasi pada perangkat juga perlu distandarisasi dan diselaraskan sehingga modul yang mungkin memproses paruh kedua siklus setelah mengumpulkan fakta.
- Kami membutuhkan metode yang ketat dan didukung untuk mengubah konfigurasi perangkat menjadi data terstruktur. Atas dasar ini, sumber kebenaran dapat dipindahkan dari perangkat jaringan.
Peningkatan fakta
Mengumpulkan fakta dari perangkat jaringan menggunakan Ansible seringkali dilakukan secara acak. Platform jaringan dilengkapi dengan tingkat yang berbeda-beda dengan kemampuan untuk mengumpulkan fakta, tetapi mereka hampir tidak memiliki - atau bahkan tidak ada sama sekali - fungsi untuk mem-parsing dan menstandarkan presentasi data dalam pasangan kunci-nilai. Baca posting Ken Celenza tentang betapa sulit dan menyakitkannya menganalisis dan membakukan data faktual.
Anda mungkin telah memperhatikan bagaimana kami bekerja pada peran Ansible Network Engine. Secara alami, 24.000 unduhan kemudian, peran Network Engine dengan cepat menjadi salah satu peran Ansible yang paling populer di Ansible Galaxy untuk skenario otomatisasi jaringan. Sebelum kita memindahkan sebagian besar dari ini ke Ansible 2.8, untuk mempersiapkan apa yang diperlukan Ansible 2.9, peran Ansible ini menyediakan seperangkat alat pertama untuk membantu dalam penguraian perintah, manajemen perintah, dan pengumpulan data untuk perangkat jaringan.
Jika Anda pandai menggunakan Network Engine, ini adalah cara yang sangat efisien untuk mengumpulkan, mengurai, dan membakukan data fakta untuk digunakan dengan Ansible. Kerugian dari peran ini adalah Anda perlu membuat sejumlah parser untuk setiap platform dan untuk semua aktivitas jaringan. Untuk memahami betapa sulitnya membuat, mengirim, dan memelihara parser, lihat 1200+ parser dari orang-orang di Cisco.
Singkatnya, untuk otomatisasi skala besar, sangat penting untuk menerima fakta dari perangkat dan menormalkannya menjadi pasangan nilai kunci, tetapi ini sulit dicapai ketika Anda memiliki banyak vendor dan platform jaringan.
Setiap modul fakta jaringan di Ansible 2.9 sekarang dapat menganalisis konfigurasi perangkat jaringan dan mengembalikan data terstruktur - tanpa pustaka tambahan, peran yang mungkin atau parser khusus.
Dimulai dengan Ansible 2.9, dengan setiap rilis modul jaringan yang diperbarui, modul fakta ditingkatkan untuk memberikan informasi tentang bagian konfigurasi ini. Artinya, pengembangan fakta dan modul sekarang terjadi pada kecepatan yang sama, dan mereka akan selalu memiliki struktur data yang sama.
Konfigurasi sumber daya pada perangkat jaringan dapat diekstraksi dan dikonversi menjadi data terstruktur dengan dua cara. Dengan kedua cara ini, Anda dapat mengkompilasi dan mengonversi daftar sumber daya tertentu menggunakan gather_network_resources baru. Nama sumber daya sesuai dengan nama modul, dan ini sangat nyaman.
Pada saat mengumpulkan fakta:
Menggunakan gather_facts Anda dapat mengekstrak konfigurasi perangkat saat ini di awal playbook, dan kemudian menggunakannya di seluruh playbook. Tentukan sumber daya individual yang akan diambil dari perangkat.
- hosts: arista module_defaults: eos_facts: gather_subset: min gather_network_resources: - interfaces gather_facts: True
Anda mungkin melihat sesuatu yang baru dalam contoh ini, yaitu gather_facts: true sekarang tersedia untuk pencarian fakta asli untuk perangkat jaringan.
Menggunakan modul fakta jaringan secara langsung:
- name: collect interface configuration facts eos_facts: gather_subset: min gather_network_resources: - interfaces
Playbook mengembalikan fakta berikut tentang antarmuka:
ansible_facts: ansible_network_resources: interfaces: - enabled: true name: Ethernet1 mtu: '1476' - enabled: true name: Loopback0 - enabled: true name: Loopback1 - enabled: true mtu: '1476' name: Tunnel0 - enabled: true name: Ethernet1 - enabled: true name: Tunnel1 - enabled: true name: Ethernet1
Perhatikan bagaimana Ansible mengambil konfigurasi asli dari perangkat Arista dan mengubahnya menjadi data terstruktur untuk digunakan sebagai pasangan nilai kunci standar untuk tugas dan operasi selanjutnya.
Fakta antarmuka dapat ditambahkan ke variabel tersimpan yang mungkin dan digunakan segera atau lambat sebagai input ke eos_interfaces sumber daya eos_interfaces tanpa pemrosesan atau konversi tambahan.
Modul sumber daya
Jadi, kami mengekstraksi fakta, menormalkan data, menuliskannya dalam skema internal standar dari struktur data dan mendapatkan sumber kebenaran yang sudah jadi. Hore! Ini, tentu saja, sangat bagus, tetapi kita masih perlu mengubah pasangan nilai kunci kembali ke konfigurasi spesifik yang diharapkan oleh platform perangkat tertentu. Sekarang kita membutuhkan modul untuk platform spesifik untuk memenuhi persyaratan pengumpulan dan normalisasi fakta baru ini.
Apa itu modul sumber daya? Bagian konfigurasi perangkat dapat dianggap sebagai sumber daya yang disediakan oleh perangkat ini. Modul sumber daya jaringan sengaja terbatas pada satu sumber daya, dan dapat ditumpuk seperti batu bata untuk mengkonfigurasi layanan jaringan yang kompleks. Akibatnya, persyaratan dan spesifikasi untuk modul sumber daya secara alami disederhanakan, karena modul sumber daya dapat membaca dan mengonfigurasi layanan jaringan tertentu pada perangkat jaringan.
Untuk menjelaskan apa yang dilakukan modul sumber daya, mari kita lihat contoh buku pedoman yang memperlihatkan operasi idempoent menggunakan fakta baru dari sumber daya jaringan dan modul eos_l3_interface .
- name: example of facts being pushed right back to device. hosts: arista gather_facts: false tasks: - name: grab arista eos facts eos_facts: gather_subset: min gather_network_resources: l3_interfaces - name: ensure that the IP address information is accurate eos_l3_interfaces: config: "{{ ansible_network_resources['l3_interfaces'] }}" register: result - name: ensure config did not change assert: that: not result.changed
Seperti yang Anda lihat, data yang dikumpulkan dari perangkat ditransfer langsung ke modul sumber daya yang sesuai tanpa konversi. Saat startup, playbook mengambil nilai dari perangkat dan membandingkannya dengan yang diharapkan. Dalam contoh ini, nilai yang diperoleh sesuai dengan yang diharapkan (yaitu, penyimpangan konfigurasi diperiksa) dan pesan ditampilkan jika konfigurasi telah berubah.
Cara ideal untuk mendeteksi penyimpangan konfigurasi adalah dengan menyimpan fakta-fakta dalam variabel tersimpan yang mungkin dan menggunakannya secara berkala dengan modul sumber daya dalam mode cek. Ini adalah metode sederhana untuk melihat apakah seseorang telah mengubah nilai secara manual. Dalam kebanyakan kasus, organisasi mengizinkan perubahan dan konfigurasi manual, walaupun banyak operasi dilakukan melalui Otomatisasi yang Mungkin.
Bagaimana modul sumber daya baru berbeda dari yang sebelumnya?
Untuk seorang insinyur jaringan otomatisasi, ada 3 perbedaan utama antara modul sumber daya di Ansible 2.9 dari versi sebelumnya.
1) Untuk sumber daya jaringan tertentu (yang juga dapat dianggap sebagai bagian konfigurasi), modul dan fakta akan berkembang di semua sistem operasi jaringan yang didukung secara bersamaan. Kami berpikir bahwa jika Ansible mendukung konfigurasi sumber daya pada platform jaringan tunggal, kami harus mendukungnya di mana saja. Ini menyederhanakan penggunaan modul sumber daya, karena insinyur otomatisasi jaringan sekarang dapat mengkonfigurasi sumber daya (misalnya, LLDP) di semua sistem operasi jaringan dengan modul asli dan yang didukung.
2) Modul sumber daya sekarang termasuk nilai status.
merged : konfigurasi digabungkan dengan konfigurasi yang disediakan (default);replaced : konfigurasi sumber daya akan diganti dengan konfigurasi yang disediakan;overridden : konfigurasi sumber daya akan diganti dengan konfigurasi yang disediakan; contoh sumber daya berlebih akan dihapus;deleted : konfigurasi sumber daya akan dihapus / dikembalikan secara default.
3) Modul sumber daya sekarang termasuk nilai pengembalian stabil. Ketika modul sumber daya jaringan telah membuat (atau menyarankan) perubahan yang diperlukan untuk perangkat jaringan, itu mengembalikan pasangan nilai kunci yang sama ke buku pedoman.
before : konfigurasi pada perangkat dalam bentuk data terstruktur sebelum tugas;after : jika perangkat telah berubah (atau dapat berubah jika mode verifikasi digunakan), konfigurasi yang dihasilkan akan dikembalikan dalam bentuk data terstruktur;commands : commands konfigurasi apa pun yang berjalan pada perangkat untuk membawanya ke keadaan yang diinginkan.
Apa artinya semua ini? Mengapa ini penting?
Posting ini menjelaskan banyak konsep kompleks, tetapi kami berharap bahwa pada akhirnya Anda akan lebih memahami bahwa klien korporat meminta fakta, normalisasi data dan konfigurasi loop untuk platform otomatisasi. Tetapi mengapa mereka membutuhkan perbaikan ini? Banyak organisasi sekarang terlibat dalam transformasi digital untuk membuat lingkungan TI mereka lebih fleksibel dan kompetitif. Baik atau buruk, banyak insinyur jaringan menjadi pengembang jaringan, baik karena minat mereka sendiri atau atas perintah manajer.
Organisasi memahami bahwa mengotomatiskan templat jaringan individual tidak menyelesaikan masalah fragmentasi dan hanya meningkatkan efisiensi hingga batas tertentu. Platform Red Hat Ansible Automation menyediakan model data sumber daya yang ketat dan normatif untuk secara terprogram mengelola data yang mendasarinya pada perangkat jaringan. Artinya, pengguna secara bertahap meninggalkan metode konfigurasi individual demi metode yang lebih modern dengan penekanan pada teknologi (misalnya, alamat IP, VLAN, LLDP, dll.), Dan bukan pada implementasi vendor tertentu.
Apakah ini berarti bahwa hari-hari modul perintah dan konfigurasi yang dapat diandalkan dan terbukti sudah dinomori? Tidak mungkin. Modul sumber daya jaringan yang diharapkan tidak akan berlaku dalam semua kasus dan tidak untuk masing-masing vendor, sehingga insinyur jaringan masih membutuhkan modul perintah dan konfigurasi untuk implementasi tertentu. Tujuan dari modul sumber daya adalah untuk menyederhanakan template Jinja yang besar dan menormalkan konfigurasi perangkat yang tidak terstruktur menjadi format JSON terstruktur. Dengan modul sumber daya, akan lebih mudah bagi jaringan yang ada untuk mengubah konfigurasi mereka menjadi pasangan nilai kunci terstruktur yang akan menjadi sumber kebenaran yang mudah dibaca. Jika Anda menggunakan pasangan nilai kunci terstruktur, Anda dapat beralih dari menjalankan konfigurasi pada setiap perangkat untuk bekerja dengan data terstruktur independen dan membawa jaringan ke garis depan dengan pendekatan "infrastruktur sebagai kode".
Modul sumber daya apa yang akan muncul di Ansible Engine 2.9?
Sebelum menceritakan secara terperinci apa yang akan terjadi di Ansible 2.9, mari kita ingat bagaimana kita membagi seluruh jumlah pekerjaan.
Kami mengidentifikasi 7 kategori dan masing-masing ditugaskan sumber daya jaringan tertentu:
Catatan: sumber daya yang berani telah direncanakan dan diimplementasikan dalam Ansible 2.9.
Berdasarkan umpan balik dari klien korporat dan komunitas, adalah logis untuk pertama-tama berurusan dengan modul-modul yang terkait dengan protokol topologi jaringan, virtualisasi, dan antarmuka.
Modul sumber daya berikut dikembangkan oleh tim Ansible Network dan sesuai dengan platform yang didukung Red Hat:
Modul-modul berikut dikembangkan oleh komunitas Ansible:
exos_lldp_global - dari Extreme Networks.nxos_bfd_interfaces - dari Cisconxos_telemetry - dari Cisco
Seperti yang Anda lihat, konsep modul sumber daya cocok dengan strategi orientasi platform kami. Artinya, kami menyertakan kapabilitas dan fungsi yang diperlukan dalam Ansible itu sendiri, untuk mendukung standardisasi dalam pengembangan modul jaringan, serta untuk menyederhanakan pekerjaan pengguna di level peran dan buku pedoman yang dimungkinkan. Untuk memperluas pengembangan modul sumber daya, tim Ansible merilis alat Pembuat Modul.
Berencana untuk Ansible 2.10 dan seterusnya
Setelah rilis Ansible 2.9, kita akan berurusan dengan set modul sumber daya berikut untuk Ansible 2.10, yang dapat digunakan untuk mengkonfigurasi lebih lanjut topologi dan kebijakan jaringan, misalnya, ACL, OSPF, dan BGP . Paket pengembangan masih dapat disesuaikan, jadi jika Anda memiliki komentar, laporkan ke komunitas Ansible Network .
Sumber daya dan memulai
Siaran Pers Platform Otomatisasi yang Mungkin
Blog Platform Otomatisasi yang Mungkin
Masa depan pengiriman konten di Ansible
Refleksi tentang Mengubah Struktur Proyek yang Mungkin