Ansible如何进行源码分析？这是一个提问篇
之前一直停留在使用上，现在需要了解源码，内部是如何工作的，因为ansible源码是python写的，我很庆幸，因为我了解python语言，可是最近看了源码，有种要崩溃的赶脚，怎么办
为了跟踪源码，我写了基于ansible-api的ad-hoc代码段，
环境：
Ansible 2.7.3
Python 2.7.5
Pycharm 2018.1
Centos7.0
准备工作：
1、 ad-hoc代码段大致如下网址所示（不是我写的，但是跟我写的非常像）
https://blog.csdn.net/python_tty/article/details/73822071
2、 ansible大致执行流程如下图所示，抄自51cto，了解流程对源码分析会有所帮助
目的：
1、要了解代码的执行流程
2、要了解模块或者插件的调用入口
3、要知道执行结果如何返回的，最好能知道常用模块的工作原理
源码分析原理：
源码的入口在哪，源码段是如何定义的，通过哪些语句调用的，它的返回值有哪些
源码分析：
良心声明：该有的步骤我是写了，但是我不会分析，这里所写的都是我想象的，没有经验之谈，希望有人指点一二
入口：
根据基于ansible-api写的ad-hoc代码段，我定义的入口为
定义：
Play初始化，_attributes初始化，返回给play
初始化Play()类，然后调用类中的load（）方法
return返回遍历输入数据结构并分配任何值
以看到_attrbutes中已经存在该方法的定义了
按照以上的加载过程，将我们要执行的模块都加载进来了，执行完成之后，将对象返回给play，因此play也就有了属性以及对应的方法了
Ad-hoc执行入口run(play)
加载所有回调函数到_module_cache字典中（path和对象）
以下作为我的入口程序，原因是基础到数据都准备好了，比如play（将需要的任务，以及对应任务的定义），inventory,variable_manager,options,loader,password,stdout_callback都准备就绪，开始执行接下来的定义以及调用的部分了
有初始化类TaskQueueManager，调用该类的run方法参数为play对象
进入如下的模块，task_queue_manager.py中，执行
/*注释是这样的，
Iterates over the roles/tasks in a play,using the given (or default)
使用给定(或默认)迭代剧中的角色/任务
strategy for queueing tasks.
任务排队策略。
The default is the linear strategy, which
默认是线性策略*/
执行self.load_callbacks()，跳转到同一个模块（task_queue_manager.py）下的如下函数中，
/*注释是这样的：
Loads all available callbacks, with theexception of those which
加载所有可用的回调函数，除了那些
utilize the CALLBACK_TYPE option.
使用CALLBACK_TYPE选项*/
下面进入callback_loader.all(xxx)加载所有可用的回调函数了
在往下是_module_cache自定的形式存储path和对应的对象
至此，将callback插件都加载进来了，如下所示
收集连接信息（连接信息，比如options的信息）：
play_context = PlayContext(new_play,self._options, self.passwords, self._connection_lockfile.fileno())
发送回调函数执行如下列表中的两个方法，（具体做什么用的，我也不知道！）
['v2_playbook_on_play_start', 'v2_on_any']
self.send_callback('v2_playbook_on_play_start',new_play)
初始化线程池：
self._initialize_processes(min(self._options.forks,iterator.batch_size))
下一步进入如下的代码段执行
/*给的注释是：
The linear strategy is simple - get thenext task and queue
线性策略很简单——获取下一个任务和队列
it for all hosts, then wait for the queueto drain before
它适用于所有主机，然后等待队列耗尽之前
moving on to the next task
继续下一个任务*/
按照我的理解就是从队列中取出一个个任务执行，直到队列为空，执行结束，是不是这样子的呢，是这样的
首先了解参数是什么？iterator是可迭代的任务，play_context是连接的参数
下面进入代码进行分析吧
可以看到代码是写在了linear.py模块中了，在代码中，你可以看到一行注释
/*iteratate over each task, while there isone left to runiteratate over each task, while there is one left to run
对每个任务进行迭代，只要还有一条路可走
*/这句话感觉有点励志，就是对每个任务进行迭代
hosts_left = self.get_hosts_left(iterator)
这是获取可用的主机名称列表
本次为了方便，我只设置主机为localhost,下一步，获取对应的任务
linear.py模块中执行如下的函数获取下一个任务，会执行以下1,2,3,步骤执行文件linear.py ---》 task.py ---》 base.py，完成的功能，初始化task任务，并得到主机和任务的元祖
1）
2）
3）
初始化数据，loader,variable在对象被加载后将被提供
第一步骤中，下图标记的是获取主机名称和对应的任务清单
任务执行：
以下开始任务的执行阶段了，前面主机名和任务以及变量的信息均已初始化好了（host_tasks{主机名：任务对象}，task_vars获取变量的对象），接下来开始执行了
Task_queue_manager.py
Linear.py中执行如下语句，开始进行执行的部分了
Strategy/__init__.py文件中执行如下的函数，参数：主机名，任务，变量，连接参数
/*给的注释是这样的：
handles queueing the task up to be sent toa worker
处理将任务排队发送给工作人员*/
执行如下的语句，跳转对应的函数执行，对此处有点蒙蔽的状态，先看下程序备注的解释
作用是/*create adummy object with plugin loaders set as an easier way to share them with theforked processes
创建一个虚拟对象，并设置插件加载器，以便更容易地与分叉进程共享它们*/
跳转到对应的函数如下：
给出的文档注释：
/*A simple object to make pass the variousplugin loaders to
一个简单的对象，用来传递各种插件加载器
the forked processes over the queue easierAsimple object to make pass the various plugin loaders to
分叉的进程通过队列easierA简单对象传递各种插件加载器*/
好了，假装理解以上的作用，进入下面分析阶段
下面开始任务的执行了
参数： self._final_q 不太清楚是啥东东
Task_vars: 任务需要的变量信息，这部分信息跟多，ansible_connection ansible_playbook_python 。。。
Host: localhost
Task: file
Play_context: ansible的连接信息，比如options一大堆
….
点击进入如下的函数中执行
/*给出的注释是这样的：
The worker thread class, which usesTaskExecutor to run tasks
工作线程类，它使用TaskExecutor运行任务
read from a job queue and pushes resultsinto a results queue
从作业队列读取并将结果推入结果队列
for reading later.
以后阅读。*/ 真正拿数据 ---执行 ----给数据到队列中的过程了
创建一个进程了，下面开始start执行起来
以下是执行的部分，没太看懂，主进程加入了孩子进程，没看到执行，到底怎么回事呢
可以看到在本机的目录中/root/.ansible/tmp/中生成了以下的文件，这和ansible流程中的在本地产生文件，然后将封装的执行语句和对应的模块，通过ssh发送到受控端貌似有点贴近了，生成的文件已经到了受控端，执行完成后就立即删除了，所以受控端没有看到产生的临时文件了
下面再看
Task,file执行完毕，接下来看这样一段代码，这是做什么的？
提醒下，这前面有缩进，当前是在host：localhost task:file的for循环中
/*给出的函数注释是这样的：不知道什么鬼
Closure to wrap ``StrategyBase.
结束以结束“strategy
ybase”。
_process_pending_results`` and invoke thetask debugger
并调用任务调试器*/
执行完毕后返回的结果如下所示，将执行的结果返回给列表result
接着执行下一个task吧！
没想到下一个是这个meta，我的程序中没有meta的任务，以下看出确实没有做什么
接下来的任务应该是我设置的task:shell语句了
进入执行部分
跳转到执行的函数中，进入如下语句的执行，可以看到发生的变化
在本地/root/.ansible/tmp中多出来command文件，也在预料中，同时发送到受控段同级目录中存在.py可执行文件，执行得到执行结果返回给主控端
下面开始另外一个模块的执行了（也是最后一个fetch模块）
同样根据参数获取fetch.py插件的对象
跳转语句执行对应的函数模块
对应的执行函数如下：执行
同样执行完了，下面看下本地在/root/.ansible/tmp/下是否产生对应fetch文件吧
至此三个ad-hoc执行完成，（file,shell,fetch）
胡乱总结以下：
任务的初始化（包括收集属性以及对应的callback插件对象，获取连接信息，以及异常捕获）
将数据分配给任务执行部分，进行调用执行
最终执行在线程中，（这是最重要一点，掌握这点，ansible源码的分析就差不多了）
调用：
出口：
执行结果的取值，一定在以下的调用函数中产生
Linear.py模块中如下的语句
会调用到如下的函数中
是不是这样呢，进行验证以下
进入此函数中，可以看到，task_result已经是第一个task产生的结果数据了
继续往下看：
Task_result._result,是锁定到task的执行结果，结果中如果有diff会执行对应下面的语句快了
实时证明是有的，所以执行语句块
实时证明callback中已经记录了对应的数据信息了
类中已经记录了这些数据，那么我们在继承该类中，同样能取到对应的数据的信息了
例如以下自己写的代码中继承自callbackbase中，而callbackbase类就是在/callback中的__init__.py中，能够利用result取到对应的值的信息。
将结果信息整理成我们想要的格式就可以了
重点知识掌握：
特殊语句的使用
obj = getattr(self._module_cache[path],self.class_name)
issubclass(obj, plugin_class)
args = FieldAttribute(isa='dict',default=dict)
if original_task.loop: 这是什么鬼，loop是系统默认还是自己定义的标记呢
装饰器的使用
这是什么语句，执行完成后还会跳转到这个位置，想装饰器的使用，但是在装饰器外面没有对应的函数定义，那是不是和@functools.wraps(func)有关呢
多线程的使用，需要重点理解掌握
遗留问题：
在给定的任务，如何确定那个模块可以执行这个任务（1）
主控端如何产生临时文件的，临时文件又是如何传递到受控端的（2）
多线程的处理，弄不大清楚（3）
重点知识掌握，需要掌握哦（4）
接下来要掌握的是具体模块的原理（5）
（1）问题解答：
出现在任务执行的过程之前，for循环host,task的时候，建检索task的时候，会根据task的名称来检索对应目录下的模块的文件的完整路径，然后加载进来到制定的字典中，下面看下这个的过程是怎样的
Linear.py文件中执行如下的语句，这个就是获取action的完整动作的
先初始化action_loader,然后调用其中的Get方法，进入如下的函数，我想要根据self.find_plugin函数参数是任务fetch，来找到模块的完整路径，问题来了self.find_plugin如何存储这么多的数据的呢
跟踪到self.find_plugin函数到如下所示：问题进一步针对到了self._find_plugin函数上，这个为什么也有很多很多的模块在里面缓存呢
带着疑问继续跟踪此函数到如下所示：原来这些数据都是根据plugin所在的路径，根据以.py为结尾的文件全部检索出来得到的，至此，能够按照最开是的self.find_plugin来检索数据也就不奇怪了
由以上基本上可以确定，模块是通过任务名称来确定的，也就是说在制定的目录下，模块文件名称和任务名称相等就能够检索到对应的模块加载进来，进行执行操作了
于是就可以通过以下的代码来加载对应的模块文件了
可以看到path已经对应上了任务所对应的模块文件的完整路径了
接下来就就是把完整路径作为key 模块的对象作为value加载到self._module_cache字典中，进入self._load_module_source函数中，如下所示，得到所对应的模块对象
经验总结：
1. 如果需要自定义模块，只需要在制定的位置，按照任务的名称为命名的执行模块就可以了
2. [Callback回显的信息，我们可以根据得到的原始数据进行定制化输出自己的样式，常见的是json格式输出