Hva er hovedfokuset i blogg #2 av CCIE Automation-reisen?

Blogg #2 handler om å gå fra et enkeltstående verktøy til en modulær løsning bygget som en mikrotjenestearkitektur, der et Inventory REST API blir kjernen i applikasjonen.

Hva er Inventory REST API-et i denne løsningen?

Inventory-tjenesten fungerer som et REST API for å opprette, lese, oppdatere og slette (CRUD) modeller for enheter og lenker. I tillegg tilbyr den et endepunkt for å hente full topologi (alle enheter og koblinger) i ett kall.

Hvilken teknologi brukes for å bygge API-et?

API-et bygges med Flask og Flask-RESTx for REST-endepunkter og OpenAPI-dokumentasjon. Flask-SQLAlchemy brukes som ORM for databaseoperasjoner, med SQLite som et lettvekts utgangspunkt.

Hvorfor velges mikrotjenester i stedet for ett samlet script?

Mikrotjenester gjør løsningen mer modulær og utvidbar. Hver tjeneste kan fokusere på et avgrenset ansvar, og arkitekturen gjør det enklere å legge til nye tjenester etter hvert som flere blueprint-temaer dekkes.

Hvordan er containerisering og kjøring løst?

Tjenestene kjøres i containere og orkestreres med Docker Compose. Dette gir en praktisk måte å kjøre flere komponenter samlet, og legger samtidig grunnlag for en senere overgang til Kubernetes.

Hvordan samhandler tjenestene (Inventory, Automation, Topology)?

Automation Service henter enheter og koblinger fra Catalyst Center via API og sender data inn i Inventory API for å holde inventaret oppdatert. Topology Service henter deretter data fra Inventory API og genererer topologi-visualisering som eksponeres via Nginx.

Hva er planen videre i serien?

Etter en sommerpause fortsetter blogg #3 med fokus på NETCONF og YANG, inkludert bygging av payloads, filtre og konfigurasjon av enheter ved hjelp av NETCONF og YANG-verktøy.

Hvordan kan Sicra hjelpe?

Sicra kan bistå med å designe og gjennomføre automatiserings- og arkitekturprosjekter som kombinerer nettverk og programvareutvikling, inkludert API-integrasjoner, containerbasert drift og sikker utviklingspraksis. Les mer om "Nettverk" her > Les mer om "Sikker software-utvikling" her > Les mer om "Cloud-løsninger (Azure, AWS, Google)" her > Les mer om "Prosjektledelse" her >

