爲了讓用戶的雲端應用管理更高效、更方便，今天從6個方面分享一些溜到飛起的Docker鏡像優化小竅門。
明確指定鏡像版本，管理更方便
爲了讓版本管理起來更方便，應用部署速度更快，在創建鏡像的過程中，建議工程師們明確指定包含版本或者其他輔助信息的tag。
如果不指定鏡像tag，默認會使用latest。每次啓動應用實例時，都需要去鏡像倉庫檢查鏡像是否更新。這種方式不利於版本管理，對應用啓動速度也有一定影響。
2種方法減小鏡像體積
1、使用alpine版本的基礎鏡像，來減小鏡像體積，以保證部署和擴容速度。
alpine是一個高度精簡又包含了基本工具的輕量級Linux發行版，本身的Docker鏡像只有4～5M大小。各開發語言和框架都有基於alpine製作的基礎鏡像，在開發自己應用的鏡像時，選擇這些鏡像作爲基礎鏡像，可以大大減小鏡像的體積。
各種語言對應的基礎鏡像如下：
-
Java(Spring Boot): - openjdk:8-jdk-alpine,openjdk:8-jre-alpine等
-
Java(Tomcat) - tomcat:8.5-alpine等
-
Nodejs - node:9-alpine, node:8-alpine等
-
Python - python:3-alpine, python:2-alpine等
-
PHP - 基於php:7-fpm-alpine,php:5-fpm-alpine等鏡像添加nginx，參考https://hub.docker.com/r/trafex/alpine-nginx-php7/
-
Ruby:ruby:2-alpine等
-
Go/可執行文件 - 直接基於alpine鏡像，把編譯後的可執行文件打入鏡像。因爲alpine不同於普通的Ubuntu/Centos等發行版，需要靜態編譯和鏈接應用代碼，例如Go需要關閉cgo：CGO_ENABLED=0 go build ...
-
靜態頁面 - nginx:1-alpine等
2、保證Dockerfile中的清理命令在同一行，也可以減小鏡像體積。
（上面的語句形式可以減小鏡像體積。）
Dockerfile的每條指令都會產生一個文件層，組件的安裝清理要放在一條命令裏面。
利用分層機制，減小鏡像傳輸大小
利用分層機制，可以減小鏡像傳輸大小，加快鏡像的推送和拉取速度Docker在build鏡像的時候，如果某個命令相關的內容沒有變化，會使用上一次緩存（cache）的文件層，在上傳到鏡像倉庫時，這一層也就不需要上傳了。利用這一點，在添加應用的時候可以分層添加，具體操作如下：（1）將不變或者變化很少的體積較大的依賴庫和經常修改的自有代碼分開（2）因爲cache緩存在運行Dockerbuild命令的本地機器上，建議固定使用某臺機器來進行Docker build，以便利用cache（更多相關信息，可以參考 https://runnable.com/blog/distributing-docker-cache-across-hosts ） 舉個例子：在構建Spring Boot應用鏡像，我們可以通過以下操作來進行分層。Step1：在Dockerfile所在目錄，解壓縮maven生成的jar包
unzip <path-to-app-jar>.jar -d app
Step2: Dockerfile 我們把應用的內容分成4個部分COPY到鏡像裏面：其中前面3個基本不變，第4個是經常變化的自有代碼。最後一行是解壓縮後，啓動spring boot應用的方式。
其他類型的應用，比如Java WAR包，Nodejs的npm模塊等，可以採取類似的方式。
避免使用進程管理程序，保證應用健康運行
在應用的某個實例崩潰或者非正常退出時，很多進程管理程序並不退出，導致平臺無法檢測到應用已經不可用，進而無法重啓應用。所以要避免使用這類進程管理程序來啓動鏡像。
2種方法幫助Java應用運行
調優用以下兩種方式可以讓Java應用感知到容器的內存限制，避免內存溢出。1、使用新版本JavaSE 8 ( ≥ 8u131)，啓動命令加上如下參數，自適應容器內存限制(MaxRAMFraction這個參數需要根據實際情況調整，1並不是普適值)
1、避免使用本地存儲。應用鏡像啓動後，文件系統是臨時的，崩潰後即被銷燬。持久化數據，文件等需要存儲到SDS，FDS等後端存儲服務中
2、應用日誌不能寫到本地文件，需要寫到標準輸出或者標準錯誤，平臺負責收集、彙總和後續的各種處理。
希望以上幾點建議能夠幫助大家避免或解決實際使用中的問題。
轉載請標明出處“小米雲技術”