[[134619]]

OpenStack基礎設施團隊負責管理開發在OpenStack項目當中每天所需要面對的常用服務，具體包括代碼審核與持續集成系統、維基、IRC聊天機器人以及郵件列表等等。

我們也擁有屬于自己的開源項目。我們在基礎設施當中所使用的全部代碼及配置方案都可通過一系列公共代碼庫獲得，而且全部相關說明文檔也皆向大家開放。這種方式與多數其它開源項目不同，它們要么依賴于由單一代碼托管服務所提供的專用性資源——例如SourceForge或者GitHub，要么是由某些企業中的IT人員負責完成基礎設施管理——例如Ubuntu項目。

選擇像OpenStack項目這樣構建一套由社區負責維護的開源基礎設施擁有諸多優勢，其中包括：

• 允許企業及個人參與到OpenStack基礎設施的發展規劃當中，例如為開發團隊提供直接的貢獻資源以及反饋意見。
• 允許開發人員以更為主動的方式參與項目發展，而并非坐等新功能的出現。他們可以提供貢獻資源，從而加快項目成果的交付速度。
• 鼓勵團隊中采取更理想的實踐舉措，因為我們所開發的成果并非單純服務于自身、同時也面向受眾乃至最終的下游受眾。
• 能夠接收貢獻成果，從而改善現有基礎設施并支持更多來自下游受眾的選項及方案。

我們這個團隊致力于倡導開源機制，而且堅信盡***努力保持基礎設施的開源屬性會是個正確的選擇。

當然，這種方式并不僅僅適用于開源項目。商業企業也能夠通過這種將基礎設施向其它機構開放的方式獲得切實收益。想象一下，大家可以接受來自各方的代碼貢獻來調整基礎設施請求的優先級排序，如此一來他們就能夠親自動手而非坐等運營團隊緩慢地拿出未必適合其需要的解決方案，這對基礎設施的發展顯然是種巨大的推動。除此之外，如果開發團隊能夠針對實際需求給出真正適合的配置方案，那么復制生產環境將變得非常輕松。再有，外來貢獻者能夠提供良好的說明文檔，這樣剛剛加入運營團隊的新成員就能快速熟悉整個體系長久以來所遵循的***實踐機制。

在過去幾年的實踐歷程當中，我們一直使用Puppet來創建令我們深深為之自豪的開源基礎設施體系?？偨Y來講，我們可以將其劃分為三個主要步驟：

1.籌備管理政策并進行代碼分離

2.籌備配置管理系統

3.籌備文檔與共享機制

籌備管理政策并進行代碼分離

OpenStack基礎設施團隊制定了一套管理政策，旨在確保基礎設施當中只使用開源產品。雖然這種要求對于很多組織機構而言有些不切實際，但卻切實幫助我們共享自己所使用的各類組件，同時保證下游項目能夠在全面引用我們的基礎設施時、無需擔憂許可費用或者任何“黑盒”組件可能帶來的額外支出。

雖然并不適用于所有組織機構，但這種方式能夠對基礎設施進行明確劃分，幫助管理者了解哪些組件能夠自由共享及引用、而哪些不能。如此一來，大家將不用再擔心自己會在不自知的情況下共享了專有配置文件，而其它部門也能由此了解到使用這套基礎設施方案的相關成本。

現在我們已經明確了哪些屬于專有組件而哪些能夠自由共享，接下來要做的就是通過合適的決策對代碼進行分享。如果相對內容屬于開源或者大家確信自己的許可機制允許在企業內部對其配置文件及部署細節信息進行共享，那么請放心大膽地去做。

***，整理好流程說明以降低下一次同類工作的執行難度(或者面向潛在的下游受眾)，同時為全部代碼及配置文件配備一套由您的團隊創建的許可協議。沒錯，連配置文件也要包含在內。

籌備配置管理系統

這是大家向更為開放的基礎設施方案過渡時所必需的技術要素。在構建專有型運營團隊時，我們必須精簡執行流程、采取***實踐并將所有配置機制匯總成一套綜合性配置庫。作為一個開源項目，OpenStack基礎設施團隊有時候也不得不采取這樣的執行思路，不過我們一直在努力通過自己的方式實現這類效果、從而吸引更多下游受眾的加入。

使用現有開源模塊

我們沒有為Puppet編寫一套新的Apache模塊。我們可以直接將公開模塊導入，并根據實際功能需要向上游供應方提供要求。

輕松下載開源模塊并直接對其進行修改的方式無疑***吸引力，其本質上相當于創建出一套專門在內部環境下使用的fork。不過這也會給維護團隊帶來學生的負擔，因為我們將無法再輕松升級到***開源版本，同時也會因此而被迫采取對模塊內的定制變量進行定義等糟糕的實踐方式。事實上，我們的團隊想當初也嘗試過這樣的作法，并最終導致不得不利用一系列項目來對配置組合進行整理。當時我們編寫出一套規范，其中闡述了我們所采取的模塊分享與標準化調整步驟，包括我們用于為所有文件保存歷史記錄并將它們劃歸至不同獨立模塊時所使用的一部分git命令。

更進一步，如果要構建可供其他用戶使用的模塊、我們需要自行負責編寫，同時確保將這些經過修改的部分從原始模塊中分離出來。大家部署在服務器上的這些本地修改成果能夠存在于特定模塊當中，它們針對組織機構的實際需求作出了針對性調整。我們自己的模塊被命名為openstack_project。

#p#

[[134620]]

將系統配置與項目配置加以拆分

在項目發展早期，我們擁有一套綜合性配置方案。在此之后，我們發現如果下游受眾希望將我們的基礎設施方案引入他們自己的項目，那么他們必須同時使用這些配置機制才能使其生效——但與此同時，他們更希望能夠自行定義項目配置。

我們需要為此制定計劃，所以我們的團隊***編寫了一套規范，其中概述了需要將哪些組件拆分出來、又需要通過怎樣的方式讓整套體系以及變更內容切實生效。與服務相關且需要運行在我們基礎設施當中的一切(包括代碼審查系統、測試服務器等等)都被配置在一套庫當中，這樣我們就能利用它來容納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