四件簡單的事情，幫助改善部署過程

作者：DevOps云學(xué)堂 2020-10-09 10:51:42

在所有更改中，某些內(nèi)容保持不變。這些問題是，我們?nèi)绾我宰钚〉墓ぷ髁亢蜔o中斷的方式將代碼部署到生產(chǎn)中。其次，我們?nèi)绾沃婪?wù)是否正常運(yùn)行，是處于運(yùn)行狀態(tài)還是處于關(guān)閉狀態(tài)，如果我們配置正確，服務(wù)是否按預(yù)期運(yùn)行呢？

[[345134]]

以下是可以在任何環(huán)境中完成的四件簡單的事情，以幫助改善部署過程。這些將使您獲得更好的見解和信心，使您的應(yīng)用程序正確運(yùn)行和配置。

應(yīng)用程序運(yùn)行狀況檢查
事件注釋
Pod：盡量減少影響
藍(lán)綠部署

應(yīng)用程序運(yùn)行狀況檢查

改善應(yīng)用程序的部署和管理的第一步是了解您的應(yīng)用程序是否運(yùn)行正常（正在運(yùn)行并能夠執(zhí)行其預(yù)期任務(wù)），可以與下游服務(wù)進(jìn)行對話并運(yùn)行正確的版本。顯然，監(jiān)控是至關(guān)重要的，但是我們的監(jiān)視方式是將其用于自動化部署的關(guān)鍵。在我工作過的所有地方，我們都對應(yīng)用程序和數(shù)據(jù)庫進(jìn)行了某種形式的監(jiān)控，但并非所有人都進(jìn)行了應(yīng)用程序運(yùn)行狀況檢查。

最近，在Kountable，我們在所有應(yīng)用程序上都設(shè)置了*/public/health點(diǎn)。此健康檢查將告訴我們有關(guān)應(yīng)用程序的信息。首先，應(yīng)用程序是否正常運(yùn)行*（已啟動并準(zhǔn)備就緒）。其次，應(yīng)用程序正在運(yùn)行什么版本的代碼（commit）。第三，應(yīng)用程序正常運(yùn)行時間，最后是connection_status。該connnection_status告訴我們，應(yīng)用程序是否可以連接數(shù)據(jù)庫或下游服務(wù)。如果不能，那么我們可以查看這是網(wǎng)絡(luò)問題，密碼問題還是下游服務(wù)離線的問題？這有助于縮短應(yīng)用程序故障時的時間和關(guān)注范圍。這是一個運(yùn)行狀況檢查輸出示例。

{ 
"healthy": true, 
"commit": "1e98e46", 
"uptime": "05:22:47:21", 
"connection_status": true 
}

此運(yùn)行狀況檢查不僅可以用來監(jiān)視服務(wù)，還可以用作部署過程的一部分。運(yùn)行狀況檢查可用于在藍(lán)綠色部署期間驗(yàn)證安裝的版本（commit）以及運(yùn)行狀況和連接狀態(tài)。如果所有這些都通過，再加上其他綜合測試，我們可以自動將該部署升級為生產(chǎn)。

在此設(shè)置的早期，我們已將運(yùn)行狀況檢查失敗的服務(wù)部署到AWS ECS。提交ID與要部署的ID不匹配。如果您已運(yùn)行ECS服務(wù)，則知道AWS可以出色地完成工作，允許您以對當(dāng)前正在運(yùn)行的服務(wù)影響最小的方式部署ECS任務(wù)的新版本。ECS將啟動新任務(wù)，驗(yàn)證目標(biāo)組中配置的運(yùn)行狀況檢查終端節(jié)點(diǎn)，并且只有當(dāng)它通過時，它才會耗盡舊任務(wù)并啟用新服務(wù)。過去，我多次看到部署了新的ECS任務(wù)，然后始終處于啟動和失敗的循環(huán)中。任務(wù)部署上沒有AWS錯誤。唯一的選擇是查看CloudWatch日志，您會看到您的服務(wù)每分鐘啟動和停止。可能要花一些時間

