飞牛OS还在手动维护？我用Ansible把重复操作写成了Playbook

前言

刚开始用飞牛 OS 时，我也觉得网页里点点就够了。可服务装得越来越多以后，更新配置、查日志、建目录、改文件这些事情一重复，问题就不是"会不会操作"，而是同样的步骤为什么还要一遍遍手动做。

所以我后来更想把飞牛当成一台真正的 Linux 主机来管理：能不能把目标机器写进 Inventory，把日常动作写进 Playbook，需要时一条命令执行，而不是每次先登录网页、再 SSH、再回忆上次到底敲了什么。

这篇我会先在 CentOS 7 上准备 Ansible，把飞牛 OS 加进 hosts，先用 ansible dbservers -m ping 验证连接，再写一个最简单的 Playbook，在 /tmp 下创建 haha 文件，确认自动化链路真的能落到飞牛上。

本地局域网这条线跑通以后，再继续解决"不在同一个网络怎么办"。这里通过 TCP 隧道把飞牛的 SSH 入口带到外部，再把 Ansible Inventory 从内网 IP 改成公网域名和端口，继续创建 /vol2/1000/shan 目录做第二次验证。

对我来说，这套方案真正有价值的不是"远程控制"四个字，而是把原来靠记忆、靠手点的维护动作开始变成可重复执行的配置。

我也不想把 Ansible 写成"装上就自动化"。真正有意义的是先把一个最小任务跑通，再把网络换掉后重复验证，确认变的是连接方式，而不是整套操作逻辑。

1. 为什么我想用 Ansible 管飞牛 OS

手动维护一台 NAS，短期其实没什么问题。

但一旦开始频繁改配置、建目录、重启服务、查日志，最容易让人厌烦的并不是操作难，而是这些动作明明高度重复，却还是要每次重新做。

Ansible 的意义就在这里：把"我要对哪台机器做什么"拆成两部分。

Inventory：定义目标主机、账号、端口和连接参数；
Playbook：把具体操作写成任务；
Ansible 命令：负责连接目标主机并执行。

先在局域网里把这条链跑通，再考虑跨网络访问，会比一开始同时排查 Ansible 和网络问题清楚得多。

2. 在 CentOS 7 上准备 Ansible

先更新系统软件包：

shell 复制代码

 yum update -y

然后安装 EPEL 仓库：

shell 复制代码

 yum install -y epel-release

原有流程接下来完成 Ansible 安装：

安装后验证版本：

shell 复制代码

ansible --version

能正常返回 Ansible 版本以后，再进入配置阶段。

3. 把飞牛 OS 加进 Inventory

进入 Ansible 配置目录：

shell 复制代码

cd /etc/ansible

接下来在 hosts 中定义目标主机。

现有配置为：

shell 复制代码

[dbservers]
192.168.42.140 ansible_user=root ansible_port=22 ansible_password=******

这里几项参数分别表示：

[dbservers]：主机组名称，后面执行命令时可以直接引用；
192.168.42.140：飞牛 OS 的内网 IP；
ansible_user=root：SSH 用户；
ansible_port=22：SSH 端口；
ansible_password=******：登录密码。

配置完成以后，先不要急着写复杂 Playbook，第一步只做连通性验证。

执行：

shell 复制代码

ansible dbservers -m ping

如果返回成功，说明 Ansible 已经能通过当前 SSH 参数访问飞牛。

4. 如果 Ansible ping 不通，先看 SSH

原有操作里还保留了一次连接报错。

这时候先到需要被管理的飞牛主机上检查 SSH 配置：

shell 复制代码

sudo vi /etc/ssh/sshd_config

确认下面两项：

shell 复制代码

PasswordAuthentication yes
PermitRootLogin yes

然后重启 SSH：

shell 复制代码

 systemctl restart sshd

这一步的逻辑很重要：Ansible 依赖 SSH 连接，SSH 本身没打通时，不应该先怀疑 Playbook。

等 ansible dbservers -m ping 能正常通过以后，再继续写任务。

5. 第一个 Playbook：在 /tmp 创建 haha 文件

先写一个最简单的任务，目的不是做复杂维护，而是确认 Ansible 的命令确实能落到飞牛 OS。

原有操作先创建文件：

shell 复制代码

vi /etc/ansible 1.yml

Playbook 内容如下：

shell 复制代码

---
- name: 创建文件
  hosts: dbservers
  become: yes
  tasks:
    - name: 创建/tmp/haha文件
      file:
        path: /tmp/haha
        state: touch

这个任务做的事情很简单：在 dbservers 主机组上，以提权方式创建 /tmp/haha。

运行：

shell 复制代码

ansible-playbook 1.yml --ask-pass

然后到飞牛 OS 上检查 /tmp：

shell 复制代码

ls /tmp

能看到 haha 文件以后，第一条自动化链路就验证完成了：

CentOS 7 上的 Ansible → Inventory → SSH → 飞牛 OS → Playbook 生效。

到这里，"用代码管理飞牛"已经不是概念，而是有了一个可以直接验证的结果。

6. 局域网能控以后，再解决跨网络 SSH

