這是我關於現代軟體開發實踐的系列文章的第六部分。 在本系列文章中，我介紹了軟體工程師可以通過改善流程和實踐來改進軟體的多種方法，這些都是我在ThoughtWorks擔任軟體顧問時所學到的，也可以在我在大型零售商店的工作中體會到。 公司在德國。
當今世界上建造的許多結構（例如橋樑）都是建立在基礎上的，這些基礎包括自然界中最堅固的形狀：三角形。
我在Thoughtworks工作的一部分時間專門用作基礎架構工程師，向其他軟體團隊諮詢如何增強其基礎架構……諮詢如何將其圓形基礎架構變為三角形。
此過程需要各種步驟，其中有些步驟因公司而異，但是始終保持不變的一個步驟是將基礎結構實現為代碼。
什麼是基礎架構即代碼
基礎架構即代碼是一種實踐，旨在應對基礎架構團隊應對的許多挑戰。 它著重於可預配系統及其配置的例程。
想法是，基礎架構應像其他任何軟體一樣對待，因為它應該靈活地進行頻繁的更改和改進。 最常見的實現是用代碼編寫伺服器，雲實例，管道或"在此處插入基礎結構組件"的定義，而不是通過用戶介面進行配置，並且所有更改都在代碼中實現，然後自動應用於 組件，只要它通過了各種檢查（例如驗證）。
由於資源的定義是代碼，因此使用此代碼配置的基礎結構還可以受益於各種有益的開發工具，例如版本控制，CI / CD或TDD。
基礎架構即代碼旨在實現以下結果：
· 由於公司需求的增長，基礎架構不是未來變化的障礙或約束
· 基礎架構更改無壓力，並且與其他任何軟體更改一樣容易應用
· 冗餘和例行任務的自動化擴展到團隊/公司的基礎架構部分
· 基礎架構的用戶能夠自行進行更改並將其應用於基礎架構
· 團隊的基礎架構方面，平均恢復時間下降了
作為代碼地址挑戰基礎架構
伺服器和配置不一致
隨著越來越多的團隊遷移到雲中並使用虛擬機，團隊擁有頻繁增加的衍生伺服器的能力和可能性正在增加。 但是，這也意味著使所有這些機器保持最新狀態並相互保持一致的挑戰越來越頻繁地出現。 如果機器開始彼此區分，則可能導致僅在某些機器上可運行各種程序或腳本。
想像一下，將更新部署到可以在一台伺服器上運行而不能在另一台伺服器上運行的軟體中，這意味著用戶必須"幸運"地登陸運行在該伺服器上的伺服器，以便在負載平衡的情況下擁有一個功能齊全的軟體實例。 模式。
雪花機
雪花被認為是完全獨特的，因為沒有兩個雪花是相同的，因為單個雪花是不可複製的，在軟體機器上也可能發生同一件事。
許多系統管理員試圖通過手動檢查伺服器來糾正不一致的伺服器配置。 這樣的結果是專門為解決特定問題而更新的伺服器，並且沒有更新歷史記錄。 （是的，有時在雲的情況下仍然存在在線歷史記錄，但是如果用戶在解決問題之前單擊了100次，則歷史記錄也無濟於事）。 唯一了解該伺服器已完成操作的人是更新伺服器的人。 然後，"魔術"是某些事物按預期運行的唯一原因，而當某些事物不起作用時，則不容易解釋。
通常這不是故意發生的，但我們是人類，人類會犯錯誤，例如更新伺服器1、2、3和4，但不知何故忘記了5號伺服器。
"不要碰那個"
更改伺服器並最終使其按需運行並運行軟體後，最終結果幾乎像一副紙牌屋。 可以，但是很脆弱。 因此，"請勿觸摸"。
通常，任何進一步的更新或更改都不願意進行，並且自動化變得使管理員有些擔心，因為他們不確定更改是否會導致伺服器正常運行。
基礎架構即代碼原則
單擊按鈕即可複製系統
如果已經通過代碼配置了基礎架構，而不是通過諸如Amazon Web Services或Jenkins之類的UI進行了點擊，那麼重現創建步驟就很簡單了。 所有更改均已記錄在案，沒有任何步驟會被遺忘。
當來自其他團隊的同事詢問您的團隊如何在AWS中配置Kubernetes集群的自動擴展時，您無需單擊UI即可找到3個月前最後一次編輯的設置。 相反，他們可以只查看創建設置的代碼，甚至可能複製要與自己的實例一起使用的代碼。
當執行諸如從數據中心遷移到雲甚至從一個雲提供者遷移到另一種雲提供者之類的操作時，同一件事可能會很有用，因為創建資源的過程很容易重複。
一次性機器
由於基礎結構配置步驟可以通過編程方式複製，因此您不必擔心機器損壞或需要更換的長期後果。
雲的主要好處之一就是所謂的"動態基礎架構"，它是可以快速移動，更新，創建，替換，調整大小甚至刪除資源的事實。 當您不必擔心刪除資源時可能丟失所需的設置以及潛在的未知設置時，可以充分利用動態基礎結構必須提供的好處。
一致性和適應變化
如果通過代碼而非UI來配置資源，則在更新和運行代碼時，使用代碼創建的所有資源也將被更新。
這意味著所有供應的資源（例如伺服器）將保持一致，並且基本上是彼此的精確副本。 由於我們無法輕易預測隨著系統的增長和變化基礎架構需求將如何變化，因此在很大程度上可以快速，頻繁地更改我們的系統是一種積極的情況。
使用基礎結構作為代碼，每個小的更改都可以以持續集成的方式直接應用，從而通過"經常進行小的更改"的口號來提高系統的彈性。
如何開始
定義文件
為了以"基礎結構即代碼"入門，自然地，您的基礎結構配置必須轉換為代碼並在其中定義。 這些定義文件便成為基礎架構的真實來源。
一個很好的工具是Terraform。
Terraform允許您使用HCL（Hashicorp配置語言）來配置和管理基礎結構資源。 使用各種提供程序，您可以像在UI中使用關鍵字和變量那樣配置資源。 運行代碼時，將以編程方式供應代碼中定義的資源。
關於Terraform的一個很棒的部分是，它允許將已經存在的資源導入代碼中。
這是如何在Microsoft Azure中配置基本Linux虛擬機並將其分配給虛擬網絡的示例。
resource "azurerm_resource_group" "main" {
name = "${var.prefix}-resources"
location = var.location
}
resource "azurerm_virtual_network" "main" {
name = "${var.prefix}-network"
address_space = ["10.0.0.0/16"]
location = azurerm_resource_group.main.location
resource_group_name = azurerm_resource_group.main.name
}
resource "azurerm_subnet" "internal" {
name = "internal"
resource_group_name = azurerm_resource_group.main.name
virtual_network_name = azurerm_virtual_network.main.name
address_prefix = "10.0.2.0/24"
}
resource "azurerm_network_interface" "main" {
name = "${var.prefix}-nic"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
ip_configuration {
name = "internal"
subnet_id = azurerm_subnet.internal.id
private_ip_address_allocation = "Dynamic"
}
}
resource "azurerm_linux_virtual_machine" "main" {
name = "${var.prefix}-vm"
resource_group_name = azurerm_resource_group.main.name
location = azurerm_resource_group.main.location
size = "Standard_F2"
admin_username = "adminuser"
admin_password = "P@ssw0rd1234!"
disable_password_authentication = false
network_interface_ids = [
azurerm_network_interface.main.id,
]
source_image_reference {
publisher = "Canonical"
offer = "UbuntuServer"
sku = "16.04-LTS"
version = "latest"
}
os_disk {
storage_account_type = "Standard_LRS"
caching = "ReadWrite"
}
}
版本控制
一旦用代碼定義了資源，您的基礎架構也可以從版本控制系統提供的優勢中受益。
記錄了更改的歷史記錄，記錄了由誰和何時進行的所有更改，從而在問題發生時需要調試甚至回滾時提供了非常有價值的事實來源。
這還提供了一個可見的更改日誌，所有用戶都可以輕鬆查看已更改的內容。 對存儲庫的新推送還可以觸發管道構建或其他操作，從而為基礎架構中的CI / CD提供了機會
並且不要忘記：與所有代碼一樣，進行小的更改而不是進行大的更改具有很多好處。 較小的更改更易於測試和調試，並且更容易修復。 在基礎架構中進行較小的更改也沒有什麼不同。
出色的基礎代碼工具
terraform
如上所述，terraform是用於為各種基礎結構資源編寫，管理和部署配置文件的工具。 該網站將其描述為：
" Terraform是一種用於安全高效地構建，更改和版本化基礎結構的工具。 Terraform可以管理現有和流行的服務提供商以及定製的內部解決方案。
配置文件向Terraform描述了運行單個應用程式或整個數據中心所需的組件。 Terraform生成執行計劃，以描述達到預期狀態所需執行的操作，然後執行該計劃以構建描述的基礎結構。 隨著配置的更改，Terraform能夠確定更改的內容並創建可以應用的增量執行計劃。"
Packer
Packer也是Hashicorp的工具，它允許快速自動創建機器映像。 過去創建虛擬機映像通常是通過創建虛擬機，手動配置（即安裝所需的軟體包和依賴項）然後複製其狀態來完成的。 現在可以在單個位於中央的文件中定義該映像，並通過打包程序進行構建。 它甚至可以使用Chef和Puppet之類的工具將內容安裝到圖像上。
Concourse
具有用戶介面的構建管道，用戶只能在其中查看狀態和日誌。 整個管道必須通過配置文件進行配置。 我認為，它是市場上最酷的管道工具之一，並且是開源的。
有關基礎結構作為代碼的更多信息，我強烈建議您使用以下連結：
· https://www.hashicorp.com/resources/what-is-infrastructure-as-code-Hashicorp
· https://docs.microsoft.com/zh-CN/azure/devops/learn/what-is-infrastructure-as-code-Microsoft
· https://www.thoughtworks.com/de/insights/blog/infrastructure-code-reason-smile — Thoughtworks
另一個重要的信息來源是基夫·莫里斯（Kief Morris）的同名書。 它共享了我上面編寫的許多相同信息，同時更深入地介紹了基礎設施作為代碼的各種思想，解釋了其如何參與常見的基礎設施模式，並為團隊工作流提供了輸入。 我強烈推薦它。
本文僅涉及基礎架構即代碼背後的思想。 如果您還有其他問題和意見，或者需要幫助以開始您的旅程，請隨時與我聯繫！ 編碼愉快，感謝您的閱讀！
我的有關現代軟體開發實踐的系列文章中的其他文章可以在這裡找到
(本文翻譯自Tylor Borgeson的文章《What shape is your software infrastructure?》，參考：https://levelup.gitconnected.com/how-resilient-is-your-software-infrastructure-2cf9925211dd)