[[319193]]

 文介紹了如何使用Docker中的一些關(guān)鍵概念和結(jié)構(gòu)組件來優(yōu)化Spring Boot應用程序。

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

• 在進行迭代開發(fā)和部署時，如何采用更有效的方法為Spring Boot應用程序構(gòu)建Docker鏡像。
• 為Spring Boot應用程序構(gòu)建Docker鏡像的標準方法有一些缺點，因此在這里我們要介紹如何做得更好。

Docker關(guān)鍵概念

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

Docker更新頻率

鏡像層內(nèi)容很重要

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

鏡像層影響部署

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

Docker中的Spring Boot應用

使用uber-jar方法的Spring Boot應用程序本身就是獨立的部署單元。該模型非常適合在虛擬機或構(gòu)建包上進行部署，因為該應用程序可帶來所需的一切。但是，這對Docker部署是一個缺點：Docker已經(jīng)提供了打包依賴項的方法。將整個Spring Boot JAR放入Docker鏡像是很常見的，但是，這會導致Docker鏡像的應用程序?qū)又械牟蛔儍?nèi)容太多。

Java SpringBoot單層

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

單層方法

讓我們看一下單層方法。單層方法快速，簡單，易于理解和使用。Docker的Spring Boot指南 列出了單層Dockerfile來構(gòu)建你的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"] 

它的最終結(jié)果是一個正常運行的Docker鏡像，其運行方式與你期望Spring Boot應用程序運行的方式完全相同。但是，由于它基于整個應用程序JAR，因此存在分層效率問題。隨著應用程序源的更改，整個Spring Boot JAR都會被重建。下次構(gòu)建Docker鏡像時，將重新構(gòu)建整個應用程序?qū)樱ㄋ胁蛔兊囊蕾噹?。讓我們看一個具體的例子， Spring Pet Clinic。

更深入地研究單層方法

單層方法使用Open Boot JDK基礎(chǔ)鏡像之上的Spring Boot JAR作為Docker層構(gòu)建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…   0B 
213dff56a4bd        53 seconds ago      /bin/sh -c #(nop) COPY file:d3551559c2aa35af…   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…   97.4MB 
<missing>           8 days ago          /bin/sh -c #(nop)  ENV JAVA_ALPINE_VERSION=8…   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:…   0B 
<missing>           8 days ago          /bin/sh -c #(nop)  ENV JAVA_HOME=/usr/lib/jv…   0B 
<missing>           8 days ago          /bin/sh -c {   echo '#!/bin/sh';   echo 'set…   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…   4.15MB 

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

鏡像層生命周期

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

擁抱Docker，進入雙層

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

Java Spring Boot雙層

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

在本系列的下一篇文章“ 為Spring Boot應用程序創(chuàng)建雙層Docker鏡像”中，我將介紹如何在Open Liberty項目中使用新工具為Spring Boot應用程序構(gòu)建雙層Docker鏡像。

譯者：王延飛原文鏈接：https://dzone.com/articles/optimizing-spring-boot-application-for-docker