Šis ir sestais raksts sērijā “Kā pārņemt kontroli pār savu tīkla infrastruktūru”. Visu sērijas rakstu saturu un saites var atrast .
Atstājot aiz muguras vairākas tēmas, nolēmu sākt jaunu nodaļu.
Es atgriezīšos apsardzē nedaudz vēlāk. Šeit es vēlos apspriest vienu vienkāršu, bet efektīvu pieeju, kas, esmu pārliecināta, vienā vai otrā veidā var būt noderīga daudziem. Šis drīzāk ir īss stāsts par to, kā automatizācija var mainīt inženiera dzīvi. Mēs runāsim par veidņu izmantošanu. Beigās ir manu projektu saraksts, kurā var redzēt, kā viss šeit aprakstītais darbojas.
DevOps tīklam
Konfigurācijas izveide ar skriptu, GIT izmantošana IT infrastruktūras izmaiņu kontrolei, attālināta “augšupielāde” – šīs idejas rodas pirmajā vietā, domājot par DevOps pieejas tehnisko ieviešanu. Priekšrocības ir acīmredzamas. Bet diemžēl ir arī trūkumi.
Kad pirms vairāk nekā 5 gadiem mūsu izstrādātāji vērsās pie mums, tīkla speciālistiem, ar šiem priekšlikumiem, mēs nebijām sajūsmā.
Man jāsaka, ka mēs mantojām diezgan raibu tīklu, kas sastāv no aptuveni 10 dažādu pārdevēju aprīkojuma. Dažas lietas bija ērti konfigurēt, izmantojot mūsu iecienītāko klip, bet citās mēs izvēlējāmies izmantot GUI. Turklāt ilgs darbs pie “dzīvā” aprīkojuma mums ir iemācījis kontrolēt reāllaika vadību. Piemēram, veicot izmaiņas, es jūtos daudz ērtāk, strādājot tieši caur kli. Tādā veidā es varu ātri redzēt, ka kaut kas nogāja greizi, un atsaukt izmaiņas. Tas viss bija zināmā pretrunā ar viņu idejām.
Rodas arī citi jautājumi, piemēram, saskarne var nedaudz mainīties dažādās programmatūras versijās. Tas galu galā liks jūsu skriptam izveidot nepareizu "konfigurāciju". Es negribētu izmantot ražošanu “ieskriešanai”.
Vai arī kā saprast, ka konfigurācijas komandas tika lietotas pareizi un ko darīt kļūdas gadījumā?
Es negribu teikt, ka visas šīs problēmas ir neatrisināmas. Vienkārši sakot “A”, iespējams, ir jēga teikt arī “B”, un, ja vēlaties izmaiņu kontrolei izmantot tos pašus procesus, ko izstrādē, tad papildus ražošanai ir nepieciešama arī izstrādes un iestudēšanas vide. Tad šī pieeja izskatās pabeigta. Bet cik tas maksās?
Bet ir viena situācija, kad mīnusi praktiski tiek izlīdzināti, un paliek tikai plusi. Es runāju par projektēšanas darbiem.
Projekts
Pēdējos divus gadus esmu piedalījies projektā, lai izveidotu datu centru lielam pakalpojumu sniedzējam. Šajā projektā esmu atbildīgs par F5 un Palo Alto. No Cisco viedokļa tas ir “trešās puses aprīkojums”.
Man personīgi šajā projektā ir divi atšķirīgi posmi.
Pirmais posms
Pirmajā gadā es biju bezgala aizņemts, strādāju naktīs un nedēļas nogalēs. Es nevarēju pacelt galvu. Vadības un klienta spiediens bija spēcīgs un nepārtraukts. Pastāvīgā rutīnā es pat nevarēju mēģināt optimizēt procesu. Tā bija ne tikai un ne tik daudz iekārtu konfigurēšana, cik projekta dokumentācijas sagatavošana.
Pirmie testi ir sākušies, un es būtu pārsteigts, cik daudz tika pieļautas nelielas kļūdas un neprecizitātes. Protams, viss darbojās, bet nosaukumā trūka burta, komandā trūka rinda... Testi turpinājās un turpinājās, un es jau biju nemitīgā, ikdienas cīņā ar kļūdām, testiem un dokumentāciju. .
Tas turpinājās gadu. Projekts, cik saprotu, nebija viegls visiem, taču pamazām klients kļuva arvien apmierinātāks, un tas ļāva nolīgt papildu inženierus, kuri paši varēja uzņemties daļu no rutīnas.
Tagad mēs varētu mazliet paskatīties apkārt.
Un tas bija otrā posma sākums.
Otrais posms
Es nolēmu automatizēt procesu.
Tas, ko es sapratu no toreizējās komunikācijas ar izstrādātājiem (un mums ir jāizsaka atzinība, mums bija spēcīga komanda), ir tas, ka teksta formātam, lai gan pirmajā mirklī šķiet kaut kas no DOS operētājsistēmas pasaules, ir numurs vērtīgām īpašībām.
Tātad, piemēram, teksta formāts būs noderīgs, ja vēlaties pilnībā izmantot GIT un visus tā atvasinājumus. Un es gribēju.
Šķiet, ka jūs varat vienkārši saglabāt konfigurāciju vai komandu sarakstu, taču izmaiņu veikšana ir diezgan neērta. Turklāt projektēšanas laikā ir vēl viens svarīgs uzdevums. Jums ir jābūt dokumentācijai, kas apraksta jūsu dizainu kopumā (zema līmeņa dizains) un konkrētu ieviešanu (tīkla ieviešanas plāns). Un šajā gadījumā veidņu izmantošana izskatās ļoti piemērota iespēja.
Tātad, izmantojot YAML un Jinja2, YAML fails ar tādiem konfigurācijas parametriem kā IP adreses, BGP AS numuri, ... lieliski pilda NIP lomu, savukārt Jinja2 veidnēs ir iekļauta dizainam atbilstoša sintakse, tas ir, būtībā tas ir LLD atspoguļojums.
Bija vajadzīgas divas dienas, lai apgūtu YAML un Jinja2. Pietiek ar dažiem labiem piemēriem, lai saprastu, kā tas darbojas. Pēc tam bija vajadzīgas apmēram divas nedēļas, lai izveidotu visas mūsu dizainam atbilstošās veidnes: nedēļu Palo Alto un vēl vienu nedēļu F5. Tas viss tika ievietots korporatīvajā githab.
Tagad izmaiņu process izskatījās šādi:
- mainīja YAML failu
- izveidoja konfigurācijas failu, izmantojot veidni (Jinja2)
- saglabāts attālā repozitorijā
- augšupielādēja izveidoto konfigurāciju iekārtā
- Es redzēju kļūdu
- mainīja YAML failu vai Jinja2 veidni
- izveidoja konfigurācijas failu, izmantojot veidni (Jinja2)
- ...
Skaidrs, ka sākumā daudz laika tika veltīts labojumiem, bet pēc nedēļas vai divām tas kļuva diezgan retums.
Labs tests un iespēja visu atkļūdot bija klienta vēlme mainīt nosaukumu piešķiršanas principu. Tie, kas strādāja ar F5, saprot situācijas pikanci. Bet man viss bija pavisam vienkārši. Es mainīju nosaukumus YAML failā, izdzēsu visu konfigurāciju no aprīkojuma, ģenerēju jaunu un augšupielādēju to. Viss, tostarp kļūdu labojumi, aizņēma 4 dienas: divas dienas katrai tehnoloģijai. Pēc tam biju gatavs nākamajam posmam, proti, DEV un Staging datu centru izveidei.
Izstrādātājs un iestudējums
Iestudēšana faktiski pilnībā atkārto ražošanu. Dev ir ļoti nolietota kopija, kas galvenokārt veidota uz virtuālās aparatūras. Ideāla situācija jaunai pieejai. Ja es norobežoju pavadīto laiku no kopējā procesa, tad domāju, ka darbs aizņēma ne vairāk kā 2 nedēļas. Galvenais laiks ir otrās puses gaidīšana un kopīga problēmu meklēšana. Trešās puses ieviešana palika gandrīz nepamanīta citiem. Bija pat laiks kaut ko iemācīties un uzrakstīt pāris rakstus par Habrē :)
Apkopojot
Tātad, kas man ir apakšējā rindā?
- Viss, kas man jādara, lai mainītu konfigurāciju, ir mainīt vienkāršu, skaidri strukturētu YAML failu ar konfigurācijas parametriem. Es nekad nemainu python skriptu un ļoti reti (tikai ja ir kļūda) es mainu Jinja2 heatlate
- No dokumentācijas viedokļa šī ir gandrīz ideāla situācija. Jūs maināt dokumentāciju (YAML faili kalpo kā NIP) un augšupielādējiet šo konfigurāciju iekārtā. Tādā veidā jūsu dokumentācija vienmēr ir atjaunināta
Tas viss noveda pie tā, ka
- kļūdu līmenis ir samazinājies gandrīz līdz 0
- 90 procenti rutīnas ir pazuduši
- ieviešanas ātrums ir ievērojami palielinājies
PAY, F5Y, ACY
Es teicu, ka pietiek ar dažiem piemēriem, lai saprastu, kā tas darbojas.
Šeit ir īsa (un, protams, pārveidota) versija no tā, kas tika izveidots mana darba laikā.
= izvietošana PAlo Alto no Yaml = Palo Alto no Yaml
= izvietošana F5 no Yaml = F5 no Yaml (drīzumā)
= izvietošana ACes no Yaml = F5 no Yaml
Es pievienošu dažus vārdus par ACY (nejaukt ar ACI).
Tie, kas ir strādājuši ar ACI, zina, ka šo brīnumu (un arī labā nozīmē) noteikti nav radījuši tīklnieki :). Aizmirstiet visu, ko zinājāt par tīklu - tas jums nebūs noderīgi!
Tas ir nedaudz pārspīlēts, taču tas aptuveni atspoguļo sajūtu, ko es pastāvīgi piedzīvoju pēdējos 3 gadus, strādājot ar ACI.
Un šajā gadījumā ACY ir ne tikai iespēja izveidot izmaiņu kontroles procesu (kas ir īpaši svarīgi ACI gadījumā, jo tai ir jābūt jūsu datu centra centrālajai un vissvarīgākajai daļai), bet arī sniedz jums lietotājam draudzīgs interfeiss konfigurācijas izveidei.
Šī projekta inženieri izmanto programmu Excel, lai konfigurētu ACI, nevis YAML tieši tādiem pašiem mērķiem. Protams, Excel lietošanai ir priekšrocības:
- jūsu NIP vienā failā
- skaistas zīmes, uz kurām patīkami skatīties klientam
- varat izmantot dažus Excel rīkus
Bet ir viens mīnuss, un, manuprāt, tas atsver plusus. Pārmaiņu kontrole un komandas darba koordinēšana kļūst daudz grūtāka.
ACY faktiski ir to pašu pieeju lietojumprogramma, ko es izmantoju trešajai pusei, lai konfigurētu ACI.
Avots: www.habr.com