企业网络自动化：NetBox、Nornir、Ansible与Git实战
网络自动化最常见的失败方式，是拿一份不准确的 Excel 清单直接批量下发命令。真正可持续的体系应先建立可信数据源，再生成配置、执行预检查、分批变更、验证结果并保存审计证据。本文以 NetBox 作为 Source of Truth，配合 Git、Ansible 和 Nornir 构建生产闭环。
网络设备命令和能力因厂商、型号、系统版本而异。任何自动下发都必须先在实验环境和单台低风险设备验证，并准备带外管理和回滚路径。
一、自动化不是批量SSH
成熟的变更链路应是：
需求/工单
↓
NetBox事实源
↓
校验与配置渲染
↓
Git评审与审批
↓
预检查和差异预览
↓
灰度下发
↓
业务验证
↓
回写状态与审计
如果资产、接口、VLAN、IP 或线路数据不可信，自动化只会更快地放大错误。
二、职责边界
NetBox
保存设备、机架、站点、接口、线路、VLAN、VRF、前缀、IP、租户、标签和自定义字段。它描述“期望状态与事实”，不应被当成实时监控数据库。
Git
保存模板、变量模型、自动化代码、测试和评审历史。敏感凭据不应直接提交到仓库。
Ansible
适合声明式模块、标准化 Playbook、批量任务和已有运维团队流程。
Nornir
是 Python 自动化框架，适合复杂并发、细粒度过滤、自定义流程和结果处理。
NAPALM/Netmiko/Scrapli
提供多厂商抽象或 CLI/NETCONF/SSH 连接能力。应根据平台支持选择，而不是强求所有设备使用同一驱动。
三、设计NetBox数据模型
先定义命名和唯一性：
- Region、Site、Location；
- 机房、机柜、U 位；
- Manufacturer、Device Type、Platform；
- Device Role；
- Tenant；
- VRF、VLAN Group、VLAN；
- Prefix、IP Address；
- Circuit、Provider；
- 接口、聚合口、线缆连接；
- 配置上下文与自定义字段。
常见自定义字段：
- 管理域和负责人；
- 变更窗口；
- 设备重要级别；
- 高可用组；
- Loopback、Router ID；
- 自动化允许级别；
- 配置模板版本；
- 上次备份和验证时间。
不要把所有字段都塞进设备备注。结构化字段才能校验、筛选和生成配置。
四、数据治理
事实源要有责任人和更新流程：
- 新设备入库前创建对象；
- 地址和 VLAN 从 NetBox 分配；
- 变更先修改期望状态并进入评审；
- 自动化执行后回写运行状态或差异；
- 退役时释放地址、线路和机柜资源；
- 定期发现孤立 IP、重复序列号、断开的接口和过期设备。
关键约束应自动校验：
- 主机名唯一；
- 管理 IP 唯一；
- 同一 VLAN/VRF 的前缀合法；
- 接口速率和介质与设备类型匹配；
- MLAG/堆叠成员数量正确；
- 线路两端完整；
- 自动化目标具备平台和驱动字段。
五、API与动态清单
NetBox 提供 REST API 和 GraphQL。查询时使用只读令牌、最小权限和分页，避免脚本获取全部字段。
Ansible 可使用 NetBox inventory plugin，按站点、角色、平台或标签生成组。清单只负责目标和变量来源，不应在多个地方重复维护相同地址。
示例逻辑：
plugin: netbox.netbox.nb_inventory
api_endpoint: https://netbox.example.com
token: "{{ lookup('env', 'NETBOX_TOKEN') }}"
validate_certs: true
group_by:
- sites
- device_roles
- platforms
query_filters:
- status: active
- tag: automation-enabled
令牌通过密钥系统或流水线变量注入，不写入 Git。
六、配置模板工程化
Jinja2 模板应与数据 Schema 配套，避免在模板中堆积大量业务判断。
推荐目录：
network-automation/
├── inventories/
├── models/
├── templates/
│ ├── cisco_ios/
│ ├── huawei_vrp/
│ └── h3c_comware/
├── roles/
├── tests/
├── playbooks/
└── docs/
模板输出前执行：
- 必填字段校验；
- IP、掩码、ASN、VLAN 范围校验；
- 接口名称标准化；
- 平台能力矩阵校验；
- 生成配置语法检查；
- 与黄金样例对比。
厂商差异应由平台适配层处理。不要用一个巨大模板通过几十个 if 兼容所有设备。
七、配置备份与差异
定期拉取运行配置，规范化动态字段后存入受控仓库或备份系统。需要过滤密码散列、SNMP community、私钥和其他敏感内容。
每次变更前保存：
- running/startup configuration；
- 设备版本、启动镜像和补丁；
- 邻居、路由、链路聚合和冗余状态；
- 变更前业务探测结果；
- NetBox 对象版本。
差异预览要区分命令顺序变化与真实语义变化。部分平台配置回显会重排，单纯文本 diff 容易产生噪声。
八、Ansible安全执行
- name: Precheck device facts
hosts: edge
gather_facts: false
serial: 1
max_fail_percentage: 0
tasks:
- name: Collect facts
ansible.netcommon.cli_command:
command: display version
register: version_output
changed_when: false
生产原则：
- 使用厂商模块优先于裸
shell； - 设置
serial，先单台灰度； - 预检查失败即停止；
- 变更与验证分成明确阶段；
- 结果写入工单和制品；
- 设备命令设置合理超时；
- 禁止全网无限并发；
- 不把失败设备默默跳过。
九、Nornir并发与过滤
Nornir 可按 inventory 属性筛选目标并控制 worker。并发数应根据跳板机、AAA、设备 CPU 和链路承载能力确定。
流程建议：
- 从 NetBox 获取候选设备；
- 根据工单和标签二次过滤；
- 验证目标数量和设备列表；
- 并发执行只读预检查；
- 按故障域分批下发；
- 每批完成后验证；
- 超过失败阈值立即停止。
十、预检查设计
预检查应确认：
- 管理地址可达；
- SSH/NETCONF/API 可登录；
- 当前版本受支持；
- 设备 CPU、内存和存储正常；
- 堆叠、IRF、CSS、MLAG、VRRP 状态正常；
- 目标接口和邻居符合预期；
- 当前配置未出现未审计漂移；
- 带外管理可用；
- 备份完成；
- 变更窗口有效。
若基线已经异常，应先判断是否取消变更，而不是在未知状态上继续叠加。
十一、变更分批策略
按站点、冗余对、机柜或业务域分组。冗余设备不能同时操作。
示例：
第0批：实验设备
第1批：单个低风险站点的一台设备
第2批：同类设备的10%
第3批：剩余设备分故障域推进
每批设置观察时间，验证控制面和数据面。不要因为 CLI 返回成功就认为业务正常。
十二、验证与业务探测
验证至少包含：
- 配置是否存在且无多余项；
- 接口、聚合、冗余协议状态；
- OSPF/ISIS/BGP 邻居；
- 路由数量和关键前缀；
- MAC、ARP/ND 和 ACL 计数；
- 端到端 Ping、TCP、DNS 或 HTTP；
- 丢包、延迟和流量曲线；
- 监控与日志是否出现新告警。
网络变更的成功条件应在变更前写清楚，并可由脚本判定。
十三、回滚设计
回滚不是简单把旧配置全量覆盖。不同设备可能支持候选配置、commit confirmed、checkpoint、配置会话或回滚点。
优先使用平台原生的事务能力：
- 下发候选配置；
- 对比差异；
- 定时自动回滚；
- 验证后确认提交。
对于只支持即时 CLI 的设备，应按变更生成逆向命令，并验证逆向命令不会删除其他业务配置。重大变更必须准备带外接入和现场支持。
十四、漂移检测
运行配置与期望状态不一致即漂移。漂移可能来自紧急手工操作、自动化失败、模板缺陷或设备自生成字段。
治理流程：
- 定期采集并规范化配置；
- 与期望配置做结构化比较；
- 过滤动态和无语义字段；
- 创建漂移事件；
- 判断回写事实源还是恢复期望状态；
- 保留审批和处置记录。
不要在发现漂移后立即全自动覆盖，未知的现场救火配置可能正在维持业务。
十五、凭据与审计
- 个人账号与自动化服务账号分离；
- 使用 TACACS+/RADIUS/AAA 审计；
- 密码、私钥和令牌进入 Vault 等密钥系统；
- 自动化账号按命令或 API 最小授权；
- 生产与测试凭据分离；
- 日志脱敏但保留操作者、目标、时间和结果；
- 定期轮换并验证撤销旧凭据。
十六、多厂商实践
思科 IOS/IOS XE/NX-OS、华为 VRP、华三 Comware 在命令、分页、提交方式和返回格式上不同。应维护平台能力矩阵：
| 能力 | 记录内容 |
|---|---|
| 连接方式 | SSH、NETCONF、RESTCONF、API |
| 事务 | candidate、commit、checkpoint |
| 配置备份 | 获取与恢复命令 |
| 结构化数据 | YANG、JSON、XML、TextFSM |
| 软件升级 | 镜像、补丁、回滚机制 |
| 高可用 | 堆叠、MLAG、VRRP等 |
自动化目标是统一流程，不是抹平所有厂商差异。
十七、流水线与审批
建议把自动化接入 CI：
- 提交 Merge Request；
- Schema、模板和单元测试；
- 渲染配置并生成差异制品；
- 同行评审；
- 生产审批；
- 预检查；
- 灰度执行；
- 后检查和业务探测；
- 结果回写工单与 NetBox。
流水线应把目标设备清单显示给审批人，防止过滤条件错误导致全网变更。
十八、上线清单
- [ ] NetBox 对象、字段、命名和责任人已定义；
- [ ] 地址与 VLAN 分配流程以事实源为准；
- [ ] 自动化目标需显式标签授权；
- [ ] 模板、数据模型和平台能力有测试；
- [ ] 凭据不进入 Git，账号最小权限；
- [ ] 每次执行有目标确认、预检查和配置备份；
- [ ] 冗余设备不会同批变更；
- [ ] 设备验证和业务探测都自动执行；
- [ ] 失败阈值、停止条件和回滚路径明确；
- [ ] 配置漂移、结果和审计证据可追溯。
十九、结语
网络自动化的核心不是写更多脚本，而是让数据、变更、验证和审计形成闭环。先提高事实源质量，再逐步从只读采集、配置备份、差异检测扩展到灰度下发；只有能够安全停止和回滚的自动化，才真正适合生产。
参考资料
- NetBox Documentation：https://netbox.readthedocs.io/
- Ansible Network Automation：https://docs.ansible.com/ansible/latest/network/
- Nornir Documentation：https://nornir.readthedocs.io/