Ĉi tiu artikolo estas la sesa en la serio "Kiel Preni Kontrolon de Via Reta Infrastrukturo". La enhavo de ĉiuj artikoloj en la serio kaj ligiloj troveblas .
Postlasinte plurajn temojn, mi decidis komenci novan ĉapitron.
Mi revenos al sekureco iom poste. Ĉi tie mi volas diskuti unu simplan sed efikan aliron, kiu mi certas, en unu aŭ alia formo, povas esti utila al multaj. Ĉi tio estas pli mallonga rakonto pri kiel aŭtomatigo povas ŝanĝi la vivon de inĝeniero. Ni parolos pri uzado de ŝablonoj. Fine estas listo de miaj projektoj, kie vi povas vidi kiel funkcias ĉio ĉi tie priskribita.
DevOps por la reto
Krei agordon per skripto, uzi GIT por kontroli ŝanĝojn al la IT-infrastrukturo, fora "alŝutado" - ĉi tiuj ideoj venas unue kiam vi pensas pri la teknika efektivigo de la DevOps-aliro. La avantaĝoj estas evidentaj. Sed, bedaŭrinde, estas ankaŭ malavantaĝoj.
Kiam antaŭ pli ol 5 jaroj, niaj programistoj venis al ni, la retoj, kun ĉi tiuj proponoj, ni ne ĝojis.
Mi devas diri, ke ni heredis sufiĉe diversan reton, konsistantan el ekipaĵoj de ĉirkaŭ 10 malsamaj vendistoj. Estis oportune agordi iujn aferojn per nia plej ŝatata kli, sed en aliaj ni preferis uzi la GUI. Krome, longa laboro pri "vivaj" ekipaĵoj instruis nin al realtempa kontrolo. Ekzemple, kiam mi faras ŝanĝojn, mi sentas min multe pli komforta laborante rekte per la cli. Tiel mi povas rapide vidi, ke io misfunkciis kaj refari la ŝanĝojn. Ĉio ĉi estis en iu kontraŭdiro kun iliaj ideoj.
Aliaj demandoj ankaŭ ŝprucas, ekzemple, la interfaco povas ŝanĝi iomete de versio al versio de la programaro. Ĉi tio eventuale kaŭzos vian skripton krei la malĝustan "agordo". Mi ne ŝatus uzi produktadon por "kuri".
Aŭ, kiel kompreni, ke la agordaj komandoj estis aplikitaj ĝuste kaj kion fari en kazo de eraro?
Mi ne volas diri, ke ĉiuj ĉi tiuj aferoj estas nesolveblaj. Nur diri "A" verŝajne havas sencon diri "B" ankaŭ, kaj se vi volas uzi la samajn procezojn por ŝanĝkontrolo kiel en evoluo, tiam vi devas havi dev- kaj enscenigantajn mediojn krom produktado. Tiam ĉi tiu aliro aspektas kompleta. Sed kiom ĝi kostos?
Sed estas unu situacio, kiam la malavantaĝoj estas preskaŭ ebenigitaj, kaj nur la avantaĝoj restas. Mi parolas pri desegna laboro.
La projekto
Dum la lastaj du jaroj mi partoprenas projekton por konstrui datumcentron por granda provizanto. Mi respondecas pri F5 kaj Palo Alto en ĉi tiu projekto. De la vidpunkto de Cisco, ĉi tio estas "tria-partia ekipaĵo".
Por mi persone, estas du apartaj etapoj en ĉi tiu projekto.
Unua etapo
La unuan jaron mi estis senfine okupata, mi laboris nokte kaj semajnfine. Mi ne povis levi la kapon. La premo de administrado kaj la kliento estis forta kaj kontinua. En konstanta rutino, mi eĉ ne povis provi optimumigi la procezon. Ĝi estis ne nur kaj ne tiom la agordo de ekipaĵo kiel la preparado de dezajnodokumentado.
La unuaj provoj komenciĝis, kaj mi mirus, kiom da malgrandaj eraroj kaj eraroj estis faritaj. Kompreneble ĉio funkciis, sed mankis litero en la nomo, mankis linio en la komando... La testoj daŭris kaj plu, kaj mi jam estis en konstanta, ĉiutaga lukto kun eraroj, testoj kaj dokumentado. .
Ĉi tio daŭris unu jaron. La projekto, laŭ mia kompreno, ne estis facila por ĉiuj, sed iom post iom la kliento pli kaj pli kontentiĝis, kaj tio ebligis dungi pliajn inĝenierojn, kiuj povis mem preni parton de la rutino.
Nun ni povus iomete ĉirkaŭrigardi.
Kaj ĉi tio estis la komenco de la dua etapo.
Dua etapo
Mi decidis aŭtomatigi la procezon.
Kion mi komprenis el mia komunikado kun la programistoj tiutempe (kaj ni devas omaĝi, ni havis fortan teamon) estas, ke la tekstoformato, kvankam unuavide ŝajnas io el la mondo de la mastruma sistemo DOS, havas nombron. de valoraj propraĵoj.
Do, ekzemple, la tekstformato estos utila se vi volas plene profiti GIT kaj ĉiujn ĝiajn derivaĵojn. Kaj mi volis.
Nu, ŝajnus, ke vi povas simple konservi agordon aŭ liston de komandoj, sed fari ŝanĝojn estas sufiĉe maloportuna. Krome, estas alia grava tasko dum dezajno. Vi devus havi dokumentaron priskribantan vian dezajnon kiel tuton (Malalta Nivela Dezajno) kaj specifan efektivigon (Reto-Efektivigo-Plano). Kaj en ĉi tiu kazo, la uzo de ŝablonoj aspektas kiel tre taŭga opcio.
Do, uzante YAML kaj Jinja2, YAML-dosiero kun agordaj parametroj kiel IP-adresoj, BGP AS-numeroj, ... perfekte plenumas la rolon de NIP, dum Jinja2-ŝablonoj inkluzivas sintakson respondan al la dezajno, tio estas, ĝi estas esence reflektado de LLD.
Necesis du tagoj por lerni YAML kaj Jinja2. Kelkaj bonaj ekzemploj sufiĉas por kompreni kiel tio funkcias. Tiam necesis proksimume du semajnoj por krei ĉiujn ŝablonojn, kiuj kongruis kun nia dezajno: semajnon por Palo Alto kaj alian semajnon por F5. Ĉio ĉi estis afiŝita sur kompania githab.
Nun la ŝanĝprocezo aspektis jene:
- ŝanĝis la YAML-dosieron
- kreis agordan dosieron uzante ŝablonon (Jinja2)
- konservite en fora deponejo
- alŝutis la kreitan agordon al la ekipaĵo
- Mi vidis eraron
- ŝanĝis la YAML-dosieron aŭ Jinja2-ŝablonon
- kreis agordan dosieron uzante ŝablonon (Jinja2)
- ...
Estas klare, ke komence multe da tempo estis elspezita por redaktoj, sed post unu aŭ du semajnoj tio fariĝis sufiĉe malofta.
Bona testo kaj ŝanco sencimigi ĉion estis la deziro de la kliento ŝanĝi la nomkonvencion. Tiuj, kiuj laboris kun F5, komprenas la pikancon de la situacio. Sed por mi ĉio estis sufiĉe simpla. Mi ŝanĝis la nomojn en la YAML-dosiero, forigis la tutan agordon de la ekipaĵo, generis novan kaj alŝutis ĝin. Ĉio, inkluzive de eraroj, daŭris 4 tagojn: du tagojn por ĉiu teknologio. Post tio, mi estis preta por la sekva etapo, nome la kreado de DEV kaj Staging datumcentroj.
Dev kaj Scenigo
Enscenigo fakte tute reproduktas. Dev estas tre nudigita kopio konstruita ĉefe sur virtuala aparataro. Ideala situacio por nova aliro. Se mi izolas la tempon, kiun mi pasigis de la ĝenerala procezo, tiam mi pensas, ke la laboro daŭris ne pli ol 2 semajnojn. La ĉefa tempo estas atendi la alian flankon kaj serĉi problemojn kune. La efektivigo de tria partio estis preskaŭ nerimarkita de aliaj. Estis eĉ tempo por lerni ion kaj skribi kelkajn artikolojn pri Habré :)
Ni resumu
Do, kion mi havas en la fundo?
- Ĉio, kion mi devas fari por ŝanĝi la agordon, estas ŝanĝi simplan, klare strukturitan YAML-dosieron kun agordaj parametroj. Mi neniam ŝanĝas la python-skripton kaj tre malofte (nur se estas eraro) mi ŝanĝas la varmegon de Jinja2.
- El dokumenta vidpunkto, ĉi tio estas preskaŭ ideala situacio. Vi ŝanĝas la dokumentadon (YAML-dosieroj servas kiel NIP) kaj alŝutu ĉi tiun agordon al la ekipaĵo. Tiel via dokumentaro estas ĉiam ĝisdatigita
Ĉio ĉi kondukis al tio, ke
- la eraroprocento falis al preskaŭ 0
- 90 procentoj de la rutino malaperis
- la rapideco de efektivigo signife pliiĝis
PAGI, F5Y, ACY
Mi diris, ke kelkaj ekzemploj sufiĉas por kompreni kiel ĝi funkcias.
Jen mallonga (kaj kompreneble modifita) versio de tio, kio estis kreita dum mia laboro.
= deplojo Psaluton Alto de Yaml = Palo Alto from Yaml
= deplojo F5 el Yaml = F5 el Yaml (baldaŭ)
= deplojo ACi de Yaml = F5 el Yjr
Mi aldonos kelkajn vortojn pri ACY (ne konfuzu kun ACI).
Tiuj, kiuj laboris kun ACI, scias, ke ĉi tiu miraklo (kaj ankaŭ en bona maniero) certe ne estis kreita de retuloj :). Forgesu ĉion, kion vi sciis pri la reto - ĝi ne utilos al vi!
Ĝi estas iom troigita, sed ĝi proksimume transdonas la senton, ke mi konstante spertas, dum la pasintaj 3 jaroj, laborante kun ACI.
Kaj en ĉi tiu kazo, ACY ne nur estas ŝanco por konstrui ŝanĝkontrolan procezon (kio estas precipe grava en la kazo de ACI, ĉar ĝi supozeble estas la centra kaj plej kritika parto de via datumcentro), sed ankaŭ donas al vi uzant-amika interfaco por krei agordon.
La inĝenieroj en ĉi tiu projekto uzas Excel por agordi ACI anstataŭ YAML por ĝuste la samaj celoj. Estas, kompreneble, avantaĝoj uzi Excel:
- via NIP en unu dosiero
- belaj signoj, kiujn la kliento estas agrablaj rigardi
- vi povas uzi iujn excel ilojn
Sed estas unu minuso, kaj laŭ mi ĝi superas la avantaĝojn. Kontroli ŝanĝojn kaj kunordigi teaman laboron fariĝas multe pli malfacila.
ACY estas fakte aplikaĵo de la samaj aliroj, kiujn mi uzis por la tria partio por agordi ACI.
fonto: www.habr.com