Peluncuran Red Hat Ansible Engine 2.9 mendatang menghadirkan peningkatan menarik, beberapa di antaranya dibahas dalam artikel ini. Seperti biasa, kami telah mengembangkan peningkatan Ansible Network secara terbuka, dengan dukungan komunitas. Bergabunglah dengan kami - lihatlah dan mempelajari rencana pengembangannya di halaman wiki untuk .
Seperti yang baru-baru ini kami umumkan, sekarang mencakup Ansible Tower, Ansible Engine, dan semua konten Ansible Network. Saat ini, sebagian besar platform jaringan populer diimplementasikan melalui modul Ansible. Misalnya:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Juno
- VyOS
Untuk daftar lengkap platform yang didukung penuh oleh Red Hat melalui langganan Ansible Automation, .
Apa yang telah kita pelajari
Selama empat tahun terakhir, kami telah belajar banyak tentang pengembangan platform otomasi jaringan. Kami juga mempelajarinya sebagai artefak platform digunakan dalam buku pedoman dan peran yang mungkin dilakukan oleh pengguna akhir. Dan inilah yang kami temukan:
- Organisasi mengotomatiskan perangkat tidak hanya dari satu, tetapi banyak vendor.
- Otomasi bukan hanya fenomena teknis, namun juga budaya.
- Mengotomatiskan jaringan dalam skala besar ternyata lebih sulit daripada yang terlihat karena prinsip arsitektur dasar desain otomasi.
Ketika kami membahas rencana pertumbuhan jangka panjang kami setahun yang lalu, klien korporat kami menanyakan hal-hal berikut:
- Pengumpulan fakta perlu distandarisasi dengan lebih baik dan diselaraskan dengan alur kerja otomatisasi di semua perangkat.
- Memperbarui konfigurasi pada perangkat juga perlu distandarisasi dan konsisten agar modul Ansible dapat menangani paruh kedua siklus setelah mengumpulkan fakta.
- Kami memerlukan metode yang ketat dan didukung untuk mengubah konfigurasi perangkat menjadi data terstruktur. Atas dasar ini, sumber kebenaran dapat dipindahkan dari perangkat jaringan.
Perbaikan fakta
Mengumpulkan fakta dari perangkat jaringan menggunakan Ansible sering kali terjadi secara acak. Platform berbasis web memiliki tingkat kemampuan pengumpulan fakta yang berbeda-beda, namun hanya memiliki sedikit atau tidak ada fungsi untuk menguraikan dan menstandardisasi representasi data dalam pasangan nilai kunci. Membaca Ken Celenza tentang betapa sulit dan menyakitkannya menganalisis dan menstandardisasi data faktual.
Anda mungkin memperhatikan kami sedang mengerjakan peran Ansible Network Engine. Tentu saja, setelah diunduh 24 ribu kali, peran Mesin Jaringan dengan cepat menjadi salah satu peran Ansible paling populer di Ansible Galaxy untuk skenario otomatisasi jaringan. Sebelum kami memindahkan sebagian besar dari ini ke Ansible 2.8 untuk mempersiapkan apa yang diperlukan di Ansible 2.9, peran Ansible ini menyediakan seperangkat alat pertama untuk membantu mengurai perintah, mengelola perintah, dan mengumpulkan data untuk perangkat jaringan.
Jika Anda tahu cara menggunakan Network Engine, ini adalah cara yang sangat efisien untuk mengumpulkan, mengurai, dan menstandardisasi data fakta untuk digunakan di Ansible. Kerugian dari peran ini adalah Anda perlu membuat sejumlah parser untuk setiap platform dan untuk semua aktivitas jaringan. Untuk memahami betapa sulitnya membuat, mengirimkan, dan memelihara parser, lihatlah dari orang-orang di Cisco.
Singkatnya, mendapatkan fakta dari perangkat dan menormalisasikannya ke dalam pasangan nilai kunci sangat penting untuk otomatisasi dalam skala besar, namun mencapai hal ini sulit dilakukan jika 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 Ansible, atau parser khusus.
Sejak Ansible 2.9, setiap kali modul jaringan yang diperbarui dirilis, modul fakta ditingkatkan untuk menyediakan data tentang bagian konfigurasi ini. Artinya, pengembangan fakta dan modul kini terjadi dengan kecepatan yang sama, dan keduanya akan selalu memiliki struktur data yang sama.
Konfigurasi sumber daya pada perangkat jaringan dapat diambil dan diubah menjadi data terstruktur dengan dua cara. Dengan kedua cara tersebut, Anda dapat mengumpulkan dan mengubah daftar sumber daya tertentu menggunakan kata kunci baru gather_network_resources. Nama sumber daya cocok dengan nama modul, yang sangat memudahkan.
Saat mengumpulkan fakta:
Menggunakan kata kunci gather_facts Anda dapat mengambil konfigurasi perangkat saat ini di awal playbook, lalu 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: TrueAnda mungkin memperhatikan sesuatu yang baru dalam contoh ini, yaitu - gather_facts: true sekarang tersedia untuk pengumpulan fakta asli untuk perangkat jaringan.
Menggunakan modul fakta jaringan secara langsung:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesBuku pedoman 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: Ethernet1Perhatikan bagaimana Ansible mengambil konfigurasi asli dari perangkat Arista dan mengubahnya menjadi data terstruktur untuk digunakan sebagai pasangan nilai kunci standar untuk tugas dan operasi hilir.
Fakta antarmuka dapat ditambahkan ke variabel yang disimpan dan digunakan segera atau nanti sebagai masukan ke modul sumber daya eos_interfaces tanpa pemrosesan atau konversi tambahan.
Modul Sumber Daya
Jadi, kami mengekstrak fakta, menormalkan data, memasukkannya ke dalam diagram struktur data internal standar, dan menerima sumber kebenaran yang siap pakai. Hore! Ini bagus, tentu saja, tetapi kita masih perlu mengonversi pasangan nilai kunci kembali ke konfigurasi spesifik yang diharapkan oleh platform perangkat tertentu. Kami sekarang memerlukan modul khusus platform untuk memenuhi persyaratan pengumpulan fakta dan normalisasi baru ini.
Apa itu modul sumber daya? Anda dapat menganggap bagian konfigurasi perangkat sebagai sumber daya yang disediakan oleh perangkat tersebut. Modul sumber daya jaringan sengaja dibatasi pada satu sumber daya dan dapat ditumpuk seperti blok penyusun untuk mengonfigurasi layanan jaringan yang kompleks. Hasilnya, persyaratan dan spesifikasi modul sumber daya disederhanakan secara alami, karena modul sumber daya dapat membaca ΠΈ mengkonfigurasi layanan jaringan tertentu pada perangkat jaringan.
Untuk menjelaskan fungsi modul sumber daya, mari kita lihat contoh buku pedoman yang memperlihatkan operasi idempoden menggunakan fakta dan modul sumber daya jaringan baru. 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.changedSeperti yang Anda lihat, data yang dikumpulkan dari perangkat ditransfer langsung ke modul sumber daya terkait tanpa konversi. Saat diluncurkan, pedoman mengambil nilai dari perangkat dan membandingkannya dengan nilai yang diharapkan. Dalam contoh ini, nilai yang dikembalikan sesuai dengan yang diharapkan (yaitu memeriksa penyimpangan konfigurasi) dan melaporkan apakah konfigurasi telah berubah.
Cara ideal untuk mendeteksi penyimpangan konfigurasi adalah dengan menyimpan fakta dalam variabel tersimpan yang dimungkinkan dan menggunakannya secara berkala dengan modul sumber daya dalam mode inspeksi. Ini adalah metode sederhana untuk melihat apakah seseorang telah mengubah nilainya secara manual. Dalam kebanyakan kasus, organisasi mengizinkan perubahan dan konfigurasi secara manual, meskipun banyak operasi dilakukan melalui Ansible Automation.
Apa perbedaan modul sumber daya baru dari modul sumber daya sebelumnya?
Untuk insinyur otomasi jaringan, ada 3 perbedaan utama antara modul sumber daya di Ansible 2.9 dan 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 berpendapat jika Ansible mendukung konfigurasi sumber daya pada satu platform jaringan, kami harus mendukungnya di mana pun. Hal ini menyederhanakan penggunaan modul sumber daya karena teknisi otomasi jaringan kini dapat mengonfigurasi sumber daya (seperti LLDP) di semua sistem operasi jaringan dengan modul asli dan yang didukung.
2) Modul sumber daya sekarang menyertakan 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 yang tidak diperlukan akan dihapus;deleted: Konfigurasi sumber daya akan dihapus/dipulihkan ke default.
3) Modul sumber daya sekarang menyertakan nilai pengembalian yang stabil. Ketika modul sumber daya jaringan telah membuat (atau mengusulkan) perubahan yang diperlukan pada perangkat jaringan, modul tersebut akan mengembalikan pasangan nilai kunci yang sama ke buku pedoman.
before: konfigurasi pada perangkat berupa data terstruktur sebelum tugas;after: jika perangkat telah berubah (atau mungkin berubah jika mode pengujian digunakan), konfigurasi yang dihasilkan akan dikembalikan sebagai data terstruktur;commands: Perintah konfigurasi apa pun dijalankan pada perangkat untuk membawanya ke kondisi yang diinginkan.
Apa maksudnya semua ini? Mengapa ini penting?
Postingan ini mencakup banyak konsep kompleks, namun kami berharap pada akhirnya Anda akan memiliki pemahaman yang lebih baik tentang apa yang diminta oleh klien perusahaan dalam pengumpulan fakta, normalisasi data, dan konfigurasi loop untuk platform otomatisasi. Namun mengapa mereka memerlukan perbaikan ini? Banyak organisasi kini melakukan transformasi digital untuk menjadikan lingkungan TI mereka lebih gesit dan kompetitif. Baik atau buruk, banyak insinyur jaringan menjadi pengembang jaringan baik karena kepentingan pribadi atau atas perintah manajemen.
Organisasi menyadari bahwa mengotomatiskan templat jaringan individual tidak menyelesaikan masalah silo dan hanya meningkatkan efisiensi sampai batas tertentu. Red Hat Ansible Automation Platform menyediakan model data sumber daya yang ketat dan normatif untuk mengelola data pokok pada perangkat jaringan secara terprogram. Artinya, pengguna secara bertahap meninggalkan metode konfigurasi individual demi metode yang lebih modern dengan penekanan pada teknologi (misalnya, alamat IP, VLAN, LLDP, dll.), daripada implementasi vendor tertentu.
Apakah ini berarti masa-masa modul perintah dan konfigurasi yang andal dan terbukti akan segera berakhir? Sama sekali tidak. Modul sumber daya jaringan yang diharapkan tidak akan berlaku di semua kasus atau untuk setiap vendor, sehingga modul perintah dan konfigurasi masih diperlukan oleh insinyur jaringan untuk implementasi tertentu. Tujuan modul sumber daya adalah untuk menyederhanakan template Jinja besar dan menormalkan konfigurasi perangkat tidak terstruktur ke dalam format JSON terstruktur. Dengan modul sumber daya, jaringan yang ada akan lebih mudah mengubah konfigurasinya menjadi pasangan nilai kunci terstruktur yang mewakili sumber kebenaran yang mudah dibaca. Dengan menggunakan pasangan nilai kunci terstruktur, Anda dapat beralih dari menjalankan konfigurasi di setiap perangkat ke bekerja dengan data terstruktur independen dan menjadikan jaringan terdepan dalam pendekatan infrastruktur sebagai kode.
Modul sumber daya apa yang akan hadir di Ansible Engine 2.9?
Sebelum kami memberi tahu Anda secara detail apa yang akan terjadi di Ansible 2.9, mari kita ingat bagaimana kami membagi seluruh lingkup pekerjaan.
Kami mengidentifikasi 7 kategori dan menetapkan sumber daya jaringan spesifik untuk masing-masing kategori:
Catatan: Sumber daya yang dicetak tebal direncanakan dan dilaksanakan di Ansible 2.9.
Berdasarkan masukan dari pelanggan perusahaan dan komunitas, masuk akal untuk terlebih dahulu menangani 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 oleh Red Hat:
Modul berikut dikembangkan oleh komunitas Ansible:
exos_lldp_global- dari Jaringan Ekstrim.nxos_bfd_interfaces- dari Cisconxos_telemetry- dari Cisco
Seperti yang Anda lihat, konsep modul sumber daya cocok dengan strategi kami yang berpusat pada platform. Artinya, kami menyertakan kemampuan dan fungsi yang diperlukan dalam Ansible itu sendiri untuk mendukung standardisasi dalam pengembangan modul jaringan, dan juga untuk menyederhanakan pekerjaan pengguna di tingkat peran dan pedoman Ansible. Untuk memperluas pengembangan modul sumber daya, tim Ansible merilis alat Pembuat Modul.
Rencana untuk Ansible 2.10 dan seterusnya
Setelah Ansible 2.9 dirilis, kami akan mengerjakan rangkaian modul sumber daya berikutnya untuk Ansible 2.10, yang dapat digunakan untuk mengonfigurasi topologi dan kebijakan jaringan lebih lanjut, misalnya. . Rencana pengembangannya masih bisa disesuaikan, jadi jika ada komentar silahkan lapor ke .
Sumber daya dan memulai
Sumber: www.habr.com