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

語言: CN / TW / HK

在所有更改中,某些內容保持不變。這些問題是,我們如何以最小的工作量和無中斷的方式將程式碼部署到生產中。其次,我們如何知道服務是否正常執行,是處於執行狀態還是處於關閉狀態,如果我們配置正確,服務是否按預期執行呢?

以下是可以在任何環境中完成的四件簡單的事情,以幫助改善部署過程。這些將使您獲得更好的見解和信心,使您的應用程式正確執行和配置。

  1. 應用程式執行狀況檢查

  2. 事件註釋

  3. Pod:儘量減少影響

  4. 藍綠部署

應用程式執行狀況檢查

改善應用程式的部署和管理的第一步是瞭解您的應用程式是否執行正常(正在執行並能夠執行其預期任務),可以與下游服務進行對話並執行正確的版本。顯然,監控是至關重要的,但是我們的監視方式是將其用於自動化部署的關鍵。在我工作過的所有地方,我們都對應用程式和資料庫進行了某種形式的監控,但並非所有人都進行了應用程式執行狀況檢查。

最近,在Kountable,我們在所有應用程式上都設定了*/public/health點。此健康檢查將告訴我們有關應用程式的資訊。首先,應用程式是否正常執行*(已啟動並準備就緒)。其次,應用程式正在執行什麼版本的程式碼(commit)。第三,應用程式正常執行時間,最後是connection_status。該connnection_status告訴我們,應用程式是否可以連線資料庫或下游服務。如果不能,那麼我們可以檢視這是網路問題,密碼問題還是下游服務離線的問題?這有助於縮短應用程式故障時的時間和關注範圍。這是一個執行狀況檢查輸出示例。

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

此執行狀況檢查不僅可以用來監視服務,還可以用作部署過程的一部分。執行狀況檢查可用於在藍綠色部署期間驗證安裝的版本(commit)以及執行狀況和連線狀態。如果所有這些都通過,再加上其他綜合測試,我們可以自動將該部署升級為生產。

在此設定的早期,我們已將執行狀況檢查失敗的服務部署到AWS ECS。提交ID與要部署的ID不匹配。如果您已執行ECS服務,則知道AWS可以出色地完成工作,允許您以對當前正在執行的服務影響最小的方式部署ECS任務的新版本。ECS將啟動新任務,驗證目標組中配置的執行狀況檢查終端節點,並且只有當它通過時,它才會耗盡舊任務並啟用新服務。過去,我多次看到部署了新的ECS任務,然後始終處於啟動和失敗的迴圈中。任務部署上沒有AWS錯誤。唯一的選擇是檢視CloudWatch日誌,您會看到您的服務每分鐘啟動和停止。可能要花一些時間

通過具有提交ID或版本的應用程式執行狀況檢查,以及進行藍綠色部署,我們能夠捕獲部署失敗。部署工具對要部署的提交ID和執行狀況檢查提交ID進行了驗證。當它們不匹配時,部署將停止。這一簡單的設定節省了30多分鐘的時間來確定問題,並避免了問題投入生產。

事件註釋

我一遍又一遍地看到的一個趨勢是,當對系統,應用程式或環境沒有任何更改時,幾乎沒有任何問題或中斷。當我在Apigee工作時,早期的時候,我們的客戶增長很快,並且程式碼不斷髮布。在快速開發和持續部署的這段時間內,我們將在生產應用程式中遇到很多問題。在安靜的時期,當沒有生產部署時,問題將幾乎消失或幾乎沒有。

在不斷變化的環境中,很難跟蹤所有變化。發生變更時,需要花費一些時間來縮小範圍,尤其是隨著時間的推移以及在全球範圍內推出變更時。我發現易於實現且非常有幫助的一件事是記錄更改事件並將該事件新增到您的監控系統。使用部署工具輕鬆完成此操作,以使用部署事件更新監控系統。

這是一個示例,其中我們最近部署了應用程式,響應時間立即增加。grafana批註標記部署時間,然後您會看到響應時間達到峰值。

除了幫助快速確定原因外,我還發現易於實施的任何部署過程或其他自動化過程的記錄事件。我認為需要對環境的所有更改(從配置管理工具執行,修補,備份甚至非自動更改)進行更改。

我發現新增備份事件,通過將備份視窗覆蓋到系統資源使用情況(CPU,記憶體等)而有所幫助。這是檢視備份過程是否是導致CPU和記憶體高峰的罪魁禍首的快速簡便的方法。

Pod:儘量減少影響

Pods的概念有許多不同的迭代,從資料中心設計,VMware Pods到Kubernetes Pods。Pod有多種使用或設計的方式。關鍵是設計應用程式和基礎架構,以減少任何故障對部分元件,客戶或服務的影響。

當我們在Apigee一起設計應用程式和基礎結構時,我們實現了這個概念。從操作方面與Engineering一起工作,我們設計了多租戶應用程式,以在2個或更多應用程式Pod上執行客戶。對我們而言,Pod是一組應用程式服務,其中有1到X個客戶分配給特定Pod。例如,您可能有用於核心應用程式的Pod,有另一個用於分析或日誌記錄的Pod。在AWS設定中,您可以按AWS區域擁有應用程式Pod,然後可以將客戶分配給全球所有或幾個區域中每個區域的Pod。其他示例包括Google的gmail如何基於使用者的預設位置或FaceBook如何將新功能推出給部分使用者。

如果由於雲故障,部署問題或其他因素導致特定區域中的Pod出現問題。該問題的影響將僅隔離到該區域中該Pod上的客戶。通常,將客戶部署到多個區域後,他們將永遠不會注意到該問題。

通過一起設計應用程式和基礎架構,減少問題影響/爆炸半徑的可能性越大,最終的結果就越好。

藍綠部署

藍綠部署使您可以執行兩個不同版本的應用程式,而一個執行實時流量。您可以通過幾種不同的方式進行設定。過去,我在ECS中執行過兩個版本的應用程式,都指向同一個資料庫。

您的應用程式和資料庫需要向前和向後相容。相容性的關鍵是您的資料庫架構更改。您需要確保將列刪除延遲到兩個版本都不需要它為止。

為了在v1.0.3或v1.0.5之間進行切換,AWS ALB設定了兩個規則,一個規則用於藍色,另一個規則用於綠色。ALB將偵聽器規則從藍色切換為綠色,然後耗盡所有舊的(藍色)連線。