Automatizace konfigurací

Proč automatizovat konfiguraci síťových zařízení

Automatizace konfigurací pomocí skriptů zásadně zvyšuje rychlost nasazení změn, konzistenci a auditovatelnost správy routerů a switchů. V prostředích s desítkami až tisíci zařízení se ruční CLI operace rychle stávají rizikovými, nákladnými a těžko dohledatelnými. Skripty (typicky v Pythonu) ve spojení s source of truth (např. NetBox), šablonováním (Jinja2) a síťovými API (NETCONF/RESTCONF/gNMI) umožňují zavést deklarativní, opakovatelný a testovatelný proces změn.

Architektura: od zdroje pravdy po orchestraci

• Source of Truth (SoT): centrální evidence zařízení, rozhraní, IP plánů, rolí a politik (např. NetBox). Skripty nečtou stav z náhodných excelů, ale z jednotného API.
• Inventář a proměnné: metadata o zařízeních (vendor, OS, přístupové metody, přihlašovací údaje) udržujte v Git/NetBox a poskytujte skriptům jako datový vstup (YAML/JSON).
• Orchestrace: nástroje jako Ansible nebo Nornir koordinují paralelní běhy, batchování, retry a idempotenci na úrovni tasků.
• Transportní vrstvy: SSH/CLI knihovny (Netmiko), modelově řízené protokoly (NETCONF, RESTCONF, gNMI) a vendor API (Meraki, DNAC, ACI).

Volba nástrojů: skriptovací jazyky a knihovny

• Python: de facto standard pro síťovou automatizaci. Klíčové balíčky: Netmiko (CLI/SSH), NAPALM (multi-vendor abstrakce), Nornir (orchestrace), Jinja2 (šablony), Requests (REST API), ncclient (NETCONF), pygnmi (gNMI), pyATS/Genie (testy a parsování výstupů).
• Ansible: deklarativní playbooky, bohatý ekosystém modulů (ios_config, junos_config, ios_facts), integrace s Vault a CI/CD.
• Bash/PowerShell: vhodné pro jednoduché pipeline, plánování úloh a lepitko kolem Pythonu (cron, systemd timers, Windows Task Scheduler).

Modelově řízená automatizace: NETCONF, RESTCONF, gNMI a YANG

• YANG modely: formální popis konfiguračních a stavových dat; snižují vendor-lock tím, že sjednocují datové struktury.
• NETCONF/RESTCONF: transakční operace (candidate, commit, rollback-on-error), validace proti YANG; bezpečný kanál přes SSH/TLS.
• gNMI: telemetrie a set/get operace; výhodný u moderních NOS s rich streamingem.
• Volba přístupu: pokud platforma podporuje plnohodnotné API, preferujte je před screen-scraping CLI; CLI automatizaci ponechte pro legacy.

Šablonování konfigurací: Jinja2 a oddělení logiky od dat

Konfigurace generujte ze šablon, kde proměnné (z NetBoxu či inventáře) doplňují síťové parametry. Tím dosáhnete konzistence a opakovatelnosti.

• Struktura projektu: templates/ pro Jinja2, data/ pro YAML s proměnnými, output/ pro rendery, scripts/ pro orchestrace.
• Ukázka úseku šablony Jinja2 (bez <pre>):
  interface {{ uplink.ifname }}
 description Uplink to {{ uplink.neighbor }}
 ip address {{ uplink.ip }}/{{ uplink.mask }}
 no shut
• Validace výstupu: generované konfigurace validujte proti YANG (kde lze) a statickým politikám (lint).

Idempotence a deklarativní přístup

• Idempotence: opakované spuštění stejného playbooku/systému nesmí vytvářet rozdíly. Porovnávejte candidate vs. running a aplikujte pouze dify.
• Desired State: konfigurace je cílový stav odvozený ze SoT; změny se neprovádí ručně na zařízení, ale v datech SoT a šablonách.
• Drift management: průběžně detekujte odchylky (telemetrie, compliance skeny) a automaticky je narovnávejte v údržbových oknech.

Bezpečnost: tajemství, audit a politiky

• Secrets management: žádné heslo v kódu; používejte Ansible Vault, HashiCorp Vault, KMS. Rotujte přístupy a auditujte re-use.
• Minimální oprávnění: účty pouze s nutnými právy, oddělení read-only a write rolí, schvalovací brány v CI.
• Šifrovaná komunikace: NETCONF/SSH, RESTCONF/TLS, ověřené certifikáty a pevné kryptografické politiky.
• Auditovatelnost: logování všech změn do SIEM, včetně diffu konfigurace a identity volajícího.

Testování před nasazením: syntaktické, sémantické a topologické

• Lint a syntaktická kontrola: validujte generované konfigurace (např. custom parsery, pyATS/Genie pro show výstupy v testbedu).
• Topologická analýza: Batfish pro ověření cest, ACL, reachability a „co se stane po změně“; minimalizuje black-outy.
• Lab a simulace: EVE-NG/GNS3/CML pro testy šablon a rollback scénáře před produkcí.

Pipeline CI/CD pro síťové konfigurace