通過具有提交ID或版本的應(yīng)用程序運(yùn)行狀況檢查，以及進(jìn)行藍(lán)綠色部署，我們能夠捕獲部署失敗。部署工具對要部署的提交ID和運(yùn)行狀況檢查提交ID進(jìn)行了驗(yàn)證。當(dāng)它們不匹配時，部署將停止。這一簡單的設(shè)置節(jié)省了30多分鐘的時間來確定問題，并避免了問題投入生產(chǎn)。

事件注釋

我一遍又一遍地看到的一個趨勢是，當(dāng)對系統(tǒng)，應(yīng)用程序或環(huán)境沒有任何更改時，幾乎沒有任何問題或中斷。當(dāng)我在Apigee工作時，早期的時候，我們的客戶增長很快，并且代碼不斷發(fā)布。在快速開發(fā)和持續(xù)部署的這段時間內(nèi)，我們將在生產(chǎn)應(yīng)用程序中遇到很多問題。在安靜的時期，當(dāng)沒有生產(chǎn)部署時，問題將幾乎消失或幾乎沒有。

在不斷變化的環(huán)境中，很難跟蹤所有變化。發(fā)生變更時，需要花費(fèi)一些時間來縮小范圍，尤其是隨著時間的推移以及在全球范圍內(nèi)推出變更時。我發(fā)現(xiàn)易于實(shí)現(xiàn)且非常有幫助的一件事是記錄更改事件并將該事件添加到您的監(jiān)控系統(tǒng)。使用部署工具輕松完成此操作，以使用部署事件更新監(jiān)控系統(tǒng)。

這是一個示例，其中我們最近部署了應(yīng)用程序，響應(yīng)時間立即增加。grafana批注標(biāo)記部署時間，然后您會看到響應(yīng)時間達(dá)到峰值。

除了幫助快速確定原因外，我還發(fā)現(xiàn)易于實(shí)施的任何部署過程或其他自動化過程的記錄事件。我認(rèn)為需要對環(huán)境的所有更改（從配置管理工具運(yùn)行，修補(bǔ)，備份甚至非自動更改）進(jìn)行更改。

我發(fā)現(xiàn)添加備份事件,通過將備份窗口覆蓋到系統(tǒng)資源使用情況（CPU，內(nèi)存等）而有所幫助。這是查看備份過程是否是導(dǎo)致CPU和內(nèi)存高峰的罪魁禍?zhǔn)椎目焖俸啽愕姆椒ā?/p>

Pod：盡量減少影響

Pods的概念有許多不同的迭代，從數(shù)據(jù)中心設(shè)計(jì)，VMware Pods到Kubernetes Pods。Pod有多種使用或設(shè)計(jì)的方式。關(guān)鍵是設(shè)計(jì)應(yīng)用程序和基礎(chǔ)架構(gòu)，以減少任何故障對部分組件，客戶或服務(wù)的影響。

當(dāng)我們在Apigee一起設(shè)計(jì)應(yīng)用程序和基礎(chǔ)結(jié)構(gòu)時，我們實(shí)現(xiàn)了這個概念。從操作方面與Engineering一起工作，我們設(shè)計(jì)了多租戶應(yīng)用程序，以在2個或更多應(yīng)用程序Pod上運(yùn)行客戶。對我們而言，Pod是一組應(yīng)用程序服務(wù)，其中有1到X個客戶分配給特定Pod。例如，您可能有用于核心應(yīng)用程序的Pod，有另一個用于分析或日志記錄的Pod。在AWS設(shè)置中，您可以按AWS區(qū)域擁有應(yīng)用程序Pod，然后可以將客戶分配給全球所有或幾個區(qū)域中每個區(qū)域的Pod。其他示例包括Google的gmail如何基于用戶的默認(rèn)位置或FaceBook如何將新功能推出給部分用戶。

如果由于云故障，部署問題或其他因素導(dǎo)致特定區(qū)域中的Pod出現(xiàn)問題。該問題的影響將僅隔離到該區(qū)域中該P(yáng)od上的客戶。通常，將客戶部署到多個區(qū)域后，他們將永遠(yuǎn)不會注意到該問題。

通過一起設(shè)計(jì)應(yīng)用程序和基礎(chǔ)架構(gòu)，減少問題影響/爆炸半徑的可能性越大，最終的結(jié)果就越好。