Cisco automatisering for udviklere: Wingpy under lakken

Du har sikkert allerede forsøgt at automatisere Cisco-infrastruktu, har du sandsynligvis stødt på de samme problemer som os: inkonsistente SDK’er, besværlige autentificeringsflows og alt for meget tid brugt på at oversætte API-dokumentation til brugbar kode.

Vi lavede wingpy for at løse det.

Dette indlæg er til udviklere og netværksteknikere, der allerede er komfortable med Python – men trætte af at opfinde den dybe tallerken hver gang de arbejder med en ny Cisco-platform.

Problemet: for mange SDKer og for lidt konsistens

Ciscos API’er er kapable og forholdsvis omfattende, men ikke altid ligefrem udviklervenlige. Hver platform (ISE, FMC, DNAC osv.) har sit eget SDK – eller værre, intet SDK overhovedet. Selv når de findes, har de ofte følgende problemer:

  • Kræver manuel token-håndtering
  • Mangler async-understøttelse
  • Følger ikke konsistente mønstre
  • Er tæt koblet til specifikke versioner eller platforme

Det er fint til engangsscripts. Men hvis du bygger genanvendelig automation eller integrerer i et større system, bliver det hurtigt rodet. Prøv bare at se tabellen her, som er et eksempel på nogle af de forskelle der er, og det er ikke engang et komplet overblik over platforme som wingpy allerede understøtter.

Hvad wingpy gør anderledes

Wingpy er et open source Python-bibliotek, der pakker Cisco API’er ind i et konsistent, modulært og udviklervenligt interface. Det er bygget oven på httpx, understøtter både synkrone og asynkrone workflows og abstraherer boilerplate koden – som f.eks. autentificering, sidehåndtering, token-fornyelse, backoff og parallel eksekvering.

Her er et eksempel på, hvordan det ser ud i praksis:

Platform name Authentication flow Session lifecycle Pagination Rate limiting
APIC (ACI)
  1. POST username and password in payload to /api/aaaLogin.json
  2. Retrieve imdata[0].aaaLogin.attributes.token from response payload.
  3. Send the token as an HTTP Cookie named APIC-Cookie in subsequent reqeusts
 Token has variable lifetime and must be refreshed periodically. Query parameters: page-size and page
Total size in is defined as number of resources in totalCount		 HTTP status code 503
Catalyst Center
  1. POST username and password with a Basic Authentication header to /dna/system/api/v1/auth/token
  2. Retrieve Token from response payload.
  3. Send the token as an HTTP Header named X-auth-token in subsequent reqeusts
 Token has fixed lifetime of 3600 seconds and must be refreshed periodically. Query parameters: offset and limit
Total size is not visible.		 HTTP status code 429 without Retry-After header.
FMC (Firepower)
  1. POST username and password with a Basic Authentication header to /api/fmc_platform/v1/auth/generatetoken
  2. Retrieve X-auth-access-token from response headers.
  3. Send the token as an HTTP Header named X-auth-access-token in subsequent reqeusts
 Token has fixed lifetime of 1800 seconds and must be refreshed periodically. Query parameters: offset and limit
Total size defined as number of pages in paging.count		 HTTP status code 429 without Retry-After header.
Enforced per HTTP method per minute.
Under heavy load: HTTP status codes 500 and 504.
Hyperfabric Include a static Bearer token in Authorization header in all requests Never expires. Not supported. HTTP status code 429 without Retry-After header.
ISE Include username and password as a Basic Authorization header in all requests. Never expires. Query parameters: size and page
For OpenAPI endpoints total size is not visible.
For ERS endpoints total size is defined as number of resources in SearchResult.total		 No rate limiting.
Meraki Dashboard Include a static Bearer token in Authorization header in all requests Never expires. For first page use query parameter perPage
For subsequent pages search the link header in previous page reponse for the RegEx pattern <(\S+?)>; rel=next(?:,\|$)
Total size is not visible.		 Most endpoints use HTTP status code 429 with delay-seconds based Retry-After header.
Some endpoints return HTTP status code 400.

 

from wingpy import CiscoFMC

# Opret forbindelse til Cisco Firepower Management Center (FMC)
fmc = CiscoFMC(
    base_url="https://fmc.example.com",
    username="admin",          # brug en servicekonto i praksis
    password="password",       # læg credentials i miljøvariable i produktion
    verify=False,              # slå cert-verificering til i produktion
)

# Hent alle host-objekter (indsæt din faktiske domain UUID)
domain_uuid = "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx"

hosts = fmc.get_all(
    f"/api/fmc_config/v1/domain/{domain_uuid}/object/hosts",
    expanded=True,
)

# Eksempel: print navn og IP-værdi
for item in hosts.get("items", []):
    print(item.get("name"), item.get("value"))

Hov! {domainUUID}??
Wingpy erstatter den automatisk. Du kan kopiere stier direkte fra Ciscos API-dokumentation, og de vil fungere uden ændringer.

Bygget til Udviklere

  • Konsistente signaturer: Uanset om du kalder get(), post() eller get_all(), er interfacet forudsigeligt.
  • Async-klar: Bygget på httpx, så du kan skalere med async hvis nødvendigt.
  • Skalerbart: Du kan subclass’e eller wrappe klienterne til din egen arkitektur.

Vi har også holdt det let – ingen tunge afhængigheder, ingen frameworks. Bare ren, komponerbar Python.

Open source med rammer

Wingpy er open source og tilgængelig på PyPI og GitHub, men med et fokuseret scope. Selvom kildekoden og dokumentationen er offentlige, er vores interne test-suite og CI/CD pipelines (hostet i Azure DevOps) ikke. Vi accepterer i øjeblikket ikke eksterne bidrag, men vi modtager gerne fejlrapporter og feedback via GitHub issues.

Det hjælper os med at opretholde kvalitet og konsistens, samtidig med at vi giver fællesskabet et pålideligt værktøj at bygge videre på.

Prøv det

Installer wingpy med:

pip install wingpy

Vi har gjort os umage med dokumentationen hvor du kan læse tilpassede brugervejledninger og API-referencer. Uanset om du skriver et hurtigt script eller bygger en fuld automatiseringspipeline, er wingpy her for at gøre dit liv lidt lettere.