本文讲的是PaaS平台OpenShift企业部署的“脑图”【编者的话】这篇文章是来自红帽，是关于OpenShift企业部署的“蓝图”，通过“脑图”帮助客户实现企业级部署OpenShift。
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
如下是构建高分布式平台的大部分依赖：
其中每类都包含多个子区域。下面我们将逐一说明。
即使你熟悉这个话题，你也会发现脑图的价值。
如果你想要更多，点击放大图片或查看 https://github.com/mangirdaz/ocp-mindmap
其次，你需要“微服务标准化”策略。在将服务放在新平台之前，强烈建议您定义一些标准。这里的挑战是旧的标准不适用于这个新的世界。尝试“复制 粘贴”，某些功能可能无法正常工作。
通常业务操作包括出口（egress）路由器配置、平台维护、补丁、调度规则创建、平台管理以及对平台上发生的事件的主动反应等内容。所有这一切，你将需要一个非常好的日志和监视。没有日志和监控，你将会“失明”，在高分布式系统中变得盲目。
在分布式系统中，事情可能会从坏到更坏变得非常快，与“独立服务器”的基础架构相比，系统变得更糟糕。例如，如果出现故障，你的容器将重新调度（假设你没有自动伸缩功能，即使可以自动伸缩，你也可能花费巨大的费用）。在当前配置中重新调度=高密度，将意味着会遇到滚动失败情况。
因此，你需要为运营定义标准运行手册，创建仪表盘，确保你了解你的环境，这是运营中最重要的事情之一。
开发人员的经验非常重要。得到这个权利，你的平台将被使用。错了，没有人会想使用它。
至此，我们介绍了这个旅程，你需要考虑什么。需要明白一点：公共云不能解决所有这些问题。这些可能看起来很难、不值得。但是，最终的结果就是全云不可知、水平和垂直可扩展的自助服务基础设施 ，这些将使开发人员开心。
原文出处：Enterprise OpenShift Deployment: What do you need to know?（翻译：范彬）
===============================================================
【烧脑式Kubernetes实战训练营】本次培训理论结合实践，主要包括：Kubernetes架构和资源调度原理、Kubernetes DNS与服务发现、基于Kubernetes和Jenkins的持续部署方案 、Kubernetes网络部署实践、监控、日志、Kubernetes与云原生应用、在CentOS中部署Kubernetes集群、Kubernetes中的容器设计模式、开发Kubernetes原生应用步骤介绍等。
如下是构建高分布式平台的大部分依赖：
- 战略目标 （Strategy）
- 存储计划（Storage）
- 业务操作（Operation）
- 业务连续性弹性与灾难恢复 （BCR＆DR）
- 应用开发 （AppDev）
- 安全（Security）
- 自动化（Automation）
- 网络（Networking）
- 提供（Provisioning）
- 外部依赖 （External dependencies）
其中每类都包含多个子区域。下面我们将逐一说明。
即使你熟悉这个话题，你也会发现脑图的价值。
如果你想要更多，点击放大图片或查看 https://github.com/mangirdaz/ocp-mindmap
策略目标（Strategy）
开始采用新平台之前，你的策略应该是你想到的第一件事情。你需要知道谁将使用你建立的这个平台。利益相关者是谁，最后谁负责？确定利益相关者通常是构建策略的最简单的部分。建立实践社区（CoP）将有助于制定战略和方向。一个精心设计和维护的CoP可以帮助您利用自己组织力量推动实现“正确解决方案”的进程。封闭式解决方案往往会错过组织需求。考虑对CoP进行一些研究。其次，你需要“微服务标准化”策略。在将服务放在新平台之前，强烈建议您定义一些标准。这里的挑战是旧的标准不适用于这个新的世界。尝试“复制 粘贴”，某些功能可能无法正常工作。
存储计划（Storage）
计划构建一个成功的平台，存储或持久性是关键考虑。你不仅需要简单的存储，而且需要可以高扩展的存储空间。你将需要为平台内部组件提供存储，如：日志、度量和容器镜像仓库。当然，你可以根据将要构建的解决方案选择不同的实现方式，如：对象存储、基于消息传递的日志服务，有时可能不需要考虑存储，但你无法完全消除对存储的需求。一旦我们开始说“持久性”，就意味着存储。开始思考如何做，谁将为你提供，以及你将拥有的存储空间（SSD，Magnetic，SAN，NAS等）。业务操作（Operation）
操作部分与本文的下一节紧密相连。业务主要由以下两个领域组成：通常和无计划的行为（BCR＆DR）。我们将在下一节中介绍无计划的行为。通常业务操作包括出口（egress）路由器配置、平台维护、补丁、调度规则创建、平台管理以及对平台上发生的事件的主动反应等内容。所有这一切，你将需要一个非常好的日志和监视。没有日志和监控，你将会“失明”，在高分布式系统中变得盲目。
在分布式系统中，事情可能会从坏到更坏变得非常快，与“独立服务器”的基础架构相比，系统变得更糟糕。例如，如果出现故障，你的容器将重新调度（假设你没有自动伸缩功能，即使可以自动伸缩，你也可能花费巨大的费用）。在当前配置中重新调度=高密度，将意味着会遇到滚动失败情况。
因此，你需要为运营定义标准运行手册，创建仪表盘，确保你了解你的环境，这是运营中最重要的事情之一。
业务连续性弹性与灾难恢复（BCR＆DR）
我将业务连续性和弹性（BCR）和灾难恢复（DR）从业务中分开，它是非常重要的。即使在提供生产流量之前，我建议你知道你的“失败域”，及如何失败恢复。你需要制定一个计划。例如：如果你在分布式、可靠的、键值存储集群（如：在OpenShift / Kubernetes的etcd）中丢失了仲裁，或者知道外部DNS或存储提供发生故障。同时，存在多种不同的场景，如：不同的环境有所不同，某些内部/外部依赖关系具有较少或更成熟的提供，这些都取决于你所在的组织。应用开发（AppDev）
你也需要考虑开发者。一些组织忘记了平台将主要由开发人员使用。只有开发者才知道他们想要在一个平台上运行什么。尽管事实上你将有很多工具，但你可能希望对模式和蓝图进行标准化。你应该考虑如下：- 应用开发人员将如何监控应用程序和节点性能？
- 他们将如何推广和部署？
- CI / CD管道（现有和新的）将如何与平台集成。
- 你将如何推广来自环境的镜像？
- 如何进行配置推广？
- 最后，开发人员将会使用哪些开发工具？
开发人员的经验非常重要。得到这个权利，你的平台将被使用。错了，没有人会想使用它。
自动化（Automation）
这个特定的领域与其他领域有许多关系。你将需要使用CI / CD工具自动化你的应用程序、进行镜像测试和推广等。此外，你的基础设施应该被视为与你的应用程序相同 - 自动化无处不在。为此，你可以使用配置管理工具或仅依赖于部署工具。但是，如果你从一开始就以自动化的思想开始构建，那么即使在开始时它看起来很慢，它会变得想要的更快。网络（Networking）
你需要考虑如何访问应用程序、出口（egress）和入口（ingress）流量，以及如何配置负载平衡器。决定是否将运行 “主动-被动” 或 “主动-主动”，及如何负载均衡所有的堆栈。容器是“网络中的第一个公民”或依赖SDN抽象？如何处理DNS？是否需要相互SSL？你的集群在2 - 5年内有多大？一个节点上运行多少个容器？所有这些问题都将定义你的平台的网络设计。安全（Security）
尽管平台构建要考虑是安全的，但你仍然会有很多公开的问题。例如，你如何管理你的私密凭据（密码，证书）以及如何更新它们？你将如何将你的应用程序暴露给外界？最后，最重要的是，如何验证你正在运行的镜像？运行多租户、基于微服务的应用程序，镜像扫描和生命周期是关键问题。提供（Provisioning）
提供非常广泛，与你的组织中的如下有很高的联系：- 配置管理：使用哪一个配置管理，以及它如何与平台支持的工具一起使用？一旦你确定了所使用的配置管理后，需要选择使用什么工具？你是否需要什么额外的工具？你是否需要红帽的订阅和生命周期管理吗？是否需要CloudForms控制台、能力和主动管理？需要什么可视化提供商及其功能？
- 基础设施本身：你是否使用容器化部署或基于包/ RPM？如何满足你组织的补丁策略？例如，如果你的组织是基于RPM的，你选择了基于容器化/OSTree的平台，你的运维工程师如何知道它们的生命周期？ 最后，你需要为平台做什么定制（预先及后期操作），使其符合你的需求？
外部依赖（External dependencies）
你会有很多外部依赖，请确保这些外部依赖的弹性和它们提供的SLA。外部依赖将包括如下：- 记录和监控：日志如何归档？集成哪些外部日志和监控解决方案？提供哪些元数据？
- 存储：你将如何使用它？是否足够快？每秒输入/输出操作（IOPS）？如何扩缩？
- 容器镜像仓库：如果你计划运行全局分布式集群，确定你的镜像的一致性？镜像仓库是否需要外部存储？如果是，什么格式？
- 身份验证和授权：你将如何验证你的用户和应用程序？首选的身份验证提供商？如何进行基于角色的访问控制（RBAC）？
- ITSM / CMDB：你需要在配置管理数据库中注册你的应用程序吗？如何自动化（或自动化解决方案？）。如何考虑变化？
架构
最后，一旦你知道你想去哪里（策略），你需要开始考虑更广泛的架构，例如基础设施密度、数据中心和可用性区域。已经覆盖的大部分领域与平台本身的架构有关。你需要在开始时做出正确的选择，因为分布式平台（OpenShift / Kubernetes等）构建和使用数百甚至数千个应用程序，难以修改。如果你网络错误，以后再进行更改是不可能的。如果平台不适应外部依赖关系与平台扩展的能力，将遇到瓶颈。至此，我们介绍了这个旅程，你需要考虑什么。需要明白一点：公共云不能解决所有这些问题。这些可能看起来很难、不值得。但是，最终的结果就是全云不可知、水平和垂直可扩展的自助服务基础设施 ，这些将使开发人员开心。
原文出处：Enterprise OpenShift Deployment: What do you need to know?（翻译：范彬）
===============================================================
译者介绍：范彬，从事微服务、Docker和Kubernetes容器技术等方面的工作。可以关注译者的微信公众号：范范米饭。
原文发布时间为：2017-08-17
本文作者：范彬
本文来自云栖社区合作伙伴Dockerone.io，了解相关信息可以关注Dockerone.io。
原文标题：PaaS平台OpenShift企业部署的“脑图”