[Min reise mot CCIE Automation #2] Inventory REST API og mikrotjenestearkitektur

(Denne artikkelen var tidligere en del av Bluetree.no. Siden Sicra og Bluetree har slått seg sammen, er nå innhold fra Bluetree overført til Sicra.)

[Min reise mot CCIE Automation #2] Inventory REST API og mikrotjenestearkitektur er del av en serie som dokumenterer min reise mot CCIE Automation. I det første innlegget introduserte jeg studieløpet og bygget en Python CLI-applikasjon. Denne gangen fokuserer jeg på å bygge et Inventory REST API og etablere grunnlaget for en mikrotjenestearkitektur.

Blogg #2

Denne gangen markerte et tydelig retningsskifte. I stedet for å bygge isolerte verktøy har jeg begynt å utvikle en større applikasjon bestående av flere mikrotjenester, der hver tjeneste dekker relevante temaer fra blueprinten.

Alt kjører nå i containere via Docker Compose, med en fremtidig overgang til Kubernetes i bakhodet. Denne tilnærmingen føles mer praktisk, mer modulær – og ærlig talt også morsommere.

Denne gangens hovedfokus i blueprinten var:

2.1 Bygg, forvalt og drift et Python-basert REST API med et webapplikasjonsrammeverk

I tillegg var jeg også innom følgende punkter:

4.1 Lage et Docker-image (inkludert Dockerfile)
4.2 Pakk og distribuer en løsning ved å bruke Docker Compose

Blogg fokus #2: Inventory API og tjenestearkitektur

Hovedresultatet denne gangen var utviklingen av Inventory API-et – nå en selvstendig mikrotjeneste som utgjør ryggraden i applikasjonen.

Inventory-tjenesten
Fungerer som et REST API for CRUD-operasjoner på enhets- og link-modeller. I tillegg kan man hente full topologi (alle enheter og koblinger) gjennom ett separat API-kall.

Teknologistack:

Flask og Flask-RESTx for REST API og OpenAPI-dokumentasjon
Flask-SQLAlchemy for ORM og databaseoperasjoner
SQLite som et lettvekts utgangspunkt (med planer om å gå over til Postgres senere)
Dockerfile for å containerisere tjenesten
Docker Compose for å orkestrere flere tjenester sammen

Refaktorering av kode fra blogg #1 til tjenester

For å bevege meg mot en mer modulær mikrotjenestearkitektur har jeg delt opp scriptet fra blogg #1 i to dedikerte tjenester:

Automation Service

Henter periodisk (via cron-jobb) enheter og koblinger fra Catalyst Center API
Pusher dataene inn i Inventory API-et for å holde inventory oppdatert

Topology Service

Spør periodisk Inventory API-et etter gjeldende enhets- og link-data
Genererer nettverkstopologi-tegninger som eksponeres via Nginx

Samspill mellom tjenester

architecture

- Å hei - la du merke til det?

Applikasjonen har nå fått et navn – Nautix!

Navnet er en blanding av network, automation og det klassiske -ix-suffikset som får det til å høres ut som det gjør langt mer enn det egentlig gjør. Og for å være helt ærlig – det høres også litt rampete ut, noe som passer bra siden applikasjonen neppe er produksjonsklar med det første.

Modulær og utvidbar arkitektur

Denne mikrotjenestemodellen gjør det enklere å skalere løsningen og samtidig holde den tett opp mot CCIE Automation-blueprinten:

Jeg vil fortsette å bygge nye tjenester etter hvert som jeg jobber meg gjennom studieplanen – for eksempel orkestreringstjenester, helsesjekk-tjenester eller telemetritjenester.
Eksisterende tjenester som Inventory, Automation og Topology vil også bli forbedret og utvidet med mer avansert funksjonalitet etter hvert som nye blueprint-temaer dekkes.

Refleksjoner #2

Jeg hadde ingen tidligere erfaring med Flask, men bakgrunnen min fra Django gjorde konsepter som ruting, modeller og serialisering intuitive.
Jeg likte veldig godt å jobbe med Flask-RESTx – det er en applikasjon med lavt ressursforbruk, intuitivt og gir både input-validering og OpenAPI-dokumentasjon nesten gratis.
Docker Compose vil fremover være fundamentet for å kjøre alle nye tjenester i denne CCIE-forberedelsesapplikasjonen.
Persistente data for SQLite i Docker var enklere å få til enn forventet ved hjelp av volume mounts.
Jeg kjører foreløpig miljøvariabler direkte når jeg starter docker-compose som en midlertidig løsning, frem til jeg kommer til blueprint-punktet om secrets management.
Det er helt sikkert mye som kan forbedres, men akkurat nå er jeg veldig fornøyd med fremdriften denne gangen.

Hva skjer videre (etter sommerferien)

Jeg tar nå en kort sommerpause og fortsetter CCIE Automation-studieplanen igjen i siste uke av august. Blogg #3 vil ha fullt fokus på NETCONF:

Blueprint-punkt 2.4 Opprett en NETCONF-payload basert på en gitt YANG-modul, og tolk responsen

Blueprint-punkt 2.5 Opprett et NETCONF-filter ved bruk av XPath

Blueprint-punkt 2.6 Konfigurer nettverksenheter i en eksisterende infrastruktur ved hjelp av NETCONF og YANG-analyseverktøy

Jeg har valgt å fokusere utelukkende på NETCONF i blogg #3. Det blir flere mikrotjenester, mer XML og YANG-verktøy – og selvfølgelig enda mer Docker.