我正在尝试在 Ansible (v1.9.1) 中实现以下场景：
- Ansible 连接到远程主机并使用
su成为root。 - Ansible 主机获取它将要破坏的远程配置文件。
- Ansible 主机商店添加使用 将刚刚获取的文件复制到包含目标目录的 Git 存储库
git add ...。 - Ansible 主机提交刚刚获取的文件的使用
git commit ...和适当的提交消息。
现在，(1) 自 v1.9.0.1 起已完全支持，(2) 变得非常简单获取模块- 默认情况下，它甚至将文件存储在特定于主机的子目录下。
但是，我还没能弄清楚 (3) 和 (4)。理想情况下，我希望 Ansible 以最初启动它的用户身份执行本地命令。我可以创建一个包装器 shell 脚本来执行此操作，但这似乎与 Ansible 的做事方式完全相反。
互联网上的大多数帖子都建议使用该local_action模块。local_action然而，对于我的目的来说，这似乎完全是小题大做——它试图以适当的特权升级访问主机。结果失败了：
致命：[host00 -> 127.0.0.1] => 内部错误：此模块不支持通过 su 运行命令
这就是我的处理程序当前的样子：
- name: stage-archive-file
become: false
su: false
local_action: command git -C {{ playbook_dir }} add storage/archive
notify: commit-archive-file
local_action似乎完全忽略了我的尝试不是使用su，虽然我不确定这是否与这个特定的模块或su一般的方法有关。
有没有更简单的方法可以仅从 ansible 进程执行命令？或者，是否有可能以某种方式开始local_action工作？
似乎有一个相关 Ansible 问题在这种情况下，这可能会阻止local_action正常工作。显然，local_action并delegate_to保留来自“父”任务的一些连接设置，即使这些设置对于委托主机完全无效。
答案1
虽然我预计根本原因考虑到这个问题将在未来的 Ansible 版本中得到修复，我推出了自己的解决方案。基本上，我修改/破解了一个简化的 Ansible 连接插件，它只是在主机上执行一个命令。过程如下：
在剧本目录中创建一个名为的子目录
connection_plugins。local.py将连接插件从 Ansible 安装（例如）复制/usr/lib/python2.7/site-packages/ansible/runner/connection_plugins/local.py到新创建的具有不同名称的子目录，例如execute.py。编辑
connection_plugins/execute.py并删除与权限提升方法相关的代码部分。localhost在库存文件中添加一个带有参数的条目ansible_connection=execute。
如果确实应该对某些任务使用特权升级方法，则需要修改最后一步local_action。在这种情况下，可以保留条目localhost（如果有）不进行修改，使用execute连接类型定义另一个别名，然后在任务定义中使用delegate_to:而不是。local_action: