通常一次應用的線上釋出就表示了一次新功能的上線。在上線過程中,可能發生一些非預期的情況,如新版本軟體有bug,或者功能不達預期,就會影響了線上客戶的使用。 為了盡快減少對線上使用者的影響,釋出系統需要提供復原到前一個或前幾個版本的能力。達到快速恢複線上業務的目的。
從應用的部署變更層次來看,可以分為以下三層:
![](https://img.laitimes.com/img/__Qf2AjLwojIjJCLyojI0JCLicmbw5iN0IjMkdzYjZjZmVWNkhTYhV2M0kTMmRTOxEmZwEDN38CX5d2bs92Yl1iclB3bsVmdlR2LcNWaw9CXt92Yu4GZjlGbh5yYjV3Lc9CX6MHc0RHaiojIsJye.png)
- 復原應用内的配置,适用于由于應用配置變更導緻的問題。此時如果應用能夠實作動态的配置加載,通過復原配置就能實作業務恢複的目的。否則需要重新開機應用
- 復原應用代碼的版本,适用于代碼修改導緻的問題。此時需要復原代碼的版本(鏡像),重新開機應用。
- 復原應用的工作負載與運維配置(基礎設施層)。
應用内配置復原
應用内的配置通常與應用系統需要或業務邏輯配置有關,如配置資料庫的連接配接資訊,業務規則配置等,配置的變更也很容易造成線上系統的問題,一般的做法是通過configmap或properties配置檔案來實作,這種情況下很難做到動态推送和復原的能力,因為復原需要儲存不同版本的配置。
通過
分布配置管理(ACM)(EDAS預設支援)很容易實作配置的集中管理,復原和灰階,分布式推送,審計等功能。可以在ACM或EDAS的控制台上實作一鍵復原,如下圖所示:
應用代碼復原
Deployment是一種常見部署的應用的workload,復原代碼其實對應了復原對應代碼版本的鏡像,其實就是對應就是Deployment的復原,Kubernetes可以通過以下方式支援Deployment的復原。
Deployment復原
在一個标準的 Kubernetes 體系下,如果出現新版本的pod不能正常工作,需要将deployment復原到曆史版本,Kubernetes 提供了原生的支援;其原理是在預設情況下,kubernetes 會将曆史記錄保留在系統中,直接使用使用 rollout 指令復原即可,如下:。
- 復原到上一個版本
kubectl rollout undo deployment.v1.apps/{deployment.name}
- 復原到指定的版本
- 可以通過
檢視曆史的版本kubectl rollout history
- 可以通過
kubectl rollout history deployment.v1.apps/{deployment.name}
- 可以通過以下指令復原到指定的版本
kubectl rollout undo deployment.v1.apps/{deployment.name} --to-revision={version}
EDAS中應用復原
而在 EDAS 中,結合了原生的能力做了更豐富的白屏的體驗,我們就釋出過程中和釋出完成後兩個場景分别描述。
釋出過程中復原
釋出過程中復原是指在應用釋出過程中,就發現了問題,需要将應用復原到前一個版本。此時的操作就是中斷釋出流程,将已經更新完成後或正在更新的伺服器復原到前一個版本。
EDAS在每次變更時候,可以直接中斷釋出流程,一鍵復原。如下圖所示:
另外,EDAS釋出系統提供單批,分批,金絲雀灰階等多種釋出形式,在分批和金絲雀灰階的釋出的時候,EDAS還提供不同批次的監控資訊,如系統名額,應用名額,應用異常檢測等能力,提供快速發現問題能力,如果存在問題,可以立即進行復原。如下圖所示:
我們推薦的方式也是在釋出過程中盡量使用分批和金絲雀的能力,以将釋出引起的不可用降至最小。
釋出完成後復原
釋出後復原是指一次部署過程已經完成,包含部署成功或失敗。這個時候,可以通過部署曆史的版本來實作復原的功能。EDAS 預設會存儲最多十個部署過的版本,如下圖所示:
通過以上的功能,基本上可以覆寫應用在上線過程中需要復原的場景。減少由于系統釋出出問題,造成系統功能使用上的影響。
應用自動復原
從上面的介紹,可以看到復原的操作都是人工進行的,其實在一些場景裡,可以根據一些監控名額,如CPU,load,記憶體等次元,快速發現問題,就能做到自動復原,可以能夠更快地恢複系統。在 Kubernetes 的體系中,Flagger(
https://github.com/weaveworks/flagger) 就是能夠實作自動復原的一個很好的工具。
應用工作負載和運維配置復原
上面介紹了應用内配置和應用代碼復原的方式,在常見的變更中,還存在工作負載及運維配置的變更,如更改工作負載的類型,變更JVM參數,日志配置, 彈性伸縮等。其中JVM參數等通常可以随Deployment進行復原,但是類似Kubernetes service,日志,彈性伸縮規則等這些基礎設施和運維相關的能力復原就很難做到了。需要将應用的代碼,工作負載,運維配置等實作配置化來實作復原的能力。
這裡推薦阿裡巴巴與微軟聯合提出的OAM(
Open Application Model)的規範,他定義了應用的統一傳遞模型.
在OAM中,一個應用程式包含以下幾個核心的理念:
- Component: 是指應用中的元件,可以是應用運作所依賴的服務如MySQL資料庫等,也可以是應用的本身,如Spring cloud的服務提供者。可以通過Component的定義規範來編寫一個元件。
- Trait:是指應用的運維特征,描述了應用部署在具體環境中的運維特征,比如彈性伸縮規則和Ingress配置等,這些運維特征會應用到具體的元件上。
- Applicationconfiguration:是将Components和traits組裝成一個真正能運作起來應用的定義。這個配置檔案就是OAM規範中的一個聲明式是API,通過它就能執行個體化出對應的,真實運作的應用。
一個OAM的應用例子如下:
apiVersion: core.oam.dev/v1alpha2
kind: ApplicationConfiguration
metadata:
name: springcloud-provider-deployment
annotations:
version: v1.0.0
description: "Description of this deployment"
spec:
components:
- componentName: springcloud-provider-component
parameterValues:
- name: PARAMETER_NAME
value: SUPPLIED_VALUE
- name: ANOTHER_PARAMETER
value: "AnotherValue"
traits:
- name: manualscaler.core.oam.dev
version: v1
spec:
replicaCount: 3
scopes:
- scopeRef:
apiVersion: core.oam.dev/v1alpha2
kind: NetworkScope
name: example-vpc-network
通過OAM的ApplicationConfiguration這份配置,就能描述線上真正運作的應用,結合能将配置版本化的系統,如Git,ACM等,采用對應的ApplicationConfiguration的版本,就能實作應用的一鍵復原。EDAS裡就是通過OAM規範來管理Kubernetes的應用,結合OAM聲明式API的方式,EDAS裡将會實作多種應用復原的場景,為線上業務保駕護航。
後續及結語
本章我們介紹了EDAS的釋出系統在EDAS Kubernetes叢集上進行應用釋出的時候,針對一些異常場景,如何進行快速復原。但是如果出現問題,如何快速找到問題所在,接下來的文章我們将介紹,在EDAS裡通過線上裡聯調來進行問題診斷。