Mengingat perbaikan signifikan yang diterapkan di Ansible Engine 2.6, serta dengan mempertimbangkan rilis Ansible Tower 3.3 dan rilis terbaru Ansible Engine 2.7, mari kita melihat lebih dekat prospek prospek otomatisasi jaringan.
Dalam posting ini:
- Plugin koneksi Httpapi.
- Dukungan untuk Arista eAPI dan Cisco NX-API.
- Modul otomatisasi jaringan baru.
- net_get dan net_put.
- netconf_get, netconf_rpc dan netconf_config.
- cli_command dan cli_config.
- Antarmuka web Ansible Tower yang disempurnakan.
- Kelola kredensial di Ansible Tower saat bekerja dengan perangkat jaringan.
- Menggunakan versi Ansible in Tower yang berbeda secara bersamaan
Jangan lupa bahwa rilis setiap versi baru dari Ansible disertai dengan pembaruan
ke panduan porting , yang akan sangat memudahkan transisi ke versi baru.
Plugin Koneksi HTTPAPI
Plugin koneksi adalah apa yang memungkinkan untuk terhubung ke host target dan kemudian melakukan tugasnya. Dimulai dengan Ansible 2.5, sebuah plugin baru jenis ini yang disebut network_cli telah muncul. Ini menghilangkan kebutuhan untuk menggunakan parameter penyedia dan membakukan urutan eksekusi modul jaringan, sebagai akibatnya buku pedoman untuk perangkat jaringan sekarang dieksekusi, dieksekusi dan bekerja dengan cara yang sama seperti buku pedoman untuk host Linux. Pada gilirannya, untuk Ansible Tower, perbedaan antara perangkat jaringan dan host menghilang, dan tidak perlu lagi membedakan antara nama pengguna dan kata sandi untuk perangkat jaringan dan untuk mesin. Ini telah dibahas secara lebih rinci di
sini , tetapi singkatnya, kata sandi login untuk server Linux dan beralih Arista EOS atau router Cisco sekarang dapat digunakan dan disimpan dengan cara yang sama.
Di Ansible 2.5, menghubungkan melalui metode eAPI dan NX-API hanya mungkin menggunakan metode penyedia lama. Kemungkinan 2.6 tidak lagi memiliki batasan ini dan Anda dapat dengan bebas menggunakan metode koneksi httpapi tingkat tinggi. Mari kita lihat bagaimana ini dilakukan.
Anda harus terlebih dahulu mengaktifkan eAPI atau NX-API pada perangkat jaringan sehingga Anda kemudian dapat menggunakan metode httpapi. Ini mudah dilakukan dengan perintah Ansible yang sesuai, misalnya, inilah cara mengaktifkan eAPI pada sakelar EOS Arista.
[user@rhel7]$ ansible -m eos_eapi -c network_cli leaf01 leaf01 | SUCCESS => { "ansible_facts": { "eos_eapi_urls": { "Ethernet1": [ "https://192.168.0.14:443" ], "Management1": [ "https://10.0.2.15:443" ] } }, "changed": false, "commands": [] }
Ketika terhubung ke sakelar EOS Arista nyata, perintah show api manajemen http-perintah akan menunjukkan bahwa API diaktifkan:
leaf01# show management api http-commands Enabled: Yes HTTPS server: running, set to use port 443 <<<rest of output removed for brevity>>>
Skrip Playbook Ansible di bawah ini hanya menjalankan perintah show version, dan kemudian di bagian debug hanya mengembalikan versi dari hasil tugas JSON.
--- - hosts: leaf01 connection: httpapi gather_facts: false tasks: - name: type a simple arista command eos_command: commands: - show version | json register: command_output - name: print command output to terminal window debug: var: command_output.stdout[0]["version"]
Menjalankan skrip ini akan menghasilkan hasil berikut:
[user@rhel7]$ ansible-playbook playbook.yml PLAY [leaf01]******************************************************** TASK [type a simple arista command] ********************************* ok: [leaf01] TASK [print command output to terminal window] ********************** ok: [leaf01] => { "command_output.stdout[0][\"version\"]": "4.20.1F" } PLAY RECAP*********************************************************** leaf01 : ok=2 changed=0 unreachable=0 failed=0
CATATAN: Arista eAPI tidak mendukung versi perintah yang disingkat (seperti "show ver", bukan "show version2), jadi Anda harus menulis semuanya. Untuk informasi lebih lanjut tentang plugin koneksi httpapi, lihat dokumentasi.
Modul otomatisasi jaringan baru
2.6 dan versi 2.7 yang dirilis pada bulan Oktober menawarkan tujuh modul baru untuk otomatisasi jaringan.
- net_get - Salin file dari perangkat jaringan ke Pengendali yang Mungkin.
- net_put - Menyalin file dari Pengontrol yang Mungkin ke perangkat jaringan.
- netconf_get - Mengambil data konfigurasi / status dari perangkat jaringan dengan NETCONF diaktifkan.
- netconf_rpc - Melakukan operasi pada perangkat jaringan dengan NETCONF diaktifkan.
- netconf_config - konfigurasi perangkat netconf , modul ini memungkinkan pengguna untuk mengirim file XML ke perangkat netconf dan memeriksa apakah konfigurasi telah berubah.
- cli_command - menjalankan perintah cli pada perangkat jaringan yang memiliki antarmuka perintah (cli).
- cli_config - Mengirim (push) konfigurasi teks ke perangkat jaringan melalui network_cli.
net_get dan net_put
- net_get - Salin file dari perangkat jaringan ke Pengendali yang Mungkin.
- net_put - Menyalin file dari Pengontrol yang Mungkin ke perangkat jaringan.
Modul net_get dan net_put tidak terikat dengan peralatan dari pabrikan tertentu dan cukup menyalin file dari perangkat jaringan ke perangkat yang menggunakan protokol transfer SCP atau SFTP standar (ditentukan oleh parameter protokol). Kedua modul ini memerlukan penggunaan metode koneksi network_cli, dan juga hanya berfungsi jika scp (pip install scp) diinstal pada controller dan SCP atau SFTP diaktifkan pada perangkat jaringan.
Kami berasumsi bahwa dalam contoh dengan buku pedoman kami, kami telah menjalankan perintah berikut pada perangkat Leaf01:
leaf01#copy running-config flash:running_cfg_eos1.txt Copy completed successfully.
Beginilah bentuk buku pedoman dengan dua tugas (yang pertama menyalin file dari perangkat Leaf01, dan yang kedua menyalin file ke perangkat Leaf01):
--- - hosts: leaf01 connection: network_cli gather_facts: false tasks: - name: COPY FILE FROM THE NETWORK DEVICE TO ANSIBLE CONTROLLER net_get: src: running_cfg_eos1.txt - name: COPY FILE FROM THE ANSIBLE CONTROLLER TO THE NETWORK DEVICE net_put: src: temp.txt
netconf_get, netconf_rpc dan netconf_config
- netconf_get - Mengambil data konfigurasi / status dari perangkat jaringan dengan NETCONF diaktifkan.
- netconf_rpc - Melakukan operasi pada perangkat jaringan dengan NETCONF diaktifkan.
- netconf_config - konfigurasi perangkat netconf , modul ini memungkinkan pengguna untuk mengirim file XML ke perangkat netconf dan memeriksa apakah konfigurasi telah berubah.
Protokol Manajemen Jaringan NETCONF (Network Configuration Protocol) dikembangkan dan distandarisasi oleh IETF. Menurut RFC 6241, NETCONF dapat digunakan untuk menginstal, memanipulasi, dan menghapus konfigurasi perangkat jaringan. NETCONF adalah alternatif untuk baris perintah SSH (network_cli) dan API seperti Cisco NX-API atau Arista eAPI (httpapi).
Untuk mendemonstrasikan modul netconf baru, pertama-tama kita aktifkan netconf pada router Juniper menggunakan modul
junos_netconf . Netconf tidak didukung pada semua model peralatan jaringan, jadi periksalah dokumentasi Anda sebelum menggunakannya.
[user@rhel7 ~]$ ansible -m junos_netconf juniper -c network_cli rtr4 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] } rtr3 | CHANGED => { "changed": true, "commands": [ "set system services netconf ssh port 830" ] }
Juniper Networks menawarkan Junos XML API Explorer untuk
Tag Operasional dan untuk
Tag Konfigurasi . Pertimbangkan contoh permintaan operasional yang digunakan Juniper Networks dalam
dokumentasinya untuk menggambarkan permintaan RPC untuk antarmuka tertentu.
<rpc> <get-interface-information> <interface-name>ge-2/3/0</interface-name> <detail/> </get-interface-information> </rpc> ]]>]]>
Ini mudah diterjemahkan ke dalam Ansible Playbook. get-interface-information adalah panggilan RPC, dan parameter tambahan ditentukan sebagai pasangan nilai kunci. Dalam contoh ini, hanya ada satu parameter - nama antarmuka - dan pada perangkat jaringan kami, kami hanya ingin melihat em1.0. Kami menggunakan parameter register yang diatur ke tugas, hanya untuk menyimpan hasil, jadi kami menggunakan modul debug dan menampilkan hasilnya di layar terminal. Modul netconf_rpc juga memungkinkan Anda untuk menerjemahkan output XML langsung ke JSON.
--- - name: RUN A NETCONF COMMAND hosts: juniper gather_facts: no connection: netconf tasks: - name: GET INTERFACE INFO netconf_rpc: display: json rpc: get-interface-information content: interface-name: "em1.0" register: netconf_info - name: PRINT OUTPUT TO TERMINAL WINDOW debug: var: netconf_info
Setelah memulai buku pedoman, kami mendapatkan ini:
ok: [rtr4] => { "netconf_info": { "changed": false, "failed": false, "output": { "rpc-reply": { "interface-information": { "logical-interface": { "address-family": [ { "address-family-flags": { "ifff-is-primary": "" }, "address-family-name": "inet", "interface-address": [ { "ifa-broadcast": "10.255.255.255", "ifa-destination": "10/8", "ifa-flags": { "ifaf-current-preferred": "" }, "ifa-local": "10.0.0.4" }, <<<rest of output removed for brevity>>>
Untuk informasi lebih lanjut, lihat
Panduan Platform Juniper dan
dokumentasi NETCONF .
cli_command dan cli_config
- cli_command - menjalankan perintah pada perangkat jaringan menggunakan antarmuka baris perintah mereka (jika ada).
- cli_config - Mengirim (push) konfigurasi teks ke perangkat jaringan melalui network_cli.
Modul cli_command dan cli_config yang muncul di Ansible Engine 2.7 juga tidak terikat dengan peralatan pabrikan tertentu dan dapat digunakan untuk mengotomatisasi berbagai platform jaringan. Mereka didasarkan pada nilai variabel ansible_network_os (ditetapkan dalam file inventaris atau dalam folder group_vars) untuk menggunakan plugin cliconf yang diinginkan. Daftar semua nilai variabel ansible_network_os disediakan dalam
dokumentasi . Dalam versi Ansible ini, Anda masih dapat menggunakan modul lama untuk platform tertentu, jadi luangkan waktu Anda untuk menulis ulang buku pedoman yang ada. Untuk informasi lebih lanjut, lihat
panduan porting resmi .
Mari kita lihat bagaimana modul-modul ini digunakan dalam Ansible Playbook. Buku pedoman ini akan berjalan pada dua sistem Cisco Cloud Services Routers (CSR) yang menjalankan iOS-XE. Variabel ansible_network_os dalam file inventaris diatur ke ios.
<config snippet from inventory> [cisco] rtr1 ansible_host=34.203.197.120 rtr2 ansible_host=34.224.60.230 [cisco:vars] ansible_ssh_user=ec2-user ansible_network_os=ios
Inilah cara cli_config dan cli_command digunakan:
--- - name: AGNOSTIC PLAYBOOK hosts: cisco gather_facts: no connection: network_cli tasks: - name: CONFIGURE DNS cli_config: config: ip name-server 8.8.8.8 - name: CHECK CONFIGURATION cli_command: command: show run | i ip name-server register: cisco_output - name: PRINT OUTPUT TO SCREEN debug: var: cisco_output.stdout
Dan inilah output dari buku pedoman ini:
[user@rhel7 ~]$ ansible-playbook cli.yml PLAY [AGNOSTIC PLAYBOOK] ********************************************* TASK [CONFIGURE DNS] ************************************************* ok: [rtr1] ok: [rtr2] TASK [CHECK CONFIGURATION] ******************************************* ok: [rtr1] ok: [rtr2] TASK [PRINT OUTPUT TO SCREEN] **************************************** ok: [rtr1] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } ok: [rtr2] => { "cisco_output.stdout": "ip name-server 8.8.8.8" } PLAY RECAP ********************************************************** rtr1 : ok=3 changed=0 unreachable=0 failed=0 rtr2 : ok=3 changed=0 unreachable=0 failed=0
Harap dicatat bahwa modul-modul ini
idempoten selama Anda menggunakan sintaks yang sesuai untuk perangkat jaringan yang sesuai.
Peningkatan Antarmuka Menara yang Mungkin
Antarmuka web di Red Hat Ansible Tower 3.3 telah menjadi lebih nyaman dan fungsional, memungkinkan lebih sedikit klik saat melakukan berbagai tugas.
Manajemen kredensial, penjadwal tugas, skrip inventaris, kontrol akses berbasis peran, pemberitahuan, dan banyak lagi kini dikumpulkan di menu utama di sisi kiri layar dan tersedia dalam satu klik. Layar pekerjaan melihat Pekerjaan segera menampilkan informasi tambahan penting: siapa yang memulai tugas dan kapan; inventaris apa yang dikembangkan selama implementasinya; dari proyek mana buku pedoman itu diambil.
Kelola kredensial untuk perangkat jaringan di Ansible Tower
Red Hat Ansible Tower 3.3 membuatnya lebih mudah untuk mengelola kata sandi masuk untuk perangkat jaringan. Di antarmuka web baru, perintah Kredensial terletak langsung di menu utama, di grup Sumber Daya.
Ansible Tower 3.3 meninggalkan tipe kredensial (Jaringan) yang disebut "jaringan" khusus, yang menetapkan variabel lingkungan ANSIBLE_NET_USERNAME dan ANSIBLE_NET_PASSWORD yang digunakan dalam metode penyedia lama. Semua ini masih berfungsi, seperti yang ditulis dalam
dokumentasi , sehingga Anda dapat menggunakan skrip Playbook Ansible yang ada. Namun, untuk metode koneksi tingkat tinggi baru httpapi dan network_cli, jenis kredensial jaringan tidak lagi diperlukan, karena Ansible sekarang bekerja sama dengan login kata sandi seperti dengan menghubungkan ke perangkat jaringan, dan saat terhubung ke host Linxu. Karenanya, untuk perangkat jaringan, Anda sekarang harus memilih jenis kredensial mesin - cukup pilih dan masukkan kata sandi login Anda atau berikan kunci SSH.
CATATAN: Ansible Tower mengenkripsi kata sandi segera setelah Anda menyimpan kredensial.
Berkat enkripsi, kredensial dapat dengan aman didelegasikan kepada pengguna dan grup lain - mereka tidak akan melihat atau mengenali kata sandi. Untuk informasi lebih lanjut tentang cara kerja kredensial, enkripsi apa yang digunakan, dan tipe kredensial apa (seperti Amazon AWS, Microsoft Azure, dan Google GCE) dapat ditemukan dalam
dokumentasi Ansible Tower .
Penjelasan lebih rinci tentang Red Hat Ansible Tower 3.3 dapat ditemukan di
sini .
Menggunakan versi Ansible in Tower yang berbeda secara bersamaan
Misalkan kita ingin beberapa buku pedoman dijalankan melalui Ansible Engine 2.4.2, dan yang lainnya melalui Ansible Engine 2.6.4. Tower memiliki alat virtualenv khusus untuk membuat kotak pasir Python untuk menghindari konflik dengan dependensi yang saling bertentangan dan versi yang berbeda. Ansible Tower 3.3 memungkinkan Anda untuk mengatur virtualenv di berbagai tingkatan - Organisasi, Proyek atau Template Pekerjaan. Beginilah Templat Pekerjaan yang kami buat di Ansible Tower untuk membuat cadangan jaringan kami.
Saat Anda memiliki setidaknya dua lingkungan virtual, menu pop-up Lingkungan Ansible muncul di menu utama Ansible Tower, di mana Anda dapat dengan mudah menentukan versi Ansible mana yang harus digunakan saat melakukan tugas.
Oleh karena itu, jika Anda memiliki campuran buku pedoman untuk mengotomatisasi jaringan, beberapa di antaranya menggunakan metode penyedia lama (Kemungkinan 2,4 dan versi sebelumnya), dan beberapa menggunakan plugin httpapi atau network_cli baru (Kemungkinan 2,5 dan lebih tinggi), Anda dapat dengan mudah menetapkan setiap tugas Versi yang memungkinkan. Selain itu, fitur ini akan berguna jika pengembang dan produksi menggunakan versi Ansible yang berbeda. Dengan kata lain, Anda dapat memperbarui Tower dengan aman, tanpa khawatir bahwa setelah itu Anda harus beralih ke salah satu versi Ansible Engine, yang sangat meningkatkan fleksibilitas dalam mengotomatisasi berbagai jenis peralatan dan lingkungan jaringan, serta skenario penggunaan.
Untuk informasi lebih lanjut tentang penggunaan virtualenv, lihat
dokumentasi .