OpenStack-Ansible 宣言¶
项目范围¶
这将是一个‘开箱即用’的项目。这意味着部署者可以期望从任何命名的特性分支或标签进行部署，都应该提供一个为生产环境构建的 OpenStack 云，并在部署成功完成后可用。
然而，本项目仅专注于 OpenStack 及其需求的部署。
本项目不 PXE 启动主机。主机设置和生命周期管理留给部署者。本项目还需要在主机内设置桥接，以便容器可以连接到本地桥接以进行网络访问。另请参阅 容器网络。
Ansible 用法¶
Ansible 提供了一个自动化平台，以简化系统和应用程序部署。Ansible 通过使用安全 Shell (SSH) 而不是需要远程守护程序或代理的唯一协议来管理系统。
Ansible 使用 YAML 语言编写的 playbook 进行编排。有关更多信息，请参阅 Ansible playbook。
Ansible 是一种简单但功能强大的编排工具，非常适合部署基于 OpenStack 的云。Ansible 的声明性特性允许部署者将整个部署变成一组相当简单的指令。
在 OpenStack-Ansible 框架内的角色使用 Ansible 最佳实践构建，并包含人类可理解的命名空间变量。所有角色都是相互独立的，并且可以单独测试。
所有角色都构建为与 Galaxy 兼容的角色，即使给定的角色并非用于独立使用。虽然该项目将提供许多内置角色，但部署者可以使用内置的 Ansible 功能下拉或覆盖外部角色。这为部署者提供了极大的灵活性。
基于源代码的部署¶
在创建 OpenStack-Ansible 项目时，需要提供一个能够覆盖任何 OpenStack 上游源代码的系统。
这意味着 OpenStack 服务及其 Python 依赖项默认情况下从 OpenStack Git 仓库中找到的源代码构建和安装，但允许部署者指向他们自己的仓库。
这也有助于开发者指向他们自己的代码以供工作使用。
对于 Python 构建的 OpenStack 的一部分，基于源代码的部署在处理规模和希望在长时间内保持一致性时是有意义的。部署者应该能够将相同的 OpenStack 版本部署到云的生命周期中的每个节点，即使某些组件已达到生命周期结束。通过提供源代码仓库，即使在初始部署几年后，也可以重新创建部署，假设底层操作系统和软件包保持不变。
这意味着将永远不会使用发行版提供的 OpenStack 特定软件包来用于 OpenStack 服务。第三方仓库，如 CloudArchive 和或 RDO 仍然可能需要在给定的部署中使用，但仅作为满足应用程序依赖项的一种手段。
容器化部署¶
本项目引入容器作为抽象服务的一种手段。
使用容器允许对整个应用程序堆栈进行额外的抽象，所有这些都可以在相同的物理主机内运行。
“容器化”应用程序有时被分组在一个容器内，这在某些情况下是有意义的，或者根据应用程序和/或架构需求分布在多个容器中。
默认容器架构的构建方式旨在允许可扩展性和高可用性部署。
机器容器的简单性允许部署者将容器视为物理机器。机器容器和物理机器的概念相同：这将允许部署者使用现有的操作工具集来解决部署中的问题，并能够在不重新启动物理主机的情况下将库存中的应用程序或服务恢复到已知的工作状态。
并非所有服务都容器化：有些不适合在容器内运行。需要根据服务如何容器化应用逻辑。如果由于系统限制（内核、应用程序成熟度等）而无法满足其要求，则该服务未设置为在容器内运行。
未容器化服务的示例
Nova 计算（用于直接访问虚拟化设备）
Swift 存储（用于直接访问驱动器）
容器不是保护系统的手段。容器并非出于任何最终的安全保障而选择的。选择机器容器是因为它们在提供更统一的 OpenStack 部署方面的实用性。即使容器提供的抽象可以提高整体部署安全性，这些潜在的好处也不是服务容器化的意图。
