CI/CD with Data: 通過AWS Developer Tools、 Kubernetes和Portworx來實(shí)現(xiàn)軟件交付Pipeline的數(shù)據(jù)遷移能力

數(shù)據(jù)是應(yīng)用最重要的部分。容器技術(shù)讓應(yīng)用打包和部署變得更快更容易。對于軟件的可靠交付來說，測試環(huán)節(jié)變得更加重要。由于所有的應(yīng)用都包含數(shù)據(jù)，開發(fā)團(tuán)隊(duì)需要辦法來可靠的控制、遷移、和測試真實(shí)的應(yīng)用數(shù)據(jù)。

對于一些團(tuán)隊(duì)來說，通過CI/CD pipeline來移動應(yīng)用數(shù)據(jù)，為了保持合規(guī)性和兼容其他一些問題，一直是通過手動方式來完成的，無法有效擴(kuò)展。通常只能適用于一小部分應(yīng)用，而且無法在不同環(huán)境中遷移。目標(biāo)應(yīng)該是運(yùn)行和測試有狀態(tài)容器，如同無狀態(tài)容器一樣簡單（有狀態(tài)容器 – 例如數(shù)據(jù)庫或者消息總線，其中運(yùn)行是被追蹤的；無狀態(tài)容器 – 例如網(wǎng)頁前端）

為什么測試場景中“狀態(tài)-State”十分重要？一個原因是許多bug只會在真實(shí)數(shù)據(jù)的環(huán)境下才會產(chǎn)生。例如，你需要測試一個數(shù)據(jù)庫的schema的升級，而一個小的數(shù)據(jù)集并不能完全代表包含復(fù)雜商業(yè)邏輯的關(guān)鍵應(yīng)用。如果你需要進(jìn)行端到端的完整測試，我們需要能夠容易的管理我們的數(shù)據(jù)和State。

在本篇文章中，我們定義CI/CD Pipeline的參考架構(gòu)，從而能夠達(dá)到應(yīng)用間的自動數(shù)據(jù)遷移。我們也展示如何配置CI/CD pipeline的步驟。

有狀態(tài)Pipelines: 需要可遷移的卷

作為持續(xù)集成、測試、部署的一部分，我們需要在分段setup（staging setup）中重現(xiàn)生產(chǎn)環(huán)境中發(fā)現(xiàn)的bug。這里，Hosting環(huán)境由一個集群組成：Kubernetes作為調(diào)度器，Portworx作為持久存儲卷。測試的工作流通過AWS CodeCommit、AWSCodePipeline、和AWS CodeBuild來自動完成。

Portworx提供Kubernetes存儲，從而可以實(shí)現(xiàn)在AWS環(huán)境和Pipeline之間的永久卷的遷移。AWS Developer Tools配合Portworx按照Kubernetes參考架構(gòu)的持續(xù)部署，為Kubernetes集群添加了持久存儲和存儲調(diào)度。我們使用MongoDB作為有狀態(tài)應(yīng)用的例子，但實(shí)際上，工作流可以應(yīng)用到任何容器化應(yīng)用：例如Cassandra、MySQL、Kafka、以及Elasticsearch。

使用參考架構(gòu)，開發(fā)者調(diào)用CodePipeline來觸發(fā)運(yùn)行MongoDB數(shù)據(jù)庫生產(chǎn)系統(tǒng)的快照。Portworx接著會創(chuàng)建基于塊的，可寫的MongoDB卷的快照。這個過程中，MongoDB數(shù)據(jù)庫的生產(chǎn)系統(tǒng)一直在運(yùn)行，最終用戶不會中斷。

如果沒有Portworx在其中，手動操作將會需要在CI/CD過程之外，進(jìn)行一個應(yīng)用層面的數(shù)據(jù)庫備份實(shí)例。如果數(shù)據(jù)庫較大，這會花費(fèi)好幾個小時，并且會影響到生產(chǎn)環(huán)境。使用基于塊的快照，是實(shí)現(xiàn)穩(wěn)固的不停機(jī)備份的最佳方式。

作為工作流的一部分，CodePipeline部署了一個新的MongoDB實(shí)例，Staging到Kubernetes集群上，并且Mount第二個具備生產(chǎn)數(shù)據(jù)的Porworx卷。CodePipeline通過AWS Lambda功能，來觸發(fā)Portworx卷的快照。

如下圖所示：

AWS Developer Tools與Kubernetes：通過工作流與Portworx集成

在下面的工作流中，開發(fā)者測試正在使用MongoDB的容器化應(yīng)用的一個變化。測試是針對一個Staging的MongoDB的實(shí)例。如果變化是在服務(wù)器端的話，測試工作流也是一樣的。最初的生產(chǎn)部署是作為Kubernetes的部署對象來被調(diào)度的，并且使用Portworx作為持久卷的存儲。

持續(xù)部署Pipeline按照如下來運(yùn)行：

- 開發(fā)者集成Bug修改的變化到一個主要的開發(fā)分支，這個開發(fā)分支會被合并到CodeCommit的主分支上 當(dāng)代碼被合并到AWS? ?

- CodeCommit repository的主分支后，Amazon CloudWatch觸發(fā)Pipeline AWS

- CodePipeline 發(fā)送新的版本到AWS CodeBuild, CodeBuild會創(chuàng)建一個含有build ID的Docker容器鏡像

- AWS CodeBuild推送新的已標(biāo)記build? ? ? ID的Docker容器鏡像，到Asazon ECR? ? ? registry Kubernetes從Amazon

- ECR下載新的容器（為數(shù)據(jù)庫的客戶端）、部署應(yīng)用（作為一個pod）、然后Staging MongoDB實(shí)例（作為一個部署對象）

- AWS CodePipeline, 通過Lambda功能，調(diào)用Portworx來為MongoDB生產(chǎn)系統(tǒng)做快照，并且部署一個Staging的MongoDB實(shí)例

- Portworx提供生產(chǎn)實(shí)例的快照，作為Staging MongoDB的持久存儲

- MongoDB實(shí)例Mounts快照

到這里，Staging的Setup模擬了一個生產(chǎn)環(huán)境。團(tuán)隊(duì)可以運(yùn)行集成和端到端的完整測試，使用合作伙伴的工具，不會影響到生產(chǎn)環(huán)境的負(fù)載。完整的Pipeline如下所示：

總結(jié)

這個參考架構(gòu)展示了開發(fā)團(tuán)隊(duì)可以很容易的在生產(chǎn)環(huán)境中遷移數(shù)據(jù)，以及為測試來做Staging。并不需要對應(yīng)用做特定的手動操作，所有CodePipeline的運(yùn)行都是自動的，并且作為CI/CD過程的一部分被追蹤。

這個集成過程使得有狀態(tài)容器和無狀態(tài)容器一樣容易。通過使用AWS Codepipeline來對CI/CD過程進(jìn)行管理，開發(fā)者使用Portworx存儲，可以容易的在Kubernetes集群上部署有狀態(tài)容器，并且自動的在流程中進(jìn)行數(shù)據(jù)管理。

參考架構(gòu)和代碼在Github上：

Reference architecture: https://github.com/portworx/aws-kube-codesuite

Lambda function source code for Portworx additions: https://github.com/portworx/aws-kube-codesuite/blob/master/src/kube-lambda.py

關(guān)于容器持久存儲的更多內(nèi)容，請?jiān)L問Portworx網(wǎng)站（https://portworx.com/）。關(guān)于Code Pipeline的更多內(nèi)容，請?jiān)L問AWS CodePipeline User Guide （https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html）