Month: May 2020

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

K8S数据保护工具比较：Cohesity、 Kasten、 OpenEBS、 Portworx、 Rancher Longhorn、 和Velero数据保护对于客户越来越重要。从概念上来说，数据保护包括备份、高可用性、应用连续性、和容灾恢复。所有的企业都需要实施，测试和运维自己的数据保护策略，来避免在发生问题时对商业产生不利影响。随着数据在用户体验和商业流程中的作用越来越重要，对关键数据突然不能访问的问题的容忍度越来越低。根据Uptime Institute的报告(https://uptimeinstitute.com/data-center-outages-are-common-costly-and-preventable) 数据无法访问问题中41%的情况导致的损失均超过了百万美元。企业对高可用性的基础架构的依赖性逐渐增强。 因此，一个有效的数据保护策略可以使宕机时间极少，即便发生意外宕机，应用和数据也都可以快速的恢复。同时数据保护策略还需要确保数据的隐私性和合规性（比如GDPR和CCPA），现在越来越多的用户数据转移到了线上隐私合规愈发重要。 虽然数据保护是一个硬性需求，很多客户仍然做的不够好。传统的数据保护方式在单独主机环境里很出色，但在分布式或跨数据中心环境里就能力不足了。而Kubernetes环境是典型的分布式环境。传统的业务连续性和容灾恢复（BCDR）方案，无法支持现今运行在Kubernetes上的关键商业应用所要求的RPO（Recovery Point Objective）和RTO（Recovery Time Objective）。 由于每个应用和每个客户环境都各不相同，因此数据保护方式也多种多样。当我们考虑数据保护解决方案的时候，一些重要的问题我们首先需要思考： 我是不是只需要在一个单独的数据中心里保护我的数据？ 我是否需要保护数中心内和数据中心外的数据，需要建立一个混合的数据保护方案？ 是不是合规部门对一些备份和恢复数据的存储位置有要求？ 应用对RPO和RTO的要求低还是高？