如何使用Docker優化Spring Boot應用程序

本篇內容主要講解“如何使用Docker優化Spring Boot應用程序”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“如何使用Docker優化Spring Boot應用程序”吧!

Docker功能強大且易于使用。Docker允許開發人員研制的軟件創建可移植的鏡像。這些鏡像可重復地部署。你可以很容易地從Docker中獲得很多價值，但是要從Docker中獲得最大的價值，需要理解一些概念。在進行持續集成和持續交付時，如何構建Docker鏡像具有重要的作用。在本文中，我將重點介紹：

• 在進行迭代開發和部署時，如何采用更有效的方法為Spring Boot應用程序構建Docker鏡像。

• 為Spring Boot應用程序構建Docker鏡像的標準方法有一些缺點，因此在這里我們要介紹如何做得更好。

Docker關鍵概念

Docker有四個關鍵概念：images, layers, Dockerfile 和 Docker cache  。簡而言之，Dockerfile描述了如何構建Docker鏡像。鏡像由許多層組成。Dockerfile從基礎鏡像開始，并添加了其他層。當新內容添加到鏡像時，將生成一個新層。所構建的每個層都被緩存，因此可以在后續構建中重復使用。當Docker構建運行時，它可以從緩存中獲取重復使用任何已有層。這就減少了每次構建所需的時間和空間。任何已更改或以前尚未構建的內容都將根據需要進行構建。

Docker更新頻率

鏡像層內容很重要

鏡像各層的重要性。Docker緩存中的現有層，只有當改鏡像層內容沒有變更時，才能被使用。在Docker構建期間更改的層越多，Docker需要執行更多的工作來重建鏡像。鏡像層順序也很重要。如果某個圖層的所有父圖層均未更改，則該圖層就能被重用。因此，最好把比較頻繁更改的圖層放在上面，以便對其更改會影響較少的子圖層。鏡像層的順序和內容很重要。當你把應用程序打包為Docker鏡像時，最簡單的方法是將整個應用程序放置到一個單獨的鏡像層中。但是，如果該應用程序包含大量靜態庫依賴，那么即使更改很少的代碼，也需要重新構建整個鏡像層。這就需要在Docker緩存中，花費大量構建時間和空間。

鏡像層影響部署

部署Docker鏡像時，鏡像層也很重要。在部署Docker鏡像之前，它們會被推送到Docker遠程倉庫。該倉庫是所有部署鏡像的源頭，并且經常包含同一鏡像的許多版本。Docker非常高效，每個層僅存儲一次。但是，對于頻繁部署且具有不斷重建的大體積層的鏡像，這就不行了。大體積層的鏡像，即使內部只有很少的更改，也必須單獨存儲在倉庫中并在網絡中推送。因為需要移動并存儲不變的內容，這就會增加部署時間，

Docker中的Spring Boot應用

使用uber-jar方法的Spring  Boot應用程序本身就是獨立的部署單元。該模型非常適合在虛擬機或構建包上進行部署，因為該應用程序可帶來所需的一切。但是，這對Docker部署是一個缺點：Docker已經提供了打包依賴項的方法。將整個Spring  Boot JAR放入Docker鏡像是很常見的，但是，這會導致Docker鏡像的應用程序層中的不變內容太多。

Java SpringBoot單層

Spring社區中正在進行有關減少運行Spring  Boot應用程序時的部署大小和時間的討論，尤其是在Docker中。在我看來，這最終是在簡單性與效率之間進行權衡。為Spring  Boot應用程序構建Docker鏡像的最常見方法是我所說的“單層”方法。從技術上講，這不是正確的，因為Dockerfile實際上創建了多個層，但是對于討論來說已經足夠了。

單層方法

讓我們看一下單層方法。單層方法快速，簡單，易于理解和使用。Docker的Spring Boot指南  列出了單層Dockerfile來構建你的Docker鏡像：

FROM openjdk:8-jdk-alpine VOLUME /tmp ARG JAR_FILE COPY ${JAR_FILE} app.jar ENTRYPOINT ["java","-Djava.security.egd=file:/dev/./urandom","-jar","/app.jar"]

它的最終結果是一個正常運行的Docker鏡像，其運行方式與你期望Spring  Boot應用程序運行的方式完全相同。但是，由于它基于整個應用程序JAR，因此存在分層效率問題。隨著應用程序源的更改，整個Spring Boot  JAR都會被重建。下次構建Docker鏡像時，將重新構建整個應用程序層，包括所有不變的依賴庫。讓我們看一個具體的例子， Spring Pet  Clinic。

更深入地研究單層方法

單層方法使用Open Boot JDK基礎鏡像之上的Spring Boot JAR作為Docker層構建Docker鏡像：

