Ansible docker_service/docker_compose模块无法停止容器问题

我来帮你排查这个让人头疼的问题——明明模块返回ok，但容器还在跑，手动执行docker-compose down却正常，这种情况大概率是模块参数、环境匹配或者版本兼容的问题，咱们一步步分析：

1. 参数冲突拖了后腿 #

你原来的任务里同时设置了stopped: yes和state: absent，这俩参数在docker_service模块里是互斥的：

• state: absent本来就等价于docker-compose down，会直接移除容器、网络这些资源
• stopped: yes只是停止容器，对应docker-compose stop

同时设置这俩，模块的执行逻辑会被打乱，导致实际行为不符合预期。而且现在docker_service已经被标记为过时了，官方推荐用docker_compose模块，咱们先把模块统一过来。

2. 路径或项目名称没匹配上 #

你手动执行docker-compose down的时候，是在/installdir/harbor目录下操作的吗？如果是的话，project_src路径没问题，但如果你的容器是用自定义项目名称启动的（比如docker-compose -p harbor up），那Ansible模块也得指定对应的project_name参数，不然它找不到对应的容器组。

另外，你可以先在目标主机上跑一遍docker-compose -f /installdir/harbor/docker-compose.yml ps，确认这个compose文件对应的就是你看到的运行中容器，避免路径或者文件名写错了。

3. 权限或环境变量不一致 #

手动执行的用户和Ansible执行的用户可能不一样：比如你手动用root跑，但Ansible用普通用户执行，没拿到docker操作权限？不过你说模块返回了ok，这个可能性偏低，但可以检查下Ansible执行用户能不能正常跑docker ps。

还有一种情况是环境变量差异——手动执行时的shell环境有docker-compose需要的变量，但Ansible执行时的环境没有，导致模块解析compose文件时出了问题，只是没报错而已。

4. 模块或版本兼容性坑 #

旧版本的docker_compose模块可能存在bug，比如对某些新的compose语法支持不好，或者和目标主机的docker-compose版本不兼容。你可以试试升级Ansible的community.docker集合（这是官方维护的docker相关模块集合），或者检查下目标主机的docker-compose版本是否符合模块要求。

调整后的任务示例 #

试试这个简化的docker_compose任务，把参数理清楚：

- name: Stop and remove Harbor containers
  community.docker.docker_compose:
    project_src: "/installdir/harbor"
    state: absent
    timeout: 30

如果你的容器是用自定义项目名称启动的，记得加上project_name参数：

- name: Stop and remove Harbor containers
  community.docker.docker_compose:
    project_src: "/installdir/harbor"
    project_name: harbor
    state: absent
    timeout: 30

额外排查小技巧 #

• 用-vvvv（最详细的日志级别）运行playbook，看看模块执行时具体调用了什么命令，有没有隐藏的错误信息——很多时候详细日志里能找到问题根源。
• 把日志里看到的模块实际调用的docker-compose命令，手动在目标主机上跑一遍，看看能不能正常停容器，这样就能区分是模块逻辑问题还是环境问题了。

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