有狀態Stateful，富含資料的CI/CD怎麼做？

對於一些團隊來說，透過CI/CD pipeline來移動應用資料，為了保持合規性和相容其他一些問題，一直是透過手動方式來完成的，無法有效擴充套件。通常只能適用於一小部分應用，而且無法在不同環境中遷移。 目標應該是執行和測試有狀態容器，如同無狀態容器一樣簡單（有狀態容器 – 例如資料庫或者訊息匯流排，其中執行是被追蹤的；無狀態容器 – 例如網頁前端）

為什麼測試場景中“狀態-State”十分重要？一個原因是許多bug只會在真實資料的環境下才會產生。例如，你需要測試一個資料庫的schema的升級，而一個小的資料集並不能完全代表包含複雜商業邏輯的關鍵應用。如果你需要進行端到端的完整測試，我們需要能夠容易的管理我們的資料和State。

在本篇文章中，我們定義CI/CD Pipeline的參考架構，從而能夠達到應用間的自動資料遷移。我們也展示如何配置CI/CD pipeline的步驟。

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卷的快照。

如下圖所示：

持續部署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如下所示：

這個整合過程使得有狀態容器和無狀態容器一樣容易。透過使用AWS Codepipeline來對CI/CD過程進行管理，開發者使用Portworx儲存，可以容易的在Kubernetes叢集上部署有狀態容器，並且自動的在流程中進行資料管理。

• Reference architecture: 
• Lambda function source code for Portworx additions: /blob/master/src/kube-lambda.py

關於容器持久儲存的更多內容，請訪問Portworx網站（）。關於Code Pipeline的更多內容，請訪問AWS CodePipeline User Guide （）