摘要:最理想的情況下,我們希望或者變動(dòng)的時(shí)候會(huì)重新的安裝包,在沒(méi)有變動(dòng)的情況下使用緩存縮短構(gòu)建時(shí)間。
在使用Docker部署PHP或者node.js應(yīng)用時(shí),常用的方法是將代碼和環(huán)境鏡像打包成一個(gè)鏡像然后運(yùn)行,一些云廠商提供了非常便捷的操作,只需要把我們的代碼提交到VCS上,然后它們就會(huì)幫我們拉取代碼并根據(jù)代碼包內(nèi)的Dockerfile構(gòu)建我們的鏡像然后部署到集群里。
PHP和node.js都有非常不錯(cuò)的生態(tài),有各種各樣的包,但是一旦引入的包多了我們的項(xiàng)目?jī)?nèi)的文件就會(huì)變得非常多,所以在使用VCS協(xié)作的時(shí)候我們都會(huì)忽略掉依賴包目錄(node_modules / vendor)。但是我們忽略了包目錄后在構(gòu)建鏡像的時(shí)候就要使用composer或者npm把包重新裝回去,所以Dockerfile大概長(zhǎng)這樣
FROM node COPY . /src RUN cd /src && npm install
這樣看起來(lái)沒(méi)什么問(wèn)題,但是如果包一旦多起來(lái)安裝的時(shí)候需要花費(fèi)很長(zhǎng)的時(shí)間,修復(fù)緊急bug的情況下等待的時(shí)間就是煎熬,那我們有沒(méi)有什么辦法能讓這個(gè)過(guò)程更快一些呢?
我們知道Docker構(gòu)建是分層的,一條指令一層,在沒(méi)有帶--no-cache=true指令的情況下如果某一層沒(méi)有改動(dòng),Docker就不會(huì)重新構(gòu)建這一層而是會(huì)使用緩存,先來(lái)看看Docker官方文檔的描述
Starting with a parent image that is already in the cache, the next instruction is compared against all child images derived from that base image to see if one of them was built using the exact same instruction. If not, the cache is invalidated.
In most cases, simply comparing the instruction in the Dockerfile with one of the child images is sufficient. However, certain instructions require more examination and explanation.
For the ADD and COPY instructions, the contents of the file(s) in the image are examined and a checksum is calculated for each file. The last-modified and last-accessed times of the file(s) are not considered in these checksums. During the cache lookup, the checksum is compared against the checksum in the existing images. If anything has changed in the file(s), such as the contents and metadata, then the cache is invalidated.
簡(jiǎn)單來(lái)說(shuō)就是如果第n層有改動(dòng),則n層以后的緩存都會(huì)失效,大多數(shù)情況下判斷有無(wú)改動(dòng)的方法是判斷這層的指令和緩存中的構(gòu)建指令是否一致,但是對(duì)于COPY和ADD命令會(huì)計(jì)算鏡像內(nèi)的文件和構(gòu)建目錄文件的校驗(yàn)和然后做比較來(lái)判斷本層是否有改動(dòng)。
最理想的情況下,我們希望package.json或者composer.json變動(dòng)的時(shí)候會(huì)重新的安裝包,在沒(méi)有變動(dòng)的情況下使用緩存縮短構(gòu)建時(shí)間。
了解上面的規(guī)則后我們?cè)賮?lái)看看上面那個(gè)Dockerfile,如果我們不修改任何代碼的話第二次構(gòu)建也是能使用緩存的,但是如果我們修改了代碼,COPY . /src這層的緩存就會(huì)失效,同時(shí)下一層的緩存也會(huì)失效。但是大多數(shù)情況下,重新構(gòu)建鏡像就意味著代碼有修改,但是package.json和composer.json這兩個(gè)文件并不會(huì)頻繁的修改,所以我們需要把這兩個(gè)文件以及install的操作分離出來(lái),所以有
FROM node COPY package.json /src/package.json RUN cd /src && npm install COPY . /src
在package.json里面寫(xiě)一個(gè)依賴包
{ "dependencies": { "express": "^4.16.4" } }
然后再寫(xiě)一個(gè)index.js
const app = require("express")(); app.listen(8080)
然后我們進(jìn)行第一次構(gòu)建,看看docker history的輸出
LIN2UR:~ lin2ur$ docker history demo IMAGE CREATED CREATED BY SIZE COMMENT 3c913c9e997b 6 seconds ago /bin/sh -c #(nop) COPY dir:e3c12f06720cf5f3b… 1.6MB 21373087419a 6 seconds ago /bin/sh -c cd /src && npm install 3MB 64896ee5240d 14 seconds ago /bin/sh -c #(nop) COPY file:87de28b86afd2c1c… 53B
把每一層的IMAGE ID和Dockerfile里面的指令對(duì)應(yīng)起來(lái)就是
64896ee5240d => COPY package.json /src/package.json
21373087419a => RUN cd /src && npm install
3c913c9e997b => COPY . /src
現(xiàn)在我們來(lái)修改一下index.js模擬我們業(yè)務(wù)代碼變動(dòng)然后再進(jìn)行構(gòu)建
LIN2UR:~ lin2ur$ docker history demo IMAGE CREATED CREATED BY SIZE COMMENT 5d697905ad0a 6 seconds ago /bin/sh -c #(nop) COPY dir:d698db67dac047bd2… 1.6MB 21373087419a 4 minutes ago /bin/sh -c cd /src && npm install 3MB 64896ee5240d 4 minutes ago /bin/sh -c #(nop) COPY file:87de28b86afd2c1c… 53B
可以看到除了最上一層外其他兩層的IMAGE ID是沒(méi)有變化的,再來(lái)看看docker build命令的輸出
LIN2UR:~ lin2ur$ docker build --rm -f "Dockerfile" -t demo . Sending build context to Docker daemon 1.902MB Step 1/4 : FROM node ---> c63e58f0a7b2 Step 2/4 : COPY package.json /src/package.json ---> Using cache ---> 64896ee5240d Step 3/4 : RUN cd /src && npm install ---> Using cache ---> 21373087419a Step 4/4 : COPY . /src ---> 5d697905ad0a Successfully built 5d697905ad0a Successfully tagged demo:latest
可以看到步驟2和3都使用了緩存,比第一次構(gòu)建的時(shí)間縮短不少。現(xiàn)在我們?cè)?b>package.json里面再加一個(gè)包模擬依賴包變動(dòng)
LIN2UR:~ lin2ur$ docker history demo IMAGE CREATED CREATED BY SIZE COMMENT 020ce95b1987 29 seconds ago /bin/sh -c #(nop) COPY dir:ea4d7afd475895520… 1.6MB d9697dfc7022 31 seconds ago /bin/sh -c cd /src && npm install 3MB 71d8a2fb458a 38 seconds ago /bin/sh -c #(nop) COPY file:87bd25345a96e6b3… 51B
這次底下兩層的IMAGE ID都變了,意味著沒(méi)有使用緩存,再來(lái)看看docker build命令的輸出
LIN2UR:~ lin2ur$ docker build --rm -f "Dockerfile" -t demo . Sending build context to Docker daemon 1.902MB Step 1/4 : FROM node ---> c63e58f0a7b2 Step 2/4 : COPY package.json /src/package.json ---> 71d8a2fb458a Step 3/4 : RUN cd /src && npm install ---> Running in ce424d6af936 Step 4/4 : COPY . /src ---> 020ce95b1987 Successfully built 020ce95b1987 Successfully tagged demo:latest
由于第二層的package.json改動(dòng)導(dǎo)致這層及后續(xù)的緩存失效,然后重新安裝包,實(shí)現(xiàn)了我們希望的結(jié)果。
文章版權(quán)歸作者所有,未經(jīng)允許請(qǐng)勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請(qǐng)注明本文地址:http://specialneedsforspecialkids.com/yun/27676.html
摘要:最理想的情況下,我們希望或者變動(dòng)的時(shí)候會(huì)重新的安裝包,在沒(méi)有變動(dòng)的情況下使用緩存縮短構(gòu)建時(shí)間。 在使用Docker部署PHP或者node.js應(yīng)用時(shí),常用的方法是將代碼和環(huán)境鏡像打包成一個(gè)鏡像然后運(yùn)行,一些云廠商提供了非常便捷的操作,只需要把我們的代碼提交到VCS上,然后它們就會(huì)幫我們拉取代碼并根據(jù)代碼包內(nèi)的Dockerfile構(gòu)建我們的鏡像然后部署到集群里。 PHP和node.js都...
摘要:本文將介紹精簡(jiǎn)容器鏡像的必要性并以基于的應(yīng)用為例描述最小化容器鏡像的常用技巧。經(jīng)過(guò)這一優(yōu)化,最終鏡像的大小為。 背景 隨著容器技術(shù)的普及,越來(lái)越多的應(yīng)用被容器化。人們使用容器的頻率越來(lái)越高,但常常忽略一個(gè)基本但又非常重要的問(wèn)題 - 容器鏡像的體積。本文將介紹精簡(jiǎn)容器鏡像的必要性并以基于 spring boot 的 java 應(yīng)用為例描述最小化容器鏡像的常用技巧。 精簡(jiǎn)容器鏡像的必要性 ...
摘要:接下來(lái)我們將逐步的減少這個(gè)鏡像的體積。優(yōu)化生產(chǎn)環(huán)境鏡像使用鏡像大幅減小鏡像體積的最簡(jiǎn)單和最快的方法是選擇一個(gè)小得多的基本鏡像。使用多階段構(gòu)建可以充分利用鏡像的緩存,大大減少最終部署到生產(chǎn)環(huán)境的時(shí)間。 關(guān)注作者github每日一道面試題詳解 你討厭部署你的應(yīng)用程序花費(fèi)很長(zhǎng)時(shí)間嗎? 對(duì)于單個(gè)容器來(lái)說(shuō),超過(guò)gb并不是最佳實(shí)踐。每次部署新版本時(shí)都要處理數(shù)十億字節(jié),這對(duì)我們來(lái)說(shuō)并不太合適。 本文...
摘要:極大地降低了平臺(tái)的復(fù)雜度,更加方便企業(yè)開(kāi)發(fā)人員實(shí)現(xiàn)各種業(yè)務(wù)應(yīng)用,幫助企業(yè)輕松打造基于云計(jì)算的軟件基礎(chǔ)設(shè)施。本文將從實(shí)際案例出發(fā),結(jié)合不同的使用場(chǎng)景,為各位介紹的這些特性。是未來(lái)數(shù)據(jù)中心操作系統(tǒng)的核心。 0.前言 隨著 Docker 技術(shù)的日漸火熱,本就火爆的云計(jì)算行業(yè)進(jìn)入了一個(gè)加速階段。云計(jì)算最大的特點(diǎn)是彈性和靈活,幫助企業(yè)應(yīng)對(duì)復(fù)雜的業(yè)務(wù)需求。由于云計(jì)算的IT構(gòu)架和上一代的IT構(gòu)架有很...
閱讀 2624·2021-11-18 10:07
閱讀 1083·2021-08-03 14:04
閱讀 726·2019-08-30 13:08
閱讀 2579·2019-08-29 15:33
閱讀 1087·2019-08-29 14:07
閱讀 2985·2019-08-29 14:04
閱讀 1435·2019-08-29 11:19
閱讀 1144·2019-08-29 10:59