相关疑难解决方法(0)

Java 11被宣布为最新的LTS版本.因此,我们正在尝试基于此Java版本启动新服务.

但是,Java 11的基本Docker镜像远大于Java 8的等效镜像:

• openjdk:8-jre-alpine:84 MB

• openjdk:11-jre-slim:283 MB

(我只考虑每个Java版本的官方OpenJDK和最轻量级的图像.)

更深入的挖掘发现了以下"事物":

• 的openjdk:11-jre-slim图像使用基本图像debian:sid-slim.这带来了两个问题:

  • 这比60 MB大 alpine:3.8

  • 在Debian的sid版本是不稳定

• openjdk-11-jre-headless安装在映像中的包比(运行Docker容器内部)大3倍openjdk8-jre:

  • openjdk:8-jre-alpine:

    / # du -hs /usr/lib/jvm/java-1.8-openjdk/jre/lib/
    57.5M   /usr/lib/jvm/java-1.8-openjdk/jre/lib/
    

    Run Code Online (Sandbox Code Playgroud)

  • openjdk:11-jre-slim:

    # du -sh /usr/lib/jvm/java-11-openjdk-amd64/lib/
    179M    /usr/lib/jvm/java-11-openjdk-amd64/lib/
    

    Run Code Online (Sandbox Code Playgroud)

    更深入地我发现了这种沉重的"根" - 这modules是JDK 的文件:

    # ls -lhG /usr/lib/jvm/java-11-openjdk-amd64/lib/modules
    135M    /usr/lib/jvm/java-11-openjdk-amd64/lib/modules
    

    Run Code Online (Sandbox Code Playgroud)

所以,现在问题来了:

• 为什么alpine不再使用Java 11 slim图像的基本映像？

• 为什么不稳定的sid版本用于LTS Java图像？

• 为什么OpenJDK 11的纤薄/无头/ JRE封装与类似的OpenJDK 8封装相比如此之大？

  • 什么是在OpenJDK 11中带来135 …

有没有人在尝试执行命令时遇到此错误docker-compose up。

我试图通过查看其他涉及类似内容的文章来解决这个问题，但没有成功。

我正在尝试使用 docker-compose 文件运行我的 spring boot 应用程序，但不断收到此错误：

qemu-x86_64: Could not open '/lib/ld-musl-x86_64.so.1': No such file or directory

我试图按照我在网上阅读的建议来修复它，但没有任何效果。

我努力了：

阅读这篇文章后： https: //github.com/nodejs/help/issues/3239 添加以下内容

platform: linux/amd64

到我的 docker-compose 文件，但没有什么区别

并FROM --platform=linux/amd64在我的 Dockerfile 前面尝试过

当我读到这篇文章时，我也尝试安装musl但无法执行make命令

curl https://musl.libc.org/releases/musl-1.2.2.tar.gz -o musl-1.2.2.tar.gz
tar -xvf musl-1.2.2.tar.gz
cd musl-1.2.2
./configure
make 
make install

我的 Docker 文件如下所示

FROM azul/zulu-openjdk-alpine:11 as packager

RUN { \
        java --version ; \
        echo "jlink version:" && \
        jlink --version ; \
    } …

我正在尝试使用高级 REST 客户端 6.7.2 访问 6.x ES 实例。\n通过主机名 (https://****.azureedge.net)、用户名和密码向我提供对此 ES 实例的访问权限。

当我的 Spring Boot 应用程序从我的开发环境 (IDE) 运行时，它可以毫无问题地从同一个 ES 获取数据，但当我尝试从 Docker 容器（从我的开发机器或云中的 K8s 集群）运行它时，就会抛出 SSLHandshakeException。

FROM debian:stretch-slim容器由基础镜像和OpenJDK 11.0.2Spring Boot 必要模块组成。

我使用 进行调试取得了一些进展-Djavax.net.debug=all。事实证明，在 docker 镜像中运行时，只发生了通常 SSL 握手的几个第一步：

Produced ClientHello handshake message\nWRITE: TLS13 handshake, length = 2352\nRaw write\nRaw read (0000: 15 03 03 00 02 02 28    ......(   )\nREAD: TLSv1.2 alert, length = 2\nReceived alert message (\n  "Alert": {\n    "level"      : "fatal",\n    "description": "handshake_failure"\n …