你想構建一個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容器時，我們經常會有如下類似的內容：

1. FROM maven 
2.  
3. RUN mkdir /app 
4.  
5. WORKDIR /app 
6.  
7. COPY . /app 
8.  
9. RUN mvn clean install 
10.  
11. CMD "mvn" "exec:java"
12.  
13. Copy that to a file named Dockerfile, then build and run it. 
14.  
15. $ docker build . -t java-application 
16.  
17. $ 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：

1. FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c 
2. RUN mkdir /app 
3. WORKDIR /app 
4. COPY . /app 
5. 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中所示：

1. FROM openjdk:11-jre-slim@sha256:31a5d3fa2942eea891cf954f7d07359e09cf1b1f3d35fb32fedebb1e3399fc9e 
2.  
3. RUN mkdir /app 
4.  
5. COPY ./target/java-application.jar /app/java-application.jar 
6.  
7. WORKDIR /app 
8.  
9. CMD "java" "-jar" "java-application.jar"

3. 查找并修復Java鏡像中的安全漏洞

通過上面，我們已經開始使用適合我們需求的最小基礎鏡像了，但是，我不知道此基本鏡像中的二進制文件是否包含問題。讓我們使用安全工具（如 Snyk CLI）掃描測試我們的Docker鏡像。你可以在此處注冊免費的Snyk帳戶。

使用npm，brew，scoop或從Github下載最新的二進制文件來安裝Snyk CLI：

1. $ npm install -g snyk 
2.  
3. $ snyk auth 
4.  
5. $ 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鏡像。

1. FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f 

然后使用snyk container命令對此進行測試時，此鏡像沒有已知的漏洞。

以類似的方式，你可以通過snyk test命令在項目的根目錄中測試Java應用程序。我建議你在本地計算機上進行開發時，請同時測試應用程序和創建的Java容器鏡像。緊接著，對CI流水線中的鏡像和應用程序執行相同的測試自動化。

另外，請記住，隨著時間的推移會發現漏洞。一旦發現新漏洞，你可能希望得到通知。

還有，使用snyk monitor監視你的應用程序，你將能夠及時發現新的安全問題時采取適當的措施。

另外，你也可以將git存儲庫連接到Snyk，這樣我們就可以幫助查找和補救漏洞。

讓我們更新當前的Dockerfile：

1. FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f 
2.  
3. RUN mkdir /app 
4.  
5. COPY ./target/java-application.jar /app/java-application.jar 
6.  
7. WORKDIR /usr/src/project 
8.  
9. CMD "java" "-jar" "java-application.jar"

4.使用多階段構建Java鏡像

在本文的前面，我們談到了我們不需要在容器中構建Java應用程序。但是，在某些情況下，將我們的應用程序構建為Docker鏡像的一部分很方便。

我們可以將Docker鏡像的構建分為多個階段。我們可以使用構建應用程序所需的所有工具來構建鏡像，并在最后階段創建實際的生產鏡像。

1. FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c AS build 
2.  
3. RUN mkdir /project 
4.  
5. COPY . /project 
6.  
7. WORKDIR /project 
8.  
9. RUN mvn clean package -DskipTests 
10.  
11. FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f 
12.  
13. RUN mkdir /app 
14.  
15. COPY --from=build /project/target/java-application.jar /app/java-application.jar 
16.  
17. WORKDIR /app 
18.  
19. CMD "java" "-jar" "java-application.jar"

防止敏感信息泄漏

在創建Java應用程序和Docker鏡像時，很有可能需要連接到私有倉庫，類似settings.xml的配置文件經常會泄露敏感信息。但在使用多階段構建時，你可以安全地將settings.xml復制到你的構建容器中。帶有憑據的設置將不會出現在你的最終鏡像中。此外，如果是將憑據用作命令行參數，則可以在構建鏡像中安全地執行此操作。

使用多階段構建，你可以創建多個階段，僅將結果復制到最終的生產鏡像中。這是分離是確保在生產環境中不泄漏數據的一種方法。

哦，順便說一句，使用docker history命令查看Java鏡像的輸出：

1. $ docker history java-application 

輸出僅顯示來自容器鏡像的信息，而不顯示構建鏡像的過程。

5.不要以Root用戶運行容器

創建Docker容器時，你需要應用最小特權原則，防止由于某種原因攻擊者能夠入侵你的應用程序，則你不希望他們能夠訪問所有內容。

擁有多層安全性，可以幫助你減少系統威脅。因此，必須確保你不以root用戶身份運行應用程序。

但默認情況下，創建Docker容器時，你將以root身份運行它。盡管這對于開發很方便，但是你不希望在生產鏡像中使用它。假設由于某種原因，攻擊者可以訪問終端或可以執行代碼。在那種情況下，它對正在運行的容器具有顯著的特權，并且訪問主機文件系統。

解決方案非常簡單。創建一個有限特權的特定用戶來運行你的應用程序，并確保該用戶可以運行該應用程序。最后，在運行應用程序之前，不要忘記使用新創建的用戶。

