【问题标题】:Overriding container JRE while deployment部署时覆盖容器 JRE
【发布时间】:2020-01-03 05:24:21
【问题描述】:

图像是使用 Oracle Open JDK 参考构建的。 因此,当我们启动容器时,它使用相同的 Oracle Open JDK。

我们希望提供一种工具,以便在部署时可以更改 JRE。如果任何用户不想更改,那么它将使用提供的默认 Oracle Open JDK。

我们想到的一种可能的解决方案: 我们将更改 docker-compose 以将主机 customJRE 目录卷映射到容器作为 containerJRE。 我们将更改我们的项目 Dockerfile 一次,它可以设置 JAVA_HOME 和 PATH 变量来引用 containerJRE。我们将重建一次图像。 部署时,用户将在主机上提供自己的 JRE。 因此,当容器出现时,将使用此自定义 JRE。

在继续之前,我们想知道这种方法的缺点。 如果有任何更好的方法或改进,这也将非常有帮助。

【问题讨论】:

    标签: java docker docker-compose dockerfile


    【解决方案1】:

    更好的方法是使用自定义 JRE 构建基础映像。这个基础镜像应该负责设置JAVA_HOME 和更新路径。

    稍后您可以通过扩展上述自定义 JRE 基础映像来创建应用程序 docker 映像。

    您当前方法的缺点

    1. 增加了整体映像大小和容器大小,因为它会包含未使用的 Oracle JRE 二进制文件
    2. 维持音量的开销
    3. 维护您将要执行的额外步骤以使用外部 JRE 覆盖现有 JRE 的开销
    4. 重新创建 docker 映像的开销

    【讨论】:

    • 感谢 Yogesh 的反馈。我同意你的观点,因为我们最初也有同样的想法。实际上,我们有多个图像。哪些用户将使用。重要的一点是,我们希望拥有一个默认 JRE [Oracle Open JDK] 的映像。因此,如果用户没有他们特定的 JRE,那么他们就不必做任何事情。这就是我们想到这种方法的原因。在这里,我们想知道这是否会在以后导致任何类型的问题或我们需要记住的任何事情。我会用更多信息更新描述。
    • 我们继续进行最初的设计,到目前为止没有发现任何问题。当然,我们增加了一定程度的额外复杂性。但是我们有这种要求,我们必须去争取。感谢 David 和 Yogesh 的反馈。
    【解决方案2】:

    一个 Docker 镜像通常包含一个完整的可运行文件系统;您通常不能交换像库这样的组件或像 JRE 这样的基础映像。

    如果最终用户能够选择 JRE 对您的应用程序很重要,那么捆绑固定 JRE 的基于 Docker 的打包并不是您想要的。分发 jar 文件可能不会变得更加复杂,我建议采用这种方法。

    如果您鼓励用户使用预构建的 Docker 映像,然后将他们选择的 JRE 绑定挂载到系统中的内容之上,那么这几乎是一个保证支持的噩梦。您会发现 Windows 和 Mac 用户试图将他们的主机 JRE 挂载到 Linux 容器中并遇到奇怪的故障。一些用户会拼写路径并使用标准 JRE 并获得意外行为。一些 JRE 可能只是不兼容。容器内 JRE 或主机 JRE 可能不会在单个目录中自包含,因此尝试替换它可能会导致 JRE 版本的奇怪混合。当用户有疑问或问题时,您有责任支持所有这些。

    【讨论】:

    • 感谢大卫的反馈。我完全同意你的所有观点。在我们的案例中,我们开发了基于微服务的架构,并且它变得越来越大。我们不能离开容器是有原因的。考虑到我们拥有的用户/客户类型,我们也确信在主机上提供 JRE 不会出现任何人为错误。我们只是想提供一种便利,以便用户/客户不必再要求我们使用他们自己的许可 JRE。
    猜你喜欢
    • 1970-01-01
    • 2016-10-10
    • 1970-01-01
    • 1970-01-01
    • 2016-01-08
    • 1970-01-01
    • 2010-10-05
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多