概述：
Ansible没有客户端，因此底层通信依赖于系统软件，Linux系统下基于OpenSSH通信，Windows系统下基于PowerShell,管理端必须是Linux系统，使用者认证通过后在管理节点通过Ansible工具调用各应用模块将指令推送至被管理端执行，并在执行完毕后自动删除产生的临时文件。
根据Ansible使用过程中的不同角色，我们将其分为：
- 使用者
- Ansible工具集
- 作用对象
使用者
如图ansible_1-1中ansible工作机制所示，Ansible使用者来源于多种维度，图中为我们演示了4中方式：
第一种方式: CMDB(Configuration Management Database，配置管理数据库)，CMDB存储和管理着企业IT架构中的各项配置信息，是构建ITIL项目的核心工具，运维人员可以组合CMDB和Ansible，通过CMDB直接下发指令调用Ansible工具集完成操作者所希望达成的目标。
第二种方式: public/private方式，Ansible除了丰富的内置模块外，同时提供丰富的API接口，如php、python、perl等多种当下流行的语言，基于public(公有云)/private(私有云)，Ansible以API调用的方式运行。
第三种方式: users直接使用Ad-Hoc临时命令集调用Ansible工具集来完成任务执行，Ad-Hoc后面会专门写到。
第四种方式: users预先编写好的ansible playbooks（剧本），通过执行剧本中预先编排好的任务集按顺序完成任务执行。
Ansible工具集
ansible命令是Ansible的核心工具，ansible命令并非是自身完成所有的功能集，其只是Ansible执行任务的调用接口，可以理解为“总指挥”，所有命令的执行通过其“调兵遣将”最终完成。ansible命令共有哪些兵将可供使唤呢？中间蓝色框中有inventory(命令执行的目标对象配置文件)、API(供第三方程序调用的应用程序编程接口)、modules(丰富的内置模块)、plugins(内置和可自定义的插件)这些可供调遣。
作用对象
Ansible的作用对象，不仅仅是Linux和非Linux操作系统的主机(hosts)，同样也可以作用于各类公有云/私有云，商业和非商业设备的网络设施。
同样，如果我们按Ansible工具集的组成来讲，由图ansible_1-1可以看出Ansible主要由6部分组成。
- ansible playbooks: 任务剧本(任务集)，编排定义ansible任务集的配置文件，由ansible顺序依次执行，通常是JSON格式的yml文件；
- inventory: ansible管理主机的清单；
- modules: ansible执行命令的功能模块，多数为内置的核心模块，也可以自定义；
- plugins: 模块功能的补充，如连接类型插件、循环插件、变量插件、过滤插件等，该功能不常用；
- api: 共第三方程序调用的应用程序编程接口；
- ansible: 该部分图中表示的不明显，组合inventory、api、modules、plugins的蓝色框可以理解为是Ansible命令工具，其为核心执行工具；
Ansible执行任务，这些组件相互调用关系如下图所示：
使用者使用Ansible或Ansible-playbook(会额外读取Playbook文件)时，在服务器终端输入Ansible的Ad-Hoc命令集或Playbook后，Ansible会遵循预先编排好的规则将Playbooks逐条拆解为Play，再将Play组织成可识别的任务(Task)，随后调用任务涉及的所有模块(Module)和插件(Plugin)，根据Inventory中定义的主机列表通过SSH(Linux默认)将任务集以临时文件或命令的形式传输到远程客户端执行并返回执行结果，如果是临时文件则执行完成后自动删除。
Ansible SSH工作机制
Ansible执行命令时，通过其底层传输连接模块，将一个或数个文件，或者定义一个Play或Command命令传输到远程服务器/tmp目录的临时文件，并在远程执行这些Play/Command命令，然后删除这些临时文件，同时回传整体命令执行结果。这一系列操作在未来的Ansible版本会越来越简单、直接，同时快速、稳定、安全。通过了解其工作机制及其一直以来秉承的去中心化思想，我们可以总结，Ansible是非C/S架构，自身没有Client端。
