構建Java鏡像的10個優秀實踐
你想構建一個Java應用程序并在Docker中運行它嗎？你知道在使用Docker構建Java容器有哪些最佳實踐？
在下面的速查表中，我將為你提供構建生產級Java容器的最佳實踐，旨在優化和保護要投入生產環境中的Docker鏡像。
1.Docker鏡像使用確定性的標簽
2.在Java鏡像中僅安裝需要的內容
3.查找并修復Java鏡像中的安全漏洞
4.使用多階段構建Java鏡像
5.不要以root用戶身份運行Java應用程序
6.Java應用程序不要使用PID為1的進程
7.優雅下線Java應用程序
8.使用 .dockerignore文件
9.確保Java版本支持容器
10.謹慎使用容器自動化生成工具
構建一個簡單的Java容器鏡像
讓我們從簡單的Dockerfile開始，在構建Java容器時，我們經常會有如下類似的內容：
- FROM maven
- RUN mkdir /app
- WORKDIR /app
- COPY . /app
- RUN mvn clean install
- CMD "mvn" "exec:java"
- Copy that to a file named Dockerfile, then build and run it.
- $ docker build . -t java-application
- $ docker run -p 8080:8080 java-application
這很簡單，而且有效。但是，此鏡像充滿錯誤。
我們不僅應該了解如何正確使用Maven，而且還應避免像上述示例那樣構建Java容器。
下面，讓我們開始逐步改進這個Dockerfile，使你的Java應用程序生成高效，安全的Docker鏡像。
1.Docker鏡像使用確定性的標簽
當使用Maven構建Java容器鏡像時，我們首先需要基于Maven鏡像。但是，你知道使用Maven基本鏡像時實際上引入了哪些內容嗎？
當你使用下面的代碼行構建鏡像時，你將獲得該Maven鏡像的最新版本：
FROM maven
這似乎是一個有趣的功能，但是這種采用Maven默認鏡像的策略可能存在一些潛在問題：
- 你的Docker構建不是冪等的。這意味著每次構建的結果可能會完全不同，今天的最新鏡像可能不同于明天或下周的最新鏡像，導致你的應用程序的字節碼也是不同的，并且可能發生意外。因此，構建鏡像時，我們希望具有可復制的確定性行為。
- Maven Docker鏡像是基于完整的操作系統鏡像。這樣會導致許多其他二進制文件出現在最終的生產鏡像中，但是運行你的Java應用程序不需要很多這些二進制文件。因此，將它們作為Java容器鏡像的一部分存在一些缺點：
1.鏡像體積變大，導致更長的下載和構建時間。
2.額外的二進制文件可能會引入安全漏洞。
如何解決吶？
- 使用適合你需求的最小基礎鏡像 考慮一下-你是否需要一個完整的操作系統（包括所有額外的二進制文件）來運行你的程序？如果沒有，也許基于alpine鏡像或Debian的鏡像會更好。
- 使用特定的鏡像 如果使用特定的鏡像，則已經可以控制和預測某些行為。如果我使用maven:3.6.3-jdk-11-slim鏡像，則已經確定我正在使用JDK 11和Maven 3.6.3。JDK和Maven的更新，將不再影響Java容器的行為。為了更加精確，你也可以使用鏡像的SHA256哈希值。使用哈希將確保你每次構建鏡像時都使用完全相同的基礎鏡像。
讓我們用這些知識更新我們的Dockerfile：
- FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c
- RUN mkdir /app
- WORKDIR /app
- COPY . /app
- RUN mvn clean package -DskipTests
2.在Java鏡像中僅安裝需要的內容
以下命令會在容器中構建Java程序，包括其所有依賴項。這意味著源代碼和構建系統都將會是Java容器的一部分。
RUN mvn clean package -DskipTests
我們都知道Java是一種編譯語言。這意味著我們只需要由你的構建環境創建的工件，而不需要代碼本身。這也意味著構建環境不應成為Java鏡像的一部分。
要運行Java鏡像，我們也不需要完整的JDK。一個Java運行時環境（JRE）就足夠了。因此，從本質上講，如果它是可運行的JAR，那么只需要使用JRE和已編譯的Java構件來構建鏡像。
使用Maven在CI流水線中都構建編譯程序，然后將JAR復制到鏡像中，如下面的更新的Dockerfile中所示：
- FROM openjdk:11-jre-slim@sha256:31a5d3fa2942eea891cf954f7d07359e09cf1b1f3d35fb32fedebb1e3399fc9e
- RUN mkdir /app
- COPY ./target/java-application.jar /app/java-application.jar
- WORKDIR /app
- CMD "java" "-jar" "java-application.jar"
3. 查找并修復Java鏡像中的安全漏洞
通過上面，我們已經開始使用適合我們需求的最小基礎鏡像了，但是，我不知道此基本鏡像中的二進制文件是否包含問題。讓我們使用安全工具（如 Snyk CLI）掃描測試我們的Docker鏡像。你可以在此處注冊免費的Snyk帳戶。
使用npm，brew，scoop或從Github下載最新的二進制文件來安裝Snyk CLI：
- $ npm install -g snyk
- $ snyk auth
- $ snyk container test openjdk:11-jre-slim@sha256:31a5d3fa2942eea891cf954f7d07359e09cf1b1f3d35fb32fedebb1e3399fc9e --file=Dockerfile
使用我剛剛創建的免費帳戶來登錄。使用snyk container test可以測試任何Docker鏡像。此外，我還可以添加Dockerfile以獲得更好的建議。
Snyk在此基本鏡像中發現了58個安全問題。它們中的大多數與Debian Linux發行版附帶的二進制文件有關。 根據此信息，我將基礎鏡像切換為由adoptopenjdk提供的
openjdk11:jre-11.0.9.1_1-alpine鏡像。
- FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f
然后使用snyk container命令對此進行測試時，此鏡像沒有已知的漏洞。
以類似的方式，你可以通過snyk test命令在項目的根目錄中測試Java應用程序。我建議你在本地計算機上進行開發時，請同時測試應用程序和創建的Java容器鏡像。緊接著，對CI流水線中的鏡像和應用程序執行相同的測試自動化。
另外，請記住，隨著時間的推移會發現漏洞。一旦發現新漏洞，你可能希望得到通知。
還有，使用snyk monitor監視你的應用程序，你將能夠及時發現新的安全問題時采取適當的措施。
另外，你也可以將git存儲庫連接到Snyk，這樣我們就可以幫助查找和補救漏洞。
讓我們更新當前的Dockerfile：
- FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f
- RUN mkdir /app
- COPY ./target/java-application.jar /app/java-application.jar
- WORKDIR /usr/src/project
- CMD "java" "-jar" "java-application.jar"
4.使用多階段構建Java鏡像
在本文的前面，我們談到了我們不需要在容器中構建Java應用程序。但是，在某些情況下，將我們的應用程序構建為Docker鏡像的一部分很方便。
我們可以將Docker鏡像的構建分為多個階段。我們可以使用構建應用程序所需的所有工具來構建鏡像，并在最后階段創建實際的生產鏡像。
- FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c AS build
- RUN mkdir /project
- COPY . /project
- WORKDIR /project
- RUN mvn clean package -DskipTests
- FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f
- RUN mkdir /app
- COPY --from=build /project/target/java-application.jar /app/java-application.jar
- WORKDIR /app
- CMD "java" "-jar" "java-application.jar"
防止敏感信息泄漏
在創建Java應用程序和Docker鏡像時，很有可能需要連接到私有倉庫，類似settings.xml的配置文件經常會泄露敏感信息。但在使用多階段構建時，你可以安全地將settings.xml復制到你的構建容器中。帶有憑據的設置將不會出現在你的最終鏡像中。此外，如果是將憑據用作命令行參數，則可以在構建鏡像中安全地執行此操作。
使用多階段構建，你可以創建多個階段，僅將結果復制到最終的生產鏡像中。這是分離是確保在生產環境中不泄漏數據的一種方法。
哦，順便說一句，使用docker history命令查看Java鏡像的輸出：
- $ docker history java-application
輸出僅顯示來自容器鏡像的信息，而不顯示構建鏡像的過程。
5.不要以Root用戶運行容器
創建Docker容器時，你需要應用最小特權原則，防止由于某種原因攻擊者能夠入侵你的應用程序，則你不希望他們能夠訪問所有內容。
擁有多層安全性，可以幫助你減少系統威脅。因此，必須確保你不以root用戶身份運行應用程序。
但默認情況下，創建Docker容器時，你將以root身份運行它。盡管這對于開發很方便，但是你不希望在生產鏡像中使用它。假設由于某種原因，攻擊者可以訪問終端或可以執行代碼。在那種情況下，它對正在運行的容器具有顯著的特權，并且訪問主機文件系統。
解決方案非常簡單。創建一個有限特權的特定用戶來運行你的應用程序，并確保該用戶可以運行該應用程序。最后，在運行應用程序之前，不要忘記使用新創建的用戶。
讓我們相應地更新我們的Dockerfile。
- FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c AS build
- RUN mkdir /project
- COPY . /project
- WORKDIR /project
- RUN mvn clean package -DskipTests
- FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f
- RUN mkdir /app
- RUN addgroup --system javauser && adduser -S -s /bin/false -G javauser javauser
- COPY --from=build /project/target/java-application.jar /app/java-application.jar
- WORKDIR /app
- RUN chown -R javauser:javauser /app
- USER javauser
- CMD "java" "-jar" "java-application.jar"
6.Java應用程序不要使用PID為1的進程
在許多示例中，我看到了使用構建環境來啟動容器化Java應用程序的常見錯誤。
上面，我們了解了要在 Java容器中使用Maven或Gradle的重要性，但是使用如下命令，會有不同的效果：
- CMD “mvn” “exec:java”
- CMD [“mvn”, “spring-boot run”]
- CMD “gradle” “bootRun”
- CMD “run-app.sh”
在Docker中運行應用程序時，第一個應用程序將以進程ID為1（PID=1）運行。Linux內核會以特殊方式處理PID為1的進程。通常，進程號為1的PID上的過程是初始化過程。如果我們使用Maven運行Java應用程序，那么如何確定Maven將類似SIGTERM信號轉發給Java進程呢？
如果像下面的示例，那樣運行Docker容器，則Java應用程序將具有PID為1的進程。
- CMD“ java”“-jar”“ application.jar”
請注意，docker kill和docker stop命令僅向PID為1的容器進程發送信號。例如，如果你正在運行Java應用的shell腳本，/bin/sh不會將信號轉發給子進程。
更為重要的是，在Linux中，PID為1的容器進程還有一些其他職責。在“ 《Docker和僵尸進程問題》”一文中對它們進行了很好的描述。因此，在某些情況下，你不希望應用程序成為PID為1的進程，因為你不知道如何處理這些問題。一個很好的解決方案是使用dumb-init。
- RUN apk add dumb-init
- CMD "dumb-init" "java" "-jar" "java-application.jar"
當你像這樣運行Docker容器時，dumb-init會占用PID為1的容器進程并承擔所有責任。你的Java流程不再需要考慮這一點。
我們更新后的Dockerfile現在看起來像這樣：
- FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c AS build
- RUN mkdir /project
- COPY . /project
- WORKDIR /project
- RUN mvn clean package -DskipTests
- FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f
- RUN apk add dumb-init
- RUN mkdir /app
- RUN addgroup --system javauser && adduser -S -s /bin/false -G javauser javauser
- COPY --from=build /project/target/java-code-workshop-0.0.1-SNAPSHOT.jar /app/java-application.jar
- WORKDIR /app
- RUN chown -R javauser:javauser /app
- USER javauser
- CMD "dumb-init" "java" "-jar" "java-application.jar"
7.優雅下線Java應用程序
當你的應用程序收到關閉信號時，理想情況下，我們希望所有內容都能正常關閉。根據你開發應用程序的方式，中斷信號（SIGINT）或CTRL + C可能導致立即終止進程。
這可能不是你想要的東西，因為諸如此類的事情可能會導致意外行為，甚至導致數據丟失。
當你將應用程序作為Payara或Apache Tomcat之類的Web服務器的一部分運行時，該Web服務器很可能會正常關閉。對于某些支持可運行應用程序的框架也是如此。例如，Spring Boot具有嵌入式Tomcat版本，可以有效地處理關機問題。
當你創建一個獨立的Java應用程序或手動創建一個可運行的JAR時，你必須自己處理這些中斷信號。
解決方案非常簡單。添加一個退出鉤子(hook )，如下面的示例所示。收到類似SIGINT信號后，優雅下線應用程序的進程將會被啟動。
- Runtime.getRuntime().addShutdownHook(new Thread() {
- @Override
- public void run() {
- System.out.println("Inside Add Shutdown Hook");
- }
- });
誠然，與Dockerfile相關的問題相比，這是一個通用的Web應用程序問題，但在容器環境中更重要。
8.使用 .dockerignore文件
為了防止不必要的文件污染git存儲庫，你可以使用.gitignore文件。
對于Docker鏡像，我們有類似的東西-.dockerignore文件。類似于git的忽略文件，它是為了防止Docker鏡像中出現不需要的文件或目錄。同時，我們也不希望敏感信息泄漏到我們的Docker鏡像中。
請參閱以下示例的.dockerignore：
- .dockerignore
- **/*.log
- Dockerfile
- .git
- .gitignore
使用.dockerignore文件的要點是：
- 跳過僅用于測試目的的依賴項。
- 使你免于泄露密鑰或憑據信息進入Java Docker鏡像的文件。
- 另外，日志文件也可能包含你不想公開的敏感信息。
- 保持Docker鏡像的美觀和整潔，本質上是使鏡像變小。除此之外，它還有助于防止意外行為。
9.確保Java版本支持容器
Java虛擬機（JVM）是一件了不起的事情。它會根據其運行的系統進行自我調整。有基于行為的調整，可以動態優化堆的大小。但是，在Java 8和Java 9等較舊的版本中，JVM無法識別容器設置的CPU限制或內存限制。這些較舊的Java版本的JVM看到了主機系統上的全部內存和所有CPU容量。Docker設置的限制將被忽略。
隨著Java 10的發布，JVM現在可以感知容器，并且可以識別容器設置的約束。該功能UseContainerSupport是JVM標志，默認情況下設置為活動狀態。Java 10中發布的容器感知功能也已移植到Java-8u191。
對于Java 8之前的版本，你可以手動嘗試使用該-Xmx標志來限制堆大小，但這是一個痛苦的練習。緊接著，堆大小不等于Java使用的內存。對于Java-8u131和Java 9，容器感知功能是實驗性的，你必須主動激活。
-XX：+ UnlockExperimentalVMOptions -XX：+ UseCGroupMemoryLimitForHeap
最好的選擇是將Java更新到10以上的版本，以便默認情況下支持容器。不幸的是，許多公司仍然嚴重依賴Java8。這意味著你應該在Docker鏡像中更新到Java的最新版本，或者確保至少使用Java 8 update 191或更高版本。
10.謹慎使用容器自動化生成工具
你可能會偶然發現適用于構建系統的出色工具和插件。除了這些插件，還有一些很棒的工具可以幫助你創建Java容器，甚至可以根據需要自動發布應用。
從開發人員的角度來看，這看起來很棒，因為你不必在創建實際應用程序時，還要花費精力維護Dockerfile。
這樣的插件的一個例子是JIB。如下所示，我只需要調用mvn jib:dockerBuild命令可以構建鏡像
- <plugin>
- <groupId>com.google.cloud.tools</groupId>
- <artifactId>jib-maven-plugin</artifactId>
- <version>2.7.1</version>
- <configuration>
- <to>
- <image>myimage</image>
- </to>
- </configuration>
- </plugin>
它將為我構建一個具有指定名稱的Docker鏡像，而沒有任何麻煩。
使用2.3及更高版本時，可以通過調用mvn命令進行操作：
- mvn spring-boot：build-image
在種情況下，系統都會自動為我創建一個Java鏡像。這些鏡像還比較小，那是因為他們正在使用非發行版鏡像或buildpack作為鏡像的基礎。但是，無論鏡像大小如何，你如何知道這些容器是安全的？你需要進行更深入的調查，即使這樣，你也不確定將來是否會保持這種狀態。
我并不是說你在創建Java Docker時不應使用這些工具。但是，如果你打算發布這些鏡像，則應研究Java鏡像所有方面的安全。鏡像掃描將是一個好的開始。從安全性的角度來看，我的觀點是，以完全控制和正確的方式創建Dockerfile，是創建鏡像更好，更安全的方式。
