У маючым адбыцца выпуску Red Hat Ansible Engine 2.9 вас чакаюць уражлівыя паляпшэнні, і некаторыя з іх апісаны ў гэтым артыкуле. Як звычайна, мы распрацоўвалі паляпшэнні Ansible Network у адкрытую, пры падтрымцы супольнасці. Далучайцеся - зазірніце на і вывучыце план развіцця для на старонцы wiki для .
Як мы нядаўна абвясцілі, зараз уключае Ansible Tower, Ansible Engine і ўвесь кантэнт Ansible Network. Цяпер большасць папулярных сеткавых платформаў рэалізуецца праз модулі Ansible. Напрыклад:
- Арыста EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Поўны спіс платформаў, якія цалкам падтрымліваюцца Red Hat праз падпіску Ansible Automation, .
Чаму мы навучыліся
У апошнія чатыры гады мы шмат даведаліся аб распрацоўцы платформы для аўтаматызацыі сеткі. Яшчэ мы даведаліся аб тым, як прымяняюцца артэфакты платформы ў плэйбуках і ролях Ansible з боку канчатковых карыстальнікаў. І вось што мы высветлілі:
- Арганізацыі аўтаматызуюць прылады не аднаго, а шматлікіх вендараў.
- Аўтаматызацыя – з'ява не толькі тэхнічная, але яшчэ і культурная.
- Маштабная аўтаматызацыя сетак складаней, чым здаецца, з-за фундаментальных архітэктурных прынцыпаў праектавання аўтаматызацыі.
Калі мы абмяркоўвалі нашы доўгатэрміновыя планы развіцця больш за год таму, нашы карпаратыўныя кліенты прасілі аб наступным:
- Збор фактаў трэба лепш стандартаваць і ўзгадніць з працоўным працэсам аўтаматызацыі для любых прылад.
- Абнаўленне канфігурацый на прыладзе таксама трэба стандартаваць і ўзгадніць, каб модулі Ansible апрацоўвалі другую палову цыклу пасля збору фактаў.
- Патрэбны строгія і падтрымоўваныя метады пераўтварэння канфігурацыі прылады ў структураваныя дадзеныя. На гэтай аснове крыніца ісціны можна будзе перамясціць з сеткавай прылады.
Паляпшэнні фактаў
Збор фактаў з сеткавых прылад з дапамогай Ansible нярэдка адбываецца наўздагад. Сеткавыя платформы ў рознай ступені абсталяваныя магчымасцямі збору фактаў, але ў іх амаль няма – ці нават зусім няма – функцый для парсінгу і стандартызацыі прадстаўлення дадзеных у парах ключ-значэнне. Чытайце Кена Селенцы (Ken Celenza) аб тым, як складана і пакутліва бывае аналізаваць і стандартаваць дадзеныя фактаў.
Магчыма, вы заўважылі, як мы працавалі над роляй Ansible Network Engine. Натуральна, 24 тысячы загрузак праз ролю Network Engine хутка стала адной з самых папулярных роляў Ansible у Ansible Galaxy для сцэнарыяў аўтаматызацыі сеткі. Перш чым мы перанеслі шмат з гэтага ў Ansible 2.8, каб падрыхтавацца да таго, што спатрэбіцца ў Ansible 2.9, гэтая роля Ansible падала першы набор інструментаў для дапамогі ў парсінгу каманд, кіраванні камандамі і зборы дадзеных для сеткавых прылад.
Калі вы разбіраецеся ў выкарыстанні Network Engine, гэта вельмі эфектыўны спосаб збору, парсінгу і стандартызацыі дадзеных фактаў для выкарыстання ў Ansible. Мінус гэтай ролі ў тым, што трэба ствараць цэлую кучу парсераў для кожнай платформы і для ўсёй сеткавай актыўнасці. Каб зразумець, як складана ствараць, пастаўляць і абслугоўваць парсеры, паглядзіце на ад рабят з Cisco.
У двух словах, для маштабнай аўтаматызацыі вельмі важна атрымліваць факты ад прылад і нармалізаваць іх у пары ключ-значэнне, але дамагчыся гэтага складана, калі ў вас шмат вендараў і сеткавых платформаў.
Кожны модуль фактаў сеткі ў Ansible 2.9 зараз можа аналізаваць канфігурацыю сеткавай прылады і вяртаць структураваныя дадзеныя - без дадатковых бібліятэк, роляў Ansible або кастамных парсераў.
Пачынальна з Ansible 2.9 пры кожным выпуску абноўленага сеткавага модуля модуль фактаў паляпшаецца, каб падаваць дадзеныя аб гэтай частцы канфігурацыі. Гэта значыць развіццё фактаў і модуляў зараз адбываецца ў адным тэмпе, і ў іх заўсёды будзе агульная структура дадзеных.
Канфігурацыю рэсурсаў на сеткавай прыладзе можна атрымаць і пераўтварыць у структураваныя дадзеныя двума спосабамі. Абодва спосабамі можна сабраць і пераўтварыць пэўны спіс рэсурсаў з дапамогай новага ключавога слова gather_network_resources. Імёны рэсурсаў адпавядаюць імёнам модуляў, і гэта вельмі зручна.
Падчас збору фактаў:
З дапамогай ключавога слова gather_facts можна атрымаць бягучую канфігурацыю прылады ў пачатку плэйбука, а потым выкарыстоўваць яе на працягу ўсяго плэйбука. Вызначце асобныя рэсурсы, якія трэба атрымаць з прылады.
- hosts: arista
module_defaults:
eos_facts:
gather_subset: min
gather_network_resources:
- interfaces
gather_facts: TrueВы маглі заўважыць нешта новае ў гэтых прыкладах, а менавіта - gather_facts: true зараз даступна для натыўнага збору фактаў для сеткавых прылад.
Выкарыстанне модуля сеткавых фактаў напрамую:
- name: collect interface configuration facts
eos_facts:
gather_subset: min
gather_network_resources:
- interfacesПлэйбук вяртае наступныя факты аб інтэрфейсе:
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Звярніце ўвагу, як Ansible здабывае натыўную канфігурацыю з прылады Arista і пераўтворыць яе ў структураваныя дадзеныя, каб выкарыстоўваць у выглядзе стандартных пар ключ-значэнне для наступных задач і аперацый.
Факты інтэрфейсу можна дадаць у захоўваемыя зменныя Ansible і выкарыстоўваць адразу ці потым як уваходныя дадзеныя для модуля рэсурсу eos_interfaces без дадатковай апрацоўкі ці пераўтварэнні.
Модулі рэсурсаў
Такім чынам, мы вынялі факты, нармалізавалі дадзеныя, упісалі іх у стандартызаваную ўнутраную схему структуры дадзеных і атрымалі гатовую крыніцу ісціны. Ура! Гэта, вядома, выдатна, але нам па-ранейшаму трэба неяк пераўтварыць пары ключ-значэнне назад у пэўную канфігурацыю, якую чакае канкрэтная платформа прылады. Цяпер нам патрэбныя модулі для пэўных платформаў, каб задаволіць гэтыя новыя патрабаванні збору фактаў і нармалізацыі.
Што такое модуль рэсурса? Часткі канфігурацыі прылады можна ўявіць сабе як рэсурсы, якія прадстаўляюцца гэтай прыладай. Модулі сеткавых рэсурсаў наўмысна абмежаваны адным рэсурсам, і іх можна складаць, як цаглінкі, для наладкі складаных сеткавых сэрвісаў. У выніку патрабаванні і спецыфікацыя для модуля рэсурсу натуральнай выявай спрашчаюцца, бо модуль рэсурсу можа счытваць и наладжваць пэўны сеткавы сэрвіс на сеткавай прыладзе.
Каб растлумачыць, што робіць модуль рэсурсу, давайце паглядзім на прыклад плэйбука, які паказвае ідэмпадэнтную аперацыю з выкарыстаннем новых фактаў сеткавага рэсурсу і модуля. 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Як бачыце, сабраныя з прылады дадзеныя перададзеныя напроста ў які адпавядае модуль рэсурсаў без пераўтварэння. Пры запуску плэйбук здабывае значэння з прылады і параўноўвае іх з чаканымі. У гэтым прыкладзе атрыманыя значэнні адпавядаюць чаканым (гэта значыць выконваецца праверка адхіленняў канфігурацыі) і выдаецца паведамленне, ці змянілася канфігурацыя.
Ідэальны спосаб выявіць адхіленне канфігурацыі - захоўваць факты ў захоўваемыя зменныя Ansible і перыядычна выкарыстоўваць іх разам з модулем рэсурсу ў рэжыме праверкі. Гэта просты метад убачыць, ці не змяніў хто-небудзь значэння ўручную. Часцей за ўсё арганізацыі дазваляюць змены і канфігурацыю ўручную, хоць шматлікія аперацыі выконваюцца праз Ansible Automation.
Чым новыя модулі рэсурса адрозніваюцца ад папярэдніх?
Для інжынера па аўтаматызацыі сетак існуюць 3 галоўныя адрозненні модуляў рэсурсу ў Ansible 2.9 ад папярэдніх версій.
1) Для вызначанага сеткавага рэсурсу (які таксама можна ўявіць сабе як частка канфігурацыі) модулі і факты будуць развівацца ва ўсіх падтрымліваемых сеткавых аперацыйных сістэмах адначасова. Мы думаем, што, калі Ansible падтрымлівае канфігурацыю рэсурса на адной сеткавай платформе, мы павінны падтрымліваць яе ўсюды. Гэта спрашчае выкарыстанне модуляў рэсурсаў, таму што інжынер па аўтаматызацыі сетак зараз можа наладзіць рэсурс (напрыклад, LLDP) ва ўсіх сеткавых аперацыйных сістэмах з натыўнымі і падтрымліваемымі модулямі.
2) Модулі рэсурсаў зараз уключаюць значэнне стану.
merged: канфігурацыя аб'яднана з прадстаўленай канфігурацыяй (па змаўчанні);replaced: канфігурацыя рэсурсу будзе заменена на прадстаўленую канфігурацыю;overridden: канфігурацыя рэсурсу будзе заменена на прадстаўленую канфігурацыю; лішнія экзэмпляры рэсурсаў будуць выдаленыя;deleted: канфігурацыя рэсурсу будзе выдалена/адноўлена па змаўчанні.
3) Модулі рэсурсу зараз уключаюць стабільныя якія вяртаюцца значэння. Калі модуль сеткавага рэсурсу занёс (ці прапанаваў) неабходныя змены ў сеткавай прыладзе, ён вяртае тыя ж пары ключ-значэнне ў плэйбук.
before: канфігурацыя на прыладзе ў выглядзе структураваных дадзеных да задачы;after: калі прылада змянілася (ці можа змяніцца, калі выкарыстоўваецца рэжым праверкі), атрыманая канфігурацыя будзе вернутая ў выглядзе структураваных дадзеных;commands: любыя каманды канфігурацыі, запушчаныя на прыладзе, каб прывесці яго ў жаданае стан.
Што гэта ўсё значыць? Чаму гэта важна?
У гэтым пасце апісваецца шмат складаных канцэпцый, але мы спадзяемся, што ў рэшце рэшт вы лепш зразумееце, што карпаратыўныя кліенты просяць аб зборы фактаў, нармалізацыі даных і канфігурацыі цыкла для платформы аўтаматызацыі. Але чаму ім патрэбны гэтыя паляпшэнні? Цяпер шматлікія арганізацыі займаюцца лічбавай трансфармацыяй, каб зрабіць свае ІТ-асяроддзі больш гнуткімі і канкурэнтаздольнымі. Добра гэта ці дрэнна, але многія сеткавыя інжынеры становяцца сеткавымі распрацоўшчыкамі - з уласнай цікавасці або па загадзе кіраўнікоў.
Арганізацыі разумеюць, што аўтаматызацыя асобных сеткавых шаблонаў не вырашае праблему разрозненасці і павялічвае эфектыўнасць толькі да вызначанай мяжы. Платформа Red Hat Ansible Automation Platform дае строгія і нармуючыя мадэлі дадзеных рэсурсаў, каб праграмна кіраваць базавымі дадзенымі на сеткавым прыладзе. Гэта значыць карыстачы паступова адмаўляюцца ад індывідуальных спосабаў канфігурацыі ў карысць больш сучасных метадаў з акцэнтам на тэхналогіях (напрыклад, IP-адрасы, VLAN, LLDP і т д.), а не на пэўнай рэалізацыі вендара.
Ці значыць гэта, што дні надзейных і правераных модуляў каманд і канфігурацыі палічаныя? Ні ў якім разе. Чаканыя модулі сеткавых рэсурсаў будуць дастасавальныя не ва ўсіх выпадках і не для кожнага вендара, так што модулі каманд і канфігурацыі яшчэ спатрэбяцца сеткавым інжынерам для вызначаных рэалізацый. Мэта модуляў рэсурсаў - спрасціць вялікія шаблоны Jinja і нармалізаваць неструктураваныя канфігурацыі прылады ў структураваны фармат JSON. З модулямі рэсурсаў існуючым сеткам будзе прасцей пераўтвараць сваю канфігурацыю ў структураваныя пары ключ-значэнне, якія будуць уяўляць сабой зручную для чытання крыніцу ісціны. Калі выкарыстоўваць структураваныя пары ключ-значэнне, можна перайсці ад запуску канфігурацый на кожным прыладзе да працы з незалежнымі структураванымі дадзенымі і вывесці сеткі на першы план пры падыходзе "інфраструктура як код".
Якія модулі рэсурсаў з'явяцца ў Ansible Engine 2.9?
Перш чым падрабязна расказаць, што будзе ў Ansible 2.9, давайце ўспомнім, як мы падзялілі ўвесь аб'ём работ.
Мы вылучылі 7 катэгорый і кожнай прызначылі пэўныя сеткавыя рэсурсы:
Заўвага: рэсурсы, выдзеленыя тоўстым, былі запланаваны і рэалізаваны ў Ansible 2.9.
На аснове водгукаў ад карпаратыўных кліентаў і супольнасці лагічна было спачатку заняцца тымі модулямі, якія злучаны з пратаколамі тапалогіі сеткі, віртуалізацыяй і інтэрфейсамі.
Наступныя модулі рэсурсаў распрацаваны камандай Ansible Network і адпавядаюць платформам, якія падтрымлівае Red Hat:
Наступныя модулі распрацаваны супольнасцю Ansible:
exos_lldp_global- Ад Extreme Networks.nxos_bfd_interfaces- ад Cisconxos_telemetry- ад Cisco
Як бачыце, канцэпцыя модуляў рэсурсаў упісваецца ў нашу стратэгію арыентацыі на платформы. Гэта значыць мы ўключаем неабходныя магчымасці і функцыі ў сам Ansible, каб падтрымаць стандартызацыю пры распрацоўцы сеткавых модуляў, а яшчэ спрасціць працу карыстачоў на ўзроўні роляў і плэйбукаў Ansible. Каб пашырыць распрацоўку модуляў рэсурсаў, каманда Ansible выпусціла прыладу Module Builder.
Планы на Ansible 2.10 і надалей
Пасля выпуску Ansible 2.9 мы зоймемся наступным наборам модуляў рэсурсаў для Ansible 2.10, якія можна будзе выкарыстоўваць для далейшай налады тапалогіі і палітыкі сеткі, напрыклад . План развіцця яшчэ можна карэктаваць, так што, калі ў вас ёсць каментары, паведаміце аб гэтым у .
Рэсурсы і пачатак працы
Крыніца: habr.com