ICode9

精准搜索请尝试: 精确搜索
首页 > 其他分享> 文章详细

有状态Stateful,富含数据的CI/CD怎么做?

2020-03-21 21:55:28  阅读:388  来源: 互联网

标签:容器 CI Kubernetes MongoDB AWS CD Stateful Portworx


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

如下图所示:

有状态Stateful,富含数据的CI/CD怎么做?
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如下所示:
有状态Stateful,富含数据的CI/CD怎么做?

总结

这个参考架构展示了开发团队可以很容易的在生产环境中迁移数据,以及为测试来做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

标签:容器,CI,Kubernetes,MongoDB,AWS,CD,Stateful,Portworx
来源: https://blog.51cto.com/14572152/2480742

本站声明: 1. iCode9 技术分享网(下文简称本站)提供的所有内容,仅供技术学习、探讨和分享;
2. 关于本站的所有留言、评论、转载及引用,纯属内容发起人的个人观点,与本站观点和立场无关;
3. 关于本站的所有言论和文字,纯属内容发起人的个人观点,与本站观点和立场无关;
4. 本站文章均是网友提供,不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属;如您发现该文章侵犯了您的权益,可联系我们第一时间进行删除;
5. 本站为非盈利性的个人网站,所有内容不会用来进行牟利,也不会利用任何形式的广告来间接获益,纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。

专注分享技术,共同学习,共同进步。侵权联系[81616952@qq.com]

Copyright (C)ICode9.com, All Rights Reserved.

ICode9版权所有