Jag har tidigare skrivit om hur man kan få ordentlig utväxling av Cisco DNA Center först när man skriver lite extern kod i Python. Vi kan göra mycket med hjälp av webgränssnittet, vi får viss automation på nätet men kommer inte helt ifrån att vi agerar mänsklig middleware. Här kommer ett inlägg kring hur du med enkla medel som GIT, vinner både tid och kvalitet.
Oavsett om du är en person som jobbar med flera installationer, eller flera personer som jobbar med en installation, så har ni en operationell modell som kräver att man tänker till – vad är er ”single source of truth”?
Om vi skulle slå på synkronisering mellan tre olika Cisco DNA Center installationer, vilken är det som har “rätt” information? Den med senaste ändringen? Även om den ändrats av misstag? Och när ni är flera som gör ändringar, hur informerar du dina kollegor om att du ändrat i en mall? Vad händer om en annan kollega just ändrat i samma mall, vilken gäller? Och hur bär vi oss åt för att få ut den templaten vi testat i labbmiljön till produktion?
Sanningen heter GIT
Så fort vi jobbar med ett mer distribuerat arbetssätt är det en god idé att fundera på att hålla till exempel templates i ett externt repository – det kan vara en gemensam managementserver, eller GIT. Då får du ett bra verktyg där flera personer kan arbeta med samma filer och det är smidigt att synka innehållet till flera destinationer. Vi har också en utpekad source-of-truth – det som ligger på GIT är det vi skjuter ut till våra switchar och routrar.
Hantera templates med kod
Något som en del anser saknas i DNA-Center är möjlighet att synkronisera inställningar mellan kluster i de fall där nätet är så pass stort att man behöver flera separata uppsättningar. Jag tycker att funktionen redan finns, i form av ett välfungerande API!
Nej, du letar inte efter en till appliance som synkroniserar inställningar åt dig – du letar efter ett modernt arbetssätt! För allvarligt talat, vill du vara den personen som driftar ett multinationellt nätverk helt och hållet genom att klicka runt i webbgränssnittet?
Vi tittar lite på hur man kan hantera just templates på ett sätt som skalar med stöd av GIT och lite Python (psst – och missa inte vår kostnadsfria heldagsworkshop nedan):
Låt oss koda lite – först hämtar vi templates till GIT
DNA-Center har ett bra API, och mer och mer kommer i varje uppdatering, vi kan via REST hämta(GET) skapa (POST), ändra (PUT) och ta bort (DELETE) både templates och projekt, det är egentligen allt vi behöver för att lyfta ut hela hanteringen av templates från DNA Center till ett externt repository, GIT.
Om vi tittar på exemplet ovan, så resulterar det i att vi får en dictionary som heter ’data’ som innehåller hela strukturen för dina projekt och vilka templates som ligger däri, outputen kommer se ut ungefär så här:
[
{
”name”: ”day-N”,
”id”: ”aed26255-e714-419e-8575-e2a2113837fa”,
”templates”: [
{
”name”: ”switch_hostname”,
”composite”: false,
”id”: ”418e2f7a-78a1-490f-9377-e3ae4013b559”
},
{
”name”: ”switch_etherchannel”,
”composite”: false,
”id”: ”e4a0e9b2-470f-47a0-81f3-5f357e1ea7c2”
}
],
”isDeletable”: true
}
]
Och för att tolka det som en katalogstruktur kan man se det som att projektet, eller mappen ”day-N” innehåller två olika templates: ”switch_hostname” och ”switch_etherchannel”.
Därefter skulle vi kunna säga att för varje template i projektet ’day-N’ vill jag hämta hem hela templaten, det är också ganska enkelt med Python:
Och visst, därefter skriver vi bara varje template till en fil så har vi synkroniserat ner alla önskade templates till den dator vi kört Python-scriptet från eller lägger dom på en delad yta!
Nu kan vi hantera våra templates som json:
Och om vi vill ladda upp templates till DNA Center?
Då gäller så klart omvänd logik, istället för att hämta hem (GET) så har vi två val beroende på vad vi vill göra:
Om vi vill uppdatera en existerande mall, vi kanske bara ändrat lite parametrar och är nöjda, så är det en PUT vi ska göra och då kan du helt enkelt bara PUTta upp templaten till DNA Center.
Är det så att vi hämtat mallar från en DNA Center, och potentiellt vill skjuta ut samma template till en annan DNA Center blir det något mer att tänka på. Vi kan då inte använda templatens id för att identifiera templaten, och vi kan heller inte ha med elementet ’id’ i templaten när vi uppdaterar en template för då skulle DNA Center tro att vi refererar till en existerande template, som ju inte finns där. Id’t genereras av DNA-Center i samband med att vi skapar ett objekt, och det kommer vara unikt mellan olika DNA Center. Men det är bara att vi gör en POST med samma payload, men vi får ta bort de element som DNA Center kan bråka om:
Om man vill göra det enkelt – ezdnac
Oavsett om du är van att koda och bara vill ha något att utgå ifrån, eller ny och vill ha något klart att använda kan du ladda ner modulen ezdnac (easy dna-c). Där har jag i senaste versionen lagt till två funktioner – pullTemplates och pushTemplates som gör just de här sakerna. Vi kan titta på ett par exempel hur det skulle kunna se ut.
from ezdnac import apic
dna = apic('10.10.100.50', 'admin', 'weakPassword', timeout=2)
print (dna.pullTemplates())
De här tre raderna initierar din DNA Center och hämtar alla templates i samtliga projekt, dessa laddas ner och sparas som separata filer så att du kan administrera dom lokalt. Du kan välja att skicka med argumenten ’path’ och/eller ’project’, om du vill synka ner filerna till en specifik katalog eller om du bara vill ha templates för ett specifikt projekt.
Exempel:
dna.pullTemplates(path='templates/', project='day-N')
När vi sedan kör Python-scriptet och tittar i katalogen vad som hänt så ser vi nu en hel del nya filer:
Säg att vi nu synkat ner alla templates från vår första DNA Center, den som till idag ägt hela världsbilden vad gäller templates, ner till vår gemensamma managementserver, eller GIT. Från idag kanske det är här vi gör ändringar, och antingen schemalagt eller manuellt efter att någon gjort en ändring kan vi se till att alla våra DNA Center får samma templates.
from ezdnac import apic
dnaEurope = apic('10.10.100.50', 'admin', 'weakPassword', timeout=2)
dnaUSA = apic('10.20.100.50', 'admin', 'worsePassword', timeout=2)
dnaAPAC = apic('10.30.100.50', 'admin', 'horriblePassword', timeout=2)
print (dnaEurope.pushTemplates(path='templates/'))
print (dnaUSA.pushTemplates(path='templates/'))
print (dnaAPAC.pushTemplates(path='templates/'))
Med några rader Python-kod har vi då synkat upp alla templates som finns i katalogen ’templates’ till våra geografiskt spridda DNA Center installationer. I den här funktionen kommer ezdnac att:
1. Kolla om projektet finns
2. Kolla om templaten finns
3. Om projektet inte finns, skapa projekt med samma namn
4. Om templaten inte finns, skapa template med samma namn
5. Om templaten finns sedan tidigare, uppdatera så att den ser ut såsom den vi gjorde en push från.
Hur långt kan man dra automation med GIT?
Det går att dra precis hur långt man vill, kommer man så långt att man har en modell som gör det enkelt att arbeta strukturerat har man redan vunnit massor. Man kan också dra det hela vägen till att köra CI/CD – continuous integration & delivery för sitt nätverk.
Det skulle kunna gå till som att när du gör en ändring på en template och gör en merge i GIT triggas automatiskt ett jobb som lyfter in din ändrade template i en virtuell labbmiljö, gör faktiska funktionstester – finns de routes jag förväntar mig? Har jag adjacency mellan alla routrar? Fungerar det fortfarande att nå alla destinationer i labbet?
Om alla tester flyter på bra kan samma ändring flyttas ut i produktion och tryckas ut till alla dina enheter. Det innebär alltså en riktig funktionstest av dina förändringar i labb innan du aktiverar en ändring – helt automagiskt.
Vill du ha hjälp att komma igång med ett klokare arbetssätt? Börja koda Python till någon av Ciscos produkter eller diskutera hur ni skulle kunna ta klivet längre mot en mer automatiserad arbetsmetodik? Kontakta oss på Conscia!
Johan Lahti är CCIE certifierad inom Routing & Switching och har lång erfarenhet av stora enterprisenät och service provider. Han har senaste åren jobbat allt mer med automation i olika slag av både deployment och drift av nätverk. Johan bloggar ibland på Shiproute, varifrån vi fått låna denna text. Läs mer om Johan här.
