我使用 Azure 容器服务将 dockerized 应用程序部署到 azure。它是一个使用 MongoDB 的 NodeJS/Express 应用程序。一切正常，但现在我要做的是在我的内部项目文件夹之一和 VM 上的文件夹之间设置卷映射。
这在常规 docker 中运行良好，我只需在启动容器时运行以下命令：
docker run -d --net=784849494 -p 5555:80 -v /www/uploads:/var/www/myapp/uploads myapp
基本上，我在我的虚拟机的 www 中创建了一个上传文件夹，它映射到我的项目文件夹上传。
这是我感到困惑的部分，当我在我的 VM 中创建 azure 为我启动的文件夹时，该文件夹由
user@myazureapp -p 2200 -L 22375:12.0.0.1:2375 -i mykey
这不起作用。我猜该文件夹需要在另一个与容器服务集成的 VM 中创建。但我不确定那在哪里，也找不到。
精简版：
您不想在 VM 文件夹上使用，您需要某种网络驱动器来存储您的数据。也许使用 MongoDB 服务或将 MongoDB 文件存储在可以保证数据访问的存储帐户中。例如，要执行后者，您可以使用 Docker 的 Azure Files 卷驱动程序（请参阅https://azure.microsoft.com/en-us/blog/persistent-docker-volumes-with-azure-file-storage/ )
更长的版本：
您在其上创建文件夹的机器是主机。它不是您的容器部署的位置，而是 Docker Swarm 主服务器所在的位置。这就是为什么你看不到它。您需要在代理上创建文件夹。
但是，您不知道 Swarm 将在集群中的何处部署您的容器，因此无法保证将其放置在您的文件夹所在的 VM 上。即使你很幸运并且第一次部署它时你登陆了正确的虚拟机，也不能保证如果 Docker 需要重新启动它会在同一个虚拟机上重新启动。
您可以在每个代理上创建一个文件夹，但在容器重启的情况下，您将无法保证它在同一个 VM 上重新启动，因此您的容器将无法访问相同的数据。即使您确实登陆了同一个虚拟机，您仍然可能会遇到麻烦，因为如果您的虚拟机重新启动，也许要由 Azure 修复服务，无法保证虚拟机磁盘仍然存在。VM 磁盘是短暂的，我假设您不希望这些数据消失。
在许多情况下，最好的选择是为您的数据使用服务，而不是在集群中运行它，例如https://docs.microsoft.com/en-us/azure/documentdb/documentdb-protocol-mongodb。这意味着其他人负责备份、可用性、可扩展性、性能等。这确实意味着您正在为服务付费，但是当您考虑到管理自己的服务的成本时，它通常更便宜 - 而且您需要更小的ACS 集群。
如果您真的想托管自己的 MongoDB 实例，那么您可能会考虑使用 Volume 驱动程序，以确保您的 MongoDB 容器始终可以访问网络存储位置，而不管它部署在哪里。例如，您可以为 Docker 使用 Azure Files 卷驱动程序（请参阅https://azure.microsoft.com/en-us/blog/persistent-docker-volumes-with-azure-file-storage/）。