總集

# 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，只是記錄一個標記
# 每次修改這個標記，導致後面沒有快取(中間層映象)可以複用，不也能實現控制重新整理機制麼
# 尤其是把這個標記放置在需要更新，不可複用快取的前面，進行快取-非快取的分割線
# 每次構建修改一下這個，豈不是兩全齊美
# 不會全部快取導致更新內容沒更新
# 也不會全部都重新執行降低效率
# 標記前的複用快取
# 修改了標記，標記後無快取可用，必定只能重新執行
# 完美