OpenStack基础设施团队负责管理和开发OpenStack项目中每天需要面对的公共服务，包括代码审查和持续集成系统、wiki、IRC聊天机器人和电子邮件列表等。我们也有自己的开源项目。我们在基础设施中使用的所有代码和配置解决方案都可以通过一系列公共代码存储库获得，所有相关文档也对所有人开放。这种方法不同于大多数其他开源项目，这些项目要么依赖单一代码托管服务提供的专用资源——例如SourceForge或GitHub，要么由一些企业的IT人员完成基础设施管理——例如Ubuntu项目。选择像OpenStack项目一样构建一个由社区维护的开源基础设施有很多好处，包括：让企业和个人参与到OpenStack基础设施的开发规划中，比如为开发团队提供直接的贡献资源和反馈。让开发者以更主动的方式参与项目的开发，而不是等待新功能的出现。他们可以提供有助于加速项目成果交付的资源。鼓励团队中更多的理想实践，因为我们开发的结果不仅是为了我们自己，也是为了观众，最终是为了下游观众。能够接受贡献以改进现有基础设施并支持来自下游受众的更多选项和方案。我们的团队致力于倡导开源机制，并坚信尽最大努力保持基础设施的开源性是正确的选择。当然，这种方法不仅仅适用于开源项目。通过向其他机构开放基础设施，商业企业也可以通过这种方式获得实实在在的利益。想象一下，能够接受来自各方的代码贡献来优先考虑基础设施请求，这样他们就可以亲力亲为，而不是等待运营团队慢慢想出不一定适合他们需求的解决方案。设施的发展显然是一个巨大的推动力。另外，如果开发团队能够提供真正适合实际需求的配置方案，复制生产环境也将非常容易。此外，外部贡献者可以提供良好的文档，让刚加入运营团队的新成员可以快速熟悉整个系统长期遵循的最佳实践机制。在过去的几年里，我们使用Puppet创建了一个我们引以为豪的开源基础设施系统。总结起来，我们可以分为三个主要步骤：1.准备管理策略和代码分离2.准备配置管理系统3.准备文档和共享机制准备管理策略和代码分离OpenStack基础架构团队制定了一套设计的管理策略确保在基础设施中只使用开源产品。虽然这个要求对许多组织来说不切实际，但它确实帮助我们共享我们使用的各种组件，同时确保下游项目可以充分引用我们的基础架构，而不必担心许可费用或任何“黑盒组件可能产生的额外支出”。虽然不是适用于所有组织，这种方法提供了一个清晰的基础架构描述，帮助管理人员了解哪些组件可以自由共享和引用，哪些不能。这样，您就不必担心在不知不觉中共享专有配置文件，而其他部门将能够了解与使用此基础设施解决方案相关的成本。现在我们已经确定了哪些组件是专有的，哪些可以免费共享，接下来要做的是通过适当的决策来共享代码。如果相关内容是开源的或者您确信您的许可机制允许共享其配置化文件和企业内的部署细节，然后随意这样做。最后，组织流程描述以降低执行下一个类似工作的难度（或针对潜在的下游受众），同时提供您的团队为所有代码和配置文件创建的一套许可协议。没错，连配置文件都包括在内。为配置管理系统做准备这是我们过渡到更开放的基础架构方法时所必需的技术元素。在打造专门的运营团队时，我们必须精简执行流程，采用最佳实践，将所有配置机制聚合成一个综合配置库。作为一个开源项目，OpenStack基础设施团队有时不得不采用这种执行思维，但我们一直在尝试用自己的方式来达到这种效果，从而吸引更多的下游受众加入。使用现有的开源模块我们没有为Puppet编写一组新的Apache模块。我们可以直接导入公共模块，根据实际功能需求向上游供应商提供需求。轻松下载开源模块并直接修改的方式无疑是最吸引人的方式，本质上相当于创建了一套fork供内部使用。但这也会给维护团队带来学生的负担，因为我们将无法再轻松升级到最新的开源版本，也会被迫采用在模块中定义自定义变量等不良做法。事实上，我们的团队也尝试过这样做，结果不得不使用一系列项目来组织配置组合。当时我们编写了一套规范，解释了我们为共享和规范化模块所采取的步骤，包括我们用来保存所有文件历史并将它们分组到单独模块中的一些git命令。此外，如果我们要构建可供其他用户使用的模块，我们需要自己编写，同时确保这些修改的部分与原始模块分离。您在服务器上部署的这些本地修改可以存在于根据组织的实际需要定制的特定模块中。我们自己的模块名为openstack_project。#p#分离系统配置和项目配置在项目开发的前期，我们有一套完善的配置方案。在此之后，我们发现，如果下游用户想要将我们的基础架构解决方案导入到他们自己的项目中，他们必须同时使用这两种配置机制才能使其发挥作用——但与此同时，他们更希望能够定义自己的项目配置。我们需要为此制定一个计划，因此我们的团队首先编写了一套规范，概述了需要分解的组件，以及如何使整个系统和更改真正起作用。与需要在我们的基础架构（代码审查系统、测试服务器等）上运行的服务相关的所有内容都配置在一组存储库中，我们可以使用这些存储库来存放OpenStack项目列表、自定义IRC频道集以及实际执行的各种任务跑在我们的Jenkins服务器上等等，今天总结为system-config和project-config，两者独立存在但又不矛盾。分离敏感数据现在，作为一个社区，我们有很多自由，但仍然需要保持整个OpenStack开发平台的完整性，这意味着我们有自己的小秘密。具体来说，我们需要将私有SSL证书和一系列不同类型的验证凭据保存在安全位置，并且只允许少数管理员访问它们。在我们的团队中，我们利用Puppet的Hiera工具来存储上述值。我们将其置于私有版本控制之下，只允许root管理员访问它。此外，我们在文档中明确提到我们如何使用这些值以及涉及哪些变量，以便每个用户都可以使用我们的基础设施并复制他们实际需要的一些数据。提供了解基础架构的窗口一些企业允许开发人员以受限方式访问其生产服务器，但我们选择使用一种名为PuppetBoard的工具让开发人员了解我们的服务器实际在做什么。使用此工具，任何有权访问的人都可以浏览到一个WebUI，该UI显示有关服务器如何运行以及特定更改是否已被接受或成功实施的详细信息。这相当于为贡献者提供了一个窗口，可以观察工作的进展，并独立执行与变更相关的动作。更改是否已被接受？它引入了一些错误吗？查一查PuppetBoard，一切答案都会揭晓。如果您有兴趣，可以在此处查看我们的公开示例。文档和共享机制现在您有了基础设施计划，您计划自豪地向您的父母展示它，并向您的组织提交文档和共享。确保该文档包括以下内容：在哪里可以找到代码和配置。如何提交更改（还包括代码审查、拉取请求、错误报告、票证等）。如何在副本环境中测试更改（单击此处查看相关示例）。查看代码和配置时，请确保不能直接显示任何引导和对接信息。这还包括需要由运营团队手动完成的任何事情。***，开门，欢迎开门！与我们所在的组织共享基础设施，看看更强大的开发团队和更知情的组织如何使用这种清晰的窗口机制来使用我们的基础设施。OpenStack以外的开放实践除了OpenStack，还有其他开源项目将其基础设施全部或部分开源。您可以通过以下链接了解它们的工作原理和浏览它们的开放配置：DebianFedoraJenkinsMozilla原标题：Thebenefitsofbuildinganopeninfrastructure
