Ang artikulong ito ay ang ikaanim sa seryeng "Paano Kontrolin ang Iyong Imprastraktura sa Network." Ang mga nilalaman ng lahat ng mga artikulo sa serye at mga link ay matatagpuan .
Dahil nag-iwan ng ilang paksa, nagpasya akong magsimula ng bagong kabanata.
Babalik ako sa security mamaya. Dito nais kong talakayin ang isang simple ngunit epektibong diskarte, na sigurado ako, sa isang anyo o iba pa, ay maaaring maging kapaki-pakinabang sa marami. Ito ay higit pa sa isang maikling kuwento tungkol sa kung paano mababago ng automation ang buhay ng isang engineer. Pag-uusapan natin ang tungkol sa paggamit ng mga template. Sa dulo mayroong isang listahan ng aking mga proyekto kung saan makikita mo kung paano gumagana ang lahat ng inilarawan dito.
DevOps para sa network
Paggawa ng configuration na may script, gamit ang GIT para kontrolin ang mga pagbabago sa IT infrastructure, remote na "pag-upload" - mauna ang mga ideyang ito kapag iniisip mo ang teknikal na pagpapatupad ng diskarte sa DevOps. Ang mga pakinabang ay halata. Ngunit, sa kasamaang-palad, mayroon ding mga disadvantages.
Noong mahigit 5 ββtaon na ang nakakaraan, ang aming mga developer ay dumating sa amin, ang mga networker, sa mga panukalang ito, hindi kami natuwa.
Dapat kong sabihin na minana namin ang isang medyo motley network, na binubuo ng mga kagamitan mula sa humigit-kumulang 10 iba't ibang vendor. Maginhawang i-configure ang ilang bagay sa pamamagitan ng aming paboritong cli, ngunit sa iba ay mas gusto naming gamitin ang GUI. Bilang karagdagan, ang mahabang trabaho sa "live" na kagamitan ay nagturo sa amin sa real-time na kontrol. Halimbawa, kapag gumagawa ng mga pagbabago, mas komportable akong magtrabaho nang direkta sa pamamagitan ng cli. Sa ganitong paraan, mabilis kong nakikita na may nangyaring mali at ibabalik ang mga pagbabago. Ang lahat ng ito ay nasa ilang pagkakasalungatan sa kanilang mga ideya.
Lumilitaw din ang iba pang mga katanungan, halimbawa, ang interface ay maaaring bahagyang magbago mula sa bersyon patungo sa bersyon ng software. Sa kalaunan ay magiging sanhi ito ng iyong script na lumikha ng maling "config". Hindi ko gustong gamitin ang produksyon para sa "running in".
O, kung paano maunawaan na ang mga utos ng pagsasaayos ay nailapat nang tama at kung ano ang gagawin kung sakaling magkaroon ng isang error?
Hindi ko nais na sabihin na ang lahat ng mga isyung ito ay hindi malulutas. Ang pagsasabi lang ng "A" ay malamang na makatuwiran na sabihin din ang "B", at kung gusto mong gamitin ang parehong mga proseso para sa kontrol ng pagbabago tulad ng sa pag-unlad, kailangan mong magkaroon ng dev at staging environment bilang karagdagan sa produksyon. Pagkatapos ang diskarte na ito ay mukhang kumpleto. Ngunit magkano ito?
Ngunit mayroong isang sitwasyon kung saan ang mga disadvantages ay halos na-level out, at ang mga pakinabang lamang ang natitira. Pinag-uusapan ko ang gawaing disenyo.
Proyekto
Sa huling dalawang taon ako ay nakikilahok sa isang proyekto upang bumuo ng isang data center para sa isang malaking provider. Responsable ako para sa F5 at Palo Alto sa proyektong ito. Mula sa pananaw ng Cisco, ito ay "3rd party na kagamitan".
Para sa akin personal, mayroong dalawang natatanging yugto sa proyektong ito.
Unang yugto
Sa unang taon na ako ay walang katapusang abala, nagtatrabaho ako sa gabi at katapusan ng linggo. Hindi ko maiangat ang ulo ko. Malakas at tuloy-tuloy ang pressure mula sa management at ng customer. Sa patuloy na gawain, hindi ko man lang masubukang i-optimize ang proseso. Ito ay hindi lamang at hindi gaanong pagsasaayos ng kagamitan bilang paghahanda ng dokumentasyon ng disenyo.
Nagsimula na ang mga unang pagsubok, at magugulat ako sa kung gaano karaming maliliit na pagkakamali at kamalian ang nagawa. Siyempre, gumana ang lahat, ngunit may nawawalang titik sa pangalan, may nawawalang linya sa utos... Ang mga pagsubok ay nagpatuloy, at ako ay nasa patuloy, araw-araw na pakikibaka sa mga pagkakamali, pagsubok at dokumentasyon .
Nagpatuloy ito sa loob ng isang taon. Ang proyekto, sa pagkakaunawa ko, ay hindi madali para sa lahat, ngunit unti-unting naging mas nasiyahan ang kliyente, at naging posible ang pag-hire ng karagdagang mga inhinyero na nagawang gawin ang bahagi ng gawain mismo.
Ngayon ay maaari kaming tumingin sa paligid ng kaunti.
At ito ang simula ng ikalawang yugto.
Pangalawang yugto
Nagpasya akong i-automate ang proseso.
Ang naunawaan ko mula sa aking pakikipag-usap sa mga developer noong panahong iyon (at dapat tayong magbigay pugay, mayroon tayong isang malakas na koponan) ay ang format ng teksto, bagaman sa unang tingin ay parang isang bagay mula sa mundo ng operating system ng DOS, ay may numero. ng mahahalagang ari-arian.
Kaya, halimbawa, ang format ng teksto ay magiging kapaki-pakinabang kung nais mong samantalahin nang husto ang GIT at lahat ng mga derivatives nito. At gusto ko.
Buweno, tila maaari kang mag-imbak lamang ng isang pagsasaayos o isang listahan ng mga utos, ngunit ang paggawa ng mga pagbabago ay medyo hindi maginhawa. Bilang karagdagan, mayroong isa pang mahalagang gawain sa panahon ng disenyo. Dapat ay mayroon kang dokumentasyon na naglalarawan sa iyong disenyo sa kabuuan (Mababang Antas na Disenyo) at partikular na pagpapatupad (Network Implementation Plan). At sa kasong ito, ang paggamit ng mga template ay mukhang isang napaka-angkop na pagpipilian.
Kaya, kapag gumagamit ng YAML at Jinja2, isang YAML file na may mga parameter ng pagsasaayos tulad ng mga IP address, mga numero ng BGP AS, ... perpektong tinutupad ang papel ng NIP, habang ang mga template ng Jinja2 ay may kasamang syntax na naaayon sa disenyo, iyon ay, ito ay mahalagang isang salamin ng LLD.
Tumagal ng dalawang araw para matutunan ang YAML at Jinja2. Ang ilang magagandang halimbawa ay sapat na upang maunawaan kung paano ito gumagana. Pagkatapos ay tumagal ng humigit-kumulang dalawang linggo upang gawin ang lahat ng mga template na tumugma sa aming disenyo: isang linggo para sa Palo Alto at isa pang linggo para sa F5. Ang lahat ng ito ay nai-post sa corporate githab.
Ngayon ang proseso ng pagbabago ay mukhang ganito:
- binago ang YAML file
- lumikha ng configuration file gamit ang isang template (Jinja2)
- naka-save sa isang malayuang imbakan
- na-upload ang ginawang pagsasaayos sa kagamitan
- May nakita akong error
- binago ang YAML file o Jinja2 template
- lumikha ng configuration file gamit ang isang template (Jinja2)
- ...
Malinaw na sa una ay maraming oras ang ginugol sa mga pag-edit, ngunit pagkatapos ng isang linggo o dalawa ay naging pambihira ito.
Ang isang magandang pagsubok at pagkakataon upang i-debug ang lahat ay ang pagnanais ng kliyente na baguhin ang kombensyon ng pagbibigay ng pangalan. Nauunawaan ng mga nagtrabaho sa F5 ang piquancy ng sitwasyon. Ngunit para sa akin ang lahat ay medyo simple. Binago ko ang mga pangalan sa YAML file, tinanggal ang buong configuration mula sa kagamitan, gumawa ng bago at na-upload ito. Ang lahat, kabilang ang mga pag-aayos ng bug, ay tumagal ng 4 na araw: dalawang araw para sa bawat teknolohiya. Pagkatapos noon, handa na ako para sa susunod na yugto, lalo na ang paglikha ng DEV at Staging data centers.
Dev at Staging
Talagang ganap na ginagaya ng pagtatanghal ang produksyon. Ang Dev ay isang mabigat na stripped-down na kopya na binuo pangunahin sa virtual hardware. Isang perpektong sitwasyon para sa isang bagong diskarte. Kung ihihiwalay ko ang oras na ginugol ko mula sa pangkalahatang proseso, sa tingin ko ang trabaho ay tumagal ng hindi hihigit sa 2 linggo. Ang pangunahing oras ay naghihintay para sa kabilang panig at naghahanap ng mga problema nang magkasama. Ang pagpapatupad ng 3rd party ay halos hindi napansin ng iba. Nagkaroon pa ng oras upang matuto ng isang bagay at magsulat ng ilang mga artikulo sa HabrΓ© :)
upang ibuod
Kaya, ano ang mayroon ako sa ilalim na linya?
- Ang kailangan ko lang gawin upang baguhin ang pagsasaayos ay baguhin ang isang simple, malinaw na nakabalangkas na YAML file na may mga parameter ng pagsasaayos. Hindi ko kailanman binago ang script ng python at napakabihirang (kung may error lamang) binabago ko ang heatlate ng Jinja2
- Mula sa isang punto ng dokumentasyon ng view, ito ay isang halos perpektong sitwasyon. Binago mo ang dokumentasyon (nagsisilbing NIP ang mga file ng YAML) at i-upload ang configuration na ito sa kagamitan. Sa ganitong paraan, palaging napapanahon ang iyong dokumentasyon
Ang lahat ng ito ay humantong sa katotohanan na
- ang rate ng error ay bumaba sa halos 0
- 90 porsiyento ng nakagawian ay nawala
- ang bilis ng pagpapatupad ay tumaas nang malaki
MAGBAYAD, F5Y, ACY
Sinabi ko na ang ilang mga halimbawa ay sapat na upang maunawaan kung paano ito gumagana.
Narito ang isang maikling (at siyempre binago) na bersyon ng kung ano ang nilikha sa panahon ng aking trabaho.
= deployment Palo Alto mula sa Yaml = Palo Alto mula sa Yaml
= deployment F5 mula Yaml = F5 mula Yaml (malapit na)
= deployment ACgaling ako Yaml = F5 mula Yaml
Magdaragdag ako ng ilang mga salita tungkol sa ACY (hindi malito sa ACI).
Alam ng mga nakatrabaho sa ACI na ang himalang ito (at sa mabuting paraan din) ay tiyak na hindi nilikha ng mga networker :). Kalimutan ang lahat ng iyong nalalaman tungkol sa network - hindi ito magiging kapaki-pakinabang sa iyo!
Ito ay medyo pinalaki, ngunit halos ipinapahiwatig nito ang pakiramdam na palagi kong nararanasan, sa nakalipas na 3 taon, nagtatrabaho sa ACI.
At sa kasong ito, ang ACY ay hindi lamang isang pagkakataon na bumuo ng isang proseso ng pagkontrol sa pagbabago (na kung saan ay lalong mahalaga sa kaso ng ACI, dahil ito ay dapat na ang sentro at pinaka-kritikal na bahagi ng iyong data center), ngunit nagbibigay din sa iyo isang user-friendly na interface para sa paglikha ng configuration.
Ang mga inhinyero sa proyektong ito ay gumagamit ng Excel upang i-configure ang ACI sa halip na YAML para sa eksaktong parehong mga layunin. Mayroong, siyempre, mga pakinabang sa paggamit ng Excel:
- ang iyong NIP sa isang file
- magagandang palatandaan na kaaya-ayang tingnan ng kliyente
- maaari kang gumamit ng ilang mga tool sa excel
Ngunit mayroong isang minus, at sa palagay ko ito ay mas malaki kaysa sa mga kalamangan. Ang pagkontrol sa mga pagbabago at pag-coordinate ng team work ay nagiging mas mahirap.
Ang ACY ay talagang isang application ng parehong mga diskarte na ginamit ko para sa 3rd party upang i-configure ang ACI.
Pinagmulan: www.habr.com