在大型公司中，通常很难协调工作任务的资源分配。 与新基础架构的IS签订为期三周的协议后，所有敏捷人员都在努力工作。 因此，我们经常收到将基础结构转移到容器的请求，以便每三个月一次以及在业务需要时才推出更改。 同时，他们要求将Kubernetes配置/实现为最流行的编排工具，尽管如实践所示，在10个项目中，最多需要三个。 但是实际上，值得使用Kubernetes，但可以使用OpenShift，或者不在您的基础架构中而是在公共云中使用它。 我将尝试谈论我们决定的实际业务案例，并描述Kubernetes和OpenShift之间的主要区别。 还有关于我们如何将信息安全协调时间减少到30分钟，并且所有这些仍然有效。
我们有几种有趣的实现，其中我们解决了客户的累积问题。 例如，一家零售公司来到我们这里，需要不断推出新芯片。 比赛很疯狂！ 而且，他们只有六到十天的时间才能拥有开发基础架构，这会导致停机。 通过购买用于测试和开发的新硬件来解决问题是昂贵的，而且是无路可走的。 结果，我们将IT基础架构转移到了容器虚拟化。 结果，由于有了集装箱，负荷减少了40％，新开发的基础设施现在也需要一到四个小时的准备时间。 好处是节省了成本，因为所有过程都可以继续在现有能力的基础上进行，而无需购买新的过程。
我们将如何处理信息安全？
IB是非常必要的人。 他们对项目的内部需求通常走得太远，但这比看到罗马尼亚的黑客包围了您的外部SFTP服务器要好得多。
但是他们有一个问题。 如果我们将业务流程视为传送带，那么它们的划分通常会成为其他所有人赖以生存的瓶颈。 一方面，他们负责与安全性相关的所有风险，另一方面，他们根本没有实际管理手动查看代码和新产品体系结构的所有细节。
这种情况与人流量大的地区的安全部门非常相似。 我们可以安排对每位地铁乘客的全面检查，将其照在扫描仪上，拧紧口袋，检查电话。 但是，结果是，除了安全性之外，您还将完全陷入传输崩溃和系统瘫痪的境地。 在这种情况下，唯一的选择是组织自动化系统，该系统将对个人做出响应，识别通缉人员或对某些异常行为做出反应。
在我们的上下文中，这样的自动化系统是经过适当组织的CI / CD流程，处于中间阶段，具有代码分析器，例如解决方案（如Artirefactory的JFrog Xray）和正确拧紧的Kubernetes / OpenShift螺母，这些螺母不允许使用不安全的方法，例如从root用户启动容器。 现在，我们正在准备一个盒装解决方案，将提供所有这些。
目标是从“直到我们看待交易才开始”的概念转变为“如果没有异议，它将自动部署”。 如果组织过程保持不变，自动化就没有意义。
在其中一个项目中，我们设法将IS故障的时间减少到30分钟。 换句话说，如果“安全卫士”在半小时内未拒绝该操作，则将自动同意该操作，并将更改投入生产。 现在，我们正在努力在不影响安全性的前提下，为项目中的所有协调员设定60分钟的期限。
容器管理系统之间有什么区别？
Kubernetes和OpenShift是容器编排的主要解决方案。 让我们分析业务的主要差异和优势。
开放性Kubernetes是一个完全开放的产品，可以独立部署，可以单独或在外部支持下进行服务。 劳动力市场的状况已经或多或少地趋于稳定，寻找这个主题的专家不再是问题。
OpenShift是半封闭产品，具有RedHat的复杂许可系统。 实际上，它包含Kubernetes，但是它还有很多其他绑定，可以简化许多任务。 供应商为其产品提供全额支持。
在这里，选择取决于最适合您的-在专家或供应商的支持下。
平台类Kubernetes几乎可以在任何Linux平台和大多数云提供商上使用。
除了RHEL，Red Hat Atomic，Red Hat CoreOS以外，OpenShift在任何地方都无法使用。 有一个社区版本-OKD，但它与发行版紧密相关。 唯一的例外是它可以安装在CentOS上。 请记住，正式的Red Hat不保证有偿支持。
安全政策开箱即用的OpenShift具有更严格的安全设置。 从头开始部署基础架构时，这是一个优点，但由于某些映像与政客不兼容，因此可能会成为问题。 例如，在OpenShift中，禁止从根目录运行容器，这会破坏与旧映像的兼容性。 另一方面，这种方法结合了与AD的便捷集成以及基于EFK堆栈（ElasticSearch，Fluentd，Kibana）的便捷日志记录，为我们提供了卸载IS装置所需的非常安全的即用性。
Kubernetes也可以达到此级别，但是工程师需要大量的精力和时间。
模式OpenShift模板不如Kubernetes Helm图表灵活。 由于更严格的安全策略，红帽目前无法提供Helm图表的灵活性。 但是，在OpenShift 4中，由于集成了
OperatorHub ，情况已经趋于平稳。
开箱即用的设计良好的模板使工作变得更加轻松。 实际上，这是用于构建和配置各种服务的软件包管理器选项。
一个条件命令“ helm install prometheus-operator”将部署一个相当复杂的系统，这将花费很长的时间自行部署。 Kubernetes处于领先地位。
一般结论像大多数产品一样，Red Hat OpenShift是一种更加封闭的解决方案，但是在架构上更为严格。 它需要较少的红眼睛和经验丰富的工作人员。 更方便的部署方案，与CI / CD解决方案（特别是与Jenkins）的出色集成。 OpenShift对于公司而言，比起雇用自己的专家，他们更容易为支持成品提供支持，因此非常有用。
对于在这一领域拥有强大专家的公司而言，Kubernetes可能是一个更加灵活和有趣的解决方案。 它也可能适合希望节省Red Hat许可证但不具有需要高素质专家的复杂任务的相对较小的企业。
真实案例
我将尝试展示容器化技术如何帮助解决业务问题，节省许可证并确保在大规模用户突袭期间平滑峰值负载。
案例研究：电子商务
问题该客户拥有运行VMware云基础的100多种活动服务。 这个公园所有的地方都有几个不同的问题：
- 在VMware上推出了12种资源需求型和非保证金型服务，每年的预算约为408,000美元。
- 三种服务（一个门户网站和两个移动应用程序）开始积极发展：在七个月的时间里，工作所需的资源量增长了4.5倍，并且还在继续增长。
- 几个客户服务具有高峰负载，在此期间，所需资源是正常时间的六至七倍。 因此，设备被分配用于其正确的操作，而大多数时间所用的时间不到15％。
除了所有这些，客户还希望摆脱与一个虚拟化供应商的绑定。
我们的决定第一个也是最简单的解决方案：我们将高峰服务转移到
公共CROC云中 。 与计费消耗的资源。 一切都尽可能简单和无聊。 从某人的VMware迁移到我们的KVM是云工程师最常遇到的情况之一。
由于客户已经购买了用于扩展的硬件，因此我们只需要计算许可证。 对于来自VMware的新主机，它们的成本约为210万美元，这对客户而言并不十分合适。 我们建议将一些服务转移到运行OpenStack的KVM。 并且为了不致迷路，请通过CloudForms（以及OpenShift）同时集成这两个基础架构的管理。
结果，客户收到了基于OpenStack的私有云的第二个肩膀，这结束了供应商锁问题。 通过将一些资源密集型服务转移到新的位置，事实证明可以降低VMware许可证的成本（CROC提供的24 x 7支持更便宜）。
案例：零售
问题在审核期间，事实证明，与客户有关的基础架构分配情况正在发生严重变化。 Kubernetes上的项目-超过250个，开发团队-超过150个，一半-容器。 购买了每个新项目的资源，即使没有使用它们，也无法对其进行选择，但仍会分配资源。 根本没有计费，也没有单一门户。 由于测试和预生产环境也依赖VMware，因此成本很高。
同时，客户不想完全切换到新平台，而是希望将所有组件组装在一个管理门户下。 此外，“一切”不仅是VMware，而且还包括PaaS，容器和单一计费。
我们的决定结果，解决方案内部堆积了很多，但是对于客户而言，外部看起来非常简单。
用户在其中选择虚拟机参数和必要电路的目录：DevTest，PreProd，Prod。 然后，CloudForms选择将请求的资源部署到哪里：在VMware还是在OpenShift上。 由于仍很难将VMware + OpenShift混合解决方案组合在一起，因此我们仍在进行单一计费。
实际上，通过这种方式，我们可以将基础结构中的东西整理整齐，以整理出客户堆积如山的废墟。
案例：行业
问题将虚拟机复制到各种环境（测试，开发，生产，预生产）需要三天多的时间，并且需要手动执行15种不同的操作，每个操作最多需要30分钟。 更深入的审计表明，为一个新项目分配资源花了两个星期，每个月有10-20个请求。 现在每天有十多个资源请求，如果没有自动化，就会导致崩溃。
我们的决定实际上，客户需要将IT基础架构转移到服务模型，重建和自动化对基础架构进行更改的过程，创建自助服务门户，在其中填充服务目录并实施用于管理容器化应用程序的环境。 我们使VM复制过程自动化，但是仍然花费大量时间：40-60分钟，这不适合客户。 结果，我们建议切换到容器，从而将复制时间减少到三到五分钟。
结论
容器化和微服务并不是沉迷于用左脚编写并立即投入生产的错误代码。 相反，这是一个整体概念，由于所有流程的深度自动化，因此涉及许多改进：
- 代码变得更加干净：短绒棉绒，代码分析器，自动化测试。
- 代码和体系结构变得越来越安全：具有广泛功能的安全工具，甚至可以自动阻止不安全代码的部署。
- 服务变得越来越灵活和移动：开发周期现在非常短，并且可以快速响应更改。
- 在负载下自动扩展：您的资源在高峰时段不再松弛，从而失去了销售和客户。
- 简单地为新项目分配资源，减少协调时间。
- 通常，集装箱化可以大大缩短产品上市时间。
有时根本不需要容器化，并且可以通过迁移到外部云来解决问题。 但是为了做出决定，无论如何，我们需要对发生的事情进行良好的外部审计和分析。 简而言之，容器虽然很酷，但却只是解决业务问题的工具之一。