Tämä artikkeli on kuudes sarjassa "Kuinka ottaa verkkoinfrastruktuurisi hallintaan". Sarjan kaikkien artikkeleiden sisältö ja linkit löytyvät .
Useiden aiheiden jälkeen päätin aloittaa uuden luvun.
Palaan turvallisuuteen vähän myöhemmin. Tässä haluan keskustella yhdestä yksinkertaisesta mutta tehokkaasta lähestymistavasta, josta olen varma, että muodossa tai toisessa voi olla hyötyä monille. Tämä on enemmän lyhyt tarina siitä, kuinka automaatio voi muuttaa insinöörin elämää. Puhumme mallien käytöstä. Lopussa on lista projekteistani, josta näet kuinka kaikki tässä kuvattu toimii.
DevOps verkkoon
Konfiguroinnin luominen komentosarjalla, GIT:n käyttö IT-infrastruktuurin muutosten hallintaan, etälataus – nämä ideat tulevat ensimmäiseksi, kun ajattelet DevOps-lähestymistavan teknistä toteutusta. Edut ovat ilmeisiä. Mutta valitettavasti on myös haittoja.
Kun yli 5 vuotta sitten kehittäjämme tulivat meille, verkostoituneille, näillä ehdotuksilla, emme olleet iloisia.
Minun on sanottava, että perimme melko kirjavan verkoston, joka koostuu noin 10 eri valmistajan laitteista. Joidenkin asioiden konfigurointi oli kätevää suosikkiklinillämme, mutta toisissa halusimme käyttää graafista käyttöliittymää. Lisäksi pitkä työ "elävien" laitteiden parissa on opettanut meidät reaaliaikaiseen ohjaukseen. Esimerkiksi kun teen muutoksia, tunnen oloni paljon mukavammaksi työskennellä suoraan kliin kautta. Näin voin nopeasti nähdä, että jokin meni pieleen, ja peruuttaa muutokset. Kaikki tämä oli ristiriidassa heidän ideoidensa kanssa.
Muitakin kysymyksiä herää, esimerkiksi käyttöliittymä saattaa muuttua hieman ohjelmistoversiosta toiseen. Tämä saa lopulta skriptisi luomaan väärän "konfiguraation". En haluaisi käyttää tuotantoa "sisäänajoamiseen".
Tai kuinka ymmärtää, että konfigurointikomentoja käytettiin oikein ja mitä tehdä virheen sattuessa?
En halua sanoa, että kaikki nämä ongelmat ovat ratkaisemattomia. Pelkästään "A" on luultavasti järkevä sanoa myös "B", ja jos haluat käyttää samoja prosesseja muutosten ohjaamiseen kuin kehitystyössä, tarvitset myös kehitys- ja lavastusympäristöt tuotannon lisäksi. Sitten tämä lähestymistapa näyttää täydelliseltä. Mutta kuinka paljon se maksaa?
Mutta on yksi tilanne, jolloin haitat tasoittuvat käytännössä ja vain edut jäävät jäljelle. Puhun suunnittelutyöstä.
Hanke
Olen osallistunut kahden viime vuoden ajan palvelinkeskuksen rakentamiseen suurelle toimittajalle. Olen vastuussa F5:stä ja Palo Altosta tässä projektissa. Ciscon näkökulmasta tämä on "kolmannen osapuolen laitteisto".
Minulle henkilökohtaisesti tässä projektissa on kaksi erillistä vaihetta.
Ensimmäinen vaihe
Ensimmäisenä vuonna olin loputtoman kiireinen, tein töitä öisin ja viikonloppuisin. En voinut nostaa päätäni. Johdon ja asiakkaan paine oli voimakasta ja jatkuvaa. Jatkuvassa rutiinissa en voinut edes yrittää optimoida prosessia. Kyse ei ollut vain eikä niinkään laitteiden konfiguroinnista kuin suunnitteluasiakirjojen laatimisesta.
Ensimmäiset testit ovat alkaneet, ja olisin hämmästynyt kuinka paljon pieniä virheitä ja epätarkkuuksia tehtiin. Tietysti kaikki toimi, mutta nimestä puuttui kirjain, komennosta puuttui rivi... Testit jatkuivat ja jatkuivat ja olin jo jatkuvassa, päivittäisessä kamppailussa virheiden, testien ja dokumentaation kanssa. .
Tätä jatkui vuoden. Projekti ei ymmärrykseni ollut kaikille helppo, mutta vähitellen asiakas muuttui tyytyväisemmaksi ja tämä mahdollisti insinöörien palkkaamisen lisää, jotka pystyivät ottamaan osan rutiineista itse.
Nyt voisimme vähän katsoa ympärillemme.
Ja tämä oli toisen vaiheen alku.
Toinen vaihe
Päätin automatisoida prosessin.
Ymmärsin tuolloin kommunikoinnistani kehittäjien kanssa (ja meidän täytyy osoittaa kunnioitusta, meillä oli vahva tiimi), että vaikka tekstimuodolla näyttää ensi silmäyksellä joltain DOS-käyttöjärjestelmän maailmasta, sillä on numero. arvokkaista ominaisuuksista.
Joten esimerkiksi tekstimuoto on hyödyllinen, jos haluat saada täyden hyödyn GIT:stä ja kaikista sen johdannaisista. Ja minä halusin.
No, näyttää siltä, että voit yksinkertaisesti tallentaa kokoonpanon tai komentoluettelon, mutta muutosten tekeminen on melko hankalaa. Lisäksi suunnittelun aikana on toinen tärkeä tehtävä. Sinulla tulee olla dokumentaatio, joka kuvaa suunnitteluasi kokonaisuutena (Low Level Design) ja konkreettista toteutusta (Network Implementation Plan). Ja tässä tapauksessa mallien käyttö näyttää erittäin sopivalta vaihtoehdolta.
YAML:ää ja Jinja2:ta käytettäessä siis YAML-tiedosto, jossa on konfiguraatioparametreja, kuten IP-osoitteita, BGP AS -numeroita, ..., täyttää täydellisesti NIP:n roolin, kun taas Jinja2-mallit sisältävät suunnittelua vastaavan syntaksin, eli se on olennaisesti LLD:n heijastus.
YAML:n ja Jinja2:n oppiminen kesti kaksi päivää. Muutama hyvä esimerkki riittää ymmärtämään, miten tämä toimii. Sitten kesti noin kaksi viikkoa kaikkien suunnitteluamme vastaavien mallien luomiseen: viikko Palo Altolle ja toinen viikko F5:lle. Kaikki tämä on julkaistu yrityksen githabissa.
Nyt muutosprosessi näytti tältä:
- muutti YAML-tiedostoa
- loi asetustiedoston mallipohjalla (Jinja2)
- tallennettu etävarastoon
- latasi luodun kokoonpanon laitteeseen
- Näin virheen
- muutti YAML-tiedostoa tai Jinja2-mallia
- loi asetustiedoston mallipohjalla (Jinja2)
- ...
On selvää, että muokkauksiin kului aluksi paljon aikaa, mutta viikon tai kahden jälkeen tästä tuli melko harvinaista.
Hyvä testi ja mahdollisuus korjata kaikkea oli asiakkaan halu muuttaa nimeämiskäytäntöä. F5:n kanssa työskennelleet ymmärtävät tilanteen pikaisuuden. Mutta minulle kaikki oli hyvin yksinkertaista. Muutin nimet YAML-tiedostossa, poistin koko kokoonpanon laitteesta, loin uuden ja latasin sen. Kaikki, mukaan lukien virheenkorjaukset, kesti 4 päivää: kaksi päivää jokaiselle tekniikalle. Sen jälkeen olin valmis seuraavaan vaiheeseen, nimittäin DEV- ja Staging-palvelinkeskusten luomiseen.
Kehittäjä ja lavastus
Lavastus itse asiassa toistaa tuotannon täysin. Dev on voimakkaasti riisuttu kopio, joka on rakennettu pääasiassa virtuaalilaitteistolle. Ihanteellinen tilanne uudelle lähestymistavalle. Jos eristän käyttämäni ajan koko prosessista, työ ei mielestäni kestä enempää kuin 2 viikkoa. Pääaika on toisen puolen odottamista ja ongelmien yhdessä etsimistä. Kolmannen osapuolen toteutus jäi melkein huomaamatta muille. Oli jopa aikaa oppia jotain ja kirjoittaa pari artikkelia Habresta :)
Yhteenvetona
Joten mitä minulla on lopussa?
- Ainoa mitä minun tarvitsee tehdä muuttaakseni kokoonpanoa, on muuttaa yksinkertainen, selkeästi jäsennelty YAML-tiedosto kokoonpanoparametreineen. En koskaan vaihda python-skriptiä ja vaihdan hyvin harvoin (vain jos on virhe) Jinja2 heatlate
- Dokumentaation näkökulmasta tämä on lähes ihanteellinen tilanne. Muutat dokumentaatiota (YAML-tiedostot toimivat NIP:nä) ja lataat tämän kokoonpanon laitteeseen. Näin dokumentaatiosi on aina ajan tasalla
Kaikki tämä johti siihen, että
- virheprosentti on pudonnut lähes nollaan
- 90 prosenttia rutiineista on poissa
- toteutusnopeus on noussut huomattavasti
PAY, F5Y, ACY
Sanoin, että muutama esimerkki riittää ymmärtämään, miten se toimii.
Tässä lyhyt (ja tietysti muokattu) versio työni aikana luodusta.
= käyttöönotto Palo Alto alkaen Yaml = Palo Alto Yamlista
= käyttöönotto F5 alkaen Yaml = F5 alkaen Yaml (tulossa pian)
= käyttöönotto ACminä alkaen Yaml = F5 alkaen Yjr
Lisään muutaman sanan ACY:stä (ei pidä sekoittaa ACI:hen).
ACI:n kanssa työskennelleet tietävät, että tämä ihme (ja hyvällä tavalla myös) ei todellakaan ole verkostoituneiden luoma :). Unohda kaikki, mitä tiesit verkosta - siitä ei ole sinulle hyötyä!
Se on hieman liioiteltua, mutta se välittää karkeasti tunteen, jonka olen jatkuvasti kokenut viimeisen 3 vuoden ajan työskennellessäni ACI:n kanssa.
Ja tässä tapauksessa ACY ei ole vain mahdollisuus rakentaa muutoksenhallintaprosessi (mikä on erityisen tärkeää ACI:n tapauksessa, koska sen oletetaan olevan palvelinkeskuksesi keskeisin ja kriittisin osa), vaan se antaa sinulle myös käyttäjäystävällinen käyttöliittymä konfiguraatioiden luomiseen.
Tämän projektin insinöörit käyttävät Exceliä ACI:n määrittämiseen YAML:n sijaan täsmälleen samoihin tarkoituksiin. Excelin käytössä on tietysti etuja:
- NIP-osoitteesi yhdessä tiedostossa
- kauniita kylttejä, joita asiakkaan on miellyttävä katsella
- voit käyttää joitain Excel-työkaluja
Mutta siinä on yksi miinus, ja mielestäni se painaa plussat. Muutosten hallinta ja tiimityön koordinointi muuttuvat paljon vaikeammaksi.
ACY on itse asiassa samojen lähestymistapojen sovellus, joita käytin kolmannelle osapuolelle ACI:n määrittämiseen.
Lähde: will.com