Red Hat Ansible Engine 2.9-ийн удахгүй гарах хувилбар нь сэтгэл хөдөлгөм сайжруулалтыг авчирсан бөгөөд эдгээрийн заримыг энэ нийтлэлд авч үзэх болно. Бид урьдын адил олон нийтийн дэмжлэгтэйгээр Ansible Network-ийн сайжруулалтыг нээлттэй хөгжүүлсээр ирсэн. Бидэнтэй нэгдээрэй - үзээрэй болон хөгжлийн төлөвлөгөөг судлах вики хуудсан дээр .
Бидний саяхан зарласнаар, одоо Ansible Tower, Ansible Engine болон бүх Ansible Network агуулгыг багтаасан болно. Өнөө үед хамгийн алдартай сүлжээний платформуудыг Ansible модулиар дамжуулан хэрэгжүүлж байна. Жишээлбэл:
- Arista EOS
- Cisco IOS
- Cisco IOS XR
- Cisco NX-OS
- Juniper Junos
- VyOS
Red Hat-ийн Ansible Automation-н захиалгаар бүрэн дэмждэг платформуудын бүрэн жагсаалтыг авахын тулд, .
Бид юу сурсан
Өнгөрсөн дөрвөн жилийн хугацаанд бид сүлжээний автоматжуулалтын платформыг хөгжүүлэх талаар маш их зүйлийг сурсан. Бид бас үүнийг сурсан хэрхэн платформын олдворуудыг Ansible тоглоомын номонд ашигладаг бөгөөд эцсийн хэрэглэгчид үүрэг гүйцэтгэдэг. Эндээс бидний олж мэдсэн зүйл:
- Байгууллагууд нь зөвхөн нэг төдийгүй олон үйлдвэрлэгчийн төхөөрөмжийг автоматжуулж байна.
- Автоматжуулалт нь зөвхөн техникийн үзэгдэл төдийгүй соёлын үзэгдэл юм.
- Сүлжээг масштабаар автоматжуулах нь автоматжуулалтын дизайны үндсэн архитектурын зарчмуудын улмаас санагдахаас илүү хэцүү байдаг.
Жил гаруйн өмнө бид урт хугацааны өсөлтийн төлөвлөгөөгөө хэлэлцэх үед манай компанийн үйлчлүүлэгчид дараахь зүйлийг хүссэн.
- Баримт цуглуулгыг илүү сайн стандартчилж, бүх төхөөрөмж дээрх автоматжуулалтын ажлын урсгалтай уялдуулах шаардлагатай.
- Төхөөрөмж дээрх тохиргоог шинэчлэх нь мөн стандартчилагдсан, тууштай байх шаардлагатай бөгөөд ингэснээр Ansible модулиуд баримт цуглуулсны дараа мөчлөгийн хоёр дахь хагасыг зохицуулдаг.
- Бидэнд төхөөрөмжийн тохиргоог бүтэцлэгдсэн өгөгдөл болгон хувиргах нарийн бөгөөд дэмжигдсэн аргууд хэрэгтэй. Үүний үндсэн дээр үнэний эх сурвалжийг сүлжээний төхөөрөмжөөс шилжүүлж болно.
Бодит сайжруулалт
Ansible ашиглан сүлжээний төхөөрөмжөөс баримт цуглуулах нь ихэвчлэн санамсаргүй байдлаар тохиолддог. Вэб дээр суурилсан платформууд нь янз бүрийн түвшний баримт цуглуулах чадвартай боловч түлхүүр-утга хосолсон өгөгдлийг задлан шинжлэх, стандартчилах функц бага эсвэл огт байхгүй. Унших Кен Селенза бодит мэдээлэлд дүн шинжилгээ хийж, стандартчилах нь хичнээн хэцүү, зовлонтой байдгийн талаар.
Та биднийг Ansible Network Engine дүр дээр ажиллаж байгааг анзаарсан байх. Мэдээжийн хэрэг, дараа нь 24K татагдсанаар Сүлжээний хөдөлгүүрийн үүрэг нь сүлжээний автоматжуулалтын хувилбаруудад зориулсан Ansible Galaxy-ийн хамгийн алдартай Ansible дүрүүдийн нэг болсон. Бид 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: Ethernet1Ansible хэрхэн Arista төхөөрөмжөөс эх тохиргоог авч, түүнийг даалгаврууд болон үйл ажиллагаанд стандарт түлхүүр-утга хос болгон ашиглахын тулд бүтэцлэгдсэн өгөгдөл болгон хувиргаж байгааг анзаараарай.
Интерфэйсийн баримтуудыг Ansible-д хадгалагдсан хувьсагчдад нэмж, нэн даруй эсвэл дараа нь нөөцийн модулийн оролт болгон ашиглаж болно. eos_interfaces нэмэлт боловсруулалт, хөрвүүлэлтгүйгээр.
Нөөцийн модулиуд
Тиймээс бид баримтуудыг гаргаж авч, өгөгдлийг хэвийн болгож, тэдгээрийг стандартчилсан дотоод өгөгдлийн бүтцийн диаграммд оруулж, үнэний бэлэн эх сурвалжтай болсон. Өө! Энэ нь мэдээжийн хэрэг гайхалтай, гэхдээ бид ямар нэгэн байдлаар түлхүүр-утга хосыг төхөөрөмжийн тодорхой платформын хүлээгдэж буй тохиргоонд буцааж хөрвүүлэх шаардлагатай хэвээр байна. Эдгээр шинэ баримт цуглуулах, хэвийн болгох шаардлагыг хангахын тулд бидэнд одоо платформд зориулсан модулиуд хэрэгтэй байна.
Нөөцийн модуль гэж юу вэ? Та төхөөрөмжийн тохиргооны хэсгүүдийг тухайн төхөөрөмжөөс өгсөн нөөц гэж үзэж болно. Сүлжээний эх үүсвэрийн модулиуд нь нэг нөөцөөр зориудаар хязгаарлагддаг бөгөөд сүлжээний нарийн төвөгтэй үйлчилгээг тохируулахын тулд барилгын блокууд шиг давхарлаж болно. Үүний үр дүнд нөөцийн модуль унших боломжтой тул нөөцийн модульд тавигдах шаардлага, техникийн үзүүлэлтүүд нь аяндаа хялбаршуулсан болно. и сүлжээний төхөөрөмж дээр тодорхой сүлжээний үйлчилгээг тохируулах.
Нөөцийн модуль юу хийдэгийг тайлбарлахын тулд шинэ сүлжээний нөөцийн баримтууд болон модулийг ашиглан idempodent үйлдлийг харуулсан жишээ тоглоомыг харцгаая. 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-ээр дамжуулан олон үйлдлийг гүйцэтгэдэг ч гараар өөрчлөх, тохируулахыг зөвшөөрдөг.
Шинэ нөөцийн модулиуд өмнөхөөсөө юугаараа ялгаатай вэ?
Сүлжээний автоматжуулалтын инженерийн хувьд Ansible 3 болон өмнөх хувилбаруудын нөөцийн модулиудын хооронд 2.9 үндсэн ялгаа байдаг.
1) Өгөгдсөн сүлжээний нөөцийн хувьд (үүнийг тохиргооны хэсэг гэж үзэж болно) модулиуд болон баримтууд нь дэмжигдсэн бүх сүлжээний үйлдлийн системд нэгэн зэрэг хөгжинө. Хэрэв Ansible нэг сүлжээний платформ дээр нөөцийн тохиргоог дэмждэг бол бид үүнийг хаа сайгүй дэмжих ёстой гэж бид бодож байна. Сүлжээний автоматжуулалтын инженер одоо эх болон дэмжигдсэн модулиуд бүхий бүх сүлжээний үйлдлийн системүүд дээрх нөөцийг (LLDP гэх мэт) тохируулах боломжтой тул энэ нь нөөцийн модулиудын хэрэглээг хялбаршуулдаг.
2) Нөөцийн модулиуд нь төлөвийн утгыг агуулж байна.
merged: тохиргоог өгсөн тохиргоотой нэгтгэсэн (анхдагч);replaced: Нөөцийн тохиргоог өгсөн тохиргоогоор солих болно;overridden: Нөөцийн тохиргоог өгсөн тохиргоогоор солих болно; шаардлагагүй нөөцийн тохиолдлууд устах болно;deleted: Нөөцийн тохиргоо устгагдах/өгөгдмөл байдалд сэргээгдэх болно.
3) Нөөцийн модулиуд одоо тогтвортой өгөөжийн утгыг агуулдаг. Сүлжээний эх үүсвэрийн модуль нь сүлжээний төхөөрөмжид шаардлагатай өөрчлөлтүүдийг хийсэн (эсвэл санал болгосон) үед энэ нь ижил түлхүүр-утга хосыг тоглоомын дэвтэрт буцаана.
before: даалгаврын өмнө бүтэцлэгдсэн өгөгдлийн хэлбэрээр төхөөрөмж дээрх тохиргоо;after: хэрэв төхөөрөмж өөрчлөгдсөн бол (эсвэл туршилтын горим ашиглаж байгаа бол өөрчлөгдөж магадгүй) үүссэн тохиргоог бүтэцлэгдсэн өгөгдөл болгон буцаана;commands: Төхөөрөмжийг хүссэн төлөвт оруулахын тулд аливаа тохиргооны командууд төхөөрөмж дээр ажиллана.
Энэ бүхэн юу гэсэн үг вэ? Яагаад чухал вэ?
Энэ нийтлэлд маш олон нарийн төвөгтэй ойлголтуудыг багтаасан байгаа боловч эцэст нь та автоматжуулалтын платформын цуглуулга, өгөгдлийг хэвийн болгох, давталтын тохиргоог хийх гэж байгаа аж ахуйн нэгжийн үйлчлүүлэгчид юу хүсч байгааг илүү сайн ойлгох болно гэж найдаж байна. Гэхдээ яагаад эдгээр сайжруулалт тэдэнд хэрэгтэй байна вэ? Одоо олон байгууллага мэдээллийн технологийн орчноо илүү уян хатан, өрсөлдөх чадвартай болгохын тулд дижитал өөрчлөлтийг хийж байна. Сайн ч бай, муу ч бай, олон сүлжээний инженерүүд хувийн ашиг сонирхлоор эсвэл удирдлагын захиалгаар сүлжээ хөгжүүлэгч болдог.
Сүлжээний бие даасан загваруудыг автоматжуулах нь силосны асуудлыг шийдэхгүй бөгөөд зөвхөн үр ашгийг тодорхой хэмжээгээр нэмэгдүүлдэг гэдгийг байгууллагууд ойлгож байна. Red Hat Ansible Automation Platform нь сүлжээний төхөөрөмж дээрх үндсэн өгөгдлийг программчлан удирдахын тулд нарийн бөгөөд норматив нөөцийн өгөгдлийн загваруудыг өгдөг. Өөрөөр хэлбэл, хэрэглэгчид бие даасан тохиргооны аргуудаас аажмаар татгалзаж, тодорхой үйлдвэрлэгчийн хэрэгжилтээс илүү технологид (жишээ нь, IP хаяг, VLAN, LLDP гэх мэт) анхаарлаа хандуулж, илүү орчин үеийн аргууд руу шилжиж байна.
Энэ нь найдвартай, батлагдсан тушаалын модулиуд болон тохиргооны өдрүүдийг дугаарласан гэсэн үг үү? Ямар ч тохиолдолд. Хүлээгдэж буй сүлжээний нөөцийн модулиуд нь бүх тохиолдолд эсвэл үйлдвэрлэгч бүрт тохирохгүй тул команд болон тохиргооны модулиуд нь сүлжээний инженерүүдэд тодорхой хэрэгжилтэд шаардлагатай хэвээр байх болно. Нөөцийн модулиудын зорилго нь том Жинжа загваруудыг хялбарчилж, бүтэцгүй төхөөрөмжийн тохиргоог 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- Cisco-аасnxos_telemetry- Cisco-аас
Таны харж байгаагаар нөөцийн модулиудын үзэл баримтлал нь манай платформ төвтэй стратегид нийцэж байна. Өөрөөр хэлбэл, бид сүлжээний модулиудыг хөгжүүлэх стандартчиллыг дэмжих, мөн Ansible-ийн үүрэг, тоглоомын дэвтрийн түвшинд хэрэглэгчдийн ажлыг хялбаршуулахын тулд шаардлагатай чадавхи, функцуудыг Ansible-д багтаасан болно. Нөөцийн модулиудын хөгжлийг өргөжүүлэхийн тулд Ansible баг Module Builder хэрэгслийг гаргасан.
Ansible 2.10 ба түүнээс дээш хувилбаруудын төлөвлөгөө
Ansible 2.9-ийг гаргасны дараа бид Ansible 2.10-д зориулсан нөөцийн модулиудын дараагийн багц дээр ажиллах бөгөөд үүнийг сүлжээний топологи болон бодлогыг цаашид тохируулахад ашиглаж болно, жишээ нь. . Хөгжлийн төлөвлөгөөг өөрчлөх боломжтой хэвээр байгаа тул санал хүсэлт байвал мэдэгдэнэ үү .
Нөөц ба эхлэл
Эх сурвалж: www.habr.com