问题描述
希望在Docker Swarm集群中部署的Django应用程序上运行Django Admin CLI命令。特别地，他想要管理员能够运行特定的命令，如myproject-admin manage qmonitor，并从他们自己的机器上获取命令的输出。目前，他创建的网络不能被非Swarm容器连接。他还提到了关于允许Docker Swarm网络可连接性的安全风险。
解决方案
最佳解决方案
方案1：使用depends_on属性控制容器启动顺序
在Docker或docker-compose中，可以使用depends_on属性来确保容器B在容器A停止之前运行。但需要注意，这并不能保证容器A完全就绪。
以下是在Docker Compose中实现的步骤：
- 创建一个
docker-compose.yml文件。 - 在该文件中定义需要的服务（容器A和容器B）以及它们的配置。
- 使用
depends_on属性来指定容器B依赖于容器A。
下面是一个示例docker-compose.yml文件：
version: '3'
services:
service_a:
image: your_image_for_service_a:latest
# 定义容器A的其他配置
service_b:
image: your_image_for_service_b:latest
depends_on:
- service_a
# 定义容器B的其他配置
在上面的示例中，我们定义了两个服务service_a和service_b。容器B通过depends_on属性指定依赖于容器A。这将确保容器A在容器B之前启动。
请注意，depends_on属性并不能保证容器A的完全可用性。如果容器A需要一些额外的时间来准备并变为可连接状态（如数据库启动时间），则还需要在容器B连接之前等待适当的时间。
其他解决方案
方案2：手动控制容器启动顺序
你可以编写一个脚本来手动控制容器的启动顺序。以下是一个示例的bash脚本，它可以在容器A启动后启动容器B：
#!/bin/bash
# 启动容器A
docker run -d --name container_a your_image_a
# 等待容器A完全启动
while ! docker exec container_a echo "Container A is ready"; do
sleep 1
done
# 启动容器B
docker run -d --name container_b your_image_b
在这个示例中，我们首先使用docker run命令启动容器A，并将其命名为container_a。然后，使用一个循环来等待容器A完全启动（这里是通过在容器内运行echo命令来测试）。一旦容器A就绪，我们再使用docker run命令启动容器B，并将其命名为container_b。
方案3：临时网络链接和SSH端口转发
另一种方法是通过临时网络链接和SSH端口转发来解决问题。这将允许管理员在本地运行Django Docker容器，并通过SSH访问数据库。这样的方法会使用他们自己的系统资源，但带宽可能会成为限制因素。
总结
解决方案主要取决于您的特定要求和偏好。使用depends_on属性是在Docker Compose中实现容器启动顺序的一种简单方法。手动控制容器启动顺序可能会增加复杂性，但也提供了更大的灵活性。临时网络链接和SSH端口转发是另一种可行的方法，但可能需要一些额外的配置和管理。
请注意，不管您选择哪种方法，都要确保采取必要的安全措施，以保护您的应用程序和数据。