Ansible və inventory

Nəzəri əsaslar və memarlıq

Operatorun avadanlıq parkının konfiqurasiya avtomatlaşdırılması agentsiz konfiqurasiya idarəetmə sistemi olan Ansible ilə həyata keçirilir. Şəbəkə modulları kontrollerdə icra olunur, cihaza isə CLI komandaları və ya RPC göndərilir, ona görə qoşulma connection plugin ilə seçilir (ansible.netcommon.network_cli, netconf və ya httpapi). Əsas komponentlər: 1. İnventar (Inventory): cihaz qrupları (pe_routers, p_routers, rr_servers), onların ünvanları, platforma (ansible_network_os: cisco.ios.ios, junipernetworks.junos.junos, Huawei CloudEngine üçün community.network.ce, community.routeros.routeros) və qrup (group_vars) və host (host_vars) dəyişənləri olan YAML və ya INI faylı. 2. Modullar (cisco.ios.ios_config, junipernetworks.junos.junos_config və s.): *_config modullarının idempotentliyi konfiqurasiya mətninin müqayisəsi ilə həyata keçirilir: lazımi sətirlər artıq varsa, modul ok qaytarır. Sətirlər normallaşdırılmış formada yazılır, əks halda tapşırıq həmişə changed olur. 3. Playbook-lar: faktların toplanması, uyğunluq yoxlaması, VRF və interfeyslərin --check --diff, backup: true və mərhələli serial ilə yayılması ssenariləri. Playbook əl xətalarını azaldır, lakin tətbiqdən əvvəl məlumatların yoxlanmasını və geri qaytarma ilə təsdiqlənmiş commit-i əvəz etmir.

Ansible operator şəbəkəsinə nə verir və nə vermir

Ansible agentsizdir: kontroller cihaza SSH (və ya NETCONF, HTTP API) ilə qoşulur və modul icra edir. Şəbəkə üçün modullar cihazda işə düşmür: Python kontrollerdə icra olunur, avadanlığa isə CLI əmrləri və ya RPC-lər gedir. Ona görə qoşulma ssh ilə yox, connection plagini ilə verilir: ansible.netcommon.network_cli (SSH üzərində CLI), ansible.netcommon.netconf (NETCONF) və ya ansible.netcommon.httpapi. Platforma ansible_network_os dəyişəni ilə seçilir.

Kolleksiya versiyaları requirements.yml-də sabitlənir, əks halda kontrollerin yenilənməsi modulların davranışını dəyişir. Huawei routerləri üçün istehsalçının rəsmi kolleksiyası yoxdur; işlək alternativ cihazın YANG modelinə əsaslanan XML yükü ilə ansible.netcommon.netconf_config-dir.

Inventory, group_vars, host_vars

Inventory hansı cihazların olduğunu və onlara necə qoşulmaq lazım olduğunu təsvir edir. YAML formatı iç-içə qruplara icazə verir: pe_routers özündə pe_cisco, pe_juniper və s. saxlayır. Dəyişənlər üstünlük sırası ilə götürülür: group_vars/all group_vars/<qrup>-dan aşağıdır, host_vars/<host> isə qrupdan yuxarıdır. Layihələndirmə qaydası: inventory-də yalnız qoşulma və qrup üzvlüyü üçün lazım olanlar durur, xidmət məlumatı (VRF, RD, RT) isə group_vars və host_vars-da və ya xarici həqiqət mənbəyində saxlanılır. Böyük şəbəkələrdə inventory dinamik qurulur: netbox.netbox.nb_inventory cihazları və teqləri NetBox-dan oxuyur və əl ilə siyahı yox olur.

# inventory/prod/hosts.yml
all:
  children:
    pe_routers:
      children:
        pe_cisco:
          hosts: {pe1: {ansible_host: 10.255.0.1, pe_id: 1}}
        pe_juniper:
          hosts: {pe2: {ansible_host: 10.255.0.2, pe_id: 2}}
# group_vars/all.yml
as_number: 65000
allowed_rt: {A: ["65000:100"], B: ["65000:200"]}

ansible-inventory -i inventory/prod --graph əmri nəticə qrup ağacını, --host pe1 isə birləşmədən sonra hostun yekun dəyişənlərini göstərir. Hər hansı gözlənilməz hal zamanı ilk yoxlama budur.

İdempotentlik: həqiqətən necə qurulub

İdempotentlik təkrar işə salınmanın dəyişiklik yaratmaması deməkdir. *_config modulları üçün o, mətn müqayisəsi ilə həyata keçirilir: Ansible running-config-i yükləyir, lines sətirlərini lazım olan parents altında uyğunlaşdırır və yalnız çatışmayanları göndərir. Buradan tipik problemlər yaranır:

• Playbook-dakı sətir cihazın əmri necə saxladığına uyğun olmalıdır. IOS-XE-də route-target both 65000:100 running-config-də iki sətirə, import və export-a çevrilir, ona görə belə tapşırıq həmişə changed olacaq. Sətirləri normallaşdırılmış formada yazın.
• Cihazın göstərmədiyi susmaya görə dəyərləri olan əmrlər də daimi changed verir.
• ios_config susmaya görə match: line işlədir; sıranın vacib olduğu sətirlər üçün match: exact və ya strict, bütöv blokun əvəzlənməsi üçün replace: block istifadə edin.
• RouterOS-un /ip/vrf/add əmri idempotent deyil: təkrar əlavə etmə xəta qaytarır, ona görə ya əlavə etməzdən əvvəl yoxlama, ya da community.routeros.api_modify modulu lazımdır.

Check mode və diff

ansible-playbook --check --diff modulları "nə dəyişərdi" rejimində icra edir. ios_config, junos_config və ce_config üçün modul diff qurur, lakin tətbiq etmir; Junos-da candidate check_commit ilə yüklənir. Məhdudiyyətlər: *_command modulları check mode-da dəyişdirici əmrləri icra etmir, asılı tapşırıqlar isə əvvəlki addımlar tətbiq olunmadığı üçün xəta verə bilər. Ona görə CI-da check mode sintaksis və diff yoxlamasıdır, işlək olmanın sübutu deyil: onu stendlə tamamlayırlar.

Təhlükəsiz yayım

• serial: 1 və ya serial: [1, "25%"] PE-ləri bir-bir (canary), sonra dəstələrlə yayır; max_fail_percentage: 0 və any_errors_fatal: true ilk xətada yayımı dayandırır.
• --limit pe1 işə salınmanı məhdudlaşdırır, --tags tapşırıqların bir hissəsini seçir.
• Timeout ilə təsdiq: Junos-da junos_config-də confirm: 5 (5 dəqiqəlik commit confirmed), IOS-XE-də configure replace ... time və ya archive/rollback qabığı. Xidmət yoxlandıqdan sonra ayrıca tapşırıq commit-i təsdiqləyir (confirm_commit: true).
• Dəyişiklikdən əvvəl ehtiyat nüsxə: *_config-də backup: true running-config-i kontrollerdə saxlayır; o, həm də geri qayıtma nöqtəsidir.
• forks (susmaya görə 5) paralelliyi məhdudlaşdırır; tapşırıqda throttle: 1 ortaq resursa eyni vaxtda müraciətləri məhdudlaşdırır.