神话还是现实？Docker 和 Kubernetes 架构

如果你有一个统一的测试方法对 Docker 镜像(或“黑盒”)进行测试，你就可以假设这样的测试结果将允许你无缝地(并且问心无愧地)将 特性分支(feature-branch)集成到 git 存储库的 上游(upstream)或 主分支(master)中。

或许，这里唯一的障碍是集成和交付的顺序。当没有发布时，你如何在一个拥有一组并行 功能分支(feature-branches)的系统上防止“竞争条件”的发生?

因此，只有在没有竞争的情况下，这个过程才应该开始，否则“竞争条件”会一直萦绕在你的脑海中：

1. 尝试将 功能分支(feature-branch)更新到 上游分支(upstream)(git rebase/git merge)
2. 使用 Dockerfile 构建镜像
3. 测试所有构建好的镜像
4. 启动并等待，直到使用第 2 步中构建的镜像的系统成功完成部署
5. 如果前一步失败，将生态系统回滚到之前的状态
6. 将 功能分支(feature-branch)合并进 上游分支(upstream)，并将其提交到代码库

任何步骤中发生的任何失败都应该终止交付过程，并将任务返回给开发人员来修复错误，不管是测试失败还是代码合并冲突。

你可以使用此流程来在多个代码库上工作。只需一次对所有代码库执行每个步骤(在 A 库和 B 库上执行步骤 1，在 A 库和 B 库上执行步骤 2，如此类推)，而不是在每个单独的代码库上重复执行整个过程(在 A 库上执行步骤 1-6，在 B 库上执行步骤 1-6，如此类推)。

此外，Kubernetes 还允许你进行部分更新，以便执行各种 A/B 测试和风险分析。Kubernetes 在内部通过分离服务(访问点)和应用程序来实现这一点。你总是可以按期望的比例平衡组件的新版本和旧版本，以便于问题分析并为潜在的回滚提供可能。

回滚系统

架构框架的强制性要求之一是回滚任何部署过程的能力。这反过来又会带来一些显而易见和隐含的细微差别。以下是其中一些最重要的：

• 服务应该能够设置其环境以及回滚更改。例如，数据库迁移、RabbitMQ 的 schema 等等。
• 如果无法回滚环境，那么服务应该是 多态的(polymorphic)，并且支持旧版本和新版本的代码同时共存部署。例如：数据库迁移不应该导致旧版本服务的中断(通常是之前的 2 到 3 个旧版本)。
• 任何服务更新的向后兼容性。通常，这是应用编程接口 API 的兼容性、消息格式等等。

在 Kubernes 集群中的回滚状态非常简单(运行 kubectl rollout undo deployment/some-deployment，Kubernes 将恢复到以前的“快照”)，但是为了有效地做到这一点，你的元项目应该包含关于该快照的信息。非常不鼓励使用更复杂的交付回滚算法，尽管它们有时是必要的。

（编辑：西安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!