nginxWebUI 项目并非本人所写，其国内国内项目地址： Gitee nginxWebUI ，官网：nginxWebUI.cn。
由于源项目并未提供 ARM 平台的适配，但是该项目提供了 Dockerfile 文件，我们可以根据 Dockerfile 的说明和项目的源码，进行 ARM 平台下的重编译和 Docker 容器构建。
非 ARM 平台的，也可以按照本文进行本平台的实战测试。
对于源项目的源码来说，已经打包好了 x86_64 平台的 jar.tar.gz 包，该包内包含的 java 可执行程序是无法被用于 ARM 平台下运行。所以，虽然 arm64 系统的 Docker 可以下载源项目的镜像并保持容器的运行，但是实际上， 到镜像内部的 jre 和 jar 包都是不能顺利执行的。
我们需要重新将 AArch64 的 jre 重新打包并用于容器构建。
可以通过访问甲骨文（Oracle）的 jdk 下载官网，下载 AArch64 的 jdk 进行过滤打包： Oracle Java 8 。
实际上，Oracle 提供了 Java 8 和 Java 11 两个稳定版本的 AArch64 的 rpm 和 tar.gz （Compressed Archive）。但是为了使容器尽量的精简，这里使用 Java 8 来进行过滤打包。
-
对下载得到的 jdk-8u291-linux-aarch64.tar.gz 进行解压。
-
提取出要用的两部分，复制 文件夹到新建目录 下，并删除无用的、全是 文件 目录。
-
重新压缩打包为 。
这时打包好的文件 40.13 MB ，解压后文件大小 106 MB 。注意这个数字，方便后面理解。
由于源项目是基于 SpringBoot 的，对于 ARM 环境下的 jar 要重新进行编译。这是使用 Docker 搭建 ARM 下 Maven 环境 来进行编译打包。
- 请参考： Docker 搭建 ARM 下 Maven 环境 。
-
初始镜像为 ubuntu:20.04
-
维护者为 cym1102@qq.com
-
：环境变量，告知操作系统应该从哪儿获得用户输入。
设为 可以直接运行命令，而无需向用户请求输入（所有操作都是非交互式的）。这在运行apt-get命令的时候格外有用，因为它会不停的提示用户进行到了哪步并且需要不断确认。非交互模式会选择默认的选项并以最快的速度完成构建。
但是在源 Dockerfile 中，是使用 命令进行全局的设置，这会使该环境变量在整个容器运行过程中都会生效。本应确保只在 Dockerfile 中调用的 命令中设置该选项，以避免通过 和容器进行交互时出问题。
-
通过 安装环境。注意，源 Dockerfile 中将 openjdk-11-jre 的下载安装注释掉了，这里将安装情况展示出来就能明白了：
看到 964 MB 的时候，去和之前的解压后 106 MB 相比，就知道这是多么愚蠢的一件事了。
-
命令将源作者打包好的 jre.tar.gz 压缩包，添加到 目录下解压，并对 添加 权限。
命令将源作者的 nginxWebUI.sh 脚本，添加到 目录下，并对其添加 权限。
-
将我们通过 Maven 容器编译好 jar 包复制到 。
-
作为默认入口命令，以 的形式由 调用执行。
让 将一个字串作为完整的命令来执行， 将参数传入脚本运行，利用 命令防止容器启动后退出（利用tail -f /dev/null命令防止container启动后退出）。
回顾下在本小节之前，本文中做了哪些工作：简化压缩了 的 jre 包；重编译了 AArch64 的 jar 包。
接下来需要就修改了的文件对 Dockerfile 进行修改。
- 修改了 的内容，由于要生成的新的镜像由本人构建，所以维护者（maintainer）是更改为本人邮箱，时间是 ，作者保留为源项目作者 。
- 中删除了已注释的安装 openjdk-11-jre 的命令。
- 修改了导入 jre.tar.gz 的压缩包为 jre1.8.0_291.tar.gz ，并对对应的 可执行程序的路径进行修改。
若查看 nginxWebUI.sh 脚本的内容，会发现脚本中调用了导入的 可执行程序，所以也必须对脚本的内容进行修改。
-
源脚本内容：
-
修改 可执行程序对应路径即可：
Docker 启动：
docker-compose 启动：
由于目前市场上主流的大部分 ARM 平台处理器的性能并比不上 x86_64 的主流处理器性能，容器内 SpringBoot 项目的运行启动需要时间。