許多人在日常工作中了解並使用 Terraform，但其最佳實踐尚未形成。 每個團隊都必須發明自己的方法和方法。
您的基礎設施幾乎肯定是從簡單開始的：一些資源+一些開發人員。 隨著時間的推移，它會向各個方向生長。 您是否找到了將資源分組到 Terraform 模組中、將程式碼組織到資料夾中的方法，以及還有哪些可能出錯的地方？ （著名遺言）
隨著時間的流逝，您感覺您的基礎設施是您的新寵物，但為什麼呢？ 您擔心基礎設施發生莫名其妙的變化，您害怕接觸基礎設施和程式碼 - 結果，您延遲了新功能或降低了品質...
在 Github 上管理 AWS 的 Terraform 社群模組集合並在生產中長期維護 Terraform 三年後，Anton Babenko 準備分享他的經驗：如何編寫 TF 模組，以便將來不會受到傷害。
在演講結束時，參與者將更加熟悉 Terraform 中的資源管理原則、與 Terraform 中的模組相關的最佳實踐以及與基礎設施管理相關的一些持續整合原則。
免責聲明： 我注意到這份報告的日期是 2018 年 2 月——已經過了 0.11 年。 報告中討論的 Terraform 2 版本不再支援。 過去2年裡，已經發布了XNUMX個新版本，其中包含了大量的創新、改進和變化。 請注意這一點並檢查文件。
引用：
- +
- - 自動格式化程式碼和文檔
- — Terraform 模組產生器（WIP）
- — 來自視覺化圖表的 Terraform 程式碼產生器（WIP）
- www.terraform-Best-practices.com
- （新貼文在我的個人網站 www.antonbabenko.com/ 上）
- @antonbabenko - Twitter，以及一堆不同的休閒褲
我叫安東·巴本科。 你們中的一些人可能使用了我寫的程式碼。 現在我會比以往任何時候都更有自信地談論這個問題，因為我可以獲得統計數據。
我從事 Terraform 工作，自 2015 年以來一直是與 Terraform 和 Amazon 相關的大量開源專案的積極參與者和貢獻者。
從那時起，我已經編寫了足夠的程式碼，以有趣的方式表達它。 我現在將嘗試告訴你們這一點。
我將討論使用 Terraform 的複雜性和細節。 但這並不是 HighLoad 的真正主題。 現在你會明白為什麼。
隨著時間的推移，我開始寫 Terraform 模組。 用戶寫了問題，我重寫了它們。 然後我編寫了各種實用程式來使用預提交掛鉤等來格式化程式碼。
有很多有趣的項目。 我喜歡程式碼生成，因為我喜歡電腦為我和程式設計師做越來越多的工作，所以我目前正在使用視覺化圖表開發 Terraform 程式碼生成器。 也許你們有些人見過它們。 這些是帶有箭頭的漂亮盒子。 我認為如果您可以單擊“導出”按鈕並將其全部作為代碼獲取，那就太好了。
我來自烏克蘭。 我在挪威生活了很多年。
此外，本報告的資訊是從知道我的名字並在社交網路上找到我的人收集的。 我幾乎總是有相同的暱稱。
正如我所提到的，我是 Terraform AWS 模組的主要維護者，它是 GitHub 上最大的儲存庫之一，我們在其中託管用於最常見任務的模組：VPC、自動擴展、RDS。
而你現在聽到的是最基本的。 如果您懷疑自己是否理解 Terraform 是什麼，那麼最好將時間花在其他地方。 這裡會有很多技術術語。 我毫不猶豫地宣布該報告的等級是最高的。 這意味著我可以使用所有可能的術語進行交談，而無需太多解釋。
Terraform 於 2014 年作為一個實用程式出現，讓您以程式碼形式編寫、規劃和管理基礎架構。 這裡的關鍵概念是「基礎設施即程式碼」。
正如我所說，所有文檔都是用 。 我希望大多數人都知道這個網站並閱讀過文件。 如果是這樣，那麼您來對地方了。
這就是常規 Terraform 設定檔的樣子，我們首先在其中定義一些變數。
在本例中，我們定義「aws_region」。
然後我們描述我們想要創建什麼資源。
我們運行一些命令，特別是「terraform init」來載入依賴項和提供者。
我們執行“terraform apply”命令來檢查指定的配置是否與我們建立的資源相符。 由於我們之前沒有創建任何內容，Terraform 會提示我們建立這些資源。
我們確認了這一點。 因此我們創建了一個名為seasnail的桶。
還有幾個類似的實用程式。 許多使用 Amazon 的人都知道 AWS CloudFormation 或 Google Cloud Deployment Manager 或 Azure Resource Manager。 他們每個人都有自己的某種實作來管理每個公有雲提供者內的資源。 Terraform 特別有用，因為它允許您管理 100 多個提供者。 （更多細節 )
Terraform 從一開始就追求的目標：
- Terraform 提供單一資源視圖。
- 允許您支援所有現代平台。
- Terraform 從一開始就被設計為一個實用程序，可讓您安全且可預測地更改基礎設施。
2014年，「可預測」這個詞在這種背景下聽起來很不尋常。
Terraform 是一個通用實用程式。 如果你有 API，那你絕對可以控制一切：
- 您可以使用 120 多個提供者來管理您想要的一切。
- 例如，您可以使用 Terraform 來描述對 GitHub 儲存庫的存取。
- 您甚至可以在 Jira 中建立和關閉錯誤。
- 您可以管理 New Relic 指標。
- 如果您確實願意，甚至可以在 Dropbox 中建立文件。
這一切都是使用 Terraform 提供者實現的，這些提供者俱有可以用 Go 描述的開放 API。
假設我們開始使用 Terraform，閱讀了網站上的一些文檔，觀看了一些視頻，然後開始編寫 main.tf，正如我在前面的幻燈片中所示的那樣。
一切都很好，您有一個創建 VPC 的檔案。
如果您想建立 VPC，則大約需要指定這 12 行。 描述您要在哪個區域建立、要使用哪個 cidr_block IP 位址。 就這樣。
自然而然，專案就會逐漸壯大。
你將在那裡添加一堆新東西：資源、資料來源，你將與新的提供者集成，突然你會想要使用 Terraform 來管理你的 GitHub 帳戶中的用戶等。你可能想要使用不同的DNS提供者，跨越一切。 Terraform 讓這一切變得簡單。
讓我們看下面的例子。
您逐漸新增 internet_gateway，因為您希望 VPC 中的資源能夠存取 Internet。 這是一個好主意。
結果是這樣的 main.tf：
這是 main.tf 的頂部部分。
這是 main.tf 的底部部分。
然後添加子網路。 當您想要新增 NAT 閘道、路由、路由表和一堆其他子網路時，您將不再有 38 條線路，而是大約 200-300 條線路。
也就是說，你的 main.tf 檔案正在逐漸成長。 人們常常將所有內容放在一個文件中。 10-20 Kb 出現在 main.tf 中。 想像一下 10-20 Kb 是文字內容。 一切事物都相互關聯。 這逐漸變得難以處理。 10-20 Kb 是一個很好的使用者案例，有時甚至更多。 人們並不總是認為這很糟糕。
與常規程式設計一樣，也就是不是基礎設施即程式碼，我們習慣使用一堆不同的類別、套件、模組、分組。 Terraform 允許您做很多相同的事情。
- 代碼正在增長。
- 資源之間的依賴性也不斷增強。
我們有一個非常非常大的需求。 我們明白我們不能再這樣生活下去了。 我們的程式碼變得越來越龐大。 當然，10-20 Kb 並不是很大，但我們只討論網絡堆棧，即您只添加了網絡資源。 我們不是在談論應用程式負載平衡器、部署 ES 叢集、Kubernetes 等，100 Kb 可以輕鬆編織進去。 如果您寫下所有這些，您很快就會了解到 Terraform 提供了 Terraform 模組。
Terraform 模組是一個獨立的 Terraform 配置，作為一個群組進行管理。 這就是您需要了解的有關 Terraform 模組的全部內容。 他們一點也不聰明，他們不允許你根據某些東西建立任何複雜的連結。 這一切都落在了開發商的肩上。 也就是說，這只是您已經編寫的某種 Terraform 配置。 您可以簡單地將其稱為一個群組。
因此，我們試圖了解如何優化 10-20-30 Kb 的程式碼。 我們逐漸意識到我們需要使用一些模組。
您遇到的第一種模組是資源模組。 他們不了解您的基礎設施是什麼、您的業務是什麼、地點和條件是什麼。 這些正是我與開源社群一起管理的模組，我們將其作為您的基礎設施的最初構建塊。
資源模組的範例。
當我們呼叫資源模組時，我們指定應該從哪個路徑載入其內容。
我們指明要下載哪個版本。
我們在那裡傳遞了一堆參數。 就這樣。 這就是我們使用該模組時需要知道的全部內容。
很多人認為使用最新版本就一切穩定了。 但不是。 基礎架構必須進行版本控制；我們必須清楚回答這個或那個元件部署到哪個版本。
這是該模組內的程式碼。 安全群組模組。 這裡滾動到第 640 行。 在 Amazon 中以每種可能的配置建立安全性群組資源是一項非常重要的任務。 僅僅創建一個安全群組並告訴它傳遞什麼規則是不夠的。 這會很簡單。 亞馬遜內部有上百萬種不同的限制。 例如，如果您使用 VPC端點、前綴列表、各種API 並嘗試將所有這些與其他所有內容結合起來，那麼 Terraform 不允許您這樣做。 亞馬遜 API 也不允許這樣做。 因此，我們需要將所有這些可怕的邏輯隱藏在一個模組中，並為使用者提供看起來像這樣的程式碼。
用戶不需要知道它的內部是如何製作的。
第二類模組由資源模組組成，已經解決了更適合您業務的問題。 通常，這是 Terraform 的擴展的地方，並為公司標準的標籤設定一些嚴格的值。 您也可以在此處新增 Terraform 目前不允許您使用的功能。 這就是現在。 現在版本 0.11，這即將成為過去。 但是，預處理器、jsonnet、cookiecutter 和其他一些東西仍然是必須用於成熟工作的輔助機制。
接下來我將展示一些這方面的例子。
基礎設施模組的呼叫方式完全相同。
指示了下載內容的來源。
傳入一堆值，傳入這個模組。
接下來，在這個模組內，呼叫一堆資源模組來建立 VPC 或應用程式負載平衡器，或建立安全性群組或彈性容器服務叢集。
有兩種類型的模組。 理解這一點很重要，因為我在本報告中分組的大部分資訊都沒有寫在文件中。
現在 Terraform 中的文件很有問題，因為它只是說有這些功能，你可以使用它們。 但她沒有說明如何使用這些功能，以及為什麼使用它們會更好。 因此，很多人寫出了他們無法忍受的東西。
接下來我們來看看這些模組是如何寫的。 然後我們將了解如何呼叫它們以及如何使用程式碼。
地形註冊表 -
提示 #0 是不要寫資源模組。 這些模組中的大多數已經為您編寫了。 正如我所說，它們是開源的，它們不包含任何業務邏輯，它們沒有 IP 位址、密碼等硬編碼值。該模組非常靈活。 而且很可能已經寫好了。 亞馬遜有很多資源模組。 大約650個。而且大部分品質都很好。
在這個例子中，有人來找你說：「我希望能夠管理資料庫。 創建一個模組，以便我可以創建一個資料庫。” 此人不知道 Amazon 或 Terraform 的實作細節。 他只是說：“我想管理 MSSQL。” 也就是說，我們的意思是它將呼叫我們的模組，傳遞引擎類型並指示時區。
人們不應該知道我們將在這個模組中建立兩種不同的資源：一個用於 MSSQL，第二個用於其他所有資源，只是因為在 Terraform 0.11 中您無法將時區值指定為可選。
在該模組的出口處，人們將能夠簡單地收到一個地址。 他不會知道我們在內部從哪個資料庫、哪個資源創建所有這些。 這是隱藏的一個非常重要的元素。 這不僅適用於那些在開源中公開的模組，也適用於您將在專案和團隊中編寫的那些模組。
這是第二個參數，如果您已經使用 Terraform 一段時間，那麼這一點非常重要。 您有一個儲存庫，其中放置了您公司的所有 Terraform 模組。 隨著時間的推移，這個項目的大小會成長到一到兩兆字節，這是很正常的。 這可以。
但問題是 Terraform 如何呼叫這些模組。 例如，如果您呼叫模組來建立每個單獨的用戶，Terraform 將首先載入整個儲存庫，然後導航到該特定模組所在的資料夾。 這樣您每次將下載一兆位元組。 如果您管理 100 或 200 個用戶，那麼您將下載 100 或 200 兆字節，然後轉到該資料夾。 因此，您自然不想每次點擊“Terraform init”時下載一堆東西。
這個問題有兩種解決方案。 第一種是使用相對路徑。 這樣，您就可以在程式碼中指示該資料夾是本機資料夾 (./)。 在啟動任何內容之前，您可以在本機上對該儲存庫進行 Git 複製。 這樣你就可以做一次。
當然，也有很多缺點。 例如，您不能使用版本控制。 有時這很難忍受。
第二個解決方案。 如果您有很多子模組並且已經建立了某種管道，那麼可以使用 MBT 項目，它允許您從單一儲存庫收集許多不同的套件並將它們上傳到 S3。 這是一個非常好的方法。 因此，iam-user-1.0.0.zip 檔案的大小僅為 1 Kb，因為建立此資源的程式碼非常小。 而且它的工作速度會快得多。
讓我們來談談模組中不能使用的內容。
為什麼這在模組中是邪惡的？ 最糟糕的是假設用戶。 假設使用者是一個提供者身份驗證選項，可以由不同的人使用。 例如，我們都會同化這個角色。 這意味著 Terraform 將承擔這個角色。 然後它會透過這個角色執行其他操作。
邪惡的是，如果 Vasya 喜歡以一種方式連接到 Amazon，例如使用預設環境變量，而 Petya 喜歡使用他在秘密地方的共享金鑰，那麼您不能在地形。 為了讓他們不會經歷痛苦，沒有必要在模組中指出這個區塊。 這必須在更高的層面上指出。 也就是說，我們有一個資源模組、一個基礎設施模組和頂部的組合。 這應該在更高的地方指出。
第二個邪惡是供給者。 這裡的邪惡並不是那麼微不足道，因為如果你寫程式碼並且它對你有用，那麼你可能會認為如果它有效，那麼為什麼要改變它。
問題在於，您並不總是能夠首先控制何時啟動此配置程式。 其次，您無法控制 aws ec2 的含義，即我們現在談論的是 Linux 還是 Windows。 因此，您無法編寫在不同作業系統或不同使用者情況下相同工作的東西。
最常見的例子（也在官方文件中指出）是，如果您編寫 aws_instance 並指定一堆參數，那麼如果您在那裡指定配置程式“local-exec”並運行您的 ansible- 則沒有任何問題 -劇本。
事實上，是的，這並沒有什麼錯。 但很快你就會意識到這個 local-exec 的東西不存在，例如在 launch_configuration 中。
當您使用 launch_configuration，並且想要從一個實例建立一個自動縮放群組時，那麼在 launch_configuration 中就沒有「provisioner」的概念。 這裡有一個「用戶資料」的概念。
因此，更通用的解決方案是使用使用者資料。 當實例開啟時，它將在實例本身上啟動，或當自動縮放群組使用此 launch_configuration 時，它將在相同的使用者資料中啟動。
如果您仍然想運行配置程序，因為它是一個粘合組件，當創建資源時，此時您需要運行您的配置程序，您的命令。 這樣的情況還有很多。
最正確的資源稱為 null_resource。 Null_resource 是從未實際建立的虛擬資源。 它不接觸任何東西，沒有API，沒有自動縮放。 但它允許您控制何時運行命令。 在這種情況下，該命令在建立期間運行。
鏈接
有幾個跡象。 我不會詳細討論所有跡象。 有一篇文章是關於這個的。 但如果你使用過 Terraform 或使用過其他人的模組，那麼你經常會注意到許多模組，就像開源中的大多數程式碼一樣，都是人們根據自己的需求編寫的。 一個人寫了它並解決了他的問題。 我把它放在 GitHub 上，讓它活下去。 它會存在，但如果沒有文件和範例，那麼就沒有人會使用它。 如果沒有任何功能可以讓您解決比其特定任務更多的問題，那麼也沒有人會使用它。 失去用戶的方法有很多。
如果你想寫一些東西以便人們會使用它，那麼我建議遵循這些標誌。
它們分別是：
- 文檔和範例。
- 功能齊全。
- 合理的預設值。
- 乾淨的代碼。
- 試驗。
測試是一種不同的情況，因為它們很難編寫。 我更相信文件和範例。
因此，我們研究瞭如何編寫模組。 有兩種說法。 第一個，也是最重要的，如果可以的話就不要寫，因為很多人在你之前已經完成這些任務了。 其次，如果您仍然決定，請盡量不要在模組和設定程式中使用提供者。
這是文檔的灰色部分。 你現在可能會想：「有些事情還不清楚。 不相信。” 但我們將在六個月後看到結果。
現在我們來談談如何呼叫這些模組。
我們知道我們的程式碼會隨著時間的推移而增長。 我們不再只有一個文件，我們已經有 20 份文件了。 它們都在一個資料夾中。 或者也許在五個資料夾中。 也許我們開始以某種方式按地區、按某些組成部分將它們分解。 然後我們就明白，現在我們已經有了一些同步和編排的基礎。 也就是說，我們必須了解如果我們更改了網路資源我們應該做什麼，我們應該如何處理其餘的資源，如何導致這些依賴關係等等。
有兩個極端。 第一個極端是一體的。 我們有一個主文件。 目前，這是 Terraform 網站上的官方最佳實踐。
但現在它被寫為已棄用並被刪除。 隨著時間的推移，Terraform 社群意識到這遠非最佳實踐，因為人們開始以不同的方式使用這個計畫。 並且存在問題。 例如，當我們在一處列出所有依賴項時。 在某些情況下，當我們點擊「Terraform plan」時，直到 Terraform 更新所有資源的狀態，可能會過去很多時間。
很多時間是，例如5分鐘。 對某些人來說，這是很多時間。 我見過需要 15 分鐘的案例。 AWS API 花了 15 分鐘試圖弄清楚每個資源的狀態發生了什麼事。 這是一個非常大的區域。
當然，當您想要更改某個地方的某些內容時，就會出現相關的問題，然後您等待 15 分鐘，它就會為您提供一些更改的畫布。 你吐了口唾沫，寫了“是”，然後出了問題。 這是一個非常真實的例子。 Terraform 不會試圖讓您免受問題的困擾。 也就是說，寫你想要的東西。 會有問題——你的問題。 雖然 Terraform 0.11 並沒有試圖以任何方式幫助您。 0.12中有一些有趣的地方可以讓你說：“Vasya，你真的想要這個，你能清醒過來嗎？”
第二種方式是減少這個區域，即來自一個地方的呼叫可以較少地從另一個地方連接。
唯一的問題是你需要寫更多的程式碼，即你需要在大量文件中描述變數並更新它。 有些人不喜歡它。 這對我來說很正常。 還有人想：“為什麼要寫在不同的地方呢，我把它都放在一個地方吧。” 這是可能的，但這是第二個極端。
誰把這一切都集中在一個地方？ 一、二、三人，即有人在使用。
誰呼叫一個特定元件、一個區塊或一個基礎設施模組？ 五到七人。 這很酷。
最常見的答案是介於兩者之間。 如果專案很大，那麼您經常會遇到沒有合適的解決方案並且並非所有問題都能解決的情況，因此您最終會得到一個混合體。 這並沒有什麼錯，只要你明白兩者都有優點。
如果堆疊VPC 中發生了某些變化，並且您想要將這些變更套用到EC2，即您想要更新自動縮放群組，因為您有一個新的子網，那麼我將這種類型稱為依賴項編排。 有一些解決方案：誰使用什麼？
我可以建議有哪些解決方案。 您可以使用 Terraform 來發揮作用，也可以使用 makefile 來使用 Terraform。 看看那裡是否有什麼變化，您可以在這裡啟動它。
您覺得這個決定怎麼樣？ 有人認為這是一個很酷的解決方案嗎？ 我看到一個微笑，顯然疑慮已經悄悄至。
當然，不要在家裡嘗試這個。 Terraform 從未被設計為從 Terraform 運行。
在一份報告中，他們告訴我：“不，這行不通。” 關鍵是它不應該起作用。 雖然當您可以從 Terraform 啟動 Terraform，然後啟動 Terraform 時看起來非常令人印象深刻，但您不應該這樣做。 Terraform 應該總是很容易啟動。
如果當某個地方發生某些變化時您需要呼叫編排，那麼 Terragrunt 是不錯的選擇。
Terragrunt 是一個實用程序，是 Terraform 的附加元件，可讓您協調和編排對基礎設施模組的呼叫。
典型的 Terraform 設定檔如下所示。
您指定要呼叫哪個特定模組。
該模組有哪些依賴項？
此模組接受什麼參數。 這就是關於 Terragrunt 的全部信息。
文件就在那裡，GitHub 上有 1 個星。 但在大多數情況下，這是您需要了解的。 對於剛開始使用 Terraform 的公司來說，這很容易實現。
所以編排就是 Terragrunt。 還有其他選擇。
現在我們來談談如何使用程式碼。
如果您需要為程式碼新增功能，在大多數情況下這很容易。 您正在編寫一個新資源，一切都很簡單。
如果你有一些預先創建的資源，例如你開了AWS帳戶後了解了Terraform，並想使用你已有的資源，那麼透過這種方式擴展你的模組是合適的，這樣它支援使用現有資源。
並支援使用區塊資源建立新資源。
在輸出時，我們總是根據所使用的內容返回輸出 ID。
Terraform 0.11 中的第二個非常重要的問題是使用清單。
困難在於，如果我們有這樣一個使用者清單。
當我們使用區塊資源建立這些使用者時，一切都會順利。 我們遍歷整個列表，為每個列表建立一個文件。 一切都好。 然後，例如中間的user3，應該從這裡刪除，那麼在他之後創建的所有資源都會重新創建，因為索引會改變。
在有狀態環境中使用清單。 什麼是有狀態環境？ 這就是當這個資源被創造出來的時候，就創造了一個新的價值的情況。 例如，AWS存取金鑰或AWS秘密金鑰，即當我們建立使用者時，我們會收到新的存取金鑰或秘密金鑰。 而每次我們刪除一個使用者時，這個使用者都會有一個新的金鑰。 但這不是風水，因為如果每次有人離開團隊時我們都為他創建一個新用戶，用戶就不會想與我們成為朋友。
這就是解決方案。 這是用 Jsonnet 寫的程式碼。 Jsonnet 是 Google 的一種模板語言。
此命令允許您接受此模板，並返回根據您的模板製作的 json 檔案作為輸出。
模板看起來像這樣。
Terraform 允許您以相同的方式使用 HCL 和 Json，因此如果您有能力產生 Json，那麼您可以將其放入 Terraform 中。 副檔名為.tf.json的檔案將會成功下載。
然後我們像往常一樣使用它：terraform init，terramorm apply。 我們創建兩個用戶。
現在我們不害怕有人離開球隊。 我們只需編輯 json 檔案即可。 瓦夏·普普金離開了，佩佳·皮托奇金留下來。 Petya Pyatochkin 將不會收到新鑰匙。
將 Terraform 與其他工具整合並不是 Terraform 真正的工作。 Terraform 是作為創建資源的平台而創建的，僅此而已。 而之後發生的一切就不是 Terraform 關心的了。 而且沒有必要把它編織在那裡。 Ansible 可以滿足您所需的一切。
但是，當我們想要擴展 Terraform 並在某件事完成後呼叫某些命令時，就會發生這種情況。
第一種方式。 我們在編寫此命令的位置創建一個輸出。
然後我們從 shell terraform 輸出中呼叫此命令並指定我們想要的值。 因此，該命令將使用所有替換值執行。 非常舒服。
第二種方式。 這是 null_resource 的使用取決於我們基礎設施的變化。 一旦某些資源的ID發生變化，我們就可以呼叫相同的local-exe。
當然，這在紙面上是很順利的，因為亞馬遜和所有其他公共提供者一樣，有很多自己的邊緣情況。
最常見的邊緣情況是，當您開設 AWS 帳戶時，使用哪個區域很重要； 該功能是否已啟用； 也許您在 2013 年 XNUMX 月之後打開過它； 也許您在VPC等中使用預設值。有很多限制。 亞馬遜將它們分散在整個文件中。
我建議避免一些事情。
首先，請避免 Terraform 計劃或 Terraform CLI 中的所有非秘密參數。 所有這些都可以放入 tfvars 檔案或環境變數中。
但你不需要記住整個魔法指令。 Terraform 計劃 – var，我們開始吧。 第一個變數是var，第二個變數是var，第三個，第四個。 我最常使用的基礎設施即程式碼最重要的原則是，只需查看程式碼，我就應該清楚地了解那裡部署了什麼、處於什麼狀態以及具有什麼值。 因此，我不必閱讀文件或詢問 Vasya 他使用哪些參數來創建我們的叢集。 我只需要打開一個擴展名為 tfvars 的檔案（該檔案通常與環境相符），然後查看其中的所有內容。
另外，不要使用目標參數來縮小範圍。 為此，使用小型基礎設施模組要容易得多。
而且，不需要限制和增加並行性。 如果我有 150 個資源，並且我想將 Amazon 並行度從預設的 10 增加到 100，那麼很可能會出現問題。 或者現在可能進展順利，但當亞馬遜說你打太多的電話時，你就會遇到麻煩。
Terraform 將嘗試重新啟動大多數此類問題，但您幾乎不會取得任何成果。 如果您偶然發現 AWS API 或 Terraform 提供者內部的某些錯誤，Parallelism=1 是一個很重要的選擇。 然後您需要指定：parallelism=1 並等待 Terraform 完成一個調用，然後是第二個調用，然後是第三個調用。 他將一一發射它們。
人們經常問我：“為什麼我認為 Terraform 工作空間是邪惡的？” 我認為基礎設施即程式碼的原則是查看創建了哪些基礎設施以及具有哪些價值。
工作空間不是由使用者創建的。 這並不意味著用戶在 GitHub 中寫道，沒有 Terraform 工作區我們就無法生存。 不，不是這樣的。 Terraform Enterprise 是一個商業解決方案。 HashiCorp 的 Terraform 認為我們需要工作空間，因此我們將其歸檔。 我發現將其放在單獨的資料夾中要容易得多。 然後文件會多一點，但會更清晰一些。
如何使用代碼？ 事實上，使用清單是唯一的痛苦。 讓 Terraform 變得更容易。 這並不能為你帶來一切好處。 沒有必要把文件中寫的所有內容都塞在那裡。
報告的主題是「為了未來」。 我將非常簡短地討論這一點。 對於未來來說，這意味著0.12即將發布。
0.12 是一大堆新東西。 如果您來自常規編程，那麼您會錯過各種動態區塊、循環、正確和條件比較操作，其中左側和右側不是同時計算的，而是根據情況計算的。 你很想念它，所以 0.12 會為你解決它。
但！ 如果您使用現成的模組和第三方解決方案編寫更少、更簡單，那麼您就不必等待並希望 0.12 會到來並為您解決所有問題。
感謝您的報告！ 您談到了基礎設施即程式碼，並逐字逐句地談到了測試。 模組中是否需要測試？ 這是誰的責任？ 我需要自己寫還是由模組負責？
明年將會充斥著我們決定測試一切的報告。 測試什麼是最大的問題。 有很多依賴關係，來自不同提供者的許多限制。 當你和我談話時，你說：“我需要測試”，然後我問：“你要測試什麼？” 您說您將在您所在的地區進行測試。 然後我說這在我的地區行不通。 也就是說，我們甚至無法在這一點上達成一致。 更不用說還有很多技術問題。 也就是說，如何編寫這些測試以使它們足夠。
我正在積極研究這個主題，即如何根據您編寫的基礎設施自動產生測試。 也就是說，如果你編寫了這段程式碼，那麼我需要運行它，基於此我可以創建測試。
是最常被提及的程式庫之一，它允許您為 Terraform 編寫整合測試。 這是實用程式之一。 我更喜歡 DSL 類型，例如 rspec。
安東，感謝您的報告！ 我叫瓦萊裡。 讓我問一個小哲學問題。 有條件地，有供應，有部署。 配置創建了我的基礎設施，在部署中我們用一些有用的東西填充它，例如伺服器，應用程式等。在我看來，Terraform更適合配置，而Ansible更適合部署，因為Ansible也適用於實體基礎設施可讓您安裝 nginx、Postgres。 但同時，Ansible 似乎允許配置 Amazon 或 Google 資源等。 但是 Terraform 還允許您使用其模組部署一些軟體。 從您的角度來看，Terraform 和 Ansible 之間是否存在某種邊界，在哪裡使用以及什麼更好？ 或者，例如，您是否認為 Ansible 已經是垃圾，您應該嘗試使用 Terraform 來完成所有事情？
好問題，瓦萊裡。 我相信自 2014 年以來，Terraform 的目的就沒有改變。 它為基礎設施而生，也為基礎設施而亡。 我們仍然需要並且將會需要 Ansible 設定管理。 挑戰在於 launch_configuration 中有使用者資料。 然後你就可以使用 Ansible 等。這是我最喜歡的標準差。
如果我們談論的是美麗的基礎設施，那麼有像 Packer 這樣的實用程式可以收集此圖像。 然後 Terraform 使用資料來源尋找該圖片並更新其 launch_configuration。 也就是說，這樣的pipeline就是我們先拉Tracker，再拉Terraform。 如果發生構建，則會發生新的變更。
你好！ 感謝您的報告！ 我叫 Misha，來自 RBS 公司。 建立資源時，您可以透過provisioner呼叫Ansible。 Ansible 還有一個主題稱為動態庫存。 你可以先呼叫 Terraform，然後呼叫 Ansible，Ansible 將從狀態取得資源並執行它。 什麼更好？
人們使用兩者都取得了相同的成功。 在我看來，如果我們不談論自動縮放群組，Ansible 中的動態庫存是一件很方便的事情。 因為在autoscaling群組中我們已經有了自己的工具包，叫做launch_configuration。 在 launch_configuration 中，我們記錄了建立新資源時需要啟動的所有內容。 因此，在我看來，對於 Amazon，使用動態庫存並讀取 Terraform ts 檔案是大材小用。 如果您使用其他沒有「自動縮放群組」概念的工具，例如，您使用 DigitalOcean 或其他沒有自動縮放群組的供應商，那麼您將必須手動拉取 API，查找 IP 位址，建立動態清單文件，Ansible 已經在其中漫遊了。 也就是說，對於亞馬遜，有 launch_configuration，而對於其他一切，有動態庫存。
來源： www.habr.com