如何将 docker 卷映射到 EC2 主机文件系统
How to map docker volume to EC2 host file system
我们有一堆微服务 运行 每个都在共享的 AWS EC2 实例中自己的 Docker 容器中。
在 运行 在本地提供出色的结果后,我们现在正尝试使用 Chronicle 队列作为我们在 AWS 中的微服务之间进行通信的一种方式。
MS1 收到一个 API 请求进行一些内部处理并向 CH2 Chronicle 队列发出一个事件。 MS2 正在侦听 CH2 编年史队列,当事件到达那里时,它会进行一些内部处理并向 CH3 编年史队列发出事件。
API --> MS1 --> CH2 --> MS2 --> CH3 --> ...
在每个容器中,我们有一个应用程序根文件夹和一个子文件夹,用于微服务与之交互的每个 Chronicle 队列。
例如,在 MS1 容器中我们有 /tmp/my_app_data/ch2
,在 MS2 容器中我们有 /tmp/my_app_data/ch2
和 /tmp/my_app_data/ch3
所有这些文件夹都以类似的结构映射到 EC2 主机:
/tmp/my_app_data
|_ch2
|_ch3
|_...
现在,当尝试 运行 我们的系统时,我们遇到了访问数据的各种问题,这些数据是由一个微服务为工作流程中的下一个微服务编写的。在上面的示例中,我们可以进一步让 MS2 从 ch2 读取由 MS1 发送给您的数据,但我们仍然无法将数据标记为已处理,这意味着 MS2 正在写入 ch2 文件夹下的文件。
我无法列出我们尝试过的全部排列,甚至试图破解容器内和 EC2 主机上的文件权限;看来我缺少一些特定于 Docker/AWS.
的基本设置
这是我们来自 MS1 Docker 文件的 Docker 配置:
RUN mkdir -p /tmp/my_app_data && chown nobody:nobody /tmp/my_app_data
RUN mkdir -p /tmp/my_app_data/ch2 && chown nobody:nobody /tmp/my_app_data/ch2
USER nobody
VOLUME ["/tmp/my_app_data"]
类似地,我们有来自 MS1 Docker 文件的相同 Docker 配置:
RUN mkdir -p /tmp/my_app_data && chown nobody:nobody /tmp/my_app_data
RUN mkdir -p /tmp/my_app_data/ch2 && chown nobody:nobody /tmp/my_app_data/ch2
RUN mkdir -p /tmp/my_app_data/ch3 && chown nobody:nobody /tmp/my_app_data/ch3
USER nobody
VOLUME ["/tmp/my_app_data"]
在 AWS 端的 MS1 和 MS2 任务定义部分,我们有:
"mountPoints": [
{
"readOnly": null,
"containerPath": "/tmp/my_app_data",
"sourceVolume": "chronicle"
}
],
....
"volumes": [
{
"fsxWindowsFileServerVolumeConfiguration": null,
"efsVolumeConfiguration": null,
"name": "chronicle",
"host": {
"sourcePath": "/tmp/my_app_data"
},
"dockerVolumeConfiguration": null
}
]
所以这是我的问题:我做错了什么,我该如何解决?
理想情况下,这应该在 运行 以用户 nobody
身份 运行ning 时工作,但因为这是一个 POC,我会很感激无论如何 运行ning 得到它,包括 root
。对我们来说,此 POC 的目的是确认我们在云中使用 Chronicle 获得的结果是否与在本地 运行ning 时获得的结果相同。
提前感谢您的意见。
Chronicle FAQ 中记录了如何设置 Chronicle 队列以使用 Docker。您需要确保:
容器共享 IPC 命名空间(运行 与 --ipc="host")
队列安装在主机绑定安装的文件夹中(即 -v /host/dir/1/:/container/dir)
我们有一堆微服务 运行 每个都在共享的 AWS EC2 实例中自己的 Docker 容器中。 在 运行 在本地提供出色的结果后,我们现在正尝试使用 Chronicle 队列作为我们在 AWS 中的微服务之间进行通信的一种方式。
MS1 收到一个 API 请求进行一些内部处理并向 CH2 Chronicle 队列发出一个事件。 MS2 正在侦听 CH2 编年史队列,当事件到达那里时,它会进行一些内部处理并向 CH3 编年史队列发出事件。
API --> MS1 --> CH2 --> MS2 --> CH3 --> ...
在每个容器中,我们有一个应用程序根文件夹和一个子文件夹,用于微服务与之交互的每个 Chronicle 队列。
例如,在 MS1 容器中我们有 /tmp/my_app_data/ch2
,在 MS2 容器中我们有 /tmp/my_app_data/ch2
和 /tmp/my_app_data/ch3
所有这些文件夹都以类似的结构映射到 EC2 主机:
/tmp/my_app_data
|_ch2
|_ch3
|_...
现在,当尝试 运行 我们的系统时,我们遇到了访问数据的各种问题,这些数据是由一个微服务为工作流程中的下一个微服务编写的。在上面的示例中,我们可以进一步让 MS2 从 ch2 读取由 MS1 发送给您的数据,但我们仍然无法将数据标记为已处理,这意味着 MS2 正在写入 ch2 文件夹下的文件。
我无法列出我们尝试过的全部排列,甚至试图破解容器内和 EC2 主机上的文件权限;看来我缺少一些特定于 Docker/AWS.
的基本设置这是我们来自 MS1 Docker 文件的 Docker 配置:
RUN mkdir -p /tmp/my_app_data && chown nobody:nobody /tmp/my_app_data
RUN mkdir -p /tmp/my_app_data/ch2 && chown nobody:nobody /tmp/my_app_data/ch2
USER nobody
VOLUME ["/tmp/my_app_data"]
类似地,我们有来自 MS1 Docker 文件的相同 Docker 配置:
RUN mkdir -p /tmp/my_app_data && chown nobody:nobody /tmp/my_app_data
RUN mkdir -p /tmp/my_app_data/ch2 && chown nobody:nobody /tmp/my_app_data/ch2
RUN mkdir -p /tmp/my_app_data/ch3 && chown nobody:nobody /tmp/my_app_data/ch3
USER nobody
VOLUME ["/tmp/my_app_data"]
在 AWS 端的 MS1 和 MS2 任务定义部分,我们有:
"mountPoints": [
{
"readOnly": null,
"containerPath": "/tmp/my_app_data",
"sourceVolume": "chronicle"
}
],
....
"volumes": [
{
"fsxWindowsFileServerVolumeConfiguration": null,
"efsVolumeConfiguration": null,
"name": "chronicle",
"host": {
"sourcePath": "/tmp/my_app_data"
},
"dockerVolumeConfiguration": null
}
]
所以这是我的问题:我做错了什么,我该如何解决?
理想情况下,这应该在 运行 以用户 nobody
身份 运行ning 时工作,但因为这是一个 POC,我会很感激无论如何 运行ning 得到它,包括 root
。对我们来说,此 POC 的目的是确认我们在云中使用 Chronicle 获得的结果是否与在本地 运行ning 时获得的结果相同。
提前感谢您的意见。
Chronicle FAQ 中记录了如何设置 Chronicle 队列以使用 Docker。您需要确保:
容器共享 IPC 命名空间(运行 与 --ipc="host")
队列安装在主机绑定安装的文件夹中(即 -v /host/dir/1/:/container/dir)