Ansible为何在两个任务间从ubuntu用户切换到root用户？

一、~解析不一致的原因 #

1. copy模块的~解析逻辑 #

copy模块默认remote_src: no，也就是从控制端读取源文件，再传输到目标端。这时候src: ~/bin里的_{是在**控制端解析**的——如果你的控制端当前登录用户是ubuntu，那}/bin就指向控制端的/home/ubuntu/bin，这就是复制能成功的原因。

2. file模块的~解析逻辑 #

file模块（不管是删除还是创建文件）的操作是在目标端执行的。Ansible默认用root用户连接目标端（除非你指定了remote_user），所以目标端执行时，_{会被shell解析为root的家目录`/root`，这就是删除任务找不到ubuntu的}/bin、创建的文件跑到/root/test42的原因。

二、解决~解析歧义的方法 #

• 直接写绝对路径：把~/bin换成/home/ubuntu/bin，彻底避免~的解析问题，这是最稳妥的方式。
• 指定remote_user：在playbook开头加上remote_user: ubuntu，让所有任务都以ubuntu用户在目标端执行，此时~就会解析为/home/ubuntu。如果需要执行sudo操作（比如复制到/usr/local），可以配合become: yes，但要确保ubuntu用户有sudo权限。
• 使用变量获取家目录：开启gather_facts: yes后，可以用{{ ansible_user_dir }}（当前remote_user的家目录）或者{{ ansible_ubuntu.home }}（直接获取ubuntu用户的家目录）代替~，示例：

  - name: Delete origin directory
    file:
      path: "{{ ansible_ubuntu.home }}/bin"
      state: absent
  

三、更优雅的Ansible文件移动方案 #

Ansible确实没有内置的move模块，但有几种更靠谱的实现方式：

1. 用command模块执行mv命令 #

直接调用系统mv命令，简单直接：

- name: Move bin directory to /usr/local
  command: mv /home/ubuntu/bin /usr/local
  args:
    creates: /usr/local/bin  # 仅目标不存在时执行，避免重复操作

2. 优化版copy+delete流程 #

用remote_src: yes让copy在目标端本地复制（比跨节点传输快），仅在复制成功后删除源：

- name: Copy bin directory locally on target
  copy:
    src: /home/ubuntu/bin
    dest: /usr/local
    remote_src: yes
    owner: ubuntu
    group: ubuntu
    mode: '0774'
  register: copy_status

- name: Delete original directory after successful copy
  file:
    path: /home/ubuntu/bin
    state: absent
  when: copy_status is succeeded

3. 用synchronize模块（基于rsync） #

适合大文件/目录，效率更高，还能自动删除源文件：

- name: Move bin directory via rsync
  synchronize:
    src: /home/ubuntu/bin/  # 末尾加/表示复制目录内的内容
    dest: /usr/local/bin/
    rsync_opts:
      - "--remove-source-files"  # 同步完成后删除源文件
    owner: yes
    group: yes
    mode: yes

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