有状态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）