Alpine安装Oracle JDK存在的问题

简介

前面我们提到了Alpine使用的不是正统的glibc，对于一些强依赖glibc的系统建议不要使用Alpine，比如使用了Oracle JDK的系统，建议在Alpine换成OpenJDK。

Alpine官方给出了Alpine的三大特征 Small、Simple、Secure，但其实我们知道一个jdk就已经不小了，强行安装只会违背Alpine的设计初衷，最后其实与其他操作系统差不多了。所以对于java程序来说使用CentOS等操作系统会更好一下

那么强行安装Oracle JDK会怎样呢，下面我们来讨论一下

常规流程安装JDK

下载一个Oracle JDK，随便哪个版本都行吧，一般来说java程序员JDK还是有的，就不带大家安装了，提前准备了一个，将JDK拷贝到Alpine容器

docker cp jdk1.8.0_231.tar.gz alpine:/usr/local/share/java

Alpine容器里解压查看jdk版本

/usr/local/share/java # ls
jdk1.8.0_231.tar.gz

## 解压
tar -zxvf jdk1.8.0_231.tar.gz

## 重新命个名
mv jdk1.8.0_231 jdk

## 查看版本  not found问题
/usr/local/share/java # /usr/local/share/java/jdk/bin/java -version
/bin/sh: /usr/local/share/java/jdk/bin/java: not found

又是似曾相识的问题，上篇文章讲到了，创建一个软连接就行
Alpine执行其他操作系统的二进制文件报错not found问题

mkdir /lib64 && ln -s /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

## 再次执行还是报错了 这次是缺少动态链接库
/usr/local/share/java # /usr/local/share/java/jdk/bin/java -version
Error relocating /usr/local/share/java/jdk/bin/../lib/amd64/jli/libjli.so: __strdup: symbol not found
Error relocating /usr/local/share/java/jdk/bin/../lib/amd64/jli/libjli.so: __rawmemchr: symbol not found

缺少动态链接库，这些库我也不认识呀，这么大问题，总有人给alpine反馈吧。下面我就来看看大佬们怎么看待吧。

---

大佬们的争议

貌似看到了一个官方解答

This is more of a musl libc issue. The Oracle Java binaries only run on glibc at the moment. We are looking at possibly rebuilding https://aur.archlinux.org/packages/jd/jdk/PKGBUILD and making it available as a standalone package. I'll keep this issue open for now as we have had requests for Java 8 multiple times already.

## 这是musl libc的一个问题，Oracle JDK的二进制文件只能在glibc下运行，我们正在考虑重新编译jdk的包使其作为alpine中一个独立的包，我们会保留这个issue，因为我们收到了很多java 8的需求

上面已经很肯定说明了，使用musl libc是运行不了Oracle JDK的，至于他说的重新编译不晓得啥时候去了，因为他连源码都拿不到。

下面还有一些其他的回答也看看

Then why are you trying to use that glibc package on Alpine? This is unofficial hack that is not supported by Alpine community. The only officially supported JRE/JDK are the mentioned openjdk packages built against musl libc.

## 你为啥要在alpine使用glibc库呢，这是不受Alpine社区支持的非官方的库，官方唯一支持的就只有针对musl libc构建的openjdk包。

## 有人提问
Our project is very complex and getting it running on OpenJDK would likely be very costly...
## 我们的项目非常复杂，如果改成运行在OpenJDK可能代价非常大。

## 回答
Then you’re probably doing it wrong… Oracle JDK is just branded distribution of OpenJDK, the code base is nearly identical. That said, exceptions may exist, mainly in case of graphic applications.
## 那你可能错了，Oracle JDK只是OpenJDK的一个发行版，代码库基本是一样的，例外可能存在，主要是在图形应用程序的情况下（意思是应该可以无缝迁移）

If you really need OracleJDK, then use some glibc-based distribution, not Alpine. Adding glibc to Alpine is not a stable production-quality solution.
## 如果你真的选择OracleJDK，那使用一些基于glibc的发行版而不是使用Alpine，在Alpine中添加glibc库并不是生产上完美的解决方案

# 继续看别人提问
I hope alpine considers officially supporting oracle java in the future.
## 我希望alpine考虑在未来正式支持oracle java。

Once again. Oracle JDK is a proprietary product, they don’t provide source-code of all their modifications to OpenJDK and build system, just binaries. These binaries are build against glibc (GNU C Library). Alpine Linux doesn’t use glibc, it’s based on (much better) musl libc.
## 再解释一遍，oracle jdk它是一个专属产品，它在OpenJDK之上写的源代码不提供啊，就仅仅提供了一个二进制文件还是基于glibc编译的，Alpine不使用glibc，它是基于更小的musl libc

Glibc and musl libc are (partially) incompatible (mainly because glibc doesn’t comply with POSIX standards). Therefore software built against glibc may not work on musl libc without recompiling. This is the case of Oracle JDK. Because it’s a proprietary product, we can’t recompile it and there’s nothing we can do about it!

