神话还是现实?Docker 和 Kubernetes 架构
假如你有一个同一的测试要领对 Docker 镜像(或“黑盒”)举办测试,你就可以假设这样的测试功效将应承你无缝地(而且心安理得地)将 特征分支(feature-branch)集成到 git 存储库的 上游(upstream)或 主分支(master)中。 或者,这里独一的障碍是集成和交付的次序。当没有宣布时,你如安在一个拥有一组并行 成果分支(feature-branches)的体系上防备“竞争前提”的产生? 因此,只有在没有竞争的环境下,这个进程才应该开始,不然“竞争前提”会一向萦绕在你的脑海中:
任何步调中产生的任何失败都应该终止交付进程,并将使命返回给开拓职员来修复错误,不管是测试失败照旧代码归并斗嘴。 你可以行使此流程来在多个代码库上事变。只需一次对全部代码库执行每个步调(在 A 库和 B 库上执行步调 1,在 A 库和 B 库上执行步调 2,云云类推),而不是在每个单独的代码库上一再执行整个进程(在 A 库上执行步调 1-6,在 B 库上执行步调 1-6,云云类推)。 另外,Kubernetes 还应承你举办部门更新,以便执行各类 A/B 测试和风险说明。Kubernetes 在内部通过疏散处事(会见点)和应用措施来实现这一点。你老是可以定祈望的比例均衡组件的新版本和旧版本,以便于题目说明并为隐藏的回滚提供也许。 回滚体系 架构框架的逼迫性要求之一是回滚任何陈设进程的手段。这反过来又会带来一些显而易见和隐含的渺小不同。以下是个中一些最重要的:
在 Kubernes 集群中的回滚状态很是简朴(运行 kubectl rollout undo deployment/some-deployment,Kubernes 将规复到早年的“快照”),可是为了有用地做到这一点,你的元项目应该包括关于该快照的信息。很是不勉励行使更伟大的交付回滚算法,尽量它们偶然是须要的。 以下是触发回滚机制的身分:
确保信息安详和审计 没有一个事变流可以神奇地“构建”防弹车级此外安详并掩护你的生态体系免受外部和内部威胁,因此你必要确保你的架构框架在执行时着眼于公司在每个级别和全部子体系中的尺度和安详计策。 稍后,我将在关于监控和告警的章节中接头提议的全部三个级别办理方案,它们对体系完备性也至关重要。 Kubernetes 有一套精采的内置 会见节制机制 、 收集计策 、 变乱审计 和其余与信息安详相干的强盛器材,可用于构建精彩的 周界掩护(perimeter of protection)、抵制和防备进攻以及数据走漏。 二、从开拓事变流到架构 应应当真看待在开拓流程和生态体系之间成立细麋集成的实行。将这种集成的需求添加到传统架构需求集(机动性、可伸缩性、可用性、靠得住性、防威胁等)中,可以极大地增进架构框架的代价。这长短常要害的一个方面,它导致了DevOps(Development Operation)这个观念的呈现。DevOps 是实现基本办法完全自动化和优化的一个合乎逻辑的步调。然而,一个计划精采的架构架构和靠得住的子体系,可以让 DevOps 使命最小化。 微处事架构 没有须要赘述面向处事的架构(SOA)的甜头,包罗为什么处事应该是 “微”(micro)粒度的。我只想说,假如你已经抉择行使 Docker 和 Kubernetes,那么你很也许会领略(并接管)这样的概念:维护一个 单体(monolithic)架构是坚苦的,乃至在意识形态上是错误的。Docker 被计划成运行 单历程(single process)应用,并和耐久层一路事变。它迫使我们在 DDD( 规模驱动开拓(Domain-Driven Development))框架内思索。在 Docker 中,被打包的代码被视为一个袒露部门会见端口的黑盒。 生态体系的要害构成部门息争决方案 按照我计划可用性和靠得住性更高的体系的履历,有几个组件对微处事的运行至关重要。稍后我将列出并接头这些组件,纵然以下我只是在 Kubernetes 情形中引用它们,你也可以将我的这个列表作为任何其他平台的搜查表行使。 假如你(和我一样)能得出这样的结论,也即将这些组件作为一个通例 Kubernetes 处事来打点长短常好的,那么我提议你在差异于 “出产集群”(production)的单独集群中运行它们。譬喻, “预出产/准出产”(staging)集群可以在出产情形不稳按时拯救你的生命,由于这种环境下你会急切必要一个能提供镜像、代码或监控器材的情形。可以说,这办理了鸡和蛋的题目。 (编辑:湖南网) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |