构建开放基础设施的益处

图片来源

Opensource.com

OpenStack 基础设施团队管理着 OpenStack 项目中开发者日常交互的所有服务，包括代码审查和持续集成系统、Wiki、IRC 机器人和邮件列表。

我们本身也是一个开源项目。我们基础设施中使用的所有代码和配置都可以在一系列公共代码仓库中找到，我们所有的文档都公开可用。这与许多其他开源项目形成对比，这些项目要么依赖于代码托管服务（如 SourceForge 或 GitHub）提供的专有资源，要么拥有一家公司及其 IT 员工来管理基础设施，例如 Ubuntu 项目。

拥有一个开源且由社区维护的基础设施为 OpenStack 项目带来了许多好处，包括

允许与 OpenStack 相关的公司和个人通过向团队提供直接、建设性的资源和反馈来影响基础设施的开发。
允许开发者不必袖手旁观等待某个功能的实现。他们可以提供资源来帮助推动事情进展。
鼓励我们的团队采用更好的实践，因为我们不仅为自己开发，也为最终包括下游受众的受众开发。
能够接受贡献来改进我们的基础设施，并支持来自我们下游的更多选项。

我们是一个由忠实的开源倡导者组成的团队，并相信尽可能开放我们的基础设施是正确的做法。

这不仅适用于开源项目。商业企业也可以通过使其基础设施对组织内的其他人更加开放而受益。想象一下，如果您的开发部门可以通过提出代码而不是等待运维团队确定优先级并处理工单，从而根据需要优先处理基础设施请求，那会怎么样。或者，想象一下，如果开发团队拥有实际的配置可供参考，那么复制生产环境会容易多少。或者，想象一下，如果当前团队坚持最佳实践，并提供适当的文档，那么新入职的运维人员的上手过程会顺利多少。

在我们的团队花费数年的历程中，我们使用 Puppet 创建了一个可以引以为傲的开源基础设施。这基本上归结为三个主要步骤

制定策略并隔离代码
准备配置管理系统
编写文档并共享

制定策略并隔离代码

OpenStack 基础设施团队的政策是在我们的基础设施中只使用开源产品。这对于每个组织来说可能并非可行，但这使我们能够自由地共享我们所有的组件，并让下游项目完全复制我们的基础设施，而无需许可成本或基础设施中可能需要进一步审查的任何“黑盒”组件。

这对所有组织来说并非可行，但必须明确说明基础设施的哪些部分可以自由共享和复制，哪些部分不可以。这使您可以确信您没有共享专有的配置文件，并使其他部门了解复制基础设施相关的成本。

现在您已经确定了哪些是专有的，哪些不是，就代码隔离做出适当的决策。如果它是开源的，或者您确信您的许可证允许在您的组织内共享配置文件和专有部署的详细信息，那么将其自由地提供给您组织中的任何人。

最后，为了下次（或潜在的下游）方便，请对您的团队正在创建的所有代码和配置文件添加许可证。是的，即使是配置文件。

准备您的配置管理系统

这是您向更开放基础设施过渡的技术核心。在专门的运维团队内部工作时，很容易走捷径、违反最佳实践并将所有配置转储到一个单体配置仓库中。即使作为一个开源项目，OpenStack 基础设施团队也在此过程中犯了一些这样的错误，但随着我们寻求对下游更具吸引力，我们已经摆脱了困境。

利用现有的开源模块

我们没有必要为 Puppet 编写一个新的 Apache 模块。我们可以直接拉取公共模块，并在需要其他功能时向上游提出更改。

直接下载开源模块并直接修改它们的诱惑很大，这实际上是创建您自己的内部使用的分支。但这会造成主要的维护负担，因为您将无法再轻松升级到最新的开源版本，并导致其他不良实践，例如在模块中定义自定义变量。事实上，我们的团队早期就做过一些这样的事情，这最终导致了一系列项目来解开我们的配置。首先，我们编写了一个规范，其中概述了我们用于分离和规范化模块的步骤，包括我们用于保留最终位于其各自模块中的所有文件历史记录的一些巧妙的 git 命令。

展望未来，编写您的模块时，要假设它们将被其他人使用，并确保将原始模块与您的本地修改分开。您实际部署的服务器的本地修改可以存在于专门为您的组织定制的模块中。我们称之为 openstack_project。

分离系统和项目配置

早期，我们有一个单体配置。我们很快了解到，如果下游希望采用我们的基础设施用于他们自己的项目，他们将需要我们的系统配置，但希望定义他们自己的项目配置。

我们需要为此制定一个计划，因此我们的团队首先编写了一个规范，其中概述了我们需要分离的内容，然后开始进行更改以实现这一点。与服务本身相关的一切都需要运行我们的基础设施（我们的代码审查系统、测试服务器等）都在一个仓库中配置，然后我们有一个单独的仓库，其中包含诸如 OpenStack 项目列表、我们自定义的 IRC 频道设置、Jenkins 服务器上运行的实际作业等等。

今天，我们有一个 system-config 和一个 project-config。

分离敏感数据

现在，尽管我们作为一个社区非常自由，但我们仍然需要保护 OpenStack 开发平台的完整性，这意味着我们确实有一些秘密。私有 SSL 证书和各种类型的身份验证凭据需要存储在安全的地方，只有少数管理员可以访问它们。在我们的团队中，我们使用 Puppet 的 Hiera 工具来存储这些值。我们将其保存在只有我们的 root 管理员才能访问的私有修订控制中，并在我们的文档中明确说明我们使用它以及我们的变量是什么，以便任何使用我们基础设施的人都可以根据需要使用他们自己的数据复制部分内容。

提供基础设施的窗口

一些公司允许其开发人员有限地访问生产服务器，但我们使用一个名为 PuppetBoard 的工具来让人们了解我们的服务器上正在发生的事情。借助此工具，任何有权访问的人都可以浏览 Web UI，该 UI 向他们显示有关服务器的一些详细信息，以及特定更改是否已提交以及是否成功。这为我们项目的贡献者提供了一个窗口，让他们了解事情的进展情况，并允许他们独立地处理已批准的更改。更改是否已提交？是否有任何错误？查看 PuppetBoard。您可以在此处浏览我们的公共实例。