如何在本地Ansible playbook中使Linux用户组分配修改即时生效

问题复现场景 #

在Ubuntu 18.04系统上，通过本地连接模式运行包含多Play的Ansible Playbook，流程为：

1. 安装Docker依赖与docker.io组件
2. 将当前执行用户添加至docker用户组
3. 启动Docker后台服务
4. 后续Play中通过community.docker.docker_container模块创建Docker容器

执行时会遇到典型问题：

• 首次运行Playbook时，创建容器的任务抛出permission denied错误
• 只有重启系统、让用户组配置在新的登录会话中完全加载后，再次运行Playbook才能正常执行
• 手动在当前终端会话中执行用户组刷新命令后再运行Playbook可正常执行，但尝试在Playbook内添加ansible.builtin.shell任务执行exec sg docker newgrp \id -gn``命令时，完全无法达到组配置即时生效的效果。

原有操作失效的核心原因 #

Linux系统的用户组权限列表是在用户会话初始化时，加载到每个运行进程的权限上下文中的。之前在shell模块中执行的sg、newgrp类命令，作用域仅限于该次任务调用的临时shell子进程，当该任务执行完成、临时进程退出后，对应的权限上下文就会被销毁，完全无法影响后续运行其他任务的Ansible主进程的权限配置，自然无法解决跨任务的Docker socket访问权限问题。

可直接在Playbook内实现的解决方案 #

不需要强行修改Ansible主进程的运行时组权限——这类跨进程的权限上下文调整本身就受Linux安全模型的限制，可通过以下思路从根源规避权限拦截：

• 方案一：为需要访问Docker的任务单独配置提权
  因为root用户天然拥有Docker Unix套接字/var/run/docker.sock的访问权限，不需要依赖普通用户的docker组配置，直接在创建容器的任务上配置提权参数即可：

  - name: Create docker container
    community.docker.docker_container:
      image: your-target-image
      name: your-container-name
    become: yes
    become_user: root
  

  这种方式的可靠性最高，完全不受当前会话用户组未刷新的影响，也不会留下持久化的安全配置变更。
• 方案二：为当前会话临时调整Docker套接字权限
  如果不希望让Docker操作以root权限运行，可以在安装完Docker服务、启动服务后，增加一个临时调整套接字权限的任务，让当前用户可直接访问Docker套接字：

  - name: Temporarily adjust docker socket access permission
    ansible.builtin.file:
      path: /var/run/docker.sock
      mode: '0666'
  

  该权限调整是临时的，只要Docker服务重启，套接字的权限会自动恢复为系统默认的0660（属主root、属组docker），不会破坏系统原有的安全配置。
• 方案三：在单个任务的执行上下文中加载docker组权限
  如果需要严格按照“普通用户通过docker组访问Docker”的逻辑运行，不要依赖全局会话的组配置，直接在调用Docker模块的任务前，通过vars指定任务的执行组上下文：

  - name: Create docker container
    community.docker.docker_container:
      image: your-target-image
      name: your-container-name
    vars:
      ansible_become: yes
      ansible_become_flags: "--group=docker"
  

  这种提权方式会让当前任务以原用户身份、docker组权限运行，不需要切换为root，也不受当前会话未加载docker组配置的影响。

注意：不要尝试在shell模块中通过newgrp、sg命令试图全局生效组配置。这类命令的作用域仅限单次shell调用的子进程，而Ansible的每个shell模块任务都会单独启动一个临时shell，任务之间的会话完全独立，命令执行完对应的权限上下文就会销毁，完全无法传递到后续任务的执行流程中。手动在交互终端执行这类命令有效，是因为所有操作都在同一个持续存在的shell会话中，和Ansible的任务执行模型存在本质区别。

内容的提问来源于stack exchange，提问作者Tristan Schmidt