Docker踩坑四個教訓 - resurface

1. “latest”標籤
我們不是第一個意識到最新標籤存在重大問題的人，但我們一開始真的沒有看到這些問題。我們現在走另一條路，從我們的 Docker 映象中刪除了我們的“latest”標籤。有幾件事讓我們處於邊緣。
“latest”模式扭曲或破壞了每個 CDN 想做的快取型別，因為隨著時間的推移，這會導致多個具有相同名稱但內容不同的工件。CDN 真正喜歡的是具有唯一版本號的不可變工件。真正可怕的是，如果最新標籤由於這種快取而失敗，您將永遠不會知道。
“latest”的另一個瘋狂之處在於，使用者很難找到實際的版本號。假設您使用特定版本名稱和“latest”標籤釋出影像。安裝後docker images，即使安裝了較新版本的容器，輸出也將顯示“latest”而不是版本號。那麼使用者應該如何確定實際安裝了哪些版本呢？透過回退到比較影像 id 雜湊值，這是對人們時間的瘋狂利用。
 

2. Docker的快取很致命
Docker 映象是分層構建的，Docker 積極地快取這些層以避免下載未更改的位。問題是這種快取基於 Dockerfile 中的指令碼文字，而不是這些指令碼的實際結果。
使用--no-cache指令很容易解決這個問題
 

3. 為多個程式設計是很棘手
Docker 支援每個容器都有一個它執行的單個命令的想法。這對於簡單的情況非常有用，但假設您有三個一起執行的輕量級服務。有些人會爭辯說，這應該始終分解為三個獨立的容器，但這並非沒有成本。現在，您需要構建/管理/版本的元件數量增加了 3 倍，並且這些過程如何相互互動受到更多限制，因為它們是完全獨立的。
我們將我們的服務放在一起，並在作為容器的主要控制點的supervisord上進行標準化。這使我們可以放心地在單個容器包中執行多個服務，而無需編寫任何自定義指令碼。
 

4.較小的容器並不總是更快
很多采用Docker 理由是 Docker 容器將比它們所取代的傳統虛擬機器小得多，開銷也更少。您不必執行額外的 Ubuntu 副本，而是擁有一個很小的容器！不幸的是，這遠不能保證。
還有一個神話，即 Alpine 作為最明顯的小發行版，普遍優於其他發行版。它很小，所以它必須更快，對吧？不必要！
我們在 Alpine 上看到了在 RedHat 或 Ubuntu 上沒有看到的顯著效能下降，因為 Alpine 不是基於 glibc。最終，我們決定花費額外的時間和精力來調整我們在 Alpine 上的配置是值得的，以獲得儘可能小的下載大小。但這是一項重大的時間投資，一開始並不明顯如何去做。
Docker 使構建非常小的高效能容器成為可能，但簡化效能和下載大小的大部分負擔仍然落在容器開發人員身上。基於用於開發的相同發行版釋出多 GB 映像非常容易。獲得輕量級影像仍然需要技巧和細心。