docker-dockerfile構建過程
阿新 • • 發佈:2019-02-19
總集
# dockerfile的構建過程,看起來實在是讓人暢快
# 以一個簡單的指令碼,就可以構建出一個隨處執行的容器,實在是簡便至極
# 不說手工搭建環境多麼的繁瑣,哪怕是容器構建,也避免不了一些瑣碎的事情
# 不過,現在開始,dockefile完美的第一印象,我們必須就此推翻
# 只能說dockfile肯定比手工搭建更加方便快捷
# 不過有些時候,卻不一定比容器提交來的暢快
# 忘記先入為主的第一印象,接下來慢慢體會一下dockerfile到底是怎麼構建映象的
# 是總集指令碼的一次性構建呢
# 還是掩蓋了事實的一次性謊言
分步
# 仔細觀察dockerfile構建過程,不難發現,這是一個看似完整的外包專案 # 對外的確是一次性構建 # 但是內部卻是更繁瑣的分步實現 # 1. 單次構建 # 仔細觀察構建的情況,你會發現一個事實,那就是更繁瑣的構建辦法 # 1.1 它在準備基本映象之後,會依據此映象建立一個容器 # 1.2 然後在此容器基礎之上執行執行命令 # 1.3 接下來容器提交,生成新的映象 # 1.4 最後刪除這個容器 # 這不就是我們容器構建映象的方式麼 # 只不過我們命令比較多? # 2. 命令組合 # 以基礎映象開始,每一條命令重複上述步驟 # 2.1 每次的命令執行,都會在原有基礎映象上建立容器 # 2.2 執行完畢,都會有一個映象生成 # 天哪,即使是簡單的ENV環境變數設定,居然也會這麼來一套 # 為了節約資源,命令條數如果不能濃縮一點,建立的映象怕是多了去了 # EXPOSE單個埠多次宣告?WORKDIR相對路徑多次拼接? # 3. 中間層映象 # 之前說過docker ps -a能看到沒有tag的映象 # 不就是構建過程中的單命令中間映象麼
中間
# 回想一下可怕的事實
# 1. FROM為什麼需要作為非註釋第一行
# 因為每次都需要有一個基礎映象作為開始啊
# 2. 以基礎映象,建立容器,執行命令後提交映象
# 這個好浪費啊,雖然容器最後會刪除,但是構建過程中真的浪費
# 手動構建一個容器好歹能執行多個命令的啊
# 3. 雖然容器刪除了,但是中間層無名映象仍然保留
# 手工建立的話,一個容器也就夠了
# 建立這麼多容器,最後刪了也就罷了,還遺留了這麼多黑市戶口的無名映象
# 4. 中間層映象和執行命令成正比
# 好吧,dockerfile儘量濃縮
# 5. 人力外包本質
# 步驟更繁瑣了,只是不是我們做
快取
# 黑了半天,然後我們再把它洗白 # 同一個dockerfile,我們第二次build的時候 # 後面居然發現了use cache # 1. 沒錯,一個dockerfile重複構建時,由於中間層映象的存在 # 作為快取,基本你上就是直接使用組裝,沒有更多構建的消耗 # 相較於手工的容器構建,每次commit都會消耗資源,即使是相同的操作 # 2. 中間層除錯 # 手工搭建環境最麻煩的是啥,各種環境的配置和交雜 # 到最後都記不得詳細資訊了,問題都不記得 # 手工容器構建映象時依舊存在這個問題 # 但是dockerfile構建時,如果出了問題,我們可以精確定位到出錯行 # 畢竟一個dockerfile指令碼就那麼點,還是單行進行執行的 # 最主要的是,前面操作的中間層映象依然是複用的,好方便啊 # 3. --no-cache # 當然,快取不見的總是好事 # 當命令中有 apt-get update 時,使用快取就不會進行更新操作了 # docker build --no-cache dockerfile # 不啟用快取,這樣就能夠隨心所欲了 # 4. ENV REFRESH_DATE 2018-09-16 # 恩,這個是個環境變數(屁話) # 其實也不是環境變數才能進行的操作 # 只是相同命令的話,中間層映象必然會進行快取複用 # 或者使用LABEL,只是記錄一個標記 # 每次修改這個標記,導致後面沒有快取(中間層映象)可以複用,不也能實現控制重新整理機制麼 # 尤其是把這個標記放置在需要更新,不可複用快取的前面,進行快取-非快取的分割線 # 每次構建修改一下這個,豈不是兩全齊美 # 不會全部快取導致更新內容沒更新 # 也不會全部都重新執行降低效率 # 標記前的複用快取 # 修改了標記,標記後無快取可用,必定只能重新執行 # 完美