這是演講的文字記錄 и .
這是一個使用自行編寫的組態管理系統的專案的故事，以及為什麼遷移到 Ansible 花了 18 個月的時間。
日號 -ХХХ: 開始之前
最初，基礎架構由許多運行 Hyper-V 的獨立主機組成。 建立虛擬機器需要許多步驟：將磁碟放在正確的位置、註冊 DNS、保留 DHCP、將 VM 配置放入 git 儲存庫。 此過程部分機械化，但例如，虛擬機器是手動在主機之間分配的。 但是，例如，開發人員可以在 git 中修正 VM 配置並透過重新啟動 VM 來套用它。
定製配置管理解決方案
我懷疑最初的想法被設想為 IaC：許多無狀態虛擬機器在重新啟動時將其狀態重置為零。 什麼是虛擬機器配置管理？ 從原理上看，它看起來很簡單：
- 為虛擬機器確定了靜態 MAC。
- 帶有 CoreOS 的 ISO 和啟動磁碟已連接到虛擬機器。
- CoreOS根據其IP從WEB伺服器下載客製化腳本來啟動客製化腳本。
- 該腳本根據 IP 位址透過 SCP 下載 VM 配置。
- systemd 單元檔案的 footcloth 和 bash 腳本的 footcloth 已啟動。
這個解決方案有很多明顯的問題：
- CoreOS ISO 已被棄用。
- 遷移/創建虛擬機器時有很多複雜的自動化操作和魔法。
- 更新困難以及需要特定版本的軟體時。 使用內核模組會更有趣。
- 沒有資料就無法取得虛擬機，即虛擬機器出現時，磁碟上掛載了額外的用戶資料。
- 有人不斷搞砸 systemd 單元依賴關係，CoreOS 在重新啟動時會凍結。 使用 CoreOS 中的可用工具很難捕捉到這一點。
- 秘密管理。
- 沒有CM。 CoreOS 有 bash 和 YML 設定。
要套用虛擬機器配置，您需要重新啟動它，但它可能不會重新啟動。 這似乎是一個明顯的問題，但沒有永久磁碟 - 沒有地方可以保存日誌。 好吧，我們嘗試添加內核加載選項，以便發送日誌。 但不，這一切是多麼複雜。
第 0 天：認識問題
這是通常的開發基礎設施：jenkins、測試環境、監控、註冊表。 CoreOS 是為託管 k8s 叢集而設計的，即問題在於CoreOS是如何被使用的。 第一步是選擇堆疊。 我們決定：
- CentOS的 作為基礎分佈，因為這是最接近生產環境的發行版。
- Ansible 對於組態管理，因為對此進行了廣泛的審查。
- 詹金斯 作為自動化現有流程的框架，因為它已經被積極用於開發過程
- Hyper-V的 作為虛擬化平台。 有很多原因超出了故事的範圍，但簡而言之 - 我們不能使用雲，我們必須使用我們自己的硬體。
第 30 天：修復現有協定 - 協定即程式碼
當堆疊清理完畢後，搬家的準備工作就開始了。 以程式碼的形式修復現有協定（協定即程式碼！）。 過渡 體力勞動 -> 機械化 -> 自動化.
1. 配置虛擬機
Ansible 在這方面做得很好。 只需最少的身體動作，您就可以控制虛擬機器配置：
- 建立 git 儲存庫。
- 我們將虛擬機器清單放入清單中，將配置放入劇本和角色中。
- 我們正在設定一個特殊的詹金斯奴隸，您可以從中運行 Ansible。
- 我們建立一個作業並配置 Jenkins。
第一個過程已準備就緒。 協議是固定的。
2.建立新虛擬機
這裡的一切都不是很方便。 從Linux在Hyper-V上建立虛擬機器不是很方便。 使這一過程機械化的嘗試之一是：
- Ansbile 透過 WinRM 連接到 Windows 主機。
- Ansible 執行 powershell 腳本。
- Powershell 腳本建立一個新的虛擬機器。
- 使用 Hyper-V/ScVMM，在來賓作業系統中建立 VM 時，會配置主機名稱。
- 更新 DHCP 租約時，VM 會傳送其主機名稱。
- 網域控制站端的標準 ddns 和 dhcp 整合設定 DNS 記錄。
- 您可以將虛擬機器新增到您的清單中並使用 Ansible 設定它。
3.建立虛擬機器模板
他們在這裡沒有發明任何東西——他們帶了一個包裝機。
- 將打包程式、kickstart 設定新增至 git 儲存庫。
- 使用 hyper-v 和 Packer 設定一個特殊的 jenkins 從屬伺服器。
- 我們建立一個作業並配置 Jenkins。
此連結的工作原理：
- Packer 建立一個空 VM 並取得 ISO。
- VM 啟動後，Packer 將命令輸入到引導程式中，以使用軟碟或 http 中的 kickstart 檔案。
- Anaconda 使用我們的設定啟動，初始作業系統配置已完成。
- Packer 等待 VM 變成可用。
- 虛擬機器內的 Packer 以本地模式運作 ansible。
- Ansible 使用與步驟 #1 完全相同的角色。
- Packer匯出虛擬機器範本。
第 75 天：在不破壞協議的情況下重構協議 = Test ansible + Testkitchen
捕獲程式碼中的約定可能還不夠。 畢竟，如果在整個過程中你想改變一些東西，你就可以破壞一些東西。 因此，就基礎設施而言，出現了對基礎設施的測試。 為了在團隊內同步知識，我們開始測試 Ansible 角色。 我不會深入探討，因為… 有一篇文章描述了當時發生的事件 （劇透，這不是最終版本，後來一切都變得更加複雜 ).
第 130 天：也許不需要 CentOS+ansible？ 也許是開檔？
我們必須明白，引進基礎設施的過程並不是唯一的過程，還有一些附帶的子項目。 例如，我們收到一個在 openshift 中啟動我們的應用程式的請求，這導致我們進行了一個多星期的研究 這減慢了移動過程。 結果證明，openshift 並不能滿足所有需求；您需要真正的硬件，或至少需要能夠使用核心。
第 170 天：Openshift 不合適，我們來試試 Windows Azure Pack 吧？
Hyper-V 不是很友好，SCVMM 也沒有讓它變得更好。 但是有一個名為 Windows Azure Pack 的東西，它是 SCVMM 的附加元件並模仿 Azure。 但實際上，該產品看起來已被廢棄：文檔連結已損壞且非常稀疏。 但作為簡化雲端生命週期選項研究的一部分，他們也對此進行了研究。
第 250 天：Windows Azure Pack 不太好。 我們仍然堅持 SCVMM
Windows Azure Pack 看起來很有前途，但出於不必要的功能考慮，決定不將其複雜性的 WAP 引入系統，並繼續使用 SCVMM。
第 360 天：一塊一塊吃掉大象
僅僅一年後，搬遷平台就準備好了，搬遷過程開始了。 為此，設定了 SMART 任務。 我們檢查了所有虛擬機，並開始一一弄清楚配置，在 Ansible 中對其進行描述，並透過測試對其進行覆蓋。
第 450 天：您獲得了什麼樣的系統？
這個過程本身並不有趣。 這是例行公事，可以注意到，大多數配置都相對簡單或同構，根據帕累托原理，80% 的虛擬機器配置需要 20% 的時間。 依照同樣的原則，80% 的時間花在準備動作上，只有 20% 的時間花在動作本身。
第 540 天：決賽
18個月裡發生了什麼事？
- 這些協議成為了代碼。
- 體力勞動 -> 機械化 -> 自動化.
外部連結
來源： www.habr.com