sdn开放架构_建立开放式基础架构的好处

sdn开放架构

OpenStack基础结构团队每天管理OpenStack项目接口中开发人员所使用的所有服务，包括代码检查和持续集成系统，Wiki，IRC机器人和邮件列表。

我们本身也是一个开源项目。 我们的基础架构中使用的所有代码和配置都可以在一系列公共代码存储库中获得 ，我们的所有文档也可以公开获得 。 这与许多其他开源项目相反，这些项目要么依赖于代码托管服务提供的专有资源（例如SourceForge或GitHub），要么依赖公司的IT人员来管理基础架构，例如Ubuntu项目。

拥有由社区维护的开源基础架构，为OpenStack项目提供了许多好处，包括：

• 让参与OpenStack的公司和个人能够通过向团队提供直接的，建设性的资源和反馈来影响基础架构的发展。
• 允许开发人员在等待功能实现时不会袖手旁观。 他们可以提供资源来帮助推动发展。
• 鼓励我们的团队采取更好的做法，因为我们不仅在为自己发展，而且还在为最终包括下游受众的受众发展。
• 能够接受捐助以改善我们的基础设施并支持我们下游的更多选择的能力。

我们是一支致力于开源的倡导者团队，并且相信使我们的基础架构尽可能开放是正确的选择。

这不仅适用于开源项目。 商业企业还可以从使其基础结构对组织中的其他人更开放的方式中受益。 想象一下，让您的开发部门通过为基础结构需求提供优先级，为它们提出代码，而不是等待操作团队对这些需求进行优先排序并采取行动。 或者，想象一下，如果开发团队具有可用于工作的真实配置，那么复制生产环境将多么容易。 或者，想象一下当前团队遵循的最佳实践以及合适的文档将使新操作人员的入职更加顺利。

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

1. 准备政策并隔离代码
2. 准备配置管理系统
3. 记录和分享

准备政策并隔离代码

OpenStack基础架构团队的政策是仅在我们的基础架构中使用开源产品。 对于每个组织来说，这可能不可能实现，但它使我们可以自由共享所有组件，并让下游项目完全复制我们的基础结构，而无需许可成本或可能需要进一步检查的基础结构的任何“黑匣子”组件。

并非所有组织都可以做到这一点，但是必须弄清楚基础架构的哪些部分可以自由共享和复制，哪些不是。 这使您可以确定您不会共享专有配置文件，以便其他部门了解与复制基础结构相关的成本。

既然您已经确定了什么是专有的，什么不是专有的，就代码隔离做出适当的决定。 如果它是开源的，或者您有信心许可证允许在组织内共享配置文件和专有部署的详细信息，请使其对组织内的任何人免费使用。

最后，在下次（或对潜在的下游用户）轻松进行此操作，并在您的团队正在创建的所有代码和配置文件上放置一个许可证。 是的，甚至是配置文件。

准备您的配置管理系统

这是您向更开放的基础架构过渡的技术要素。 在专门的运营团队中工作时，很容易采取捷径，改变最佳做法并将所有配置转储到整体配置存储库中。 尽管作为一个开源项目，OpenStack基础架构团队一直是其中一部分的受害者，但是我们一直在努力摆脱它，因为我们希望对下游更具吸引力。

利用现有的开源模块

无需我们为Puppet编写新的Apache模块。 如果需要其他功能，我们可以直接引入公共模块并向上游提出更改建议。

诱惑力很强，您只需下载开源模块并直接对其进行修改，就可以创建自己的内部使用的fork。 但这是一个主要的维护负担，因为您不再能够轻松升级到最新的开源版本，并且会导致其他不良做法，例如在模块中定义自定义变量。 实际上，我们的团队在早期就做了一些工作，最终导致了一系列项目来解构我们的配置。 首先，我们写了一个规范 ，概述了我们用来分离和规范化模块的步骤，包括一些聪明的git命令，我们用来保留最终存放在各自模块中的所有文件的历史记录。

继续前进，编写模块，就好像其他模块将要使用它们一样，并确保将原始模块与本地修改区分开。 您实际部署的服务器的本地修改可以存在于根据您的组织调整的特定模块中。 我们将其称为openstack_project。

拆分系统和项目配置

早期，我们采用了整体式配置。 我们很快了解到，如果下游希望为自己的项目采用我们的基础架构，则他们将需要我们的系统配置，但将希望定义自己的项目配置。

我们为此需要一个计划，因此我们的团队首先编写了一个规范 ，概述了我们需要拆分的内容，然后着手进行更改，以便能够做到这一点。 与运行我们的基础架构所需的服务本身（我们的代码查看系统，测试服务器等）相关的所有内容都在一个存储库中进行配置，然后我们拥有一个单独的存储库，其中包含诸如OpenStack项目列表，自定义IRC通道之类的内容集，实际的作业在我们的Jenkins服务器上运行，等等。

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

拆分敏感数据

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

提供基础架构的窗口

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

记录和分享

现在您已经拥有一个基础架构，您将很自豪向父母炫耀，记录并与组织共享。

确保您记录以下内容：

• 在哪里找到代码和配置
• 如何提交更改（代码审查？拉取请求？错误报告？票证？）
• 如何在复制的环境中测试更改（ 在此处查看示例）
• 通过查看代码和配置可能看不到的任何引导和粘合信息。 这可以包括您的运营团队必须手动执行的任何操作。

最后，打开水闸！ 与您的组织共享您的基础架构，并查看功能更强大的开发团队和知识渊博的组织如何工作，并清晰地了解您的基础架构如何工作。

超越OpenStack的专业知识

除OpenStack之外，其他几个开源项目也已将其基础架构的全部或部分开源。 您还可以通过浏览其开放式配置来从他们的工作中学习：

• 德比安
• 软呢帽
• 詹金斯
• Mozilla

翻译自: https://opensource.com/life/15/5/constructing-open-infrastructure

sdn开放架构