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