## Glibc和musl libc(部分)不兼容，主要是因为Glibc不符合POSIX标准，所以基于glibc构建的软件如果不重新编译就可能无法在musl libc上运行（因为那部分的不兼容），这就是目前不支持OracleJDk的情况，OracleJDk它又是一个私有产品，我们拿不到源码不能重新编译，我们也无能为力呀。

libc is a very base system library, it’s not yet another library you can simply install along with others. Adding support for glibc would basically mean supporting another platform. The cost of this is too high. Also it doesn’t make much sense; Alpine with glibc would not be Alpine anymore! Alpine’s “motto” is: small, simply and secure. You can’t get this with glibc.

## glibc是一个非常底层的系统库，它还不是一个可以简单与其他库一起安装的库，添加对glibc的支持就意味着需要支持另一个平台，这样做的代价太高，并且也没啥太大意义。这样做Alpine将不再是Alpine,Alpine的宗旨就是小，简单，安全，这是glibc做不到的。

这个jirutka不晓得是不是官方的大佬，感觉也要被气死了，后面的还有很多就不都翻译了，大家可以去看看大佬们对这个问题的争论。下面我们还是看怎么强行在Alpine安装OracleJDK吧。

安装glibc

常规流程走不通，实在要用，那就只能是跟jirutka小哥说的一样，让他不再是一个Alpine了，安装glibc

安装key

## 下载key，以前用的这个地址现在好像访问不了了，可以换一个地址
~ # wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://raw.githubusercontent.com/sgerrand/alpine-pkg-glibc/master/sgerrand.rsa.pub
wget: server returned error: HTTP/1.1 404 Not Found

## 上面那个用不了就用这个
~ # wget -q -O /etc/apk/keys/sgerrand.rsa.pub https://alpine-pkgs.sgerrand.com/sgerrand.rsa.pub

## 查看key
cat /etc/apk/keys/sgerrand.rsa.pub

下载glibc.apk包，自己指定需要版本，可能有点慢，大家可以想办法下载然后上传也行

wget https://github.com/sgerrand/alpine-pkg-glibc/releases/download/2.29-r0/glibc-2.29-r0.apk

我这边是在外面下载了一个上传，然后copy到容器内

[root@node01 ~]# docker cp glibc-2.29-r0.apk alpine:/root

安装

~ # apk add glibc-2.29-r0.apk --no-network
(1/1) Installing glibc (2.29-r0)
OK: 13 MiB in 16 packages

安装成功后再usr目录下会多出一个glibc-compat目录

~ # cd /usr/
/usr # ls
bin           glibc-compat  lib           local         sbin          share

查看/lib64/下的软链接发现自动连接到了/usr/glibc-compat/lib/ld-linux-x86-64.so.2

/usr # cd /lib64/
/lib64 # ls -l
total 0
lrwxrwxrwx    1 root     root            42 Dec  6 19:34 ld-linux-x86-64.so.2 -> /usr/glibc-compat/lib/ld-linux-x86-64.so.2

再次查看java版本，可以正常使用了

~ # /usr/local/share/java/jdk/bin/java -version
java version "1.8.0_231"
Java(TM) SE Runtime Environment (build 1.8.0_231-b11)
Java HotSpot(TM) 64-Bit Server VM (build 25.231-b11, mixed mode)

---

JDK虽然是使用正常了，但是有的东西就不正常了，上篇文章我特意使用cronolog举了一些例子。现在来看看cronolog还能正常使用不

查看现在的时区,

~ # date
Tue Dec  6 20:02:20 CST 2022

## 按小时生成日志文件
~ # while true; do echo 'test...';sleep 1;done| cronolog  /root/test-%m%d%H.log

## 生成文件120612 现在明明是20点怎么生成的是12点
~ # ls
glibc-2.29-r0.apk  test-120612.log    tzdata

咋回事，时区明明是对的，但是cronolog切割日志出问题了，这明显少了八个小时呀。上篇文章我们是软链接到/lib目录。改回去看看

## 修改动态库软连接
ln -snf /lib/libc.musl-x86_64.so.1 /lib64/ld-linux-x86-64.so.2

## 按小时生成日志文件 
while true; do echo 'test...';sleep 1;done| cronolog  /root/test-%m%d%H.log

## 正常生成
~ # ls
glibc-2.29-r0.apk  test-120612.log    test-120620.log    tzdata


## 但是改回去jdk就不可用了，还是改回来吧
ln -snf /usr/glibc-compat/lib/ld-linux-x86-64.so.2 /lib64/ld-linux-x86-64.so.2

这明显是glibc少了时区，看看glibc下有没有时区补丁，发现目前最新版本只有i18n等一些补丁，并没有zoneinfo

https://github.com/sgerrand/alpine-pkg-glibc/releases

解决办法

将cronolog源码下载下来，再alpine中编译一版。编译前提需要安装gcc,g++,make库，编译好后在验证无问题。如果其他二进制文件再Alpine使用了glibc库后也有类似问题，可以使用此方法在Alpine中编译一版。

---

欢迎关注，学习不迷路！