这是我们的系列出版物中的第一本，该出版物致力于在即将到来的Red Hat OpenShift平台4.0版更新中进行改进和添加，这将帮助您为过渡到新版本做准备。
您可以使用哪些工具来创建更好的软件产品，它们将如何提高安全性并使开发更容易，更可靠？
从新成立的Kubernetes社区的代表于2014年秋季在西雅图Google办事处首次聚会起，就可以说Kubernetes项目注定要从根本上改变软件开发和实施的现代方法。 同时，公共云服务提供商继续积极投资于基础架构和服务的开发，这极大地促进和简化了与IT的合作以及软件的创建，并使它们的价格令人难以置信，这在本世纪初几乎没人能想到。
当然，每项新的云服务的发布都伴随着Twitter专家的众多讨论，并且围绕各种主题发生了争执-包括开源时代的结束，客户端IT的衰落（本地IT），新软件垄断的必然性以及新范式X将如何取代所有其他范式。
但是，现实是什么都没有消失，今天您可以观察到最终产品及其开发方法的指数增长，这与我们生活中新软件的不断出现有关。 尽管事实上周围的一切都会改变，但实际上，一切都会保持不变。 软件开发人员将继续编写错误代码，维护工程师和可靠性专家将继续与传呼机一起走，并在Slack中收到自动警报，管理人员仍将使用OpEx和CapEx的概念，并且每当发生故障时，高级开发人员会悲伤地叹息：“我说过” ...
随着项目复杂性的增加，出现了新的风险，如今人们的生活越来越依赖于软件，以至于开发人员只是必须尽力做好自己的工作。
Kubernetes就是这样一种工具。 正在将其与其他工具和服务集成到Red Hat OpenShift框架内的单个平台中的工作，这将使该软件更加可靠，易于管理并且对用户安全。
话虽如此，问题就来了：如何使Kubernetes的使用变得更加轻松便捷？答案似乎很简单：
- 在云上或云外部署时自动执行复杂的时刻
- 专注于可靠性，同时隐藏复杂性；
- 继续努力发布简单而安全的更新
- 实现可控性和审计能力；
- 力争最初提供高安全性，但不以牺牲可用性为代价。
OpenShift的下一个发行版应考虑创建者的经验以及在世界上最大的公司中大规模实施软件的其他开发者的经验。 此外，有必要考虑到当今构成现代世界基础的开放生态系统的所有积累经验。 在这种情况下，有必要放弃业余开发人员的旧思想，而转向自动未来的新哲学。 它应该是新旧方法之间的“桥梁”，用于部署软件和充分利用所有可用的基础架构-无论是由最大的云提供商提供服务还是在外围的小型系统上运行都无所谓。
如何实现这样的结果？
在Red Hat，习惯于长时间进行无聊和忘恩负义的工作，以保护已建立的社区并防止关闭公司参与的项目。 开源社区由众多才华横溢的开发人员组成，他们创造了最非凡的事物-娱乐，教育，发现新机会并仅仅是美丽，但当然，没有人期望所有参与者朝着同一方向前进或追求共同目标。 为了发展对用户有用的区域，有时需要使用这种能量及其向正确方向的重定向，但是与此同时，我们必须监视社区的发展并向他们学习。
在2018年初，红帽收购了CoreOS项目，该项目对未来有类似的看法-一种更安全，更可靠的开源方法。 该公司致力于进一步发展这些构想及其实施，贯彻我们的理念-力求使所有软件安全运行。 所有这些工作都基于Kubernetes，Linux，公共云，私有云以及构成我们现代数字生态系统的数千个其他项目。
OpenShift 4的新版本将易于理解，自动化且更加自然OpenShift平台将与最佳和最可靠的Linux操作系统一起使用，并具有裸机硬件支持，便捷的虚拟化，基础架构的自动编程以及容器（基本上只是Linux映像）。
该平台从一开始就应该是安全的，但同时为开发人员提供方便的迭代可能性-即具有足够的灵活性和可靠性，同时仍允许管理员进行审核并简化管理。
它应该允许您以“服务形式”运行软件，而不会导致运营商的基础架构不受控制地扩展。
它将使开发人员可以专注于为用户和客户创建真实的产品。 无需破坏硬件和软件设置的丛林，所有的随机并发症将成为过去。
OpenShift 4：NoOps平台无需维护
该出版物描述了有助于塑造公司对OpenShift 4愿景的任务。该团队的任务是最大程度地简化操作和维护软件的日常任务，使这些过程既轻松又轻松，无论是对于实施专家还是对于开发人员。 但是，如何才能实现这一目标呢？ 如何创建需要最少干预的启动软件平台？ 在这种情况下，NoOps是什么意思？
如果您尝试忽略它，那么对于开发人员来说，“无服务器”或“ NoOps”的概念意味着工具和服务，它们使您可以隐藏“操作”组件或最大程度地减轻开发人员的负担。
- 不是使用系统，而是使用应用程序接口（API）。
- 不要实施软件-让提供商代替您执行此操作。
- 您不应该立即着手建立一个大型框架-首先编写充当“构建块”的小片段，然后尝试使此代码适用于数据和事件，而不适用于磁盘和数据库。
和以前一样，任务是加快软件开发的迭代速度，提供创建更好产品的机会，从而使开发人员不必担心其软件在其上运行的系统。 经验丰富的开发人员很清楚，如果您专注于用户，那么情况可能会迅速改变，因此，如果您对软件的必要性没有绝对的信心，则不应在编写软件上投入过多的精力。
对于从事维护和操作的专业人员，“ NoOps”一词听起来有些吓人。 但是，在与运营工程师进行交流时，很明显，他们使用的旨在确保可靠性的模式和方法（Site Reliability Engineering，SRE）在很大程度上与上述模式重叠：
- 不管理系统-自动化其管理过程。
- 不实施软件-创建用于部署的管道。
- 尽量不要将所有服务组合在一起，不要让其中一项服务导致整个系统发生故障-使用自动化工具将它们分散在整个基础架构中，并进行连接，以提供控制和监视的可能性。
SRE专家知道某些地方可能出了问题，因此他们必须跟踪并解决问题-因此，他们会自动执行例程并预先确定错误容忍度，以便在出现问题时可以优先考虑并做出决策。
OpenShift的Kubernetes是一个旨在解决两项主要任务的平台：与其强迫您处理虚拟机或负载平衡器API，不如使用更高阶的抽象-部署过程和服务。 您可以运行容器而不是安装软件代理，而不必编写自己的监视堆栈，而使用平台上已经可用的工具。 因此，OpenShift 4的秘密成分实际上并不代表任何秘密-您只需要以SRE和无服务器概念为基础，并得出合理的结论，以帮助开发人员和维护工程师：
- 自动化和标准化应用程序使用的基础架构
- 整合部署和开发流程，而不会限制开发人员本身
- 确保第一百个服务，功能，应用程序或整个堆栈的启动，审核和安全性不比第一个难。
但是，OpenShift 4平台及其前身与解决这些问题的“标准”方法有什么区别？ 如何实现实施和运营团队的规模扩展？ 由于国王在这种情况下是一个集群。 所以
- 我们使集群的目的易于理解（亲爱的云，我提出了这个集群是因为我可以）
- 存在为集群服务的计算机和操作系统（Y下）
- 管理集群中主机的状态，最大程度地减少其重建（漂移）。
- 对于系统的每个重要元素，都需要一个保姆（机制）来跟踪和修复问题
- 系统各个方面或元素的故障*；相应的恢复机制是生活中的普通部分
- 整个基础架构必须通过API进行配置。
- 使用Kubernetes启动Kubernetes。 （是的，这不是错字）
- 应该轻松自然地安装更新。 如果安装安装此更新不只一次，那么显然您\我们在做错事。
- 监视和调试任何组件都不应该成为问题，因此，在整个基础架构中进行跟踪和报告也应该简单方便。
想查看平台的功能吗？
开发人员可以使用OpenShift 4的初步版本。 借助易于使用的安装程序，您可以在Red Had CoreOS之上运行AWS集群。 要使用预览版，您仅需要一个AWS帐户来提供基础架构，并需要一组帐户来访问预览版图像。
- 要开始使用，请访问try.openshift.com ，然后单击“开始使用”。
- 登录到您的Red Hat帐户（或创建一个新帐户），然后按照说明设置第一个集群。
成功安装后，请查看我们的
OpenShift培训教程，详细了解使OpenShift 4平台成为启动Kubernetes的简单便捷工具的系统和概念。
在2019年DevOpsForum大会上，OpenShift开发人员之一Vadim Rutkovsky将举办一个大师班“在这里您需要更改整个系统：与认证的锁匠一起修理损坏的k8s集群”-它将破坏十个集群并展示如何修复它们。会议入场费已支付，但使用#RedHat促销代码-享有37％的折扣。
我们将于4月20日在17:15在2号馆的大师班中全天候恭候您的光临。 有用的产品信息，与专家会面，T恤，帽子，红帽贴纸-一切照常！ :-)