之前給付費進階群里答疑時，遇到一個新手很容易犯的典型的問題：在Docker上使用latest鏡像版本部署服務。

一、故障現象

他之前部署了一套gitlab，今天發現無法登錄了，查看狀態時，顯示一會是UP狀態，一會又進行重啟。

查看日志時，發現一些配置文件加載不成功。

重要日志：看著好像是配置文件壞了。

Malformed configuration JSON file found ...
This usually happens when your last run of `gitlab-ctl reconfigure` didn’t complete successfully.

經過詢問后，他使用了latest標簽運行了gitlab。

根本原因分析：看似是配置文件損壞，但問題的根源并不在配置，而在于這個用戶用的是：

image: gitlab/gitlab-ce:latest

沒錯，罪魁禍首就是 latest。

最終解決辦法：刪除有問題的配置文件，將latest標簽大為具體版本，然后重新運行容器。

二、為什么不能用 latest

很多人圖省事，覺得 latest 就是“最新版”，用起來方便，還不用記版本號。 但在生產環境，這其實是一個定時炸彈。

1. 版本不可控

latest 不是固定版本，它永遠指向倉庫里最新推送的鏡像。 今天可能是 16.2，明天就變成 16.5。 你以為環境沒動，其實已經“偷偷升級”了。

2. 兼容性風險

每個大版本之間差異很大。

• 配置文件格式變了
• 數據庫結構變了
• 依賴環境升級了

只要有一點不兼容，就可能導致服務起不來。

3. 排障困難

出問題時，你連“自己跑的到底是哪一個版本”都說不清。 這讓排障、回滾、復現都變得異常困難。

4. 自動更新 = 自動踩坑

如果有 CI/CD 流水線或者鏡像自動更新機制，latest 會在你不知情的情況下被替換成新版本。 想象一下：凌晨 3 點服務掛掉，原因是鏡像自動更新到了一個不兼容的版本。

三、容器部署正確做法

1. 固定版本號

明確指定鏡像版本，而不是 latest。

# 錯誤做法
image: redis:latest

# 正確做法
image: redis:7.2.4

好處是：

• 版本可控
• 可復現
• 升級由自己掌握

2. 持久化存儲

大多數服務都會有數據目錄，比如：

• GitLab：/etc/gitlab、/var/opt/gitlab、/var/log/gitlab
• MySQL：/var/lib/mysql

這些目錄必須掛載到宿主機或持久化卷，否則容器一刪數據就沒了。

3. 升級要有計劃

不要依賴 latest 自動升級，而是：

• 查官方升級路徑
• 先在測試環境驗證
• 生產環境逐步升級

比如 GitLab 官方要求不能跨大版本直接升級，必須走 15.x → 16.0 → 16.5 這樣的路徑。

4. 升級前必須備份

無論是 GitLab、MySQL還是其他服務，升級前一定要備份數據。

5.  升級后要驗證

升級完成后，不要覺得“能啟動就行”，還需要：

• 檢查版本號
• 檢查數據庫遷移情況
• 跑一遍關鍵功能驗證

記住一句話：latest = 不穩定，固定版本 = 可控；不用 latest、不忘備份、不跨大版本、不忘驗證。