有狀態Stateful，富含數據的CI/CD怎麼作？

CI/CD with Data: 經過AWS Developer Tools、 Kubernetes和Portworx來實現軟件交付Pipeline的數據遷移能力

數據是應用最重要的部分。容器技術讓應用打包和部署變得更快更容易。對於軟件的可靠交付來講，測試環節變得更加劇要。因爲全部的應用都包含數據，開發團隊須要辦法來可靠的控制、遷移、和測試真實的應用數據。

對於一些團隊來講，經過CI/CD pipeline來移動應用數據，爲了保持合規性和兼容其餘一些問題，一直是經過手動方式來完成的，沒法有效擴展。一般只能適用於一小部分應用，並且沒法在不一樣環境中遷移。目標應該是運行和測試有狀態容器，如同無狀態容器同樣簡單（有狀態容器 – 例如數據庫或者消息總線，其中運行是被追蹤的；無狀態容器 – 例如網頁前端）

爲何測試場景中「狀態-State」十分重要？一個緣由是許多bug只會在真實數據的環境下才會產生。例如，你須要測試一個數據庫的schema的升級，而一個小的數據集並不能徹底表明包含複雜商業邏輯的關鍵應用。若是你須要進行端到端的完整測試，咱們須要可以容易的管理咱們的數據和State。

在本篇文章中，咱們定義CI/CD Pipeline的參考架構，從而可以達到應用間的自動數據遷移。咱們也展現如何配置CI/CD pipeline的步驟。

有狀態Pipelines: 須要可遷移的卷

做爲持續集成、測試、部署的一部分，咱們須要在分段setup（staging setup）中重現生產環境中發現的bug。這裏，Hosting環境由一個集羣組成：Kubernetes做爲調度器，Portworx做爲持久存儲卷。測試的工做流經過AWS CodeCommit、AWSCodePipeline、和AWS CodeBuild來自動完成。

Portworx提供Kubernetes存儲，從而能夠實如今AWS環境和Pipeline之間的永久卷的遷移。AWS Developer Tools配合Portworx按照Kubernetes參考架構的持續部署，爲Kubernetes集羣添加了持久存儲和存儲調度。咱們使用MongoDB做爲有狀態應用的例子，但實際上，工做流能夠應用到任何容器化應用：例如Cassandra、MySQL、Kafka、以及Elasticsearch。

使用參考架構，開發者調用CodePipeline來觸發運行MongoDB數據庫生產系統的快照。Portworx接着會建立基於塊的，可寫的MongoDB卷的快照。這個過程當中，MongoDB數據庫的生產系統一直在運行，最終用戶不會中斷。

若是沒有Portworx在其中，手動操做將會須要在CI/CD過程以外，進行一個應用層面的數據庫備份實例。若是數據庫較大，這會花費好幾個小時，而且會影響到生產環境。使用基於塊的快照，是實現穩固的不停機備份的最佳方式。

做爲工做流的一部分，CodePipeline部署了一個新的MongoDB實例，Staging到Kubernetes集羣上，而且Mount第二個具有生產數據的Porworx卷。CodePipeline經過AWS Lambda功能，來觸發Portworx卷的快照。

以下圖所示：

AWS Developer Tools與Kubernetes：經過工做流與Portworx集成

在下面的工做流中，開發者測試正在使用MongoDB的容器化應用的一個變化。測試是針對一個Staging的MongoDB的實例。若是變化是在服務器端的話，測試工做流也是同樣的。最初的生產部署是做爲Kubernetes的部署對象來被調度的，而且使用Portworx做爲持久卷的存儲。

持續部署Pipeline按照以下來運行：

• 開發者集成Bug修改的變化到一個主要的開發分支，這個開發分支會被合併到CodeCommit的主分支上 當代碼被合併到AWS

• CodeCommit repository的主分支後，Amazon CloudWatch觸發Pipeline AWS
• CodePipeline 發送新的版本到AWS CodeBuild, CodeBuild會建立一個含有build ID的Docker容器鏡像
• AWS CodeBuild推送新的已標記build ID的Docker容器鏡像，到Asazon ECR registry Kubernetes從Amazon
• ECR下載新的容器（爲數據庫的客戶端）、部署應用（做爲一個pod）、而後Staging MongoDB實例（做爲一個部署對象）
• AWS CodePipeline, 經過Lambda功能，調用Portworx來爲MongoDB生產系統作快照，而且部署一個Staging的MongoDB實例
• Portworx提供生產實例的快照，做爲Staging MongoDB的持久存儲
• MongoDB實例Mounts快照

到這裏，Staging的Setup模擬了一個生產環境。團隊能夠運行集成和端到端的完整測試，使用合做夥伴的工具，不會影響到生產環境的負載。完整的Pipeline以下所示：

總結

這個參考架構展現了開發團隊能夠很容易的在生產環境中遷移數據，以及爲測試來作Staging。並不須要對應用作特定的手動操做，全部CodePipeline的運行都是自動的，而且做爲CI/CD過程的一部分被追蹤。

這個集成過程使得有狀態容器和無狀態容器同樣容易。經過使用AWS Codepipeline來對CI/CD過程進行管理，開發者使用Portworx存儲，能夠容易的在Kubernetes集羣上部署有狀態容器，而且自動的在流程中進行數據管理。

參考架構和代碼在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
關於容器持久存儲的更多內容，請訪問Portworx網站（https://portworx.com/）。關於Code Pipeline的更多內容，請訪問AWS CodePipeline User Guide （https://docs.aws.amazon.com/codepipeline/latest/userguide/welcome.html）