Terraform 開發人員似乎為使用 AWS 基礎架構提供了相當方便的最佳實務。 只是有一個細微差別。 隨著時間的推移，環境的數量不斷增加，每個環境都有自己的功能。 應用程式堆疊的幾乎副本出現在鄰近區域。 而Terraform程式碼需要根據新的需求仔細複製和編輯或製作成雪花。
我的報告是關於 Terraform 中的模式，以對抗大型和長期專案中的混亂和手動例程。
視頻：
我今年 40 歲，從事 IT 工作已經 20 年了。 我在 Ixtens 工作了 12 年。 我們從事電子商務驅動的開發。 我已經實踐 DevOps 實踐 5 年了。
我的故事將講述我在一家公司的一個專案中的經歷，我不會透露該公司的名字，隱藏在保密協議後面。
幻燈片上的數字是為了了解項目的規模而顯示的。 接下來我要說的一切都與亞馬遜有關。
我四年前加入了這個計畫。 由於專案規模不斷擴大，基礎設施重構如火如荼地進行。 而且以前使用的圖案已經不合適了。 考慮到專案的所有計劃增長，有必要想出一些新的東西。
感謝馬特維，他昨天告訴我們在渡渡鳥披薩發生的事。 這就是4年前這裡發生的事。
開發人員開始製作基礎設施代碼。
之所以需要這樣做，最明顯的原因就是上市時間。 有必要確保 DevOps 團隊在部署過程中不會成為瓶頸。 除此之外，Terraform 和 Puppet 在第一級就被使用了。
Terraform 是 HashiCorp 的開源專案。 對於那些甚至不知道這是什麼的人，請看接下來的幾張投影片。
基礎設施即程式碼意味著我們可以描述我們的基礎設施並要求一些機器人確保我們收到我們所描述的資源。
例如，我們需要一個虛擬機器。 我們將描述並添加幾個必需的參數。
之後，我們將在控制台中配置對 Amazon 的存取。 我們會要求提供 Terraform 計劃。 Terraform 計劃會說：“好吧，我們可以為您的資源做這些事情。” 並且至少會添加一種資源。 預計不會有任何變化。
一旦您對一切感到滿意，您可以要求 Terraform 進行申請，Terraform 將為您建立一個實例，您將在雲端中收到一個虛擬機器。
我們的項目正在進一步發展。 我們正在那裡添加一些更改。 我們要求更多實例，我們新增了 53 個條目。
我們重複一遍。 請計劃一下。 我們來看看計劃進行哪些改變。 我們申請。 這就是我們的基礎設施的發展方式。
Terraform 使用稱為狀態檔案的東西。 也就是說，發送到 Amazon 的所有變更都會保存在一個檔案中，其中對於您描述的每個資源，都有在 Amazon 中建立的相應資源。 因此，當資源描述發生變化時，Terraform 確切地知道 Amazon 中需要更改哪些內容。
這些狀態文件原本只是文件。 而且我們將它們儲存在Git中，這非常不方便。 總是有人忘記提交更改，從而產生了許多衝突。
現在可以使用後端，即 Terraform 指定狀態檔案應保存在哪個儲存桶中以及透過哪個鍵保存。 Terraform 本身將負責取得此狀態文件，執行所有操作並傳回最終結果。
我們的基礎設施正在不斷發展。 這是我們的程式碼。 現在我們不只是想創建一個虛擬機，我們還想有一個測試環境。
Terraform 可讓您建立模組之類的東西，即在某個資料夾中描述相同的東西。
例如，在測試中，呼叫此模組並獲得與我們在模組本身中執行 Terraform apply 相同的結果。 為了進行測試，將有此程式碼。
對於生產，我們可以在那裡發送一些更改，因為在測試中我們不需要大型實例；在生產中，大型實例才有用。
然後我會回到這個專案。 這是一項艱鉅的任務，規劃的基礎設施非常龐大。 有必要以某種方式放置所有程式碼，以便對每個人都方便：無論是對程式碼進行維護的人還是進行更改的人。 按照計劃，任何開發人員都可以根據自己平台部分的需求修復基礎設施。
如果您有一個大型項目，並且將整個基礎設施劃分為一些小部分並在單獨的資料夾中描述每個部分是有意義的，那麼這是 HashiCorp 本身推薦的目錄樹。
擁有廣泛的資源庫，您可以在測試和生產中調用大致相同的東西。
在我們的例子中，這並不完全合適，因為開發人員或測試的測試堆疊必須以某種更簡單的方式獲得。 但我不想遍歷資料夾並按所需的順序應用它們，並擔心資料庫會上升，然後使用該資料庫的實例也會上升。 因此，所有測試都是從一個資料夾啟動的。 那裡調用了相同的模組，但一切都是在一次運行中完成的。
Terraform 負責處理所有依賴關係。 並且它總是按順序建立資源，以便您可以取得IP位址，例如，從新建立的實例中取得IP位址，並在route53記錄中取得該IP位址。
另外，平台非常大。 啟動測試堆棧，即使是一個小時，即使是 8 小時，也是一項相當昂貴的任務。
我們將這件事自動化了。 Jenkins 的工作讓我們能夠運行堆疊。 其中，有必要啟動一個拉取請求，其中包含開發人員想要測試的更改，指定所有必要的選項、元件和維度。 如果他想要效能測試，那麼他可以採取更多實例。 如果他只需要檢查某些表格是否打開，那麼他可以從最低工資開始。 也指出是否需要集群等。
然後Jenkins推送了一個shell腳本，該腳本稍微修改了Terraform資料夾中的程式碼。 我刪除了不必要的文件並添加了必要的文件。 然後，透過執行一次 Terraform apply，堆疊就會被提升。
然後還有其他一些我不想討論的步驟。
由於測試時我們需要比生產中更多的選項，因此我們必須複製模組，以便在這些副本中我們可以添加僅測試所需的功能。
碰巧的是，在測試中我有點想測試那些最終將投入生產的變更。 但實際上，測試了一種東西，在生產中使用了略有不同的東西。 生產中所有變更均由營運團隊應用的模式有一個小小的突破。 有時事實證明，那些本應從測試到生產的變更仍然保留在另一個版本中。
此外，還有一個問題是添加了一項新服務，該服務與一些已經存在的服務略有不同。 我們必須複製現有模組並添加必要的更改，而不是修改現有模組。
本質上，Terraform 並不是一種真正的語言。 這是一個聲明。 如果我們需要聲明什麼，那麼我們就聲明它。 這一切都有效。
在某個時候，當討論我的一個拉取請求時，我的一位同事說沒有必要創建雪花。 我想知道他是什麼意思。 有一個科學事實：世界上沒有兩片完全相同的雪花，它們都略有不同。 當我聽到這個消息時，我立即感受到了 Terraform 程式碼的全部分量。 因為當需要從一個版本遷移到另一個版本時，Terraform 需要打破鍊式更改，即程式碼不再與下一個版本相容。 我們必須發出拉取請求，該請求涵蓋了基礎設施中幾乎一半的文件，以便將基礎設施引入下一版本的 Terraform。
當這樣的雪花出現之後，我們所有的Terraform程式碼都變成了一大堆雪。
對於操作之外的外部開發人員來說，這對他來說並不重要，因為他發出了拉取請求，他的資源就啟動了。 僅此而已，這已經不再是他關心的事了。 確保一切正常的 DevOps 團隊需要進行所有這些更改。 每增加一片雪花，這些改變的成本就會增加得非常非常多。
有一個故事是關於一個研討會上的學生如何用粉筆在黑板上畫兩個完美的圓圈。 老師很驚訝他在沒有圓規的情況下竟然能畫得如此流暢。 學生回答：“很簡單，我在部隊待了兩年，開絞肉機。”
在我參與這個計畫的四年中，我從事 Terraform 工作大約兩年了。 當然，我有一些技巧和一些關於如何簡化 Terraform 程式碼、像程式語言一樣使用它以及減輕必須保持此程式碼最新的開發人員的負擔的建議。
我想開始的第一件事是符號連結。 Terraform 有很多重複的程式碼。 例如，我們創建基礎設施的幾乎每個點對提供者的呼叫都是相同的。 將其放在單獨的資料夾中是合乎邏輯的。 以及任何需要提供者為此文件創建符號連結的地方。
例如，在生產中，您使用假設角色，這允許您獲得某些外部亞馬遜帳戶的存取權限。 更改一個檔案後，資源樹中的所有剩餘檔案都將擁有所需的權限，以便 Terraform 知道要存取哪個 Amazon 區段。
符號連結在哪裡失敗？ 正如我所說，Terraform 有狀態檔。 他們非常非常酷。 但問題是 Terraform 先初始化了後端。 並且他不能在這些參數中使用任何變數；它們必須始終以文字形式編寫。
結果，當有人製作新資源時，他會從其他資料夾複製一些程式碼。 他可能會弄錯鑰匙或水桶。 例如，他從沙箱中製作沙箱的東西，然後在生產中製作它。 因此，生產中的儲存桶可能會從沙箱中使用。 當然，他們很快就會找到。 有可能以某種方式解決這個問題，但無論如何，這都是浪費時間，並且在某種程度上浪費資源。
接下來我們可以做什麼？ 在使用 Terraform 之前，您需要對其進行初始化。 在初始化時，Terraform 下載所有外掛。 在某些時候，它們從單體架構分裂成更微服務的架構。 而且您始終需要執行 Terraform init，以便它拉出所有模組、所有插件。
您可以使用 shell 腳本，它首先可以取得所有變數。 shell腳本不以任何方式受到限制。 其次，路徑。 如果我們始終使用儲存庫中的路徑作為狀態檔案的金鑰，那麼相應地，這裡的錯誤將被消除。
我在哪裡可以獲得數據？ JSON 檔案。 Terraform 不僅允許您使用 hcl（HashiCorp 配置語言）編寫基礎設施，還允許您使用 JSON 編寫基礎設施。
JSON 很容易從 shell 腳本中讀取。 因此，您可以將帶有儲存桶的設定檔放在某個位置。 並在 Terraform 程式碼和 shell 腳本中使用此儲存桶進行初始化。
為什麼為 Terraform 提供一個儲存桶很重要？ 因為有遠端狀態文件這樣的東西。 也就是說，當我提出一些資源時，為了告訴亞馬遜：“請提出實例”，我需要指定許多必需的參數。
這些標識符儲存在其他資料夾中。 我可以說：“Terraform，請運行到該資源的狀態文件並為我提供這些標識符。” 因此，在不同地區或環境之間出現了某種統一性。
並不總是可以使用遠端狀態文件。 例如，您手動建立了一個VPC。 建立 VPC 的 Terraform 程式碼會建立如此不同的 VPC，這將需要很長時間，而且您必須將一個 VPC 調整為另一個 VPC，因此您可以使用以下技巧。
也就是說，創建一個似乎創建 VPC 的模組，並且可以為您提供標識符，但實際上只是一個包含硬編碼值的文件，可用於創建相同的實例。
並不總是需要將狀態文件保存在雲端。 例如，在測試模組時，您可以使用後端初始化，其中檔案將在測試時簡單地保存在磁碟上。
現在介紹一下測試。 您可以在 Terraform 中測試什麼？ 可能有很多可能，但我會談談這四件事。
HashiCorp 了解 Terraform 程式碼應如何格式化。 而 Terraform fmt 允許您根據這種信念來格式化您編輯的程式碼。 因此，測試必須檢查格式是否與 HashiCorp 遺贈的格式相對應，以便不需要更改括號的位置等。
下一個是 Terraform 驗證。 它只是檢查語法 - 唉，所有括號是否都配對。 這裡重要的是什麼？ 我們的基礎設施非常廣泛。 裡面有很多不同的爸爸。 在每個中，您都需要執行 Terraform 驗證。
因此，為了加快測試速度，我們使用並行方式並行運行多個進程。
並行是一個非常酷的東西，使用它。
但每次 Terraform 初始化時，它都會向 HashiCorp 詢問：「最新的插件版本是什麼？ 還有我快取中的插件——它是正確的還是錯誤的？” 而且每一步都減慢了速度。
如果你告訴 Terraform 插件在哪裡，那麼 Terraform 會說：「好吧，這可能是最新的東西。 我哪裡也不去，我會立即開始驗證你的 Terraform 程式碼。”
為了用必要的插件填充資料夾，我們有一個非常簡單的 Terraform 程式碼，只需要初始化即可。 當然，在這裡，您需要指定以某種方式參與代碼的所有提供程序，否則 Terraform 會說：“我不知道某個提供程序，因為它不在快取中。”
接下來是 Terraform 計劃。 正如我所說，發展是周期性的。 我們對程式碼進行更改。 然後您需要了解計劃對基礎架構進行哪些變更。
當基礎架構非常非常大時，您可以變更一個模組，修復某些測試環境或某些特定區域並破壞某些相鄰的模組。 因此，應該為整個基礎設施制定 Terraform 計劃，並顯示計劃進行哪些更改。
你可以巧妙地做到這一點。 例如，我們編寫了一個解決依賴關係的Python腳本。 根據更改的內容：Terraform 模組或特定元件，它會為所有依賴資料夾制定計劃。
Terraform 計劃必須根據要求制定。 至少我們就是這麼做的。
當然，為每次更改、每次提交進行測試是件好事，但計劃是相當昂貴的事情。 在拉取請求中，我們說：“請給我計劃。” 機器人啟動。 並發送評論或附上您的更改預期的所有計劃。
計劃是一件相當昂貴的事。 這需要時間，因為 Terraform 會去亞馬遜詢問：「這個實例還存在嗎？ 這個自動秤的參數一模一樣嗎？” 為了加快速度，您可以使用刷新= false 等參數。 這意味著 Terraform 將從 S3 下載狀態。 並且它會相信該狀態將與亞馬遜中的狀態完全匹配。
這樣的 Terraform 計劃要快得多，但狀態必須與您的基礎設施相對應，即在某個地方、某個時間點必須開始 Terraform 刷新。 Terraform 刷新正是這樣做的：狀態與實際基礎架構中的內容相符。
我們需要談談安全。 這是我們必須開始的地方。 當您執行 Terraform 且 Terraform 在您的基礎架構上執行時，存在漏洞。 也就是說，您實際上是在執行程式碼。 如果拉取請求包含某種惡意程式碼，那麼它可以在具有過多存取權限的基礎架構上執行。 因此，在運行 Terraform 計劃的地方要小心。
接下來我想談的是用戶資料測試。
什麼是用戶資料？ 在亞馬遜中，當我們創建實例時，我們可以隨該實例發送特定的字母——元資料。 當實例啟動時，通常 cloud init 總是存在於這些實例上。 Cloud init 讀到這封信後說：“好吧，今天我是負載平衡器。” 並且按照這些契約他執行一些行動。
但是，不幸的是，當我們制定 Terraform 計劃並應用 Terraform 時，用戶資料看起來就像是一堆數字。 也就是說，他只是向您發送哈希值。 你在計劃中所能看到的就是是否會有任何變化或哈希值是否保持不變。
如果您不注意這一點，那麼一些損壞的文字檔案可能最終會出現在亞馬遜的真實基礎設施上。
或者，執行時，您可以不指定整個基礎架構，而僅指定模板。 並在程式碼中說：“請在我的螢幕上顯示此範本。” 因此，您可以列印您的資料在亞馬遜上的樣子。
另一種選擇是使用模組來產生使用者資料。 您將應用此模組。 您收到磁碟上的檔案。 與參考品進行比較。 因此，如果有人決定稍微更正用戶數據，那麼你的測試會說：“好吧，這裡那裡有一些變化 - 這是正常的。”
接下來我想談的是自動化 Terraform 應用程式。
當然，以自動模式應用 Terraform 是相當可怕的，因為誰知道那裡發生了什麼變化以及它們對生活基礎設施有多大破壞性。
對於測試環境來說，這都是正常的。 也就是說，創建測試環境的工作是所有開發人員都需要的。 像「一切都對我有用」這樣的表達並不是一個有趣的模因，而是證明一個人感到困惑，提出了一個堆疊，並在這個堆疊上運行了一些測試。 他確保一切正常後說：“好的，我要發布的程式碼已經過測試。”
在生產、沙箱和其他對業務更關鍵的環境中，您可以非常安全地部分使用某些資源，因為它不會導致任何人死亡。 它們是：自動縮放群組、安全群組、角色、route53，而且清單可能相當大。 但請密切注意正在發生的事情，閱讀自動應用程式報告。
如果應用程式是危險或可怕的，例如，如果這些是來自資料庫的一些持久資源，則收到有關基礎設施的某些部分存在未應用的變更的報告。 工程師在監督下開始申請工作或透過他的控制台進行工作。
亞馬遜有「終止保護」之類的東西。 在某些情況下，它可以防止您不需要的更改。 也就是說，Terraform 去了亞馬遜並說：“我需要殺死這個實例以創建另一個實例。” 亞馬遜說：「抱歉，今天不行。 我們有終止保護。”
錦上添花的是程式碼優化。 當我們使用 Terraform 程式碼時，我們必須向模組傳遞大量參數。 這些是創建某種資源所必需的參數。 且程式碼會變成大量參數，需要從一個模組傳遞到另一個模組、從一個模組傳遞到另一個模組，尤其是在模組嵌套的情況下。
而且它很難閱讀。 對此進行審查非常困難。 很多時候，事實證明，有些參數經過審查，但它們並不完全是所需要的。 這需要時間和金錢來修復。
因此，我建議您使用這樣的東西作為包含特定值樹的複雜參數。 也就是說，您需要某種資料夾，其中包含您希望在某個環境中擁有的所有值。
透過呼叫該模組，您可以獲得一棵在一個公共模組中產生的樹，即在對整個基礎設施具有相同作用的公共模組中產生的樹。
在本模組中，您可以使用 Terraform 中的最新功能（如局部變數）進行一些計算。 然後，透過一個輸出，給出一些複雜的參數，其中可能包括數組哈希值等。
這是我所有最好的發現結束的地方。 我想講一個關於哥倫布的故事。 當他為發現印度的探險隊尋找資金時（正如他當時所想的那樣），沒有人相信他，他們認為這是不可能的。 然後他說：“確保雞蛋不會掉下來。” 所有的銀行家，非常富有而且可能很聰明的人，都試圖以某種方式放置雞蛋，但它不斷掉落。 然後哥倫布拿起雞蛋，稍微壓了一下。 蛋殼碎了，蛋一動也不動。 他們說：“哦，這太簡單了！” 哥倫布回答：「是的，這太簡單了。 當我開放印度時，每個人都會使用這條貿易路線。”
而我剛才告訴你的，可能是很簡單、瑣碎的事。 當你了解它們並開始使用它們時，一切都是按順序進行的。 所以要充分利用。 如果這些對你來說是完全正常的事情，那麼至少你知道如何放置雞蛋以免它掉落。
我們總結一下：
- 盡量避免雪花。 雪花越少，您在整個大型基礎設施中進行任何更改所需的資源就越少。
- 不斷的變化。 也就是說，當程式碼中發生某些變更時，您需要盡快使您的基礎架構符合這些變更。 不應該出現這樣的情況：兩三個月後有人來看Elasticsearch，制定了Terraform計劃，並且出現了一堆他沒有預料到的變化。 並且需要花費很多時間才能讓一切恢復正常。
- 測試和自動化。 您的程式碼包含的測試和功能越多，您就越有信心自己所做的一切都是正確的。 自動交付將使您的信心倍增。
- 測試環境和生產環境的程式碼應該幾乎相同。 實際上，因為生產仍然有點不同，並且仍然存在一些超出測試環境的細微差別。 但無論如何，這都是可以保證的。
- 如果您有大量 Terraform 程式碼，並且需要花費大量時間來保持這些程式碼最新，那麼重構並使其保持良好狀態永遠不會太晚。
- 不可變的基礎設施。 AMI 按計畫交付。
- 當您有很多條目並且希望它們的順序一致時，route53 的結構。
- 對抗 API 速率限制。 這時亞馬遜說：“就是這樣，我無法接受更多請求，請稍等。” 一半的辦公室正在等待基礎設施啟動。
- 現貨實例。 亞馬遜並不是一個便宜的活動，景點可以讓你省下很多。 在那裡你可以講述一份完整的報告。
- 安全和 IAM 角色。
- 尋找失去的資源，當你在亞馬遜有來源不明的實例時，它們會吃錢。 即使實例每月費用為 100-150 美元，每年也超過 1 美元。 尋找這樣的資源是一門有利可圖的生意。
- 和預留實例。
這就是我的全部。 Terraform 很酷，你用它。 謝謝你！
問題
感謝您的報告！ 你的狀態檔案在S3中，但是如何解決幾個人可以拿走這個狀態檔案並嘗試擴展的問題？
首先，我們並不著急。 其次，有一些標誌，我們在其中報告我們正在編寫某些程式碼。 也就是說，儘管基礎設施非常龐大，但這並不意味著有人不斷地使用某些東西。 當有一個活躍階段時，這就是一個問題；我們將狀態檔案儲存在 Git 中。 這很重要，否則有人會製作狀態文件，我們必須手動將它們放在一起才能使一切繼續。 現在不存在這樣的問題了。 總的來說，Terraform 解決了這個問題。 如果某些內容不斷變化，那麼您可以使用鎖來阻止您所說的內容。
您使用開源還是企業？
沒有企業，即您可以免費下載的所有內容。
我的名字是斯坦尼斯拉夫。 我想做一點補充。 您談到了 Amazon 的一項功能，該功能允許您使執行個體無法被殺死。 Terraform 本身也是如此；在 Life Second 區塊中，您可以指定禁止更改或禁止破壞。
時間有限。 好點子。
我還想問兩件事。 首先，您談到了測試。 您使用過任何測試工具嗎？ 我聽過 Test Kitchen 外掛。 也許還有更多的事情。 我還想問當地價值觀。 它們與輸入變數有什麼根本不同？ 為什麼我不能只透過本地值參數化某些內容？ 我試圖弄清楚這個話題，但不知何故我自己無法弄清楚。
我們可以在這個房間外更詳細地討論。 我們的測試工具完全是自製的。 沒有什麼可以測試的。 一般來說，當自動化測試在某處獲取基礎設施時，有一些選擇，檢查它是否正常，然後銷毀所有內容，並報告您的基礎設施仍處於良好狀態。 我們沒有這個，因為測試堆疊每天都在運行。 這就足夠了。 如果某些東西開始損壞，我們無需在其他地方檢查它，它就會開始損壞。
關於當地價值觀，我們在戶外繼續討論吧。
你好！ 感謝您的報告！ 資訊非常豐富。 你說你有很多相同類型的程式碼來描述基礎設施。 您是否考慮過產生此程式碼？
很好的問題，謝謝！ 關鍵是，當我們使用基礎設施即程式碼時，我們假設我們查看程式碼並了解該程式碼背後的基礎設施。 如果產生了程式碼，那麼我們需要想像將產生什麼程式碼，以便了解那裡會有什麼樣的基礎設施。 要么我們產生程式碼，提交它，本質上會發生相同的事情。 所以我們按照我們寫的路走，我們得到了它。 當我們開始製造 Plus 發電機時，它們出現得稍晚。 而此時想要改變已經太晚了。
你聽過 jsonnet 嗎？
號
看，這是一件非常酷的事情。 我看到一個特定的案例，您可以應用它並產生資料結構。
擁有發電機就很好用，就像關於刮鬍機的笑話一樣。 也就是說，第一次的臉是不同的，但後來每個人的臉都是一樣的。 發電機工作得很好。 但不幸的是，我們的臉孔略有不同。 這是問題。
只是看看。 謝謝你！
我叫馬克西姆，來自俄羅斯聯邦儲蓄銀行。 您談到如何嘗試將 Terraform 轉化為相當於程式語言的東西。 使用 Ansible 不是更簡單嗎？
這些是非常不同的事情。 您可以在 Ansible 中建立資源，Puppet 可以在 Amazon 中建立資源。 但 Terraform 是直接銳化的。
你們只有亞馬遜嗎？
這並不是說我們只有亞馬遜。 我們幾乎只有亞馬遜。 但關鍵特徵是 Terraform 具有記憶功能。 在 Ansible 中，如果你說：“給我 5 個實例”，那麼它就會升高，然後你說：“現在我需要 3 個。” Terraform 會說：“好吧，我會殺掉 2 個”，Ansible 會說：“好吧，這是 3 個給你。” 共 8 個。
你好！ 感謝您的報告！ 聽到 Terraform 的消息非常有趣。 我想立即對 Terraform 仍然沒有穩定版本這一事實發表一點評論，因此請謹慎對待 Terraform。
晚餐的好湯匙。 也就是說，如果你需要一個解決方案，那麼有時你會推遲不穩定的事情等等，但它有效並且對我們有幫助。
問題是這樣的。 你使用遠端後端，你使用S 3。為什麼不使用官方後端？
官方的？
地形雲。
他什麼時候出現的？
大約4個月前。
如果它出現在四年前，那麼我可能會回答你的問題。
已經有內建函數和鎖，並且可以儲存狀態檔案。 試一試。 但我也沒有測試過。
我們搭乘一列高速行駛的大型火車。 而且你不能只拿走幾輛車然後丟掉。
你談到了雪花，為什麼不用樹枝呢？ 為什麼事情沒有這樣發展呢？
我們的方法是，整個基礎設施都位於一個儲存庫中。 Terraform、Puppet、所有與此相關的腳本，它們都在一個儲存庫中。 這樣我們就可以確保增量變更被一個又一個地測試。 如果是一堆分支，那麼這樣的專案幾乎不可能維護。 六個月過去了，他們的分歧如此之大，以至於這只是某種懲罰。 這就是我在重構之前想要逃避的。
那麼它不起作用嗎？
這根本行不通。
在分支中，我剪出了資料夾投影片。 也就是說，如果你對每個測試堆疊都這樣做，例如，團隊 A 有自己的資料夾，團隊 B 有自己的資料夾，那麼這也不起作用。 我們創建了一個統一的測試環境程式碼，該程式碼足夠靈活，可以適合每個人。 也就是說，我們提供了一個程式碼。
你好！ 我的名字是尤拉！ 感謝您的報告！ 關於模組的問題。 你說你正在使用模組。 如果對一個模組所做的更改與其他人的更改不相容，您如何解決問題？ 您是否以某種方式對模組進行版本控製或嘗試使用 wunderwaffle 來滿足兩個要求？
這是一個大雪堆問題。 當一些無害的變化可能破壞基礎設施的某些部分時，我們就會遭受這種痛苦。 而且這一點只有在很長一段時間後才會明顯。
也就是說，事情還沒解決？
您製作通用模組。 避免雪花。 一切都會成功。 報告的後半部是關於如何避免這種情況的。
你好！ 感謝您的報告！ 我想澄清一下。 在幕後有一大堆我來找的。 Puppet 和角色分配是如何整合的？
用戶資料。
也就是說，您只是吐出文件並以某種方式執行它？
使用者資料是一個註釋，即當我們複製影像時，Daemon 會在那裡升起，並試圖找出他是誰，並讀取他是負載平衡器的註釋。
也就是說，這是某種被放棄的單獨過程嗎？
它不是我們發明的。 我們用它。
你好！ 我只是有一個關於用戶資料的問題。 你說那裡有問題，有人可能會把東西送到錯誤的地方。 是否有某種方法可以將使用者資料儲存在同一個 Git 中，以便始終清楚使用者資料所指的內容？
我們從模板產生用戶資料。 也就是說，那裡使用了一定數量的變數。 Terraform 產生最終結果。 因此，你不能只看模板就說會發生什麼，因為所有問題都與開發人員認為他在這個變數中傳遞的是字串，但那裡使用了陣列有關。 然後他──砰的一聲和我──某某，某某，下一行，一切都崩潰了。 如果這是一個新資源，有人拿起它並發現有些東西不起作用，那麼它很快就會解決。 如果更新此自動縮放群組，則在某個時刻自動縮放群組中的執行個體將開始被取代。 砰，有些東西不起作用了。 好痛。
原來唯一的解決辦法就是測試？
是的，您看到了問題，您在那裡添加了測試步驟。 也就是說，還可以測試輸出。 也許不太方便，但您也可以做一些標記 - 檢查用戶資料是否已固定在此。
我的名字是帖木兒。 有關於如何正確組織 Terraform 的報告真是太酷了。
我還沒開始呢
我想也許在下次會議上會有。 我有一個簡單的問題。 為什麼將值硬編碼在單獨的模組中而不是使用 tfvars，也就是為什麼具有值的模組比 tfvars 更好？
也就是說，我應該在這裡寫（幻燈片：Production/environment/settings.tf）：domain = variable、domain vpcnetwork、variable vpcnetwork 和 stvars – 我可以得到相同的東西嗎？
這正是我們所做的。 例如，我們指的是設定來源模組。
本質上，這就是這樣的 tfvar。 Tfvars 在測試環境中非常方便。 我有針對大型實例和小型實例的 tfvar。 我將一個文件放入資料夾中。 我得到了我想要的。 當我們削減基礎設施時，我們希望能夠查看並立即了解一切。 所以事實證明你需要看看這裡，然後看看 tfvars。
是否有可能將一切集中在一處？
是的，tfvars 就是當你只有一個代碼。 它被用在幾個不同的地方，有不同的細微差別。 然後你會拋出 tfvars 並得到你的細微差別。 我們是最純粹的基礎設施即程式碼。 我一看就明白了。
你好！ 您是否遇到過雲端供應商幹擾您製作的 Terraform 的情況？ 假設我們編輯元資料。 有 ssh 密鑰。 谷歌不斷地將其元資料和金鑰放在那裡。 Terraform 總是寫下它有變化。 每次運行後，即使沒有任何變化，他總是說他現在就更新這個字段。
有了金鑰，但是，是的，部分基礎設施受到了這個東西的影響，即 Terraform 無法改變任何東西。 我們也無法用手改變任何事。 我們暫時就接受它。
就是你遇到了這樣的事情，但是沒有想出什麼辦法，他是怎麼做的，自己又是怎麼做的？
不幸的是，是的。
你好！ 我的名字是斯塔科夫·斯坦尼斯拉夫。 郵件。 茹集團. 怎麼解決在…上產生標籤的問題，怎麼傳進去呢？ 據我了解，透過User-data來指定主機名，設定Puppet on？ 以及問題的第二部分。 你如何在SG中解決這個問題，即當你產生SG時，數百個相同類型的實例，它們的正確名稱是什麼？
那些對我們非常重要的實例，我們會用漂亮的名字來命名。 那些不需要的，有一個註釋，這是一個自動縮放群組。 從理論上講，您可以將其固定下來併購買新的。
至於標籤的問題，不存在這樣的問題，但有這樣的任務。 我們非常非常頻繁地使用標籤，因為基礎設施龐大且昂貴。 我們需要了解資金的去向，因此標籤可以讓我們詳細了解資金的去向。 因此，尋找一些意味著很多錢的東西都花在這裡。
問題還涉及什麼？
當SG創建數百個實例時，是否需要以某種方式區分它們？
不，不要。 在每個實例上都有一個代理報告我遇到了問題。 如果代理報告，則該代理知道他，並且至少知道他的 IP 位址存在。 你已經可以逃跑了。 其次，我們使用 Consul 進行發現，而 Kubernetes 則沒有。 Consul 也會顯示實例的 IP 位址。
也就是說，您是否特別關注 IP，而不是主機名稱？
無法透過主機名稱進行導航，即主機名稱有很多。 有實例標識符-AE等。你可以在某個地方找到它，你可以把它扔到搜尋中。
你好！ 我意識到 Terraform 是一個好東西，專為雲端量身定制。
不僅如此。
這正是我感興趣的問題。 例如，如果您決定將所有實例全部移轉到裸機？ 會不會有什麼問題？ 或者您仍然需要使用其他產品，例如此處提到的同一個 Ansible？
Ansible 也涉及其他一些事情。 也就是說，當實例啟動時，Ansible 就已經可以運作了。 Terraform 在實例啟動之前工作。 切換到裸機 - 不。
不是現在，但生意會過來並說：“來吧。”
切換到另一個雲——是的，但這裡有一個稍微不同的技巧。 您需要以這樣的方式編寫 Terraform 程式碼，以便您可以輕鬆地切換到其他雲端。
最初，設定的任務是我們的整個基礎設施是不可知的，即任何雲端都應該適合，但在某些時候業務放棄了並說：「好吧，在接下來的N 年內我們不會去任何地方，我們可以使用服務來自亞馬遜“
Terraform 可讓您建立前端作業、設定 PagerDuty、資料文件等。它有很多尾巴。 他幾乎可以掌控整個世界。
感謝您的報告！ 我使用 Terraform 已經 4 年了。 在平穩過渡到 Terraform、基礎設施、聲明性描述的階段，我們面臨著這樣一種情況：有人手工做某事，而你試圖制定計劃。 我在那裡遇到了某種錯誤。 您如何處理此類問題？ 如何找到已列出的遺失資源？
主要是用我們的手和眼睛，如果我們在報告中看到一些奇怪的東西，那麼我們就會分析那裡發生了什麼，或者乾脆殺人。 一般來說，拉取請求是很常見的事。
如果發生錯誤，是否回滾？ 你嘗試過這樣做嗎？
不，這是一個人看到問題那一刻的決定。
來源： www.habr.com