问题描述
在设置Docker镜像时遇到了问题，他希望为开发和支持团队成员创建一个即插即用的Docker镜像，让他们可以使用自己喜欢的编辑器。但是，他遇到了一个难题，需要将构建过程中的两个关键文件夹（eggs和src）暴露给最终用户，以便他们可以在任何编辑器中进行编辑。他注意到所有关于将容器文件在主机上进行编辑的选项都涉及在docker run时挂载一个新的文件夹，但是他的src和eggs文件夹是构建过程的一部分，因此不能在docker run期间挂载一个新的文件夹。
用户思考过使用卷（volumes），但对这种方法有一些疑问：
1. 我们通常会将容器内部实际作为容器一部分的构建内容放入卷中吗？没有这些卷，容器将毫无意义。
2. 最终用户是否可以复制这些卷并根据自己的方便进行修改，而不需要这些卷的主要副本？（类似于镜像与容器的概念？）
解决这个问题似乎相当复杂，用户还没有深入研究卷（volumes）的相关知识，但他觉得可以提出这个问题并获得一些指导。
解决方案
请注意以下操作可能涉及版本差异及修改前做好备份。
方案1：采用CI/CD工作流程
鉴于你的需求，Docker可能并不是解决方案，因为Docker的设计初衷是用于容器化，而不是版本控制。考虑采用持续集成（CI）和持续交付（CD）工作流程，这可能会更适合你的需求：
- 提交到
src和eggs文件夹的更改会触发新镜像的构建。 - 新镜像被推送到Docker镜像仓库。
- 团队成员可以拉取更新后的镜像。
这种方式能够满足你的需求，让开发和支持团队可以根据需要编辑src和eggs文件夹。至于你提出的两个问题：
- 通常情况下，不会将作为容器一部分的构建内容放入卷中。如果需要对容器进行更改，我通常会远程进入容器并提交更改。
- 这听起来像是版本控制系统，而Docker并不是设计用于此目的的。你可以创建一个共享的卷，让用户访问，但这通常用于持久化容器外的数据（例如SQL数据库数据）。
方案2：使用脚本控制容器启动顺序
另一种方法是使用脚本来控制容器的运行顺序。你可以手动使用docker run命令来控制容器的启动顺序，或者使用一些第三方工具来管理容器的依赖关系。以下是一个简单的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。
这种方法可能会增加复杂性，并且需要确保容器A和容器B之间的依赖关系设置正确。
这两种方法中，第一种（CI/CD工作流程）更为通用，适合团队协作和版本控制。而第二种（脚本控制容器启动顺序）则相对简单，但需要考虑依赖关系的管理。选择哪种方法取决于你的实际需求和团队的工作流程。