OpenStack基础设施团队负责管理开发在OpenStack项目当中每天所需要面对的常用服务，具体包括代码审核与持续集成系统、维基、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的工具让开发人员了解我们的服务器到底在搞些什么。有了这款工具，任何人都访问时都能够浏览到一套Web UI，其中显示出与服务器运行相关的细节信息以及某项特殊改动是否已经被接受或成功实现。这相当于为贡献者们提供了一个窗口，他们能够借此观察工作进展并独自执行与变更相关的操作。某项变更是否已经被接受?它是否带来了某些错误?检查PuppetBoard，一切答案都将揭晓。如果大家感兴趣，可以点击此处查看我们的公开实例。
说明文档与共享机制
现在大家已经拥有了一套基础设施方案，各位肯定打算充满自豪地将其展示在父母面前，并向所在组织机构提交一份说明文档与共享资料。
请确保这份文档包含以下内容：
- 在哪里寻找代码与配置内容。
- 如何提交变更(也包括代码审查、pull请求、漏洞报告以及ticket等)。
- 如何在副本环境下进行变更测试(可点击此处查看相关示例)。
- 在查看代码及配置时，要保证任何引导及对接信息不可直接显示出来。其中也包括任何需要运营团队以手动方式执行的操作。
***，打开大门、迎接开放!将基础设施与我们所在的组织机构共享，并了解更为强大的开发团队与掌握有更多信息的组织机构如何利用这种明确的窗口机制运用我们的基础设施。
OpenStack之外的开放实践
除了OpenStack，还有其它一些开源项目以整体或者部分形式对其基础设施进行开源。大家可以通过以下链接了解它们的运作机制并浏览其开放配置：
- Debian
- Fedora
- Jenkins
- Mozilla
原文标题：The benefits of building an open infrastructure
