Docker 映象優化小手段
docker映象優化小手段
前言
在docker已經成為標配的時代，映象的優化建議大家都耳熟能詳，如指令串聯減少layer的層，使用更小的基礎映象等等。而在實際使用過程中，生成出來的映象從100MB到1GB大小都有，大家都覺得已經按照建議優化了，已經盡力了。最開始的時候，還堅持對一些較大的映象 一起來找茬 ，看看能做哪些優化。隨著專案的增多，只以映象大小論英雄的方式了，實在java哭nodejs笑（只是我們的映象一般都是java專案較大，nodejs較小，不代表具體意義）。最終只能是隨機選擇映象審查（其實目的就是給大家壓力，不要隨便搞），對於映象要求不能超過上限1GB（正如擠擠還是有的，映象減減還是小的），除非另外申請。
在我們一段時間的映象審查中，發現一個普遍的現象，映象越小的反而空間浪費率越高（無用的檔案、重複覆蓋的檔案或者被刪除的檔案等）。因為對於小映象，增加了20MB，30MB，也就是從100MB級別增長到200MB級別，大家真的沒有太在意，在刀耕火種無自動化工具支援的情況下，只能且行且將就~
人生總有亮光，程式設計師總不會單身一輩子的，dive的出現終於給我們較可行的映象評分方案。
dive
dive是一個可以檢視docker映象的工具，可以獲取映象的分層，分層的檔案資訊（增刪改），重複出現或刪除的檔案（無用空間的浪費）等。
映象概況
Total Image size : 總的映象大小
Potential wasted space : 可能的浪費空間（根據檔案覆蓋、刪除等計算得到）
Image efficiency score : 根據各層中浪費的空間大小估算的映象得分
根據映象的概況，我們將得分少於0.9（最大為1）的映象標記為可優化映象，並將浪費空間對應的相應檔案展示，如上圖中所示的檔案列表以及出現次數。
分層概況
上面圖片展示了dive針對映象的分層情況分析，基於這些資料我們主要分析以下幾點：
- 對於基礎映象（最底層）大於500MB的，建議選擇更小的基礎映象，如基於alpine的映象。
- 對於分層大於10層的映象，獲取各層的命令彙總展示，建議調整指令，是否已使用串連的形式。
- 除基礎映象外的所有層總大小如果大於500MB的，彙總各層新增、修改檔案（對大於1MB的檔案重點標），建議分析每層新增的檔案是否有無用檔案（因為映象中的檔案是否有用到只能由開發人員確認）。
- 彙總各層的無用檔案（我們定義為.pdf .txt .doc等一些文件檔案不應該出現在映象中），如果超過100MB的也建議優化
總結
dive提供了對docker映象的層的檔案資訊，通過這些檔案資訊，我們可以更精準的對映象提出合理的優化建議，不再是兩眼摸黑亂指定。使用了上面的分析方式整改之後，現有的映象優化了30%左右。
想了解更多dive的相關使用可以至 github dive 上瀏覽，至於不想安裝dive只想試驗的可以嘗試我業餘時間開發的網頁版 https://diving.aslant.site/ 。大家在使用網頁版的時候，可以嘗試輸入 redis （映象需要先下載，如果其它未下載映象會很慢很慢，因為大家都懂的牆）或者使用國內的映象源如 registry.docker-cn.com/library/redis 。還有大家在使用網頁版的時候，請手下留情，不要嘗試太大的映象，因為我的最低配的伺服器，小胳膊小腳，不耐操。