3. ONTAP CLI自动化基础
ONTAP 的自动化入口主要有三类：命令行接口（CLI）、REST API，以及基于两者的脚本与编排工具。CLI 是运维人员最熟悉、最容易验证的入口，也是理解 ONTAP 自动化逻辑的起点。本节围绕 CLI 命令结构、命令模式、脚本执行方式、SSH 密钥认证，以及 CLI 与 REST API 的适用场景对比展开，目标是让读者能够独立构造一条可执行、可复用、可脚本化的 ONTAP 命令。
命令结构与命令模式
ONTAP CLI 采用分层命令树结构，一条完整命令通常由“命令模式 + 动词 + 对象 + 参数”组成。例如：
cluster1::> volume create -vserver svm1 -volume vol1 -aggregate aggr1 -size 100g -junction-path /vol1其中 cluster1::> 是提示符，表示当前处于集群管理上下文；volume 是命令对象；create 是动词；-vserver、-volume、-aggregate、-size、-junction-path 是参数。ONTAP 命令模式分为两类：集群管理模式（cluster admin）和 SVM 管理模式（vserver admin）。集群模式提示符形如 cluster1::>，可管理整个集群资源；SVM 模式提示符形如 svm1::>，只能操作该 SVM 范围内的对象。进入 SVM 模式使用 vserver context 命令，返回集群模式使用 vserver context -vserver cluster1 或直接输入 exit。
命令模式决定了可用命令集合和权限边界。例如在 SVM 模式下执行 volume create 时，-vserver 参数可省略，系统默认使用当前 SVM；而在集群模式下必须显式指定。自动化脚本中建议始终显式写出 -vserver，避免因上下文切换导致误操作。
脚本执行方式
ONTAP CLI 支持三种脚本执行方式：交互式逐条执行、本地脚本文件执行、以及通过 SSH 远程批量执行。交互式适合验证单条命令；脚本文件适合重复性任务；SSH 远程执行适合与外部调度系统集成。
本地脚本文件执行使用 source 命令。例如将以下内容保存为 create_vols.txt：
volume create -vserver svm1 -volume vol_a -aggregate aggr1 -size 50g -junction-path /vol_a
volume create -vserver svm1 -volume vol_b -aggregate aggr1 -size 50g -junction-path /vol_b
volume create -vserver svm1 -volume vol_c -aggregate aggr1 -size 50g -junction-path /vol_c在 CLI 中执行 source create_vols.txt 即可依次运行。脚本中可使用 set -privilege advanced 提升权限，使用 set -confirm off 关闭交互确认，适合无人值守场景。需要注意，source 执行时若某条命令失败，默认会继续执行后续命令，因此建议在脚本中显式加入错误检查，或使用 set -onerror stop 让脚本在出错时停止。
SSH 远程执行是自动化集成中最常用的方式。例如从 Linux 跳板机执行：
ssh admin@cluster1 "volume show -vserver svm1 -fields volume,size,state"该方式将命令作为 SSH 参数传入，ONTAP 执行后返回标准输出，便于被 Shell、Python 或 Ansible 捕获解析。若需执行多条命令，可将命令用分号连接，或使用 ssh admin@cluster1 < script.txt 方式批量输入。
SSH 密钥认证
自动化场景下不建议使用密码认证，而应配置 SSH 公钥认证。ONTAP 支持在集群和 SVM 级别管理公钥。以集群管理员为例，操作步骤如下：
- 在客户端生成密钥对：
ssh-keygen -t rsa -b 4096 -f ~/.ssh/ontap_key。 - 将公钥内容复制到 ONTAP：
security login publickey create -username admin -index 0 -publickey "ssh-rsa AAAA..."。 - 验证登录：
ssh -i ~/.ssh/ontap_key admin@cluster1。
ONTAP 还支持 security login publickey show 查看已注册公钥，使用 security login publickey delete 删除失效密钥。对于自动化平台，建议为每个集成系统创建独立的管理账号和密钥，便于审计和吊销。
CLI 与 REST API 的适用场景对比
CLI 和 REST API 并非替代关系，而是互补关系。CLI 适合交互式排障、一次性操作、脚本快速验证；REST API 适合大规模并发、结构化数据交换、与外部平台深度集成。下表从多个维度进行对比：
| 对比维度 | CLI | REST API |
|---|---|---|
| 交互方式 | SSH 登录后逐条执行 | HTTP/HTTPS 请求 |
| 返回格式 | 文本，需解析 | JSON/XML，结构化 |
| 并发能力 | 较弱，受 SSH 会话限制 | 强，支持批量并发 |
| 权限模型 | 基于命令模式和角色 | 基于 RBAC 和 OAuth |
| 适用场景 | 排障、验证、简单脚本 | 平台集成、自动化编排、监控采集 |
| 版本兼容 | 命令语法相对稳定 | API 版本需与 ONTAP 版本匹配 |
实际工作中，常见做法是：用 CLI 完成前期验证和命令构造，再将稳定命令转换为 REST API 调用或 Ansible 模块，纳入正式自动化流水线。例如先用 volume create 验证参数，再在 Ansible 中使用 na_ontap_volume 模块实现批量创建。
实践建议：在正式自动化前，先用 CLI 交互模式验证命令语法和参数，确认无误后再写入脚本或转换为 REST API 调用。对于批量操作，优先使用 source 脚本或 SSH 远程执行；对于需要与外部平台交换结构化数据的场景，优先使用 REST API。
注意：使用 source 执行脚本时，默认不会因单条命令失败而停止。若脚本中包含关键操作，建议在脚本开头加入 set -onerror stop，或在每条命令后检查返回状态，避免部分成功导致配置不一致。
掌握 CLI 命令结构、模式切换、脚本执行和 SSH 密钥认证，是构建 ONTAP 自动化能力的基础。在此基础上，再根据任务规模、集成需求和数据结构化程度，合理选择 CLI 或 REST API，才能让自动化既稳定又高效。