{"id":34742,"date":"2019-10-31T22:00:10","date_gmt":"2019-10-31T19:00:10","guid":{"rendered":"https:\/\/prohoster.info\/blog\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty\/"},"modified":"2019-10-31T22:00:10","modified_gmt":"2019-10-31T19:00:10","slug":"kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","status":"publish","type":"post","link":"https:\/\/prohoster.info\/et\/blog\/administrirovanie\/kak-vzyat-setevuyu-infrastrukturu-pod-svoj-kontrol-glava-chetvertaya-avtomatizatsiya-templejty","title":{"rendered":"Kuidas v\u00f5tta v\u00f5rguinfrastruktuur enda kontrolli alla. Neljas peat\u00fckk. Automatiseerimine. Mallid","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

See artikkel on kuues artikkel seerias \"Kuidas v\u00f5tta v\u00f5rgu infrastruktuur oma kontrolli alla\". K\u00f5igi seeria artiklite sisu ja lingid leiate siit. siit<\/a><\/noindex><\/i>.<\/p>\n

J\u00e4tkates mitme teema arutamist, otsustasin siiski alustada uut peat\u00fckki.<\/p>\n

Turvalisuse teemade juurde tulen tagasi veidi hiljem. Siin tahan arutada \u00fcht lihtsat, kuid efektiivset l\u00e4henemist, mis, olen kindel, v\u00f5ib paljudele mingil moel kasuks tulla. See on pigem l\u00fchike lugu sellest, kuidas automatiseerimine v\u00f5ib inseneri elu muuta. R\u00e4\u00e4gime mallide kasutamisest. L\u00f5pus toome v\u00e4lja loendi minu projektidest, kus saab n\u00e4ha, kuidas k\u00f5ik siin kirjeldatu t\u00f6\u00f6tab.<\/p>\n

DevOps v\u00f5rgus<\/h2>\n

\nScriptide abil konfigureerimine, GIT-i kasutamine IT infrastruktuuri muudatuste j\u00e4lgimiseks, kaug-\u2018upload\u2019 \u2014 need ideed tulevad esimesena meelde, kui m\u00f5elda DevOps l\u00e4henemise tehnilisele rakendamisele. Plusse on selgelt palju. Kuid, kahjuks, on ka miinuseid.<\/p>\n

Kui meie arendajad rohkem kui 5 aastat tagasi nende ettepanekutega meie, v\u00f5rguinseneride, juurde tulid, ei olnud me vaimustuses.
\n<\/a><\/noindex>
\nPeab \u00fctlema, et meile j\u00e4i p\u00e4randuseks \u00fcsna kirju v\u00f5rgustik, koosnes see umbes 10 erineva tootja seadmetest. Osa oli mugav konfigureerida meie lemmik CLI kaudu, kuid m\u00f5nes kohas eelistasime kasutada GUI-d. Lisaks sellele on pikka aega t\u00f6\u00f6tamine 'otse' seadmetega \u00f5petanud meid reaalajas kontrollima. Mina, n\u00e4iteks, tunnen end muutusi tehes palju mugavamalt, t\u00f6\u00f6tades otse CLI kaudu. Nii n\u00e4en kiiresti, kui midagi on valesti l\u00e4inud, ja saan muudatused 'tagasi v\u00f5tta'. K\u00f5ik see sattus veidi vastuollu nende ideedega.<\/p>\n

Tekkivad ka teised k\u00fcsimused, n\u00e4iteks v\u00f5ib tarkvara versioonide vahel liides veidi muutuda. See toob l\u00f5puks kaasa selle, et teie skript loob vale 'konfiguratsiooni'. Ei tahaks kasutada tootmisre\u017eiimi 'katsetamiseks'. <\/p>\n

Kuidas aru saada, et konfiguratsiooni k\u00e4sud rakendati korrektselt ja mida teha vea korral?<\/p>\n

Ma ei taha \u00f6elda, et k\u00f5ik need k\u00fcsimused on lahendamatud. Lihtsalt \u00f6eldes \"A\" on m\u00f5istlik \u00f6elda ka \"B\", ja kui soovite kasutada samu protsesse muudatuste juhtimiseks nagu arenduses, siis tuleb omada lisaks production'ile ka dev ja staging keskkondi. Siis tundub selline l\u00e4henemine l\u00f5petatuna. Kuid kui palju see maksma l\u00e4heb?<\/p>\n

Aga on \u00fcks olukord, kus miinused on praktiliselt tasakaalust v\u00e4ljas ja j\u00e4\u00e4vad alles ainult plussid. R\u00e4\u00e4gin projektit\u00f6\u00f6st.<\/p>\n

Projekt<\/h2>\n

\nViimased kaks aastat olen osalenud andmekeskuse ehitusprojekti suurele teenusepakkujale. Olen selles projektis vastutav F5 ja Palo Alto eest. Cisco vaatevinklist on see \"3rd party equipment\".<\/p>\n

Isiklikult on mul selles projektis kaks selgelt m\u00e4\u00e4ratletud etappi. <\/p>\n

Esimene etapp<\/h3>\n

\nEsimesel aastal olin ma l\u00f5putult h\u00f5ivatud, t\u00f6\u00f6tasin \u00f6\u00f6siti ja puhkep\u00e4evadel. Ma ei saanud pead t\u00f5sta. Surve juhtimise ja tellija poolt oli tugev ja pidev. Pidevas rutiinis ei suutnud ma isegi proovida protsessi optimeerida. See ei olnud mitte ainult seadmete konfigureerimine, vaid ka projektidokumentatsiooni koostamine. <\/p>\n

N\u00fc\u00fcd algasid esimesed testid ja olin \u00fcllatunud, kui palju pisivigu ja ebat\u00e4psusi oli tehtud. Loomulikult t\u00f6\u00f6tas k\u00f5ik, kuid seal puudus t\u00e4ht nimes, siin j\u00e4i rida k\u00e4sust vahele... Testid j\u00e4tkusid ja j\u00e4tkusid, ning olin pidevas igap\u00e4evases v\u00f5itluses vigade, testide ja dokumentatsiooniga. <\/p>\n

Nii kestis see aasta. Projekt, nii palju kui ma aru saan, ei olnud lihtne kellelegi, kuid aeglaselt sai klient j\u00e4rjest rohkem ja rohkem rahulolevaks, mis andis v\u00f5imaluse v\u00f5tta juurde t\u00e4iendavaid insenere, kes suudaksid osa rutiinist enda kanda v\u00f5tta.<\/p>\n

N\u00fc\u00fcd oli v\u00f5imalik natuke ringi vaadata.
\nJa see oli teise etapi algus. <\/p>\n

Teine etapp<\/h3>\n

\nOtsustasin protsessi automatiseerida.<\/p>\n

Mida ma tol hetkel arendajatega suheldes taipasin (ja tuleb tunnustada, et meil oli tugev meeskond), on see, et tekstivorming, ehkki n\u00e4ib esmapilgul olema midagi DOS-i operatsioonis\u00fcsteemi maailmast, omab mitmeid v\u00e4\u00e4rtuslikke omadusi.
\nN\u00e4iteks on tekstivorming kasulik, kui soovite t\u00e4ielikult \u00e4ra kasutada GIT-i ja k\u00f5iki selle tuletisi. Ja mina tahtsin. <\/p>\n

Tundub, et saaks lihtsalt konfiguratsiooni v\u00f5i k\u00e4skude nimekirja s\u00e4ilitada, kuid muudatuste tegemine on sellega \u00fcsna keeruline. Samuti on projekteerimise k\u00e4igus veel \u00fcks oluline \u00fclesanne. Teil peab olema dokumentatsioon, mis kirjeldab teie disaini tervikuna (Low Level Design) ja konkreetset rakendust (Network Implementation Plan). Sel juhul n\u00e4ib mallide kasutamine v\u00e4ga sobiv variant.<\/p>\n

Nii, kui kasutada YAML ja Jinja2, t\u00e4idab YAML-fail, mis sisaldab konfiguratsiooni parameetreid, nagu IP-aadressid, BGP AS-numbrid,\u2026 suurep\u00e4raselt NIP-i rolli, samas kui Jinja2 mallid sisaldavad disainile vastavat s\u00fcntaksit, mis on tegelikult LLD peegeldus. <\/p>\n

YAML ja Jinja2 keeltesse s\u00fcvenemine v\u00f5ttis kaks p\u00e4eva. Et m\u00f5ista, kuidas see t\u00f6\u00f6tab, piisab m\u00f5nest heast n\u00e4itest. Edasi kulus umbes kaks n\u00e4dalat, et luua k\u00f5ik mallid, mis vastavad meie disainile: n\u00e4dal Palo Alto jaoks ja veel n\u00e4dal F5 jaoks. K\u00f5ik see pandi ettev\u00f5tte GitHubi.<\/p>\n

N\u00fc\u00fcd n\u00e4gi muudatuste protsess v\u00e4lja j\u00e4rgmine:<\/p>\n