之前給付費(fèi)進(jìn)階群里答疑時(shí)，遇到一個(gè)新手很容易犯的典型的問(wèn)題：在Docker上使用latest鏡像版本部署服務(wù)。

一、故障現(xiàn)象

他之前部署了一套gitlab，今天發(fā)現(xiàn)無(wú)法登錄了，查看狀態(tài)時(shí)，顯示一會(huì)是UP狀態(tài)，一會(huì)又進(jìn)行重啟。

查看日志時(shí)，發(fā)現(xiàn)一些配置文件加載不成功。

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

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

經(jīng)過(guò)詢問(wèn)后，他使用了latest標(biāo)簽運(yùn)行了gitlab。

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

image: gitlab/gitlab-ce:latest

沒(méi)錯(cuò)，罪魁禍?zhǔn)拙褪?nbsp;latest。

最終解決辦法：刪除有問(wèn)題的配置文件，將latest標(biāo)簽大為具體版本，然后重新運(yùn)行容器。

二、為什么不能用 latest

很多人圖省事，覺(jué)得 latest 就是“最新版”，用起來(lái)方便，還不用記版本號(hào)。 但在生產(chǎn)環(huán)境，這其實(shí)是一個(gè)定時(shí)炸彈。

1. 版本不可控

latest 不是固定版本，它永遠(yuǎn)指向倉(cāng)庫(kù)里最新推送的鏡像。 今天可能是 16.2，明天就變成 16.5。 你以為環(huán)境沒(méi)動(dòng)，其實(shí)已經(jīng)“偷偷升級(jí)”了。

2. 兼容性風(fēng)險(xiǎn)

每個(gè)大版本之間差異很大。

• 配置文件格式變了
• 數(shù)據(jù)庫(kù)結(jié)構(gòu)變了
• 依賴環(huán)境升級(jí)了

只要有一點(diǎn)不兼容，就可能導(dǎo)致服務(wù)起不來(lái)。

3. 排障困難

出問(wèn)題時(shí)，你連“自己跑的到底是哪一個(gè)版本”都說(shuō)不清。 這讓排障、回滾、復(fù)現(xiàn)都變得異常困難。

4. 自動(dòng)更新 = 自動(dòng)踩坑

如果有 CI/CD 流水線或者鏡像自動(dòng)更新機(jī)制，latest 會(huì)在你不知情的情況下被替換成新版本。 想象一下：凌晨 3 點(diǎn)服務(wù)掛掉，原因是鏡像自動(dòng)更新到了一個(gè)不兼容的版本。

三、容器部署正確做法

1. 固定版本號(hào)

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

# 錯(cuò)誤做法
image: redis:latest

# 正確做法
image: redis:7.2.4

好處是：

• 版本可控
• 可復(fù)現(xiàn)
• 升級(jí)由自己掌握

2. 持久化存儲(chǔ)

大多數(shù)服務(wù)都會(huì)有數(shù)據(jù)目錄，比如：

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

這些目錄必須掛載到宿主機(jī)或持久化卷，否則容器一刪數(shù)據(jù)就沒(méi)了。

3. 升級(jí)要有計(jì)劃

不要依賴 latest 自動(dòng)升級(jí)，而是：

• 查官方升級(jí)路徑
• 先在測(cè)試環(huán)境驗(yàn)證
• 生產(chǎn)環(huán)境逐步升級(jí)

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

4. 升級(jí)前必須備份

無(wú)論是 GitLab、MySQL還是其他服務(wù)，升級(jí)前一定要備份數(shù)據(jù)。

5.  升級(jí)后要驗(yàn)證

升級(jí)完成后，不要覺(jué)得“能啟動(dòng)就行”，還需要：

• 檢查版本號(hào)
• 檢查數(shù)據(jù)庫(kù)遷移情況
• 跑一遍關(guān)鍵功能驗(yàn)證

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