连接插件决定怎么连
Ansible 把“怎么连到被管对象”这件事交给连接插件：它负责建立通道、把模块代码送过去、取回结果。Linux 服务器默认用 ssh，Windows 用 winrm 或 psrp，网络设备用 network_cli（本质是持久的命令行会话），容器用 docker 或容器内的 local，纯离线处理用 local。选错插件最典型的表现是变量明明对、任务却连不上或者行为怪异。
基本信息
| 设置方式 | 清单变量 ansible_connection，或在 play 中 connection: |
|---|---|
| Linux 默认 | ssh，启用 ControlPersist 复用底层连接 |
| 常见备选 | paramiko（纯 Python，无复用）、local、docker、chroot |
| Windows | winrm（5985/5986）、psrp（走 WinRM 或 PowerShell Remoting） |
| 网络设备 | network_cli（命令行）、httpapi（REST 类设备）、netconf |
| 关键参数 | ansible_port、ansible_user、ansible_ssh_private_key_file、ansible_winrm_transport |
典型使用场景
- 常规 Linux 服务器：保持 ssh，并确认 ControlPersist 生效以减少重复握手
- 把控制节点自身也纳入 playbook：用 local 连接，避免自己 SSH 自己
- 容器编排辅助：用 docker 连接直接进入容器执行，跳过宿主端口暴露
- Windows 主机：改用 winrm，按域环境选 NTLM、Kerberos 或证书认证
- 网络设备：用 network_cli，靠持久会话连续下发多条命令
- 受限网络只能走特定跳板：在 ssh 插件上配置 ProxyCommand 而不是换插件
清单里按主机指定
清单里按主机指定
# inventory 片段
[web]
web1 ansible_host=10.0.1.11
[db]
db1 ansible_host=10.0.1.21 ansible_connection=ssh
[win]
w1 ansible_host=10.0.2.11 ansible_connection=winrm
w1 ansible_winrm_transport=ntlm
[netdev]
sw1 ansible_connection=network_cli ansible_network_os=ios
[local]
ctl ansible_connection=local # 控制节点自己，不经过 SSH连接插件对照
| 插件 | 传输 | 适用与代价 |
|---|---|---|
| ssh | SSH + ControlPersist | Linux/Unix 默认，会复用连接所以快；依赖目标机有 sshd |
| paramiko | SSH（纯 Python 实现） | 目标机 sshd 异常或需要特殊认证时可用；没有连接复用，批量执行明显更慢 |
| local | 直接在本机 fork 执行 | 控制节点自身与容器内场景；写错主机名就会改到控制节点 |
| winrm/psrp | HTTP(S) 或 PowerShell Remoting | Windows 专用；需要目标机开启相应服务与认证方式 |
| network_cli | SSH/Telnet 上的持久 CLI 会话 | 网络设备专用，按平台选择 network_os |
| httpapi/netconf | HTTPS 或 NETCONF over SSH | 支持 API 或结构化管理的设备，返回数据是结构化而非回显文本 |
批量执行的耗时大头往往是每次任务的点对点连接开销。ssh 插件的 ControlPersist 让多次任务复用同一条底层连接，这是最省事的加速手段；换成 paramiko 等于主动放弃这项优化，只在必要时才用。
网络设备不能用普通 ssh 插件：network_cli 会维持一条交互式会话并按提示符解析回显，普通 ssh 只适合执行命令取返回码。设备侧若只支持 API，则改用 httpapi；这是两条不同的路径，不能互相替代。
选择顺序
按“被管是什么对象”倒推：服务器优先 ssh，Windows 优先 winrm，网络设备看是命令行还是 API，容器内的东西优先考虑用 docker 连接或干脆在容器内跑 local。只有在默认插件确实连不通（sshd 版本异常、认证方式不支持）时，才换成 paramiko 之类的备选，并接受性能代价。