任何对 Ansible 略有了解的人都会证明，维护幂等性是稳定自动化的关键秘诀。没有幂等性，几乎不可能检测到漂移和/或可预测地管理状态更改。同样，任何超出 Podman 初学者的用户都会知道，定义和使用卷是必不可少的操作。

现在的问题是：在 Ansible 中，template 模块是用于部署和持续管理远程文件内容的重要工具。但是，如果您尝试使用模板自动化 podman 卷内容管理，您将很快意识到一个重大缺点

Ansible 在用户命名空间方面完全卡住了。

注意：如果您还不熟悉用户命名空间，我建议阅读 Dan 的“在 Podman 无根容器中使用文件和设备”。这将要么让您了解，要么让您更加困惑。在后一种情况下，我建议您在继续之前阅读我的“用简单的英语解释无根 Podman 用户命名空间” 文章。

例如，考虑下面的剧本 ./local_1.yml。它旨在部署一个 Web 服务器容器，不映射主机用户到 root 用户（userns: nomap）。这种缺乏 user -> root 映射旨在保护主机。如果进程从容器中逃逸，它将无法访问主机用户的文件或进程。请忽略对 localhost 的定位，这仅仅是为了演示目的。但请注意明确管理卷和配置文件所有权的任务

./local_1.yml

---

- hosts: localhost
  gather_facts: true
  gather_subset: user
  become: false
  tasks:
    - name: Config volume for nginx container
      containers.podman.podman_volume:
        name: nginx_confd
        options:
          - o=uid=0,gid=0
        state: present
      register: vresult

    - name: Deploy nginx configuration
      template:
        src: default.conf.j2
        dest: >-
         {{ vresult.volume.Mountpoint }}/default.conf
        mode: u=rw,g=r,o=r
        owner: 0
        group: 0

    - name: Run nginx container
      containers.podman.podman_container:
        name: webserver
        image: nginx
        publish: ["8080:80"]
        userns: nomap
        volume:
          - >-
            {{ vresult.volume.Name }}:/etc/nginx/conf.d:Z,U
        recreate: true
        state: started

如果您还没有安装它，请确保安装 podman 集合

$ ansible-galaxy collection install containers.podman

此外，在运行剧本之前，请确保您获取了内置的默认配置的副本。该示例可以使用此作为配置模板的存根，因此无需实际在其中添加任何 jinja2 元素

$ mkdir templates
$ podman run -it --rm nginx \
    cat /etc/nginx/conf.d/default.conf \
    > ./templates/default.conf.j2

最后，当剧本以 ansible-playbook -i localhost, -l localhost -c local local_1.yml 的方式应用时，结果应该是一个类似于以下内容的错误消息