• Git jako zdroj pravdy: PR proces s code review pro šablony i data. Každá změna prochází testy a statickou validací.
• Stages: render šablon → lint/validace → Batfish/pyATS testy → dry-run na pilotních zařízeních → řízený rollout.
• Artefakty: ukládejte rendery, dify, test reporty a podpisy buildů pro audit.

Rollout strategie a návrat z chyb

• Canary/batch: aplikujte změny nejprve na vzorek (např. 5 % switchů v jedné lokalitě) a vyhodnoťte metriky.
• Údržbová okna: respektujte SLA a časové zóny; skripty musí umět pauzovat/retry.
• Rollback: automatické uložené body (rollback-on-error u NETCONF), zálohy startup-config/running-config před změnou, „golden config“ pro emergency návrat.

Telemetry a ověření po změně

• Post-checky: skript bezprostředně po deployi ověřuje BGP sousedy, OSPF adjacency, stav portů, chybovost rozhraní a latenci.
• Streaming telemetry: gNMI/Telegraf/Prometheus/Grafana pro kontinuální monitorování KPI a včasnou detekci regrese.

Ukázky praktických úloh skripty (koncepty)

• Záloha konfigurací (Netmiko):
  for device in inventory:
  conn = ConnectHandler(**device)
  cfg = conn.send_command("show running-config")
  save(cfg, "backups/{hostname}-{date}.cfg")
• Konfigurace VLAN z YAML + Jinja2:
  vlans = load_yaml("data/vlans.yaml")
render = jinja("templates/vlan.j2", vlans)
napalm.load_merge_candidate(config=render)
napalm.commit_config()
• Bezvýpadková změna BGP souseda (NETCONF):
  edit-config target=candidate
validate → commit-confirmed 300
post-check → commit
fail → discard-changes

Integrace s NetBox a CMDB

• Čtení dat: přes REST API NetBoxu načtěte role, zařízení, IP, VRF a vztahy uplinků; generujte z nich šablony.
• Obousměrný tok: po úspěšném deployi aktualizujte metadata (např. verzi NOS, timestamp poslední změny, audit záznamy).
• Validace konzistence: pravidelně porovnávejte běhový stav s CMDB a řešte drift.

Vícevendorová směs: abstrakce a specifika

• Abstrakce: NAPALM/Nornir sjednocují běžné úlohy (fakty, konfigurace), ale vendor-specifické nuance řešte dedikovanými rolemi/filtry Jinja2.
• Podmíněné šablony: vkládejte bloky podle vendor, model, os_version; dodržujte common core + vendor overrides.

Provozní provoz a plánování

• Plánovače: cron/systemd timers pro rutiny (zálohy, compliance skeny), centralizované orchestrátory pro změny (AWX/Ansible Tower).
• ChatOps: schválení a spouštění přes Slack/Teams s auditním logem a dry-run výstupy difů před potvrzením.

Compliance a standardy

• Policy as Code: definujte bezpečnostní a konfigurační pravidla (např. zakázané protokoly, povinné banner/ACL) v testech pipeline.
• Golden Config: minimální baseline (NTP, syslog, AAA, SNMPv3, SSH ciphers, login banner) vynucovaná idempotentně.
• Evidence změn: každá změna má ticket, PR, dify a sign-off vlastníka služby.

Výkonnost a škálování automatizace

• Paralelizace: řízená míra paralelismu dle lokality a typu zařízení; vyhněte se masivním „thundering herd“.
• Rate limiting a backoff: chraňte kontrolní plane zařízení, respektujte API kvóty kontrolerů.
• Observabilita pipeline: metriky do Promethea (počet úspěchů/selhání, latence, velikost generovaných konfigů).

Typické chyby a jak jim předcházet

• Ad-hoc skripty bez SoT: bez centrálních dat roste chaos; standardizujte inventář a datové modely.
• Bez testů a dry-run: vždy validujte a zobrazujte dify před commitem.
• Tajemství v Gitu: okamžitě zaveďte Vault, revokujte kompromitované klíče a rotujte přístupové údaje.
• Vendor lock ve šablonách: oddělte common a vendor specifika, dokumentujte rozdíly a verzujte je.

Checklist pro produkční připravenost automatizace

• Definovaný SoT (NetBox/CMDB) a verzované šablony + data v Git.
• CI pipeline s renderem, lintem, testy (Batfish/pyATS) a povinným review.
• Idempotentní implementace, dry-run a batch/canary rollout.
• Bezpečné zacházení s tajemstvími, audit logy a RBAC.
• Rollback plán, zálohy před změnou a post-change ověření.
• Monitoring pipeline a telemetrie síťových KPI.

Závěr: od skriptu k řízené síťové výrobě

Automatizace konfigurací pomocí skriptů není jen o nahrazení ručního psaní příkazů. Jde o zavedení procesu s jasnými daty, šablonami, testy, bezpečností a auditovatelností. Kombinací SoT, modelově řízených API, šablonování a CI/CD získáte předvídatelné releasy, rychlou obnovu po chybě a síť, která se chová jako kód – transparentně, opakovatelně a škálovatelně.