如何開啟一個基礎設施即代碼項目
譯文【51CTO.com快譯】多年來，基礎設施即代碼(Infrastructure as Code，IaC)一直是一種趨勢。它通過定義相關標準，以及推出各種新的方法與工具，來盡可能地自動化我們的各項日常任務。例如，Ansible、Pulumi、Terraform等，都是我們耳熟能詳的該領域自動化工具。由于每種工具都各有著各自的優缺點，因此，我們選擇起來并不容易，而且往往需要團隊通過協作，來識別、測試和定義正確的工具。畢竟此類協作的成功關鍵就在于，能夠確保各個團隊成員參與到IaC項目中，進而實現適當的自動化流程。
除了由工具選擇所帶來的挑戰，定義項目的架構也并非易事。單存儲庫與多存儲庫各有利弊，它們能夠在不同應用場景中，簡化IaC項目架構的參與與協作。下面，我將和您深入討論如何在不同的環境中，使用不同的自動化工具，來開啟IaC項目。
什么是IaC項目?
基礎設施即代碼表示在描述性模型中，管理包括：云架構、網絡、虛擬或物理服務器、以及負載平衡器在內的任何基礎設施組件。由于屬于基于DevOps軟件開發的重要實踐，因此它強調的是那些用于置備和更改系統配置的一致性、可重復的例行過程。類似于相同的源代碼能夠生成相同的二進制文件，IaC模型也會在每次應用時，生成相同的環境。可見，IaC是一種通過機器可讀的定義文件，來提供、配置和管理IT基礎設施的方法。據此，我們可以輕松地對整個基礎設施的狀態，進行版本控制。
總的說來，IaC項目具有如下主要優勢：
- 提高速度：通過快速設置完整的基礎設施，讓軟件開發的生命周期更加高效。
- 提高一致性：具有可重復性、一致性的自動化流程，可以避免各種手動錯誤。
- 降低成本：IaC通過良好的云計算能力和自動化策略，降低了項目在硬件、操作人員、物理資源等方面的花費，進而大幅降低了基礎設施管理與維護的成本。
當然，IaC及其配套的工具與項目架構，并非DevOps團隊獨享，它也能夠為公司內的其他工程師賦能，提高協作水平，這也是IaC成功的關鍵。
如何啟動IaC項目?
作為一個靈活可選的架構，IaC需要根據不同的“上下文”，通過不斷迭代，來提高項目的效率。也就是說，IaC項目不一定在首次就能被正確定義，它需要通過持續迭代，才能適應本公司的工作方法。下圖展示了一個典型的項目目錄結構。
以下是針對上述目錄架構的簡單解釋：
- Root是項目的入口，它包含了諸如：README、CONTRIBUTION等項目主要文檔，以及跟蹤每次更新的CHANGELOG文件。
- Dist是一個由自動化腳本自動創建的可選文件夾，可用于配置本地環境，以便加入項目中的任何角色。例如，它可以將符號鏈接集中式地存儲到“extra-tools”文件夾中，以及那些由IaC項目使用的二進制文件。
- Docs存放了更多文檔，以便將帶有代碼源的文檔集中起來，以進行版本控制并保持同步。
- Extra-playbooks是一個可以自動下載外部playbook的文件夾。它有效地分離了內、外部資源，以便區別哪些代碼可被更新，哪些不可以。
- Extra-tools是一個文件夾，其中包含了用于管理IaC架構的每個工具的二進制文件。如果它被設置為本地，則可以方便任何角色按需使用它來運行各種操作。
- Inventory是自動化工具共享全局信息的位置，可為不同環境中的每一種資源進行編錄。
- Playbooks是項目團隊開發的內部playbook的位置。
- Plugins是由自動化腳本創建的可選文件夾，可用于配置本地自動化工具，以便擴展其功能。
- Provision是用于提供基礎設施的自動化代碼的位置。它可以是云端、或是諸如Terraform、Pulumi等本地資源、以及Vagrant、Docker、Kubernetes等本地測試環境(下文會提到)。該文件夾按照不同的工具可分為多個子文件夾，以便項目團隊輕松地識別并管理置備的工具。
- Roles是playbook用來配置提供資源的不同角色的具體位置。
因此，這樣的目錄架構可用來在邏輯上，將置備(provisioning)代碼與配置(configuration)代碼分開，以便在同一個項目內，輕松地實現完全的自動化，且無需管理多個存儲庫。例如，團隊可以使用Terraform去置備某個虛擬機，并使用Ansible等本地置備程序自動配置它。
如何進行團隊合作
常言道：“一個人可以走得更快，但一群人才能走得更遠。”可見，協作是成功的關鍵。以團隊形式開發IaC項目，可以避免出現其他人無法理解的架構，或是選擇了錯誤的自動化工具。值得注意的是，工程團隊中的任何人都應該使用IaC項目，來自動化其流程。畢竟，DevOps方法論的主要目標，就是要縮小運維與開發人員之間的差距。而IaC項目可以通過每個人的參與，來協助實現這一點。
顯然，由不同團隊開發的IaC，需要項目管理人員將其劃分為不同的路線圖、任務、子任務，并隨著時間的推移，持續跟蹤進度。因此，相比掌握如何管理項目，團隊更應該了解如何輕松地實現協作。
版本代碼
與其他軟件項目類似，IaC項目也離不開版本控制。從概念上說，版本控制是隨著時間的推移，跟蹤和管理源代碼的更改，以防止關聯性任務發生沖突的一種實踐。同時，它也能夠通過發布管理，按需快速回滾到過往的版本。
其中，版本規則(convention)必須事先定義和自動管理一個持續的管道，以實現對存儲庫、狀態文件、以及bucket進行自動標記。下圖展示了一個IaC項目的簡單版本規則：
- MAJOR的版本變化發生在引入重大更改時。例如，自動化工具的某次升級，可能會更改API的行為，或需要重寫代碼。
- MINOR的版本變化發生在需要以向后兼容的方式添加功能時。例如，添加新的角色、引入新的工具等。
- PATCH的版本變化發生在需要針對向后兼容的錯誤，進行修復、或格式設置時。
使用帶有顯式名稱的分支
在開發方面，IaC項目應該遵循的另一個的實踐是分支的使用。在源代碼控制軟件中，人們可以使用分支，將代碼從生產環境版本中分離出來，用以修復錯誤、或添加功能。因此，分支方便了用戶對開發代碼執行更改，而不會對生產環境或其他成員的工作，產生影響。
值得注意的是，我們需要在創建分支時，就使用明確的名稱，以確保其他成員可以順利地引用，并快速了解到該分支是否仍在開發中。通常的做法是，使用當前任務的單號來命名分支，以便快速地參考項目管理器的標識符。
此外，我們還需要維護生產環境代碼的主分支和每個子環境的專用分支。為此，我們可以定義一個工作流，讓其首先在開發環境(分支)中部署每個更改，然后在緩存環境(分支)中部署更改，最后在生產環境(主分支)中發布更改。
寫入顯式提交消息
運營團隊應該通過管控好提交消息的格式，來確保大家能夠更好地理解發生的更改。為了能夠從每次更新中提取到實用的信息，我們需要定義顯式的提交消息規則。下圖的規則示例是由可用于分析項目、并快速了解成熟度的信息所組成。它包括：類型(Type)、范圍(Scope)和摘要(Summary)三個組成部分。其中，類型定義了提交的全局目的，范圍定義了項目的哪個子組件會受到影響，而摘要則限定80個字符來快速描述更新。
- 文檔(Docs)：屬于更新類文檔，類似README文件。
- 功能(Feat)：向項目添加新的功能。
- 修復(Fix)：修復錯誤的代碼更新。
- 重構(Refactor)：對不引入新功能的代碼予以更新。
- 格式(Format)：代碼的糾錯(linting)。
- 測試(Test)：單元測試中的代碼更改。
- 持續集成(Ci)：持續集成過程中的代碼更改。
在規則上，我們需要使用較小的提交方式，以便輕松地找到待使用的提交類型。如果您無法確定待使用的模式，則需拆分成多個提交。您可以參考一個名為git-semantic-commits的Github項目。它展示了在命令行中自動創建提交消息的格式。
為了確保每個貢獻者都能夠遵循該格式，我們可以將預提交(pre-commit)規則運用到任何源控制器的軟件上。畢竟，提交消息對于多人協作的項目是非常重要的。如果使用得當，它可以在許多方面提供幫助，特別是在錯誤修復和回滾過程中。
查看代碼
在團隊協作過程中，代碼審查也是一個重要的環節。為了保證軟件質量，團隊會通過查看和閱讀IaC的部分代碼，來發現潛在的錯誤，進而決定是繼續還是中斷實施。一個基本的流程應當至少經過一次批準，才能在主分支(又名生產環境)中進行代碼的合并。
促進項目的啟動(On-Boarding)
貢獻者們只有在理解了項目的基本概念、各項優秀實踐、以及如何提交首次更新的基礎上，才能通過協作參與，來啟動項目。而影響IaC項目啟動的先決條件還包括：文檔的質量、代碼的質量、本地環境的設置、以及開發更新所需的時間。畢竟，設置新的環境是需要時間的，它涉及到安裝、更新和配置工具，下載依賴項，以及配置文件等。為了便于IaC項目的貢獻者更容易地實施，我們可以利用自動化工具，來完成各種所需的“基本(base)”配置，以便每個成員都能共享到相同的本地環境配置(如：工具版本、依賴項等)。
當然，我們無需臨時為設置環境而花時間研究如何使用正確的版本或命令，只需運行一個playbook，即可準備開啟IaC項目。例如，我們可以將架構交由Ansible管理，以確保能同時安裝Python、Terraform、Kubectl、Helm、以及Mitogen等，進而輕松地配置Linux和MacOS等多個環境。
可用工具速覽
下面，我們一起來簡單談論一下，那些在啟動IaC項目時，值得特別關注的工具。
使用Terraform進行配置
Terraform是由HashiCorp開發的開源工具。它允許DevOps工程師以編程的方式，提供運行應用程序所需的資源。由于是基于HashiCorp語言(又稱HCL)，因此它允許任何人通過橫跨多個的云服務、或本地數據中心，以配置和重配的方式，來輕松地維護整個基礎架構的狀態。面對不同的配置器和模塊，Terraform能夠管理應用程序所需的幾乎所有資源。
Terraform雖然旨在為項目保持最新的狀態，并同時共享多個狀態，但如果未能正確地遵循DevOps流程的話，團隊合作可能會隨著時間的推移，而變得繁瑣且復雜。對此，我們可以借用外部工具Atlanti，在Terraform項目中針對任何更新，來輕松地管理代碼審查和自動合并。當然，它也可以被用在將代碼投入生產環境之前，捕獲各種錯誤與缺陷。
正如測試是DevOps方法的重要組成部分那樣，它對于IaC項目的重要性也不言而喻。我們可以采用一個名為Terratest的工具，對自動化的Terraform資源開展測試。這是一個由Gruntwork開發的Go庫，可以為帶有Terraform的IaC，由Amazon、Google等IaaS平臺提供的Packer(下文將提到)，以及Kubernetes集群，創建和自動化各種測試，并且能夠添加自動化的管道。
使用Ansible進行配置
Ansible是一種為跨平臺主機，提供強大的自動化支持工具。任何IT專業人員都可以使用它，來管理應用程序的部署、工作站和服務器上的更新、云服務的分配、配置管理、以及系統管理員的日常事務。憑借其冪等性、以及靈活的組件配置能力，Ansible顯著地提高了IT環境的可擴展性、一致性和可靠性。
Ansible能夠通過與Terraform的耦合，實現對任何應用所需的物理資源的輕松管理。與其他編程語言類似，Ansible能夠定義各類文件在投入生產之前，必須經歷的測試和審查。目前，我們可以使用Molecule和Ansible Test，兩種不同的工具來實現自動化。它們都具有很好的易用性，可以在Ansible的各種playbook上運行單元測試，以實現在審查代碼之前，驗證其行為。
為了提高Ansible的性能，我們可以在Ansible中集成一個名為Mitogen的Python庫，以大幅降低Ansible在運行各種playbook時產生的壓縮和流量。它非常適合那些基于Ansible的IaC項目。
此外，專注于編程語言方法(programmatic language approach)的IaC工具--Pulumi，可以為IaC項目提供更好的靈活性，并讓開發者能夠按需輕松地更改各種方法、架構或工具。因此，如果您熟悉Python、Go等編程語言的話，可以試用該工具。
在虛擬環境中以本地的方式運行代碼
如前所述，IaC項目可以被視為應用開發項目中的一種，應當遵循定義開發文件、以及測試等步驟。通常，我們首先應在本地測試更新，然后在開發或測試環境中進行測試。對此，DevOps工程師可以使用Vagrant、Docker、Podman、Buildah、Minikube、Kind、以及MicroK8s等工具，來模擬特定的環境，以測試IaC項目的各個部分。例如，作為開源工具，Vagrant可以創建一個虛擬環境(例如基于Virtualbox)，來測試軟件在某個特定系統上的部署狀況。Docker、Podman和Buildah可以被用于在容器環境中，執行相同的操作。而Minikube、Kind、MicroK8s也可被用于在本地的Kubernetes集群中，執行相同的操作。通過這些不同的方法與用例，我們可以輕松地在IaC項目中開展測試，并以主動的方式解決潛在問題，而非被動地采取反應。
使用Packer構建自己的鏡像(可選)
IaC項目通常是由與計算資源有關的“基本(base)”配置文件所組成。基本配置文件、或稱通用配置文件，是自動化工具需要應用于計算資源之上，以確保跨資源一致性的角色列表。例如，基本配置文件可以包含：root密碼、NTP服務器、SMTP服務器、以及監控工具的部署等的配置信息。
不過，在IaC項目中，基本配置文件有時也會拖慢新的主機的啟動時間。為此，我們可以使用一個名為Packer的開源工具，以編程的方式，通過創建操作系統的自定義基本鏡像，來減少基本配置。Packer是一個由HashiCorp開發的開源工具，可用于從單個配置源，為多個平臺創建相同的主機鏡像。我們可以上傳已創建的鏡像，以供云端、或本地的虛擬化編排平臺(orchestrator platform)使用。
前文提到的Vagrant，可以在本地使用Packer，并根據定制的鏡像定義，去生成虛擬機，進而在本地測試IaC項目的指定部分。這對于改進自定義資源的部署十分有益。當然，是否確實需要這樣做，則完全取決于基礎設施的實際要求。
在本地模擬云服務
在生產環境中開展代碼測試之前，我們可以使用一些工具，在本地模擬云服務。這比為了測試某段代碼而生成整個環境，要更加節省IaC的項目成本。
AWS用戶可以使用一個名為LocalStack的強大工具。它可以被輕松地部署在本地虛擬環境(如：虛擬機或容器)中，模擬多個AWS端點，進而在本地測試Terraform或Ansible代碼。
而對于GCP用戶而言，則可以使用gcloud命令、及其各種實驗性的功能，臨時模擬出有限的端點。
小結
綜上所述，我們從IaC項目的基本目錄結構，團隊合作，代碼的版本管理，名稱規則，提交消息的格式，如何查看代碼，啟動項目，以及各種實用工具等方面，向您全面地介紹了開啟一個基礎設施即代碼項目。如果您想深入了解IaC的相關知識，請參閱如下鏈接：
原文標題：How to Start an Infrastructure as Code Project，作者：Nicolas Giron
【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】
