Red Hat Ansible Engine 2.9'un yakında çıkacak sürümü, bazıları bu makalede tartışılan heyecan verici iyileştirmeler getiriyor. Her zaman olduğu gibi Ansible Network iyileştirmelerini topluluk desteğiyle açık bir şekilde geliştiriyoruz. Bize katılın - bir göz atın ve kalkınma planını inceleyin için wiki sayfasında .
Geçtiğimiz günlerde duyurduğumuz gibi, artık Ansible Tower, Ansible Engine ve tüm Ansible Network içeriğini içeriyor. Günümüzde en popüler ağ platformları Ansible modülleri aracılığıyla uygulanmaktadır. Örneğin:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Ardıç Junos
- VyOS
Ansible Automation aboneliği aracılığıyla Red Hat tarafından tam olarak desteklenen platformların tam listesi için: .
Ne öğrendik?
Geçtiğimiz dört yılda bir ağ otomasyon platformu geliştirme konusunda çok şey öğrendik. Bunu da öğrendik gibi platform eserleri Ansible oyun kitaplarında ve son kullanıcılar tarafından kullanılan rollerde kullanılır. Ve işte şunu öğrendik:
- Kuruluşlar yalnızca bir değil birçok satıcının cihazlarını otomatikleştiriyor.
- Otomasyon yalnızca teknik bir olgu değil, aynı zamanda kültürel bir olgudur.
- Otomasyon tasarımının temel mimari ilkeleri nedeniyle ağları uygun ölçekte otomatikleştirmek göründüğünden daha zordur.
Bir yıl önce uzun vadeli büyüme planlarımızı tartıştığımızda kurumsal müşterilerimiz şunları sordu:
- Bilgi toplamanın daha iyi standartlaştırılması ve tüm cihazlardaki otomasyon iş akışlarıyla uyumlu hale getirilmesi gerekiyor.
- Ansible modüllerinin gerçekleri topladıktan sonra döngünün ikinci yarısını ele alabilmesi için cihazdaki güncelleme konfigürasyonlarının da standartlaştırılması ve tutarlı olması gerekir.
- Cihaz konfigürasyonunu yapılandırılmış verilere dönüştürmek için titiz ve desteklenen yöntemlere ihtiyacımız var. Bu temelde gerçeğin kaynağı ağ cihazından taşınabilir.
Gerçek iyileştirmeler
Ansible kullanarak ağ cihazlarından bilgi toplamak genellikle rastgele gerçekleşir. Web tabanlı platformların farklı derecelerde bilgi toplama yetenekleri vardır, ancak anahtar-değer çiftlerindeki verilerin temsilini ayrıştırma ve standartlaştırmaya yönelik işlevsellikleri çok azdır veya hiç yoktur. Okumak Ken Celenza, gerçek verileri analiz etmenin ve standartlaştırmanın ne kadar zor ve acı verici olabileceğini anlatıyor.
Ansible Network Engine rolü üzerinde çalıştığımızı fark etmiş olabilirsiniz. Doğal olarak, 24K indirme sonrasında Network Engine rolü, ağ otomasyon senaryoları için kısa sürede Ansible Galaxy'deki en popüler Ansible rollerinden biri haline geldi. Ansible 2.8'da ihtiyaç duyulan şeylere hazırlanmak için bunların çoğunu Ansible 2.9'e taşımadan önce, bu Ansible rolü, komutların ayrıştırılmasına, komutların yönetilmesine ve ağ cihazları için veri toplanmasına yardımcı olacak ilk araç setini sağladı.
Network Engine'in nasıl kullanılacağını biliyorsanız bu, Ansible'da kullanılmak üzere olgu verilerini toplamanın, ayrıştırmanın ve standartlaştırmanın çok etkili bir yoludur. Bu rolün dezavantajı, her platform ve tüm ağ etkinliği için çok sayıda ayrıştırıcı oluşturmanız gerekmesidir. Ayrıştırıcıları oluşturmanın, göndermenin ve sürdürmenin ne kadar zor olduğunu anlamak için şuraya bir göz atın: Cisco'daki adamlardan.
Özetle, cihazlardan gerçekleri almak ve bunları anahtar/değer çiftleri halinde normalleştirmek, geniş ölçekte otomasyon için çok önemlidir, ancak çok sayıda satıcınız ve ağ platformunuz olduğunda bunu başarmak zordur.
Ansible 2.9'daki her ağ olgu modülü artık ek kitaplıklar, Ansible rolleri veya özel ayrıştırıcılar olmadan bir ağ cihazının yapılandırmasını analiz edebilir ve yapılandırılmış verileri döndürebilir.
Ansible 2.9'dan bu yana, güncellenen bir ağ modülü her yayınlandığında, olgu modülü, yapılandırmanın bu bölümü hakkında veri sağlayacak şekilde geliştirilir. Yani olguların ve modüllerin gelişimi artık aynı hızda gerçekleşiyor ve her zaman ortak bir veri yapısına sahip olacaklar.
Bir ağ cihazındaki kaynakların yapılandırması iki şekilde alınabilir ve yapılandırılmış verilere dönüştürülebilir. Her iki şekilde de, yeni bir anahtar kelime kullanarak belirli bir kaynak listesini toplayabilir ve dönüştürebilirsiniz. gather_network_resources. Kaynak adları modül adlarıyla eşleşir ve bu çok kullanışlıdır.
Gerçekleri toplarken:
Bir anahtar kelime kullanma gather_facts Geçerli cihaz yapılandırmasını başucu kitabının başlangıcından alabilir ve bunu başucu kitabının tamamında kullanabilirsiniz. Cihazdan alınacak bireysel kaynakları belirtin.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueBu örneklerde yeni bir şey fark etmiş olabilirsiniz: gather_facts: true artık ağ cihazları için yerel bilgi toplama için kullanılabilir.
Ağ olgusu modülünü doğrudan kullanma:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesBaşucu kitabı, arayüzle ilgili aşağıdaki gerçekleri döndürür:
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: Ethernet1Ansible'ın yerel konfigürasyonu Arista cihazından nasıl aldığına ve bunu aşağı yönlü görevler ve işlemler için standart anahtar/değer çiftleri olarak kullanmak üzere yapılandırılmış verilere nasıl dönüştürdüğüne dikkat edin.
Arayüz gerçekleri Ansible'da saklanan değişkenlere eklenebilir ve hemen veya daha sonra bir kaynak modülüne girdi olarak kullanılabilir eos_interfaces ek işlem veya dönüştürme olmadan.
Kaynak Modülleri
Böylece gerçekleri çıkardık, verileri normalleştirdik, bunları standartlaştırılmış bir dahili veri yapısı şemasına yerleştirdik ve hazır bir gerçek kaynağı elde ettik. Yaşasın! Bu elbette harika, ancak yine de anahtar/değer çiftlerini belirli cihaz platformunun beklediği belirli yapılandırmaya geri dönüştürmemiz gerekiyor. Artık bu yeni bilgi toplama ve normalleştirme gereksinimlerini karşılamak için platforma özel modüllere ihtiyacımız var.
Kaynak modülü nedir? Bir cihazın konfigürasyon bölümlerini o cihazın sağladığı kaynaklar olarak düşünebilirsiniz. Ağ kaynağı modülleri kasıtlı olarak tek bir kaynakla sınırlıdır ve karmaşık ağ hizmetlerini yapılandırmak için yapı taşları gibi istiflenebilir. Sonuç olarak, kaynak modülü okuyabildiğinden kaynak modülünün gereksinimleri ve özellikleri doğal olarak basitleştirilmiştir. и bir ağ cihazında belirli bir ağ hizmetini yapılandırmak.
Bir kaynak modülünün ne yaptığını açıklamak için, yeni ağ kaynağı gerçeklerini ve modülünü kullanan eş zamanlı bir işlemi gösteren örnek bir taktik kitabına bakalım. 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.changedGördüğünüz gibi cihazdan toplanan veriler, dönüşüme gerek kalmadan doğrudan ilgili kaynak modülüne aktarılıyor. Playbook başlatıldığında cihazdan değerleri alır ve bunları beklenen değerlerle karşılaştırır. Bu örnekte döndürülen değerler beklendiği gibidir (yani konfigürasyon sapmalarını kontrol eder) ve konfigürasyonun değişip değişmediğini rapor eder.
Yapılandırma sapmasını tespit etmenin ideal yolu, gerçekleri Ansible'da saklanan değişkenlerde depolamak ve bunları periyodik olarak kaynak modülüyle inceleme modunda kullanmaktır. Bu, birisinin değerleri manuel olarak değiştirip değiştirmediğini görmek için basit bir yöntemdir. Çoğu durumda, birçok işlem Ansible Automation aracılığıyla gerçekleştirilse de, kuruluşlar değişiklik ve konfigürasyona manuel olarak izin verir.
Yeni kaynak modüllerinin öncekilerden farkı nedir?
Bir ağ otomasyon mühendisi için Ansible 3'daki kaynak modülleri ile önceki sürümler arasında 2.9 temel fark vardır.
1) Belirli bir ağ kaynağı için (bir yapılandırma bölümü olarak da düşünülebilir), modüller ve gerçekler, desteklenen tüm ağ işletim sistemlerinde aynı anda gelişecektir. Ansible, kaynak yapılandırmasını tek bir ağ platformunda destekliyorsa bizim de onu her yerde desteklememiz gerektiğini düşünüyoruz. Bu, kaynak modüllerinin kullanımını basitleştirir çünkü bir ağ otomasyon mühendisi artık yerel ve desteklenen modüllere sahip tüm ağ işletim sistemlerinde bir kaynağı (LLDP gibi) yapılandırabilir.
2) Kaynak modülleri artık bir durum değeri içeriyor.
merged: konfigürasyon, sağlanan konfigürasyonla birleştirilir (varsayılan);replaced: Kaynak yapılandırması, sağlanan yapılandırmayla değiştirilecektir;overridden: Kaynak yapılandırması, sağlanan yapılandırmayla değiştirilecektir; gereksiz kaynak örnekleri silinecek;deleted: Kaynak yapılandırması silinecek/varsayılana geri yüklenecek.
3) Kaynak modülleri artık kararlı dönüş değerleri içeriyor. Ağ kaynağı modülü ağ cihazında gerekli değişiklikleri yaptığında (veya önerdiğinde), aynı anahtar/değer çiftlerini oyun kitabına geri gönderir.
before: görevden önce yapılandırılmış veri biçiminde cihazda yapılandırma;after: cihaz değiştiyse (veya test modu kullanılıyorsa değişebilir), ortaya çıkan konfigürasyon, yapılandırılmış veri olarak döndürülecektir;commands: Cihazı istenen duruma getirmek için cihazda herhangi bir yapılandırma komutu çalıştırılır.
Bütün bunlar ne anlama geliyor? Neden önemlidir?
Bu yazı birçok karmaşık kavramı kapsamaktadır, ancak sonunda kurumsal müşterilerin bir otomasyon platformu için toplama, veri normalleştirme ve döngü yapılandırması konularında ne istediklerini daha iyi anlayacağınızı umuyoruz. Peki neden bu iyileştirmelere ihtiyaç duyuyorlar? Pek çok kuruluş artık BT ortamlarını daha çevik ve rekabetçi hale getirmek için dijital dönüşümün peşinde. İyi ya da kötü, birçok ağ mühendisi ya kişisel çıkarları nedeniyle ya da yönetimin emriyle ağ geliştiricileri haline geliyor.
Kuruluşlar, bireysel ağ şablonlarını otomatikleştirmenin silo sorununu çözmediğini ve verimliliği yalnızca belirli bir dereceye kadar artırdığının farkına varıyor. Red Hat Ansible Otomasyon Platformu, bir ağ cihazındaki temel verileri programlı bir şekilde yönetmek için sıkı ve normatif kaynak veri modelleri sağlar. Yani kullanıcılar, belirli bir satıcı uygulaması yerine teknolojilere (örneğin, IP adresleri, VLAN'lar, LLDP, vb.) vurgu yapan daha modern yöntemler lehine bireysel yapılandırma yöntemlerinden yavaş yavaş vazgeçiyorlar.
Bu, güvenilir ve kanıtlanmış komuta modülleri ve konfigürasyonunun günlerinin sayılı olduğu anlamına mı geliyor? Hiçbir durumda. Beklenen ağ kaynağı modülleri her durumda veya her satıcı için geçerli olmayacağından, belirli uygulamalar için ağ mühendisleri tarafından komut ve yapılandırma modüllerine hâlâ ihtiyaç duyulacaktır. Kaynak modüllerinin amacı, büyük Jinja şablonlarını basitleştirmek ve yapılandırılmamış cihaz yapılandırmalarını yapılandırılmış bir JSON formatına normalleştirmektir. Kaynak modülleri sayesinde mevcut ağların konfigürasyonlarını, okunması kolay bir gerçek kaynağını temsil eden yapılandırılmış anahtar/değer çiftlerine dönüştürmeleri daha kolay olacaktır. Yapılandırılmış anahtar/değer çiftlerini kullanarak, her cihazda yapılandırmaları çalıştırmaktan bağımsız yapılandırılmış verilerle çalışmaya geçebilir ve ağları, kod olarak altyapı yaklaşımının ön sıralarına taşıyabilirsiniz.
Ansible Engine 2.9'da hangi kaynak modülleri gelecek?
Ansible 2.9'da neler olacağını detaylı olarak anlatmadan önce tüm çalışma kapsamını nasıl bölüştürdüğümüzü hatırlayalım.
7 kategori belirledik ve her birine belirli ağ kaynakları atadık:
Not: Kalın harflerle yazılan kaynaklar Ansible 2.9'da planlandı ve uygulandı.
Kurumsal müşterilerden ve topluluktan gelen geri bildirimlere dayanarak, öncelikle ağ topolojisi protokolleri, sanallaştırma ve arayüzlerle ilgili modülleri ele almak mantıklıydı.
Aşağıdaki kaynak modülleri Ansible Network ekibi tarafından geliştirildi ve Red Hat tarafından desteklenen platformlara karşılık geliyor:
Aşağıdaki modüller Ansible topluluğu tarafından geliştirilmiştir:
exos_lldp_global- Extreme Networks'ten.nxos_bfd_interfaces- Cisco'dannxos_telemetry- Cisco'dan
Gördüğünüz gibi kaynak modülleri kavramı platform merkezli stratejimize uyuyor. Yani, ağ modüllerinin geliştirilmesinde standardizasyonu desteklemek ve ayrıca kullanıcıların çalışmalarını Ansible rolleri ve oyun kitapları düzeyinde basitleştirmek için gerekli yetenekleri ve işlevleri Ansible'ın kendisine dahil ediyoruz. Kaynak modüllerinin geliştirilmesini genişletmek için Ansible ekibi, Modül Oluşturucu aracını yayınladı.
Ansible 2.10 ve sonrası için planlar
Ansible 2.9 piyasaya sürüldüğünde, Ansible 2.10 için ağ topolojisini ve politikasını daha da yapılandırmak için kullanılabilecek bir sonraki kaynak modülleri seti üzerinde çalışacağız; . Kalkınma planı hala ayarlanabilir, dolayısıyla yorumlarınız varsa lütfen bunu şu adrese bildirin: .
Kaynaklar ve başlangıç
Kaynak: habr.com