神话还是现实？Docker 和 Kubernetes 架构
|
以下是触发回滚机制的因素：
确保信息安全和审计 没有一个工作流可以神奇地“构建”防弹车级别的安全并保护你的生态系统免受外部和内部威胁，因此你需要确保你的架构框架在执行时着眼于公司在每个级别和所有子系统中的标准和安全策略。 稍后，我将在关于监控和告警的章节中讨论建议的所有三个级别解决方案，它们对系统完整性也至关重要。 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)集群可以在生产环境不稳定时挽救你的生命，因为这种情况下你会迫切需要一个能提供镜像、代码或监控工具的环境。可以说，这解决了鸡和蛋的问题。 身份服务
和往常一样，一切开始于对服务器、虚拟机、应用程序、办公室邮件的访问。如果你现在就是或想要成为主要企业平台之一(IBM、谷歌、微软)的客户，访问问题将由服务提供商提供的服务来处理。然而，如果你想有自己的解决方案，那么这一切就只能由你自己搞定，并且不能超出你的预算? 这个关于单点登录的 列表 将帮助你决定合适的解决方案，并估计安装配置和维护该解决方案所需的工作量。当然，你的选择必须符合公司的安全政策并得到信息安全部门的批准。 自动化的服务开通
（编辑：西安站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
