“基于云的”（云本机）或仅“云”应用程序是专门为在云基础架构中使用而创建的。 通常，它们是作为一组松散耦合的微服务构建的，这些微服务封装在容器中，而容器又由云平台进行管理。 此类应用程序默认情况下已准备好发生故障，这意味着即使在基础结构级别出现严重故障的情况下，它们也可以可靠地工作并可以扩展。 不利的一面是云平台对容器应用程序施加的一组限制（合同），以便能够自动管理它们。
意识到迁移到云应用程序的必要性和重要性，许多组织仍然不知道从哪里开始。 在本文中，我们将考虑一些原则，即使在IT基础架构级别出现严重故障的情况下，在容器应用程序的开发过程中遵循这些原则也将实现云平台的潜力并实现可靠的应用程序运行和可伸缩性。 此处概述的原理的最终目标是学习如何创建可由Kubernetes等云平台自动管理的应用程序。
软件设计原理
在编程领域，原理被理解为相当通用的规则，在开发软件时必须遵守。 在使用任何编程语言时都可以使用它们。 每个原则都有其自己的目标，模板和实践通常用作实现目标的工具。 创建高质量软件还有许多基本原则，所有其他原则都应遵循这些原则。 以下是一些基本原则的示例：
- 吻 （保持简单，愚蠢）-不要复杂；
- 干 （不要重复自己）-不要重复；
- YAGNI （您将不需要它）-不要创建不需要立即需求的东西；
- SoC （关注点分离）-分担责任。
如您所见，这些原则未设置任何特定规则，而是基于许多开发人员共享并经常参考的实践经验，属于所谓的常识性考虑因素。
此外，还有
SOLID-罗伯特·马丁（Robert Martin）提出的一组面向对象编程和设计的前五个原则。 SOLID包含相互补充的原则，这些原则已被概括并易于解释，当组合使用时，这些原则可帮助创建更好的软件系统并从长远角度更好地支持它们。
SOLID原则适用于OOP，并根据概念和概念（例如类，接口和继承）来制定。 以此类推，对于云应用程序，您还可以制定开发原则，这里的基本要素不是类，而是容器。 遵循这些原则，您可以创建容器化的应用程序，以更好地满足Kubernetes等云平台的目标。
基于云的容器：Red Hat方法
如今，几乎所有应用程序都相对易于打包到容器中。 但是为了使应用程序在Kubernetes这样的云平台内高效地自动化和编排，需要付出额外的努力。
下面介绍的想法基于
“十二要素应用程序”的方法论，以及有关从源代码控制到缩放模型的各种其他创建Web应用程序方面的工作。 所描述的原理仅适用于基于微服务构建并针对Kubernetes等云平台设计的容器应用程序的开发。 我们讨论的基本元素是容器的映像，目标容器运行时是容器编排平台。 提出的原理的目的是创建一个容器，在大多数编排平台上，您可以针对这些容器自动执行调度任务（调度-选择运行容器实例的主机），进行缩放和监视。 原则以随机顺序列出。
单一关注原则（SCP）
该原则在许多方面类似于SOLID套件的一部分的“单一职责原则”（
SRP ），它声明每个对象必须承担一个责任，并且必须将此责任完全封装在类中。 SRP的本质是，每项职责都是改变的原因，一个阶级必须只有一个改变原因。
在SCP中，与OOP类相比，我们使用“关注”一词代替“责任”一词，以表示更高级别的抽象和更广泛的容器用途。 并且，如果SRP的目标只是改变的一个原因，那么SCP就有希望扩大重复使用和更换容器的可能性。 通过遵循SRP并创建一个可以解决一项任务并使其功能完整的容器，您可以增加在各种应用程序上下文中重用此容器的映像的机会。
SCP的原则规定，每个容器应完成一项任务并做好。 此外，在容器领域中的SCP比在OOP领域中的SRP更容易实现，因为容器通常执行一个单独的过程，并且在大多数情况下，此过程解决一个任务。
如果容器微服务必须立即解决多个问题，则可以将其划分为单任务容器，然后使用sidecar模板和init容器将它们合并为一个pod（容器平台部署单元）。 此外，SCP可以轻松地用新容器替换旧容器（例如Web服务器或消息代理），该新容器可以解决相同的问题，但功能增强或扩展性更好。
方便监视的原则（高可观察性原则，HOP）
当使用容器作为打包和启动应用程序的统一方式时，应用程序本身被视为“黑匣子”。 但是，如果这些是云容器，则它们必须为运行时提供特殊的API，以监视容器的运行状况，并在必要时采取适当的措施。 没有这个，就不可能统一更新容器和管理其生命周期的自动化，这反过来又会恶化软件系统的稳定性和可用性。
实际上，容器应用程序至少应具有用于各种类型的健康检查的API：活动性测试和准备性测试。 如果该应用程序声称具有更多功能，则应提供其他监视其状况的方法。 例如，通过STDERR和STDOUT记录重要事件，以使用Fluentd，Logstash和其他类似工具聚合日志。 以及与跟踪和收集指标库（例如OpenTracing，Prometheus等）的集成。
通常，该应用程序仍然可以被视为“黑匣子”，但同时必须配备该平台所需的所有API，以便以最佳方式对其进行监视和管理。
生命周期一致性原则（LCP）
LCP是HOP的对立面。 如果HOP指出容器必须向平台提供用于读取的API，则LCP要求应用程序能够从平台接收信息。 此外，容器不仅应接收事件，而且还应适应事件，换句话说，对事件做出响应。 因此，该原则的名称可以被视为向平台提供用于编写API的要求。
平台具有不同类型的事件，可帮助管理容器的生命周期。 但是，由应用程序决定要感知其中的一个以及如何响应。
显然，某些事件比其他事件更重要。 例如，如果应用程序不容许紧急关闭，则它必须接受信号：终止（SIGTERM）消息并尽快启动其终止过程，以捕获信号：在SIGTERM之后出现的信号：kill（SIGKILL）。
此外，诸如PostStart和PreStop之类的事件对于应用程序生命周期可能很重要。 例如，启动应用程序后，可能需要一些时间来进行“热身”，然后才能响应请求。 否则应用程序必须在关机时以某种方式释放资源。
容器图像的不变性原理（Image Immutability Principle，IIP）
公认的是，即使在不同的环境中运行，容器化的应用程序在组装后也必须保持不变。 这意味着需要在运行时将数据存储外部化（换句话说，为此使用外部工具），并依赖于为特定运行时环境配置的外部配置，而不是为每个环境修改或创建唯一的容器。 在对应用程序进行任何更改之后，必须在所有使用的环境中重新组装和部署容器映像。 顺便说一句，在管理IT系统时，使用了类似的原理，即服务器和基础结构不变的原理。
IIP的目标是防止为不同的运行时环境创建单独的容器映像，并在各处使用相同的映像以及针对特定环境的适当配置。 遵循此原则，您可以从云系统自动化的角度实现诸如应用程序更新的回滚和前滚之类的重要实践。
流程一次性原则（PDP）
容器的最重要特征之一就是它的短暂性：一个容器实例易于创建和销毁，因此可以随时轻松地用另一个实例替换它。 进行此类替换的原因可能很多：运行状况测试失败，应用程序扩展，转移到另一台主机，耗尽平台资源或其他情况。
结果，容器应用程序必须使用某些外部手段来维持其状态，或为此使用具有冗余性的内部分布式电路。 此外，该应用程序应快速启动并迅速关闭，并为突然的致命硬件故障做好准备。
一种有助于实现这一原则的做法是创建小型容器。 云环境可以自动选择一个主机来启动容器实例，因此，容器越小，启动速度越快-只需将其通过网络复制到目标主机的速度就更快。
自包含原则（S-CP）
根据该原理，在组装阶段，所有必需的组件都包含在容器中。 应该在期望系统只有一个干净的Linux内核的情况下构建容器，因此必须将所有必要的附加库放置在容器本身中。 事物也应该位于此处，例如相应编程语言的运行时，应用程序平台（如果需要）以及在容器应用程序运行期间将需要的其他依赖项。
仅针对因环境而异的配置例外，并且应在运行时提供例外，例如通过Kubernetes ConfigMap。
应用程序可以包括几个容器化的组件，例如，作为Web容器应用程序一部分的单独的DBMS容器。 根据S-CP原则，不应将这些容器组合为一个容器，而应将它们组合在一起，以使DBMS容器包含数据库工作所需的所有内容，并且Web应用程序容器包含该Web应用程序（同一个Web服务器）正常工作的所有内容。 。 结果，在运行时，Web应用程序容器将依赖于DBMS容器并根据需要对其进行访问。
运行时限制原则（RCP）
S-CP原则定义了容器的组装方式以及二进制映像文件应包含的内容。 但是，容器不仅仅是一个“黑匣子”，它只有一个特征-文件大小。 在运行时，容器获得其他维度：使用的内存量，处理器时间和其他系统资源。
在这里，RCP原则很有用，根据该原则，容器必须将其对系统资源的要求归类，并将其转移到平台上。 有了每个容器的资源配置文件（它需要多少CPU，内存，网络和磁盘系统资源），该平台可以最佳地执行调度和自动扩展，管理IT容量并支持容器的SLA级别。
除了满足容器的资源要求之外，对于应用程序来说，不要超出其指定的框架也很重要。 否则，如果资源不足，则该平台更有可能将其包括在需要中断或迁移的应用程序列表中。
说到对云的关注，我们主要是指我们的工作方式。
上面，我们制定了许多通用原则，这些原则为为云环境构建高质量的容器应用程序奠定了方法论基础。
请注意，除了这些一般原则之外，您还需要其他高级方法和技术来处理容器。 此外，我们还有一些简短的建议，这些建议较为具体，应根据情况应用（或不应用）：
新版OpenShift容器平台网络研讨会-46月11日11.00
您将学到的内容：
- 不变的Red Hat Enterprise Linux CoreOS
- Openshift服务网格
- 运营商框架
- 原生框架