Ubuntu系统下Docker未指向现有容器 无法执行docker-compose相关命令

• Docker Compose 以当前工作目录名+配置内服务名作为容器的唯一项目标识，如果你系统重启后执行docker-compose命令的目录和首次启动应用的目录不一致、或目录名被修改，Compose 会判定为全新项目，尝试新建容器时就会和系统自动拉起的旧容器端口冲突，也无法匹配到正在运行的容器执行exec等操作。
• 旧容器是被Docker的重启策略（你compose配置里的restart字段，一般为always/unless-stopped）在系统重启后自动拉起的，不属于当前Compose识别的项目范围，所以会出现"应用正常运行但Compose命令失效"的矛盾情况。

1. 临时执行artisan命令的快速方案
   直接通过容器ID操作正在运行的服务，不需要依赖Compose匹配：

# 先复制正在运行的backend服务的容器ID
docker exec <替换为你的backend容器ID> php artisan migrate

2. 修复Compose命令匹配问题
   首先查询正在运行的容器所属的Compose项目信息：

docker inspect <backend容器ID> | grep -E "com.docker.compose.project|com.docker.compose.project.working_dir"

• 如果输出的working_dir是旧路径，你只需要切换到该路径下再执行所有docker-compose命令即可恢复正常。
• 如果是目录名修改导致项目名不匹配，执行命令时指定原项目名即可：

  # 示例：原项目名为laravel-app
  docker-compose -p laravel-app up -d
  docker-compose -p laravel-app exec backend php artisan migrate
  

3. 彻底解决重启复现问题
   如果希望使用当前目录的配置重建容器，先清理旧的自动拉起容器：

# 停止并删除所有旧关联容器，替换为你自己的容器ID
docker stop <backend容器ID> <web容器ID> <mysql容器ID>
docker rm <backend容器ID> <web容器ID> <mysql容器ID>
# 重新在当前目录启动服务
docker-compose up -d

后续不要随意修改Compose配置所在的目录名、不要移动配置文件路径，即可避免重启后再次出现该问题。

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