每次操作系统会话中，只能有一个停靠上下文是活动的吗？

Question

我很难理解码头上下文文档，因为它比我的现实世界的经验到目前为止。

我想，如果我能快速、轻松地将docker-compose.yml文件转换为服务器上正在运行的应用程序堆栈，那会很有趣。理想情况下，我可以简单地将文件上传到某个地方，但无论如何，最推荐的解决方案是aws-ecs 码头组合集成。

根据这个文档，这个过程是

1. 在您的机器上本地拥有一个给定的docker-compose.yml
2. 使用aws cli和docker context的组合，使用docker命令将容器部署到aws ecs

关键的命令似乎是docker context use {{name}}。这就是我困惑的地方。

我成功地将一个容器堆栈部署到ecs (显然，我不知道如何在aws中看到这一点)，但是这个应用程序可以在URL上使用，所以它可以工作。我希望我没有被收费.)，但是后来，我想在另一个项目上做一些当地的开发。

我打开了另一个终端，试图运行停靠命令。显然，docker context仍然存在，所以我不得不docker context use default来切换回来。当我这么做的时候，我部署的应用程序崩溃了。我切换到了另一个终端，做了docker context use {{name}}，现在，尽管我的本地开发容器为另一个应用程序似乎在运行，但对它们的请求在所有端口上都失败了。

我是否理解在amazon上部署的容器堆栈依赖于本地机器的某些状态？当我关掉这台机器的时候呢？我现在不能做其他的码头开发了？如果是这样的话，是否有更好的方法来使用码头ecs集成，因为很明显，如果这是真的，这基本上是不可用的。

Answer 1

docker config context use将上下文名称记录在配置文件中(在我当前的MacOS/ Desktop系统上，在$HOME/.docker/config.json中)。因此，以这种方式更改上下文，将更改所有终端窗口中的所有shell。

Docker也是环境变量，和所有环境变量一样，这将是当前shell的本地变量。如果您试图使用这种支持部署到云环境，那么只为执行部署的命令设置环境变量可能是个好主意。

export DOCKER_CONTEXT=ecs
docker-compose up -d
docker ps -a
unset DOCKER_CONTEXT

如果部署的ECS应用程序对本地系统有任何依赖，或者在本地运行docker context use会导致云托管应用程序崩溃，我会感到非常惊讶。上下文设置只影响daemon或其他API端点本地docker命令的内容；它不会在直接系统之外进行任何持久更改。ECS应用程序可能对您的本地系统一无所知(除非您已经在环境变量设置或类似的配置中包含了它的DNS名称)，甚至可能没有网络路径来调用它。