$ docker images REPOSITORY                    TAG         IMAGE ID            CREATED             SIZE springio/spring-petclinic     latest      94b0366d5ba2        16 seconds ago      140MB

生成的Docker鏡像為140 MB。你可以使用docker history 命令檢查圖層 。你可以看到Spring  Boot應用程序JAR已復制到鏡像中，大小為38.3 MB。

$ docker history springio/spring-petclinic IMAGE               CREATED             CREATED BY                                      SIZE                COMMENT 94b0366d5ba2        52 seconds ago      /bin/sh -c #(nop)  ENTRYPOINT ["java" "-Djav&hellip;   0B 213dff56a4bd        53 seconds ago      /bin/sh -c #(nop) COPY file:d3551559c2aa35af&hellip;   38.3MB bc453a32748e        6 minutes ago       /bin/sh -c #(nop)  ARG JAR_FILE                 0B 7fe0bb0d8026        6 minutes ago       /bin/sh -c #(nop)  VOLUME [/tmp]                0B cc2179b8f042        8 days ago          /bin/sh -c set -x  && apk add --no-cache   o&hellip;   97.4MB <missing>           8 days ago          /bin/sh -c #(nop)  ENV JAVA_ALPINE_VERSION=8&hellip;   0B <missing>           8 days ago          /bin/sh -c #(nop)  ENV JAVA_VERSION=8u151       0B <missing>           8 days ago          /bin/sh -c #(nop)  ENV PATH=/usr/local/sbin:&hellip;   0B <missing>           8 days ago          /bin/sh -c #(nop)  ENV JAVA_HOME=/usr/lib/jv&hellip;   0B <missing>           8 days ago          /bin/sh -c {   echo '#!/bin/sh';   echo 'set&hellip;   87B <missing>           8 days ago          /bin/sh -c #(nop)  ENV LANG=C.UTF-8             0B <missing>           5 months ago        /bin/sh -c #(nop)  CMD ["/bin/sh"]              0B <missing>           5 months ago        /bin/sh -c #(nop) ADD file:093f0723fa46f6cdb&hellip;   4.15MB

下次構建Docker鏡像時，將重新創建整個38  MB的層，因為重新打包了JAR文件。在此示例中，應用程序的大小相對較小(因為僅基于spring-boot-starter-web和其他依賴項，例如spring-actuator)。在實際開發中，這些大小通常要大得多，因為它們不僅包括Spring  Boot庫，還包括其他第三方庫。根據我的經驗，實際的Spring Boot應用程序的大小范圍可能在50 MB到250  MB之間(如果不是更大的話)。仔細觀察該應用程序，應用程序JAR中只有372 KB是應用程序代碼。其余38  MB是依賴庫。這意味著實際上只有0.1%的層在變化。其余99.9%不變。

鏡像層生命周期

這是基于鏡像層的基本考慮：內容的生命周期。鏡像層的內容應具有相同的生命周期。Spring  Boot應用程序的內容有兩個不同的生命周期：不經常更改的依賴庫和經常更改的應用程序類。每次由于應用程序代碼更改而重建該層時，也會包含不變的二進制文件。在快速的應用程序開發環境中，不斷更改和重新部署應用程序代碼，這種附加成本可能變得非常昂貴。想象一個應用團隊在Pet  Clinic上進行迭代。團隊每天更改和重新部署應用程序10次。這10個新層的成本為每天383 MB。如果使用更多實際大小，則每天最多可以達到2.5  GB或更多。最終將浪費大量的構建時間，部署時間和Docker倉庫空間。快速迭代的開發和交付是決定我們是繼續使用簡單的單層方法，還是采用更有效的替代方法。

擁抱Docker，進入雙層

在簡單性和效率之間進行權衡時，我認為正確的選擇是“雙層”方法。(可以有更多的層，但是太多的層可能有害，并且違反了  Docker最佳實踐)。在雙層方法中，我們構建Docker鏡像，以使Spring  Boot應用程序的依賴庫，存在于應用程序代碼下方的一層中。這樣，各層將遵循內容的不同生命周期。通過將不經常更改的依賴庫推入一個單獨的層，并僅將應用程序類保留在頂層，那么迭代重建和重新部署就會更快。

Java Spring Boot雙層

雙層方法加快了迭代開發的速度，并最大程度地縮短了部署時間。當然實際效率因應用程序而異，但是平均而言，這將使應用程序部署大小減少90%，同時相應地縮短了部署周期。

到此，相信大家對“如何使用Docker優化Spring Boot應用程序”有了更深的了解，不妨來實際操作一番吧！這里是億速云網站，更多相關內容可以進入相關頻道進行查詢，關注我們，繼續學習！