(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 #6] Automatisering av Cisco ACI-utrulling med Terraform, Vault og GitLab CI er del av en serie som dokumenterer min reise mot CCIE Automation. I forrige innlegg jobbet jeg med pipelines for verifisering og utrulling av nettverksendringer. I dette innlegget fokuserer jeg på å automatisere Cisco ACI-utrulling ved hjelp av Terraform og Vault.

Blogg #6

Etter å ha jobbet med pyATS og CI/CD i blogg #5 ønsket jeg å gå dypere inn i infrastructure as code ved hjelp av Terraform, og integrere dette med GitLab CI.

Denne gangen utforsket jeg Terraform for å utrulle og administrere Cisco ACI fabric-ressurser på en tilstandsbasert og repeterbar måte, og integrerte Vault for å håndtere secrets i Nautix-applikasjonen min.

Hvorfor Terraform?

Terraform lar oss beskrive infrastruktur deklarativt. Det er godt egnet til blant annet:

• Administrasjon av ACI tenants, VRF-er og EPG-er som kode

• Automatisk håndtering av avhengigheter mellom ressurser

• Sporing av state for å vite nøyaktig hva som er utrullet

• Bruk av løkker og variabler for repeterbare, parameteriserte utrullinger

• Sikker håndtering av secrets (Vault)

I stedet for å pushe konfigurasjon manuelt, lar Terraform koden forstå og administrere nettverkets tilstand.

Hvorfor Vault?

Vault gir en sikker måte å håndtere secrets og legitimasjon i automatiseringspipelines.

I dette prosjektet brukes Vault til å:

• Lagre ACI-brukernavn og passord sikkert

• Levere legitimasjon dynamisk til Terraform uten hardkoding

• Rotere secrets uten å måtte endre kode

• Kontrollere tilgang til sensitiv informasjon per miljø eller tjeneste

I stedet for å lagre legitimasjon i .tfvars eller Git, sørger Vault for at secrets ikke lekker, samtidig som automatiseringspipelines får tilgang til det de trenger.

Prosjektet i dette innlegget

Jeg opprettet et Terraform-prosjekt for å utrulle ACI-ressurser, integrert i GitLab CI:

• Variables (aci.auto.tfvars) – sentraliserte definisjoner for tenants, VRF-er, applikasjonsprofiler og endpoint groups

• GitLab CI (.gitlab-ci.yml) – orkestrerer Terraform-kjøringer i en pipeline

• Vault-tjeneste – Docker Compose-fil som starter Vault og andre nødvendige tjenester lokalt

Pipeline-flyt:

1. Pipelinen trigges ved å opprette en pipeline

Med nødvendige JOB_METHOD- og miljøvariabler.

2. Terraform plan-steg

• Kjøres automatisk hvis JOB_METHOD er satt til "terraform".

• Initialiserer Terraform

• Genererer en plan-fil (tfplan) som viser hva som skal opprettes eller oppdateres

  

3. Terraform deploy-steg

• Kjøres manuelt etter at planen er verifisert.
• Utfører planen og provisjonerer Cisco ACI-infrastrukturen
  

Denne stegdelte tilnærmingen sikrer trygge utrullinger og gir mulighet til å gjennomgå endringer før de tas i bruk.

Implementasjon

Mappestrukturen ser slik ut:

pipelines/jobs/setup_aci/

• main.tf – Terraform-ressurser, løkker og avhengigheter

• aci.auto.tfvars – variabler og legitimasjon for ACI-utrulling

I tillegg er følgende filer oppdatert:

• .gitlab-ci.yml – orkestrerer Terraform i CI/CD-pipelinen

• docker-compose.yml – starter Vault og andre tjenester for lokal testing

Hvordan det fungerer

La oss gå gjennom det steg for steg.

1. GitLab CI

Filen .gitlab-ci.yml binder arbeidsflyten sammen og bestemmer hvilke steg som kjøres basert på JOB_METHOD-variabelen.

• Sørger for at Terraform er installert i GitLab runneren.

• Første steg kjøres automatisk (terraform plan) og produserer en plan-fil.

• Deploy-steget (terraform apply) kjøres manuelt og utruller ACI-ressursene basert på planen.

2. Terraform

Prosjektet består av main.tf og aci.auto.tfvars.

• Providers: Cisco ACI provider for ressursopprettelse Vault provider for sikker håndtering av legitimasjon

• Vault-integrasjon: Bruker VAULT_TOKEN-miljøvariabelen (export TF_VAR_VAULT_TOKEN=root-token) for å hente secrets dynamisk.

• TENANT_NAME – navn på ACI tenant ("NAUTIX")
• APPLICATIONS – liste over applikasjoner med navn, beskrivelser og endpoint groups
• VRFS – liste over VRF-er som skal opprettes under tenant (["RED", "BLUE"])

• Oppretter en ACI tenant med navnet "NAUTIX".

• Oppretter én applikasjonsprofil per applikasjon i tenant.
• Bruker for_each-løkke slik at Terraform dynamisk oppretter profiler for
  - bluetree.no
  - upstacked.com

Endpoint groups

• Oppretter EPG-er for hver applikasjon.
• Itererer over alle endpoint_groups fra locals.endpoint_groups.
• Bruker en nøkkel som kombinerer app_name og epg_name for å sikre unike nøkler i for_each.

VRF-er

• Oppretter VRF-er for tenant, én per navn i VRFS.
• Konverterer listen til et sett for å sikre unike oppføringer.

3. Vault

En ny Vault-tjeneste er lagt til i Docker Compose-filen for å levere sikker legitimasjon til Nautix, uten å eksponere den i kode.

Hvorfor dette er viktig

I stedet for å konfigurere ACI manuelt får vi nå:

• Repeterbare og versjonskontrollerte utrullinger

• Enkel skalering ved hjelp av løkker og variabler

• Beskyttede secrets med Vault

• Automatisk håndtering av avhengigheter mellom tenants, VRF-er og EPG-er

• Sikker infrastrukturadministrasjon med Terraform og GitLab CI

Nautix-arkitektur

Hva skjer videre

I blogg #7 vil jeg fokusere på model-driven telemetry:

Blueprint item 3.4 Designe en model-driven telemetry-løsning basert på gitte forretningsmessige og tekniske krav ved bruk av gNMI dial-in, gRPC dial-out og NETCONF dial-in

Blueprint item 3.5 Opprette YANG model-driven telemetry-abonnementer
3.5.a Identifisere modelelementer og kadens
3.5.b On-change eller event-drevet
3.5.c Optimalisere frekvens
3.5.d Dial-out abonnement
3.5.e Sikre telemetry-strømmer
3.5.f Bekrefte datatransmisjon
3.5.g Identifisere nettverksproblemer og gjøre endringer

Nyttige lenker

• GitLab Repo – Min CCIE Automation kode
• Terraform dokumentasjon
• Terraform Cisco ACI provider dokumentasjon
• Vault dokumentasjon

Bloggserie

• [Min reise mot CCIE Automation #1] Introduksjon + bygging av en Python CLI-applikasjon

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

• [Min reise mot CCIE Automation #3] Orchestration API og NETCONF

• [Min reise mot CCIE Automation #4] Automatisering av nettverksoppdagelse og rapporter med Python og Ansible

• [Min reise mot CCIE Automation #5] Bygging av nettverkspipelines for pålitelige endringer med pyATS og GitLab CI

• [Min reise mot CCIE Automation #7] Utforsking av Model-Driven Telemetry for sanntidsinnsikt i nettverket

• [Min reise mot CCIE Automation #8] Utforsking av ThousandEyes og automatisering av Enterprise Agent-utrulling

• [Min reise mot CCIE Automation #9] Anvendelse av OWASP Secure Coding Practices

• [Min reise mot CCIE Automation #10] Fra Docker Compose til Kubernetes