SONiC 之 Testbed（2）Ansible

Ansible 是一款由 Red Hat 主导开发的 开源自动化工具，专注于 配置管理、应用部署、任务编排和IT自动化。它基于 无代理（Agentless）架构，通过 SSH（默认）或 WinRM 协议与目标设备通信，无需在被控节点安装额外软件，因此部署和维护成本极低。

一、Ansible 的核心优势

1. 无代理架构（Agentless）

• 被控节点（服务器、网络设备、云实例等）无需安装 Ansible 客户端，仅需支持 SSH（Linux/Unix）或 WinRM（Windows），极大降低了运维复杂度。
• 控制节点（安装 Ansible 的主机）通过 SSH 远程执行命令或传输文件，适合大规模设备管理。

2. 基于 Python，简单易用

• 配置文件采用 YAML 语法（人类可读的标记语言），Playbook（自动化脚本）结构清晰，学习成本低（例如：几行 YAML 即可完成服务部署）。
• 支持 Python 自定义模块，扩展灵活，可适配各类特殊场景（如网络设备、存储系统的自动化）。

3. 幂等性（Idempotency）

• 核心设计原则：多次执行同一 Playbook，结果一致（不会因重复执行导致错误）。例如，创建用户时若用户已存在，则自动跳过，避免重复操作。

4. 模块化与丰富的生态

• 内置 数千个模块（Modules），覆盖系统管理（用户、服务、文件）、云服务（AWS、Azure、GCP）、网络设备（Cisco、Juniper、SONiC）、数据库（MySQL、PostgreSQL）等场景。
• 支持 Roles（角色）和 Galaxy（社区共享平台），可复用他人编写的自动化代码（如通过 ansible-galaxy install 下载现成 Roles）。

5. 跨平台支持

• 控制节点支持 Linux/macOS（Windows需通过 WSL 或 Linux 虚拟机），被控节点支持 Linux、Windows、网络设备（如交换机、路由器）、嵌入式系统等。

二、Ansible 的核心组件

1. 控制节点（Control Node）

• 安装 Ansible 的主机（通常为 Linux 系统），负责运行 ansible 或 ansible-playbook 命令，解析 Playbook 并向被控节点发送指令。

2. 被控节点（Managed Nodes）

• 被管理的设备（服务器、网络设备等），需开启 SSH（或 WinRM），并允许控制节点通过 SSH 密钥或密码登录。

3. Inventory（资产清单）

• 定义被控节点的配置文件（默认路径 /etc/ansible/hosts），可按 分组（如 webservers、databases）或 变量（如 IP、端口、登录用户）管理设备。
• 支持静态文件（INI/YAML）或动态生成（通过脚本从 CMDB、云平台拉取设备列表）。

4. Playbook（剧本）

• 核心自动化脚本，采用 YAML 格式，包含 Tasks（任务，如执行命令、复制文件）、Handlers（触发器，如服务重启）、Variables（变量）、Roles（角色引用）等。
• 示例（部署 Nginx 服务的 Playbook）：

- name: Deploy Nginxhosts: webservers  # 目标主机组（来自 Inventory）tasks:- name: Install Nginx packageapt: name=nginx state=present  # 使用 apt 模块安装 Nginx- name: Start Nginx serviceservice: name=nginx state=started enabled=yes  # 启动并设置开机自启

5. Modules（模块）

• 执行具体操作的“工具函数”，Ansible 任务通过调用模块实现功能（如 apt 模块管理 Debian 包，copy 模块复制文件，sonic_config 模块配置 SONiC 交换机）。
• 支持 命令模块（command/shell 执行原生命令）和 功能模块（更安全、幂等，优先推荐）

6. Roles（角色）

• 自动化代码的 模块化组织方式，将 Playbook、变量、模板、文件等按功能拆分（如 nginx 角色、database 角色），便于复用和维护。
• 典型 Roles 目录结构：

roles/nginx/tasks/        # 主任务文件handlers/     # 触发器vars/         # 变量定义templates/    # Jinja2 模板（如 Nginx 配置模板）files/        # 静态文件（如证书）

7. Vault（加密工具）

• 用于加密 Playbook 中的敏感信息（如密码、API 密钥），避免明文存储，提升安全性。

三、Ansible 的典型应用场景

1. 配置管理

• 批量配置服务器（如统一时区、SSH 密钥、防火墙规则），确保环境一致性。

2. 应用部署

• 自动化部署 Web 服务（Nginx、Tomcat）、微服务（Docker/K8s 容器）、数据库（MySQL 主从复制）等。

3. 任务编排

• 按依赖关系执行复杂流程（如：先部署数据库 → 再部署后端 API → 最后部署前端，并在每个阶段验证服务可用性）。

4. 网络自动化

• 管理网络设备（交换机、路由器）的配置（如 VLAN 创建、ACL 规则、OSPF 路由），代表框架如 Ansible Network Automation（支持 Cisco IOS、Juniper Junos、SONiC 等）。

5. 云资源管理

• 通过模块创建/删除云资源（AWS EC2 实例、Azure 存储桶、GCP 虚拟机），实现“基础设施即代码（IaC）”。

6. 测试与运维

• 自动化测试（如服务健康检查、日志收集）、故障恢复（如重启异常服务）、系统升级等。

四、SONiC 部署概述、测试平台搭建及测试情况

此 Ansible 脚本包含以下功能：

• 部署 SONiC
• 搭建 SONiC 测试环境
• 运行 SONiC 测试

五、在系统上安装 Ansible

sudo apt-get install git gcc make python python-dev python-cffi libffi-dev libssl-dev sshpass libxml2 libxslt1-dev
sudo pip install setuptools ipaddr lxml netaddr
git clone https://github.com/ansible/ansible
cd ansible
git checkout v2.0.0.2-1 -b v2.0.0.2-1
git submodule update --init --recursive
make
sudo make install

这是源码安装，不推荐，

pip3 install ansible  # 自动安装所有依赖（包括 paramiko），无需手动处理

六、Ansible playbook布局

# Ansible top level file and directory structure
# adapted from http://docs.ansible.com/ansible/playbooks_best_practices.htmlprod                      # inventory file for production servers
pre_prod                  # inventory file for staging environment
lab                       # inventory file for test lab environmentgroup_vars/prod                   # here we assign variables to particular groupspre_prod               # groups can be environments, geographical, role basedlabhost_vars/hostname1              # if an individual system must have specific variables, put them herehostname2              # (use of host_vars should be avoided)library/                  # if any custom modules, put them here (optional)
filter_plugins/           # if any custom filter plugins, put them here (optional)deploy_sonic.yml          # playbook to initialize a SONiC switch after imaging process is completeroles/sonic_common/         # common "role" for the SONiC switch, only add tasks here that are for all SONiC switchestasks/            #main.yml      #  <-- tasks file can include smaller files if warrantedhandlers/         #main.yml      #  <-- handlers filetemplates/        #  <-- files for use with the template resourcentp.conf.j2   #  <------- templates end in .j2files/            #bar.txt       #  <-- files for use with the copy resourcefoo.sh        #  <-- script files for use with the script resourcevars/             #main.yml      #  <-- variables associated with this roledefaults/         #main.yml      #  <-- default lower priority variables for this rolemeta/             #main.yml      #  <-- role dependenciessonicv2/              # role for installing SONiC v2 components (syncd, orchagent, quagga, etc)sonic_test/           # same kind of structure as above, but for the integration test role,#        see http://github.com/sonic-net/sonic-integrationtestsonic_s6000/          # place Dell s6000 specific tasks heresonic_msn2700/        # place Mellanox msn2700 specific tasks here