是的，你可以的，你通常要做的是

备选方案A：

创建一个busybox映像并复制您的框架，将该位置公开为一个卷 VOLUME /opt/framework/

FROM alpine
COPY framework /opt/framework
VOLUME /opt/framework
COPY busyscript.sh /usr/local/bin/busyscript
RUN chmod +x /usr/local/bin/busyscript
CMD ["busyscript"]

虽然busyscript.sh看起来像

#!/bin/sh
#set -x

pid=0

# SIGTERM-handler
term_handler() {
  if [ $pid -ne 0 ]; then
    kill -SIGTERM "$pid"
    wait "$pid"
  fi
  exit 143; # 128 + 15 -- SIGTERM
}

# setup handlers
# on callback, kill the last background process, which is `tail -f /dev/null` and execute the specified handler
trap 'kill ${!}; term_handler' SIGTERM

echo "Started code"
# wait forever
while true
do
  tail -f /dev/null & wait ${!}
done

将该图像作为服务添加到您的docker-compose.yml中，让我们说“ framework”，然后在您希望它们使用的服务上添加

volume_from
  - framework:ro

优点：

• 您可以编译，构建和部署framworks soley
• 运行此额外的容器几乎没有运行时开销

缺点：

• 图像大小的开销（高山，30mb）

备选方案B 您将服务之一用作“框架基础”，假设服务A，这意味着您在该服务上复制了该框架（使用该服务的两个框架之一），并且再次使用该框架VOLUME /opt/framework作为卷公开

在服务B中，以相同的方式安装卷

serviceB:
  volume_from
    - serviceA:ro

优点：

• 没有额外的容器

缺点：

• 框架需要与服务A一起部署，无论服务A是否需要更新
  • 您对A有依赖性，A是否需要更新，由于共享，需要重新创建所有其他容器