一千萬個為什麽

搜索

什麽是“基礎架構作為代碼”?



過去兩周在不同情況下多次提到“基礎設施作為守則”一語。基礎設施作為代碼在實際意義上實際上意味著什麽?

轉載註明原文: 什麽是“基礎架構作為代碼”?

一共有 2 個回答:

TL;DR: Infrastructure as Code is a way to automate and backup your environment. In ideal case, after a disaster, you could restore your Infrastructure fully and automatically by Provisioning new resources, Restoring Configuration from 代碼庫 and Recovering Data from Backup.

概觀

作為Code的基礎設施依賴於三個主要概念:

自動化

配置管理是第三代工具。在CFEngine的基礎上,現在正在廣泛部署一套新的自動配置管理工具。字母順序最流行的是Ansible,CFEngine,Chef,Puppet,PowerShell DSC和SaltStack。每個用戶都有語言來描述您的基礎架構狀態,代碼模塊可應用這些更改並提供擴展工具的能力,一些代理在服務器和 Central Repository 信息上執行這些操作。

它們通常以push或pull模式運行,要麽從中央位置連接到服務器,要麽遠程執行更改,要麽在每個服務器上運行,並從中央位置提取關於狀態的信息,並且在客戶端/服務器模型或分布式辦法。

The important concept is for the system administrator or site reliability engineer to not make changes directly to the infrastructure, but let the 自動化 do changes. Anything done manually by a human should be considered either perishable, being soon corrected back by 自動化 or in stricter form violating the integrity of the infrastructure and triggering destruction and rebuild of the affected components.

代碼庫

代碼庫, ideally separate from Repository holding Software, would be used to manage all changes to the Infrastructure and related 自動化. It should hold Configuration files and templates, Playbooks (Cookbooks) describing process of changes to be reviewed, Code extending the CM 自動化 tools, Provisioning configurations, Infrastructure Tests and Alerts, Staging/Deployment Tests, Documentation, Manual (not yet automated) Process Descriptions.

重要的概念是對變更進行同行評審,在發生不可預知和/或未經測試的問題時,記錄所有變更和自動恢復到以前狀態的能力,部署到登臺環境和測試配置更改的能力以及自動部署能力沒有人為錯誤導致的變化。

托管基礎架構

管理物理基礎設施是一項超越軟件,需要截然不同技能的現實世界任務。通過能夠通過雲計算或托管數據中心對此圖層進行抽象化,您的團隊將專註於管理增加業務價值的基礎架構。

盡管雲計算提供了一種在後期階段快速啟動和擴展的方法,但公司通常會在混合模型的自身數據中心中移動部分基礎架構,從而獲得一些收益甚至顯著節省。擁有或租用硬件並不意味著你也必須雇用處理它的人。在這樣的規模下,您需要遍布全球的數據中心分布在世界各地,並讓所有地方的人員掌握所有必需的技能將會非常昂貴。把它們放在世界各地,會增加任何變化的高延遲和運營效率的下降,這是外包數據中心管理的另一個原因。

The important takeaway is that Managed Physical Infrastructure is often forgotten or overlooked concept, but just as important. Even if you've got everything automated, all configuration stored in a backed up 代碼庫, unless you have a way to quickly provision, you have a huge bottleneck, which could easily erase all the benefits you've gained by the other two steps.

在解釋究竟是什麽之前,讓我引用一個非常好的定義,直接 from Wikipedia

作為代碼的基礎架構(IaC)是管理和維護的過程   配置計算基礎設施(流程,裸機服務器,   虛擬服務器等)及其配置   機器可處理的定義文件,而不是物理硬件   配置或使用交互式配置工具。

Okay, now let's look at one such IaC tool, Terraform to understand the concept better: https://www.terraform.io/

而且,這是Terraform自己說的:

Terraform使您能夠安全且可預測地創建,更改和   改善生產設施。它是一個開源工具   將API編碼為可共享的聲明性配置文件   團隊成員之間,被視為代碼,編輯,審查和   版本

這意味著,可以對整個基礎進行編碼。其中包括像服務器實例,負載平衡器等一樣創建雲(/ infra)資源,以及作為代碼的完整配置(其中包括基本設置調整,安全設置,區域等),這些代碼可以是可編輯的,可版本化的當然可以審查。

這是用於配置AWS資源的Terraform代碼示例:

resource "aws_elb" "frontend" {
  name = "frontend-load-balancer"
  listener {
    instance_port     = 8000
    instance_protocol = "http"
    lb_port           = 80
    lb_protocol       = "http"
  }

  instances = ["${aws_instance.app.*.id}"]
}

resource "aws_instance" "app" {
  count = 5

  ami           = "ami-408c7f28"
  instance_type = "t1.micro"
}

Bonus PS: Also, one needs to understand the differences between provisioning and orchestration tools. Devs confuse one for the other very often and tend to make the mistake of trying to tweak and use a tool for what it is not intended to be used for.