Энэ нийтлэл нь "Сүлжээний дэд бүтцээ хэрхэн хянах вэ" цувралын зургаа дахь нийтлэл юм. Цуврал дахь бүх нийтлэлийн агуулга, холбоосыг олж болно .
Хэд хэдэн сэдвийг ардаа орхиод шинэ бүлгийг эхлүүлэхээр шийдлээ.
Би хэсэг хугацааны дараа хамгаалалтад буцаж ирнэ. Энд би энгийн боловч үр дүнтэй арга барилын талаар ярихыг хүсч байна, энэ нь нэг хэлбэрээр эсвэл өөр хэлбэрээр олон хүнд хэрэг болно гэдэгт итгэлтэй байна. Энэ бол автоматжуулалт нь инженерийн амьдралыг хэрхэн өөрчилж чадах тухай богино өгүүллэг юм. Бид загваруудыг ашиглах талаар ярих болно. Төгсгөлд нь миний төслүүдийн жагсаалт байгаа бөгөөд энд тайлбарласан бүх зүйл хэрхэн ажилладагийг харж болно.
Сүлжээнд зориулсан DevOps
Скрипт ашиглан тохиргоо хийх, мэдээллийн технологийн дэд бүтцэд гарсан өөрчлөлтийг хянахын тулд GIT ашиглах, алсаас "байршуулах" - эдгээр санаанууд нь DevOps аргын техникийн хэрэгжилтийн талаар бодоход хамгийн түрүүнд гарч ирдэг. Давуу тал нь ойлгомжтой. Гэхдээ харамсалтай нь сул талууд бас бий.
5 гаруй жилийн өмнө манай хөгжүүлэгчид сүлжээнийхэн бидэнд ийм санал тавихад бид баярласангүй.
Бид 10 орчим өөр үйлдвэрлэгчдийн тоног төхөөрөмжөөс бүрдсэн нэлээд олон төрлийн сүлжээг өвлөн авсан гэдгийг би хэлэх ёстой. Бидний дуртай cli-ээр дамжуулан зарим зүйлийг тохируулах нь тохиромжтой байсан ч заримд нь бид GUI ашиглахыг илүүд үзсэн. Нэмж дурдахад, "амьд" төхөөрөмж дээр удаан ажилласан нь бидэнд бодит цагийн хяналтыг зааж өгсөн. Жишээлбэл, өөрчлөлт хийх үед би cli-ээр шууд ажиллахад илүү таатай санагддаг. Ингэснээр би ямар нэг зүйл буруу болсныг хурдан харж, өөрчлөлтүүдийг буцаах болно. Энэ бүхэн тэдний санаатай зөрчилдөж байв.
Бусад асуултууд гарч ирдэг, жишээлбэл, интерфэйс нь програмын хувилбараас хувилбар руу бага зэрэг өөрчлөгдөж болно. Энэ нь эцэстээ таны скриптийг буруу "тохиргоо" үүсгэхэд хүргэнэ. Би үйлдвэрлэлийг “гүйж” ашиглахыг хүсэхгүй байна.
Эсвэл тохиргооны командуудыг зөв ашигласан гэдгийг яаж ойлгох вэ, алдаа гарсан тохиолдолд яах вэ?
Энэ бүх асуудлыг шийдэх боломжгүй гэж хэлмээргүй байна. Зүгээр л "А" гэж хэлэх нь "B" гэж хэлэх нь утга учиртай бөгөөд хэрэв та өөрчлөлтийг хянах процессыг хөгжүүлэлттэй адил ашиглахыг хүсвэл үйлдвэрлэлээс гадна хөгжүүлэлт, үе шаттай орчинтой байх хэрэгтэй. Дараа нь энэ арга нь бүрэн дүүрэн харагдаж байна. Гэхдээ энэ нь хэр их зардал гарах вэ?
Гэхдээ сул талуудыг бараг тэгшлээд, зөвхөн давуу тал нь үлддэг нэг нөхцөл байдал бий. Би дизайны ажлын талаар ярьж байна.
Төсөл
Сүүлийн хоёр жил би томоохон үйлчилгээ үзүүлэгчийн дата төв барих төсөлд оролцож байна. Би энэ төсөлд F5 болон Palo Alto-г хариуцдаг. Cisco-ийн үүднээс авч үзвэл энэ нь "гуравдагч талын тоног төхөөрөмж" юм.
Миний хувьд энэ төсөл хоёр өөр үе шаттай.
Эхний шат
Эхний жил би эцэс төгсгөлгүй завгүй байсан, би шөнө, амралтын өдрүүдээр ажилладаг байсан. Би толгойгоо өндийлгөж чадсангүй. Удирдлага болон үйлчлүүлэгчийн дарамт шахалт хүчтэй бөгөөд тасралтгүй байсан. Тогтмол горимд би үйл явцыг оновчтой болгохыг оролдож ч чадаагүй. Энэ нь зөвхөн тоног төхөөрөмжийн тохиргоо төдийгүй дизайны баримт бичгийг бэлтгэх явдал байв.
Эхний туршилтууд эхэлсэн бөгөөд хичнээн жижиг алдаа, алдаа гарсныг би гайхах болно. Мэдээж бүх зүйл бүтсэн, гэхдээ нэрэнд нь үсэг дутуу, тушаалд дутуу мөр байна... Туршилтууд үргэлжилсээр, би алдаа, шалгалт, бичиг баримттай байнга, өдөр бүр тэмцэлдэж байсан. .
Энэ нь нэг жил үргэлжилсэн. Төсөл нь миний ойлгож байгаагаар хүн бүрт амаргүй байсан ч аажмаар үйлчлүүлэгч улам бүр сэтгэл ханамжтай болж, энэ нь ердийн ажлын нэг хэсгийг өөрсдөө хийх боломжтой нэмэлт инженерүүдийг ажилд авах боломжтой болсон.
Одоо бид эргэн тойрноо бага зэрэг харж болно.
Мөн энэ нь хоёр дахь шатны эхлэл байсан юм.
Хоёрдугаар шат
Би үйл явцыг автоматжуулахаар шийдсэн.
Тухайн үед хөгжүүлэгчидтэй харилцахдаа миний ойлгосон зүйл бол (мөн бид хүндэтгэл үзүүлэх ёстой, бид хүчирхэг багтай байсан) текстийн формат нь эхлээд харахад DOS үйлдлийн системийн ертөнцөөс ямар нэгэн зүйл мэт санагдах боловч хэд хэдэн тоотой байдаг. үнэ цэнэтэй эд хөрөнгийн .
Жишээлбэл, хэрэв та GIT болон түүний бүх деривативуудыг бүрэн ашиглахыг хүсч байвал текстийн формат хэрэгтэй болно. Тэгээд би хүссэн.
За, та зүгээр л тохиргоо эсвэл тушаалын жагсаалтыг хадгалах боломжтой юм шиг санагдаж байна, гэхдээ өөрчлөлт хийх нь нэлээд тохиромжгүй юм. Үүнээс гадна дизайны явцад өөр нэг чухал ажил байдаг. Та өөрийн дизайныг бүхэлд нь (Бага түвшний дизайн) болон тодорхой хэрэгжилтийг (Сүлжээний хэрэгжилтийн төлөвлөгөө) тодорхойлсон баримт бичигтэй байх ёстой. Мөн энэ тохиолдолд загвар ашиглах нь маш тохиромжтой сонголт мэт харагдаж байна.
Тиймээс YAML болон Jinja2-г ашиглахдаа IP хаяг, BGP AS дугаар, ... зэрэг тохиргооны параметр бүхий YAML файл нь NIP-ийн үүргийг төгс гүйцэтгэдэг бол Jinja2 загварууд нь дизайнтай тохирох синтаксийг агуулдаг, өөрөөр хэлбэл энэ нь үндсэндээ LLD-ийн тусгал.
YAML болон Jinja2-г сурахад хоёр өдөр зарцуулсан. Энэ нь хэрхэн ажилладагийг ойлгоход цөөн хэдэн сайн жишээ хангалттай. Дараа нь манай загварт тохирсон бүх загварыг бүтээхэд хоёр долоо хоног зарцуулсан: Пало Алто долоо хоног, F5-д өөр долоо хоног. Энэ бүгдийг корпорацийн githab дээр нийтэлсэн.
Одоо өөрчлөлтийн үйл явц дараах байдалтай байв.
- YAML файлыг өөрчилсөн
- загвар ашиглан тохиргооны файл үүсгэсэн (Jinja2)
- алсын хадгалах санд хадгалагдсан
- үүсгэсэн тохиргоог төхөөрөмжид байршуулсан
- Би алдаа харсан
- YAML файл эсвэл Jinja2 загварыг өөрчилсөн
- загвар ашиглан тохиргооны файл үүсгэсэн (Jinja2)
- ...
Эхэндээ засварлахад маш их цаг зарцуулсан нь ойлгомжтой боловч долоо хоногоос хоёр долоо хоногийн дараа энэ нь ховор зүйл болсон.
Сайн тест, бүх зүйлийг дибаг хийх боломж бол үйлчлүүлэгчийн нэрлэх конвенцийг өөрчлөх хүсэл байв. F5-тай ажиллаж байсан хүмүүс нөхцөл байдлын хурцадмал байдлыг ойлгодог. Гэхдээ миний хувьд бүх зүйл маш энгийн байсан. Би YAML файлын нэрийг сольж, тоног төхөөрөмжөөс бүх тохиргоог устгаж, шинээр үүсгэж, байршуулсан. Алдаа засах гэх мэт бүх зүйл 4 хоног зарцуулагдсан: технологи тус бүрт хоёр өдөр. Үүний дараа би дараагийн шатанд, тухайлбал DEV болон Staging мэдээллийн төвүүдийг бий болгоход бэлэн болсон.
Хөгжүүлэгч ба Тайз
Тайз нь үйлдвэрлэлийг бүрэн хуулбарладаг. Dev бол үндсэндээ виртуал техник хангамж дээр бүтээгдсэн, нэлээд задарсан хуулбар юм. Шинэ хандлагад тохиромжтой нөхцөл байдал. Хэрэв би зарцуулсан цагаа ерөнхий үйл явцаас тусгаарлах юм бол ажил 2 долоо хоногоос илүүгүй хугацаа шаардагдана гэж бодож байна. Гол цаг нь нөгөө талыг хүлээж, хамтдаа асуудлаа хайх явдал юм. Гуравдагч этгээдийн хэрэгжилт бусдад бараг анзаарагдсангүй. Хабрегийн талаар ямар нэгэн зүйл сурч, хэд хэдэн нийтлэл бичих цаг хүртэл байсан :)
Дүгнэж хэлье
Тэгэхээр, надад эцсийн дүндээ юу байна вэ?
- Тохиргоог өөрчлөхийн тулд миний хийх ёстой зүйл бол тохиргооны параметр бүхий энгийн, тодорхой бүтэцтэй YAML файлыг өөрчлөх явдал юм. Би python скриптийг хэзээ ч сольдоггүй бөгөөд маш ховор (алдаа гарсан тохиолдолд) Jinja2 халаагуурыг өөрчилдөг.
- Баримт бичгийн үүднээс авч үзвэл энэ нь бараг тохиромжтой нөхцөл юм. Та баримт бичгийг өөрчилж (YAML файлууд NIP байдлаар үйлчилдэг) энэ тохиргоог төхөөрөмжид байршуулна. Ингэснээр таны бичиг баримт үргэлж шинэчлэгдэнэ
Энэ бүхэн ийм байдалд хүргэсэн
- алдааны түвшин бараг 0 болж буурсан
- Ердийн ажлын 90 хувь нь алга болсон
- хэрэгжүүлэх хурд ихээхэн нэмэгдсэн
PAY, F5Y, ACY
Энэ нь хэрхэн ажилладагийг ойлгоход цөөн хэдэн жишээ хангалттай гэж би хэлсэн.
Миний ажлын явцад бүтээгдсэн зүйлийн товч (мэдээж өөрчилсөн) хувилбар энд байна.
= байршуулалт PАло A-аас Yaml = Yaml-аас Пало Алто
= байршуулалт F5 нь Yaml = F5 нь Yaml (удалгүй ирнэ)
= байршуулалт ACби-аас Yaml = F5 нь YJR
Би ACY-ийн талаар хэдэн үг хэлье (ACI-тай андуурч болохгүй).
ACI-тэй ажиллаж байсан хүмүүс энэ гайхамшгийг (мөн сайн байдлаар) сүлжээнийхэн бүтээгээгүй гэдгийг мэддэг :). Сүлжээний талаар мэддэг бүх зүйлээ март - энэ нь танд хэрэг болохгүй!
Энэ нь бага зэрэг хэтрүүлсэн боловч сүүлийн 3 жилийн турш ACI-тай хамтран ажиллаж байсан миний мэдрэмжийг бараг л илэрхийлж байна.
Мөн энэ тохиолдолд ACY нь өөрчлөлтийн хяналтын үйл явцыг бий болгох боломж төдийгүй (энэ нь ACI-ийн хувьд онцгой чухал, учир нь энэ нь таны мэдээллийн төвийн гол бөгөөд хамгийн чухал хэсэг байх ёстой) мөн танд өгөх боломжийг олгодог. тохиргоог бий болгох хэрэглэгчдэд ээлтэй интерфэйс.
Энэ төслийн инженерүүд яг ижил зорилгоор YAML-ийн оронд ACI-г тохируулахын тулд Excel ашигладаг. Excel ашиглах нь мэдээжийн хэрэг давуу талуудтай:
- Таны NIP нэг файлд
- үйлчлүүлэгчид харахад таатай сайхан тэмдэг
- Та excel-ийн зарим хэрэгслийг ашиглаж болно
Гэхдээ нэг хасах зүйл байгаа бөгөөд миний бодлоор энэ нь давуу талуудаас илүү юм. Өөрчлөлтийг хянах, багийн ажлыг зохицуулах нь илүү хэцүү болдог.
ACY нь үнэндээ миний гуравдагч этгээдэд ACI-г тохируулахын тулд ашигласан арга барилын хэрэглүүр юм.
Эх сурвалж: www.habr.com