TripleO 首要原则

TripleO 首要原则是一组指导 TripleO 未来方向决策的原则。这些原则用于评估方向和架构变更的选择。并非每个有影响力的决策都必须遵循所有原则，但我们使用它们在必要时就权衡做出明智的决定。

问题描述

在评估 TripleO 中的技术方向时，需要一种更好、更一致的方法来权衡选择的优缺点。定义这些原则是满足这一需求的一步。

策略

定义

框架

功能实现，它暴露了一组标准强制接口，服务可以利用这些接口来描述其部署和管理。框架包括实现这些接口的所有功能组件，例如 CLI、API 或库。

示例：tripleoclient/tripleo-common/tripleo-ansible/tripleo-heat-templates

Service

部署单元。服务将实现必要的框架接口，以描述其部署。

框架不会强制执行特定的服务边界，而是通过规定最佳实践来实现这一点。例如，给定的服务实现可以部署 REST API 和数据库，但实际上 API 和数据库应该更可能作为它们自己的服务部署，并表示为依赖项。

示例：Keystone、MariaDB、RabbitMQ

第三方集成

在 TripleO 项目外部开发和维护的服务实现。这些通常由希望在其产品中添加 TripleO 支持的供应商实现。

示例：Cinder 驱动程序、Neutron 插件

首要原则

  1. [UndercloudMigrate] 不抛弃任何 Undercloud

    1. TripleO 本身作为部署工具可以升级。我们目前不提出升级的具体方案或技术栈，但我们将提供升级路径或迁移路径。

  2. [OvercloudMigrate] 不抛弃任何 Overcloud

    1. 使用 TripleO 部署的 Overcloud 可以升级到下一个主要版本，通过原地升级或迁移来实现。

  3. [DefinedInterfaces] TripleO 将具有定义的接口规范。

    1. 我们将记录内部和外部（第三方集成）接口之间的清晰边界。

    2. 我们将以与代码库或 API 记录相同的方式记录框架的受支持接口。

    3. 框架的各个服务可以与其他服务隔离地部署和测试。服务依赖项按服务表示，但不排除使用框架隔离地部署服务及其依赖项。是否成功取决于服务如何响应缺失的依赖项，这是一种服务行为，而不是框架行为。

    4. 该接口将提供更新和升级任务作为一等公民

    5. 该接口将提供验证任务作为一等公民

  4. [OSProvisioningSeparation] 操作系统配置与软件配置分离。

    1. 裸机配置、网络配置和基本操作系统配置与软件部署解耦。

    2. 软件部署将具有一组定义的最低要求，这些要求需要在软件部署开始之前到位。

      1. 特定的 Linux 发行版

      2. 特定的 Linux 发行版版本

      3. 通过 ssh 无密码访问

      4. 通过 sudo 无密码访问

      5. 预配置的网络桥接

  5. [PlatformAgnostic] 平台无关的部署工具。

    1. TripleO 与平台充分隔离，可以在各种环境中使用（裸机/虚拟机/容器化/操作系统版本）。

    2. 开发人员体验是，它可以轻松地在开发人员工作站上隔离运行

  6. [DeploymentToolingScope] 部署工具具有定义的范围

    1. 数据收集工具。

      1. 负责收集主机和状态信息并将其发布到集中存储库。

      2. 处理对中央存储库的写入（例如，从存储库读取信息，进行聚合，发布到中央存储库）

    2. 用于在部署过程中配置软件和服务的配置工具

      1. 管理软件配置

        1. 文件

        2. 目录

        3. 服务（容器化或非容器化）状态

        4. 软件包

      2. 执行与服务的“配置”相关的命令。示例：配置 OpenStack AZ、Neutron 网络。

      3. 独立调用的独立执行

      4. 单一执行状态管理

        1. 输入是配置数据/任务等

        2. 单个执行产生所需的状态或报告失败。

        3. 幂等性

      5. 只读与集中数据存储库的通信，用于配置数据

    3. 部署过程依赖于编排工具来处理各种任务执行。

      1. 任务图管理器

      2. 任务传输和执行跟踪器

      3. 了解主机和要在主机上执行的工作

      4. 临时部署工具

      5. 高效执行

      6. 可扩展性和可靠性/持久性是一等公民

  7. [CI/CDTooling] TripleO 功能应在 CI/CD 管道中直接调用时考虑。

  8. [DebuggableFramework] 框架内部署/配置失败的诊断应快速且简单。应提供接口以启用服务故障的调试。

  9. [BaseOSBootstrap] TripleO 可以从基本操作系统开始，到完整的云

    1. 它应该能够在基本操作系统之后任何一点开始，但应该能够处理初始操作系统引导。

  10. [PerServiceManagement] TripleO 可以隔离地管理单个服务，并表达和依赖于服务之间的依赖关系和顺序。

  11. [Predictable/Reproducible/Idempotent] 部署是可预测的

    1. 操作员可以在实际应用这些更改之前确定将发生哪些更改。

    2. 部署是可重现的，即操作员可以使用相同的输入集重新运行部署，并在不同的环境中获得相同的结果。

    3. 部署是幂等的，即操作员可以使用相同的输入集重新运行部署，并且部署不会改变，除非它第一次部署时。

    4. 在服务需要重新启动进程的情况下，框架将提供一个接口，服务可以使用该接口来通知所需的重新启动。这样，重新启动是可预测的。

    5. 服务的重新启动接口将允许服务描述如何根据对其他服务的依赖关系、同时重新启动或顺序重新启动来重新启动它。

非原则

  1. [ContainerImageManagement] 框架不管理容器镜像。除了使用给定的容器镜像来启动容器外，框架不包含常见的容器镜像管理，包括

    1. 构建容器镜像

    2. 修补容器镜像

    3. 提供或镜像容器镜像

    4. 缓存容器镜像

    需要利用框架进行部署的特定容器镜像和运行时管理工具预计将作为服务实现。

  2. [SupportingTooling] 框架执行的用于部署服务或框架部署服务之前所需的工具不被视为框架本身的一部分。

    示例：podman、TCIB、image-serve、nova-less/metalsmith

替代方案与历史

许多（如果不是全部）原则已经得到广泛认可和理解，并且是 TripleO 的核心。将它们写下来作为策略可以使其更易于发现和正式化。

从历史上看，有些决策是由期望的技术实现或结果引导的。记录这些原则并不一定意味着这些决策会停止，但它确实允许以更合理的方式思考权衡。

我们不需要采用任何原则，或记录它们。但是，这样做没有坏处。

实现

作者

主要作者

James Slagle <jslagle@redhat.com>

其他贡献者

<launchpad-id 或 None>

里程碑

无。

工作项

无。

参考资料

无。

修订历史

修订版

发布名称

描述

v0.0.1

引入

注意

本作品采用知识共享署名 3.0 非移植许可协议授权。 http://creativecommons.org/licenses/by/3.0/legalcode