快到新年了。 全國各地的孩子們已經給聖誕老人寫了一封信，或者為自己製作了禮物，而他們的主要執行者，主要零售商之一，正在為銷售的神化做準備。 XNUMX月份，其資料中心的負載增加了數倍。 因此，該公司決定對資料中心進行現代化改造，並投入運行數十台新伺服器，而不是已達到使用壽命的設備。 故事以紛飛的雪花為背景結束，驚悚故事開始。
設備在銷售高峰前幾個月抵達現場。 當然，操作服務知道如何在伺服器上配置以及配置什麼，以便將它們帶入生產環境。 但我們需要實現自動化並消除人為因素。 此外，在遷移對公司至關重要的一組 SAP 系統之前更換了伺服器。
新伺服器的調試嚴格遵守最後期限。 移動它意味著危及十億份禮物的運輸和系統的遷移。 即使是由霜老爺子和聖誕老人組成的團隊也無法更改日期 - 每年只能轉移一次用於倉庫管理的 SAP 系統。 從31月1日到20月15日，這家零售商總共有XNUMX個足球場那麼大的倉庫停工了XNUMX個小時。 而這也是唯一一次移動系統的時間。 我們在引入伺服器時不允許出現任何錯誤。
讓我明確一點：我的故事反映了我們團隊使用的工具和配置管理流程。
配置管理複合體由多個層級組成。 關鍵組件是CMS系統。 在工業運作中，缺少其中一個層面，必然會出現令人不快的奇蹟。
作業系統安裝管理
第一級是用於管理實體和虛擬伺服器上作業系統安裝的系統。 它創建基本的作業系統配置，消除人為因素。
使用該系統，我們收到了標準伺服器實例，其作業系統適合進一步自動化。 在「澆注」期間，他們收到了一組最少的本機用戶和公共 SSH 金鑰，以及一致的作業系統配置。 我們可以保證透過 CMS 管理伺服器，並確保作業系統層級的「下方」不會出現任何意外。
安裝管理系統的「最大」任務是自動配置從BIOS/韌體等級到作業系統的伺服器。 這在很大程度上取決於設備和設定任務。 對於異質設備，可以考慮 。 如果所有硬體都來自一個供應商，那麼使用現成的管理工具（例如 HP ILO Amplifier、DELL OpenManage 等）通常會更方便。
為了在實體伺服器上安裝作業系統，我們使用了著名的Cobbler，它定義了一組與營運服務一致的安裝設定檔。 當基礎架構新增伺服器時，工程師將伺服器的 MAC 位址與 Cobbler 中所需的設定檔關聯起來。 第一次透過網路啟動時，伺服器收到一個臨時位址和一個新的作業系統。 然後它被轉移到目標 VLAN/IP 尋址並在那裡繼續工作。 是的，更改 VLAN 需要時間並且需要協調，但它提供了額外的保護，防止在生產環境中意外安裝伺服器。
我們根據使用 HashiСorp Packer 準備的模板創建了虛擬伺服器。 原因是一樣的：為了防止安裝作業系統時可能出現的人為錯誤。 但是，與實體伺服器不同，Packer 消除了 PXE、網路引導和 VLAN 變更的需要。 這使得創建虛擬伺服器變得更加容易和簡單。
米。 1. 管理作業系統的安裝。
管理秘密
任何組態管理系統都包含對普通使用者隱藏但準備系統所需的資料。 這些是本機使用者和服務帳戶的密碼、憑證金鑰、各種 API 令牌等。它們通常稱為「秘密」。
如果您從一開始就沒有確定在哪裡以及如何儲存這些秘密，那麼根據資訊安全要求的嚴重程度，可能有以下儲存方法：
- 直接在配置控製程式碼或儲存庫中的檔案中；
- 專門的組態管理工具（例如 Ansible Vault）；
- 在 CI/CD 系統（Jenkins/TeamCity/GitLab/等）或組態管理系統（Ansible Tower/Ansible AWX）中；
- 秘密也可以「手動」傳輸。 例如，將它們佈置在指定的位置，然後由組態管理系統使用；
- 上述的各種組合。
每種方法都有其自身的缺點。 主要問題是缺乏獲取秘密的策略：不可能或很難確定誰可以使用某些秘密。 另一個缺點是缺乏訪問審核和完整的生命週期。 例如，如何快速替換寫在程式碼和多個相關係統中的公鑰？
我們使用集中式秘密儲存 HashiCorp Vault。 這使我們能夠：
- 保守秘密。 它們是加密的，即使有人獲得了 Vault 資料庫的存取權限（例如，透過從備份恢復資料庫），他們也無法讀取儲存在那裡的秘密；
- 組織獲取秘密的政策。 只有「分配」給他們的秘密才可供使用者和應用程式使用；
- 審計對秘密的存取。 任何涉及機密的操作都會記錄在 Vault 審核日誌中；
- 組織一個完整的秘密工作「生命週期」。 它們可以被建立、撤銷、設定到期日等。
- 易於與需要存取機密的其他系統整合；
- 還採用端對端加密、作業系統和資料庫一次性密碼、授權中心證書等。
現在讓我們繼續討論中央身份驗證和授權系統。 沒有它也是可以的，但是在許多相關係統中管理使用者實在是太不簡單了。 我們已經透過 LDAP 服務配置了身份驗證和授權。 否則，Vault 將必須持續發布並追蹤使用者的身份驗證令牌。 刪除和新增用戶將變成一個問題“我是否在任何地方創建/刪除了這個用戶帳戶？”
我們為我們的系統添加了另一個層級：秘密管理和中央身份驗證/授權：
米。 2、保密管理。
配置管理
我們進入了核心——CMS 系統。 在我們的例子中，這是 Ansible 和 Red Hat Ansible AWX 的組合。
可以使用 Chef、Puppet、SaltStack 來取代 Ansible。 我們基於幾個標準選擇 Ansible。
- 首先，它是多功能性。 一組現成的控制模組 。 如果你還不夠，你可以在 GitHub 和 Galaxy 上搜尋。
- 其次，不需要在被管理設備上安裝和支援代理，證明它們不會幹擾負載，並確認不存在「書籤」。
- 第三，Ansible 的進入門檻較低。 一位稱職的工程師會在使用產品的第一天就寫出一本工作手冊。
但僅在生產環境中使用 Ansible 對我們來說還不夠。 否則，限制存取和審核管理員的操作會出現許多問題。 如何限制存取？ 畢竟，每個部門都有必要管理（閱讀：運行 Ansible 手冊）「自己的」伺服器集。 如何只允許某些員工執行特定的 Ansible playbook？ 或者如何追蹤誰啟動了該劇本，而無需在運行 Ansible 的伺服器和設備上設定大量本地知識？
此類問題的大部分由紅帽解決 ，或者他的開源上游項目 。 這就是為什麼我們更喜歡為客戶提供它。
我們的 CMS 系統的肖像又一觸即發。 Ansible playbook 應儲存在程式碼儲存庫管理系統中。 我們有它 .
因此，設定本身由 Ansible/Ansible AWX/GitLab 組合管理（請參閱圖 3）。 當然，AWX/GitLab 與單一身份驗證系統集成，Ansible playbook 與 HashiCorp Vault 集成。 設定只能透過 Ansible AWX 進入生產環境，其中指定了所有「遊戲規則」：誰可以設定什麼、從哪裡取得 CMS 的設定管理程式碼等。
米。 3.配置管理。
測試管理
我們的配置以程式碼形式呈現。 因此，我們被迫遵守與軟體開發人員相同的規則。 我們需要組織配置程式碼的開發、持續測試、交付和應用到生產伺服器的流程。
如果不立即執行此操作，則為配置編寫的角色將停止支援和修改，或將停止在生產中啟動。 這種疼痛的治療方法是已知的，並且在這個項目中已經證明了自己：
- 每個角色都由單元測試覆蓋；
- 每當管理配置的程式碼發生任何變更時，測試都會自動執行；
- 只有成功通過所有測試和程式碼審查後，配置管理程式碼中的變更才會發佈到生產環境中。
程式碼開發和組態管理變得更加冷靜和可預測。 為了組織持續測試，我們使用了 GitLab CI/CD 工具包，並採取了 .
每當組態管理程式碼發生變化時，GitLab CI/CD 都會呼叫 Molecule：
- 它檢查代碼語法，
- 引發 Docker 容器，
- 將修改後的程式碼應用於已建立的容器，
- 檢查角色的冪等性並執行此程式碼的測試（此處的粒度位於 ansible 角色級別，請參閱圖 4）。
我們使用 Ansible AWX 將設定交付到生產環境。 營運工程師透過預先定義的範本應用配置變更。 AWX 每次使用時都會獨立地向 GitLab 主分支「要求」最新版本的程式碼。 這樣我們就排除了在生產環境中使用未經測試或過時的程式碼。 當然，程式碼經過測試、審核和批准後才進入master分支。
米。 4. GitLab CI/CD 中角色的自動測試。
還有一個與生產系統的操作相關的問題。 在現實生活中，僅透過 CMS 程式碼進行設定變更是非常困難的。 當工程師必須「此時此地」更改配置而無需等待程式碼編輯、測試、批准等時，就會發生緊急情況。
因此，由於手動更改，同一類型設備上的配置會出現差異（例如，HA 叢集節點上的 sysctl 設定配置不同）。 或裝置上的實際配置與CMS程式碼中指定的配置不同。
因此，除了持續測試之外，我們還會檢查生產環境中的配置差異。 我們選擇了最簡單的選項：在「試運行」模式下執行 CMS 配置程式碼，即不套用更改，但會通知計劃配置與實際配置之間的所有差異。 我們透過在生產伺服器上定期執行所有帶有「-check」選項的 Ansible playbook 來實現這一點。 像往常一樣，Ansible AWX 負責啟動劇本並保持最新（見圖 5）：
米。 5. 檢查 Ansible AWX 中的設定差異。
檢查後，AWX 會向管理員發送差異報告。 他們研究有問題的配置，然後透過調整的劇本來修復它。 這就是我們在生產環境中維護配置的方式，而 CMS 始終保持最新且同步。 這消除了在「生產」伺服器上使用 CMS 程式碼時令人不快的「奇蹟」。
我們現在有一個重要的測試層，由 Ansible AWX/GitLab/Molecule 組成（圖 6）。
米。 6.測試管理。
難的？ 我不爭論。 但如此複雜的組態管理已經成為許多與伺服器配置自動化相關問題的綜合答案。 現在，零售商的標準伺服器始終具有嚴格定義的配置。 與工程師不同，CMS 不會忘記添加必要的設定、建立使用者並執行數十或數百項所需的設定。
當今的伺服器和環境設定中不存在「秘密知識」。 所有必要的功能都反映在劇本中。 不再有創意和模糊的指示：“像常規 Oracle 一樣安裝它，但您需要指定幾個 sysctl 設定並新增具有所需 UID 的使用者。 問一下營運的人，他們都知道“。
能夠偵測配置差異並主動修正它們，讓您高枕無憂。 如果沒有配置管理系統，這通常看起來會有所不同。 問題不斷積累，直到有一天它們「投入」生產。 然後進行匯報，檢查並修正配置。 循環再次重複
當然，我們將伺服器的啟動速度從幾天縮短到了幾個小時。
嗯，在除夕夜，當孩子們高興地拆開禮物，大人們在鐘聲敲響時許願時，我們的工程師將 SAP 系統遷移到了新伺服器。 就連聖誕老公公也會說，最好的奇蹟就是那些做好充分準備的奇蹟。
PS 我們團隊經常遇到這樣的情況：客戶希望盡可能簡單地解決配置管理問題。 理想情況下，就像魔術一樣 - 使用一種工具。 但在生活中，一切都更加複雜（是的，靈丹妙藥並沒有再次交付）：您必須使用對客戶團隊來說方便的工具來創建整個流程。
作者：Sergey Artemov，部門建築師 “噴射資訊系統”
來源： www.habr.com