FAILED! => {"changed": false, "checksum": "...", "mode": "0644",
"msg": "chown failed: [Errno 1] Operation not permitted:
.../nginx_confd/_data/default.conf" ...}

一种可能显而易见的解决方法可能是简单地为用户提供 sudo 访问权限，在任务中使用 become: true，并根据一些硬编码的计算手动偏移 ID。但在您这样做之前请仔细考虑。对于快速/肮脏的剧本来说这可能没问题，但它绝对无法扩展。

这完全是由于全局命名空间执行上下文造成的。Ansible 正在“远程”主机上以普通用户身份执行任务，没有 sudo 访问权限（become: false）。此外，template 模块正在尝试写入一个文件（Ansible 假设）由 UID/GID 零 拥有。而实际上它应该由某个从 $UID/$GID 偏移的 UID/GID 拥有（由 /etc/subuid 和 /etc/subgid 确定）。更糟糕的是，Ansible 将永远无法告诉操作员有关任何 default.conf 更改的信息，也无法触发相关的通知任务，例如重启容器。因此，这几乎在所有方面都是不好的。糟糕！

对像 ID 这样的自动生成的低级系统详细信息的管理完全破坏了 Ansible 的“通用”性质（在规模上）。它要求它操纵超出其预期范围的方面。请考虑以下内容并不牵强，而是完全有效的 /etc/subuid 内容

...cut...
fred:100000:65536
fred:165536:1024
fred:166560:131072
wilma:100000:999999
...cut...

如果还不明显：Ansbile 不应该直接与 subuid/subgid 映射纠缠在一起，原因与它不应该直接操作 /etc/passwd 或 /etc/group 的原因相同：这些是操作系统和系统实现细节，可能会/将意外地发生变化。想想用户命名空间迁移到身份提供商（如 FreeIPA 或 Active Directory）的情况，那怎么办，丢弃所有剧本吗？

幸运的是，有一种方法可以解决这个问题，虽然有点“hacky”：以一种对 Ansible 几乎透明的方式抽象掉用户命名空间的机制。关键是将 podman unshare 命令插入 Ansible 创建的远程进程链中，从 python 开始。这可以通过一个简单的包装器脚本轻松实现

./files/podman_unshare_wrapper.sh

#!/bin/sh

exec /usr/bin/podman unshare $(type -p python3) "$@"

如下面的 ./local_2.yml 示例剧本所示，部署包装器非常简单，请确保在本地 ./files 子目录中创建它。然后，Ansible 复制模块的默认行为（创建任何缺失的远程目标目录）就可以使用。将包装器投入使用同样简单。暂时覆盖“远程”python 解释器位置。然后，template 模块可以通过包装器正确处理用户命名空间转换，以设置预期的文件所有权

./local_2.yml

---

- hosts: localhost
  gather_facts: true
  gather_subset: user
  become: false
  tasks:
    - name: Config volume for nginx container
      containers.podman.podman_volume:
        name: nginx_confd
        options:
          - o=uid=0,gid=0
        state: present
      register: vresult

    - name: Deploy podman unshare wrapper
      copy:
        src: podman_unshare_wrapper.sh
        dest: >-
          {{ ansible_user_dir }}/.local/bin/
        mode: u=rxw,g=rx,o=rx

    - name: Deploy nginx configuration
      vars:
        ansible_python_interpreter: >-
          {{ ansible_user_dir }}/.local/bin/podman_unshare_wrapper.sh
      template:
        src: default.conf.j2
        dest: >-
         {{ vresult.volume.Mountpoint }}/default.conf
        mode: u=rw,g=r,o=r
        owner: 0
        group: 0

    - name: Run nginx container
      containers.podman.podman_container:
        name: webserver
        image: nginx
        publish: ["8080:80"]
        userns: nomap
        volume:
          - >-
            {{ vresult.volume.Name }}:/etc/nginx/conf.d:Z,U
        recreate: true
        state: started

尝试像以前一样运行该剧本，ansible-playbook -i localhost, -l localhost -c local local_2.yml。您应该发现它成功完成并启动了一个工作 nginx 容器（监听 http://localhost:8080）。此外，您可以通过以下命令从主机验证正确的文件所有权

$ vol=$(podman volume inspect -f '{{.Mountpoint}}' nginx_confd)
$ podman unshare ls -lan "$vol"
total 4
drwxr-xr-x. 2 0 0   26 Feb  6 15:23 .
drwx------. 3 0 0   19 Feb  6 15:23 ..
-rw-r--r--. 1 0 0 1093 Feb  6 15:23 default.conf

假设一切正常，Ansible template 模块现在有了新的超能力！也许最好的部分是，这个版本的模板任务将在内容漂移或需要运行处理程序时提供完整的更改详细信息。继续对本地存根模板文件进行一些修改。然后再次运行剧本，注意 changed 状态，并使用以下命令查看它是否已干净地更新了文件

$ podman exec -it webserver cat /etc/nginx/conf.d/default.conf

当然，这个包装器脚本绝对是一个 hack，因此它可能不会永远起作用，也不适用于每个需要它的 Ansible 模块。但至少目前，希望这些示例已经突出了相关的组件和关键操作。因此维护 hack 应该相对容易。在所有情况下，有了这些新知识，我希望您能够将其应用到将来可能需要/从中受益的任何剧本中。