讓我們相應地更新我們的Dockerfile。

1. FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c AS build 
2.  
3. RUN mkdir /project 
4.  
5. COPY . /project 
6.  
7. WORKDIR /project 
8.  
9. RUN mvn clean package -DskipTests 
10.  
11. FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f 
12.  
13. RUN mkdir /app 
14.  
15. RUN addgroup --system javauser && adduser -S -s /bin/false -G javauser javauser 
16.  
17. COPY --from=build /project/target/java-application.jar /app/java-application.jar 
18.  
19. WORKDIR /app 
20.  
21. RUN chown -R javauser:javauser /app 
22.  
23. USER javauser 
24.  
25. 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的進程。

1. CMD“ java”“-jar”“ application.jar” 

請注意，docker kill和docker stop命令僅向PID為1的容器進程發送信號。例如，如果你正在運行Java應用的shell腳本，/bin/sh不會將信號轉發給子進程。

更為重要的是，在Linux中，PID為1的容器進程還有一些其他職責。在“ 《Docker和僵尸進程問題》”一文中對它們進行了很好的描述。因此，在某些情況下，你不希望應用程序成為PID為1的進程，因為你不知道如何處理這些問題。一個很好的解決方案是使用dumb-init。

1. RUN apk add dumb-init 
2.  
3. CMD "dumb-init" "java" "-jar" "java-application.jar"

當你像這樣運行Docker容器時，dumb-init會占用PID為1的容器進程并承擔所有責任。你的Java流程不再需要考慮這一點。

我們更新后的Dockerfile現在看起來像這樣：

1. FROM maven:3.6.3-jdk-11-slim@sha256:68ce1cd457891f48d1e137c7d6a4493f60843e84c9e2634e3df1d3d5b381d36c AS build 
2.  
3. RUN mkdir /project 
4.  
5. COPY . /project 
6.  
7. WORKDIR /project 
8.  
9. RUN mvn clean package -DskipTests 
10.  
11. FROM adoptopenjdk/openjdk11:jre-11.0.9.1_1-alpine@sha256:b6ab039066382d39cfc843914ef1fc624aa60e2a16ede433509ccadd6d995b1f 
12.  
13. RUN apk add dumb-init 
14.  
15. RUN mkdir /app 
16.  
17. RUN addgroup --system javauser && adduser -S -s /bin/false -G javauser javauser 
18.  
19. COPY --from=build /project/target/java-code-workshop-0.0.1-SNAPSHOT.jar /app/java-application.jar 
20.  
21. WORKDIR /app 
22.  
23. RUN chown -R javauser:javauser /app 
24.  
25. USER javauser 
26.  
27. 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信號后，優雅下線應用程序的進程將會被啟動。

1. Runtime.getRuntime().addShutdownHook(new Thread() { 
2.    @Override
3.    public void run() { 
4.        System.out.println("Inside Add Shutdown Hook"); 
5.    } 
6. }); 

誠然，與Dockerfile相關的問題相比，這是一個通用的Web應用程序問題，但在容器環境中更重要。

8.使用 .dockerignore文件

為了防止不必要的文件污染git存儲庫，你可以使用.gitignore文件。

對于Docker鏡像，我們有類似的東西-.dockerignore文件。類似于git的忽略文件，它是為了防止Docker鏡像中出現不需要的文件或目錄。同時，我們也不希望敏感信息泄漏到我們的Docker鏡像中。

請參閱以下示例的.dockerignore：

1. .dockerignore 
2. **/*.log 
3. Dockerfile 
4. .git 
5. .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命令可以構建鏡像

1. <plugin> 
2.    <groupId>com.google.cloud.tools</groupId> 
3.    <artifactId>jib-maven-plugin</artifactId> 
4.    <version>2.7.1</version> 
5.    <configuration> 
6.        <to> 
7.            <image>myimage</image> 
8.        </to> 
9.    </configuration> 
10. </plugin> 

它將為我構建一個具有指定名稱的Docker鏡像，而沒有任何麻煩。

使用2.3及更高版本時，可以通過調用mvn命令進行操作：

1. mvn spring-boot：build-image 

在種情況下，系統都會自動為我創建一個Java鏡像。這些鏡像還比較小，那是因為他們正在使用非發行版鏡像或buildpack作為鏡像的基礎。但是，無論鏡像大小如何，你如何知道這些容器是安全的？你需要進行更深入的調查，即使這樣，你也不確定將來是否會保持這種狀態。

我并不是說你在創建Java Docker時不應使用這些工具。但是，如果你打算發布這些鏡像，則應研究Java鏡像所有方面的安全。鏡像掃描將是一個好的開始。從安全性的角度來看，我的觀點是，以完全控制和正確的方式創建Dockerfile，是創建鏡像更好，更安全的方式。

原文鏈接：https://www.toutiao.com/a6959742944421200387/