任何熟悉 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 与 $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 copy 模块创建任何缺失的远程目标目录的默认行为可以被使用。使用包装器也同样简单。临时覆盖“远程”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 应该非常容易。在所有情况下，有了这些新知识，我希望您能够将它们带到未来可能需要/受益于它的任何剧本中。