前面这套配置依赖内网 IP。

只要 Ansible 控制端和飞牛 OS 不在同一个网络里，192.168.x.x 这样的地址就不能直接继续用。

所以后面要解决的是 SSH 入口，而不是改 Ansible 本身。

原有流程是在飞牛 OS 上开启 SSH：

再通过飞牛内网 IP 连接进去：

然后安装 cpolar：

shell 复制代码

sudo curl https://get.cpolar.sh | sh

安装完成后检查服务：

shell 复制代码

sudo systemctl status cpolar

浏览器通过飞牛主机的 9200 端口进入管理界面：

这里 cpolar 的职责只是把飞牛现有的 SSH 服务提供一个外部 TCP 入口，Ansible 仍然通过 SSH 工作。

7. 给飞牛 SSH 创建 TCP 公网入口

现有配置中创建的是 TCP 隧道：

隧道名称：ssh
协议：tcp
本地地址：192.168.42.137:22
端口类型：随机临时 TCP 端口
地区：China Vip

创建完成后，在在线隧道列表里可以看到公网域名和端口：

现有示例里：

域名：2.tcp.cpolar.top
公网端口：13126

这两个值接下来会直接写进 Ansible Inventory。

8. 把 Inventory 从内网 IP 改成公网 SSH 地址

原来 Inventory 里写的是内网 IP。

现在改成：

shell 复制代码

[dbservers]
2.tcp.cpolar.top ansible_user=root ansible_port=13126 ansible_password=***

这里 Ansible 的使用方式其实没有变化。

变化的只是 SSH 连接目标：

内网 IP + 22 → 公网 TCP 域名 + 随机端口。

这也是这一套组合真正关键的地方：Playbook 不需要因为网络变化而重写，主要调整的是 Inventory 里的连接地址。

9. 第二个 Playbook：跨网创建 shan 目录

为了确认公网 SSH 不是"只能登录"，而是真的能继续跑 Ansible，再做第二次验证。

先创建新的 Playbook：

shell 复制代码

vi /etc/ansible/2.yml

写入：

shell 复制代码

---
- name: 创建文件
  hosts: dbservers
  become: yes
  tasks:
    - name: 创建/vol2/1000/shan 目录
      file:
        path: /vol2/1000/shan
        state: directory

这个任务会在飞牛 OS 中创建：

/vol2/1000/shan

运行：

shell 复制代码

ansible-playbook 2.yml --ask-pass

执行成功后：

再打开飞牛 OS 检查目录：

可以看到 shan 已经创建。

到这里，第二条链路也完成了：

Ansible → 公网 TCP SSH → 飞牛 OS → Playbook 执行 → NAS 文件系统实际变化。

这比单纯证明"SSH 能连上"更有分量，因为它验证的是自动化任务仍然可以正常执行。

10. 随机 TCP 能用以后，再考虑固定地址

随机端口适合先验证。

如果后面长期用 Ansible 管理飞牛，Inventory 里的地址总变化会很麻烦，所以原有流程继续配置固定 TCP 地址。

现有示例选择：

地区：China VIP
固定地址：6.tcp.vip.cpolar.cn:12648

然后回到 cpolar 隧道列表，找到 ssh 隧道：

编辑隧道，把端口类型改成固定 TCP 端口，并填写已经预留成功的地址：

更新后查看在线隧道：

最后直接测试固定 SSH 地址：

shell 复制代码

ssh -p 12648 root@6.tcp.vip.cpolar.cn

固定入口验证成功以后，再把 Ansible Inventory 更新成这组稳定的域名和端口，就可以减少后续地址变化带来的维护成本。

11. 这套"遥控器"真正省掉的是什么

我觉得 Ansible 和飞牛 OS 组合起来以后，真正变化的不是"可以远程登录 NAS"。

SSH 本来就能做到远程登录。

更有价值的是，原来需要人记住并重复执行的动作，可以开始写成 Playbook：

创建目录；
创建文件；
后续继续扩展服务管理、配置变更和批量任务；
同一套任务还可以继续作用于更多主机。

网络环境变化时，优先调整 Inventory；操作逻辑变化时，再改 Playbook。

把连接信息和任务逻辑分开以后，维护思路会比每次临时登录后手工操作清楚很多。

总结

这次真正让我觉得"飞牛多了个遥控器"的，不是公网 SSH 能连上，而是同一套 Ansible 思路在局域网和外网都能继续工作。

先在内网 Inventory 里配置飞牛 IP，用 Playbook 创建 /tmp/haha；再把连接地址换成公网 TCP 域名和端口，继续创建 /vol2/1000/shan。两次实际结果跑通以后，自动化这件事才算从概念落到了 NAS 上。

cpolar 在这里解决的是 SSH 入口，Ansible 解决的是任务自动化。网络地址变化时改 Inventory，维护动作变化时改 Playbook，两层职责分开以后，比"远程登录后继续手工敲命令"更容易长期维护。

如果后面飞牛上的重复任务越来越多，我更愿意继续把它们一点点写进 Playbook。真正省下来的不是一次点击，而是以后遇到同样的事情，不必再从头做一遍。