運維思索：如何納管服務器實現統一登陸

這是我參與8月更文挑戰的第8天。

簡述

繼《運維思索：Cobbler無人值守實現操做系統安裝規範化》、《運維思索：操做系統配置規範化、自動化》兩篇文章後，運維團隊已經可以快速交付規格一致的服務器了，接下來咱們的需求就是如何進一步納管服務器並對外提供統一登陸。

爲了實現這一需求，咱們須要藉助於堡壘機。在此咱們特經過JumpServer的應用來深度體驗如何納管服務器並實現統一登陸。

傳統管理方式

傳統管理方式給運維團隊及開發、測試人員帶來如下問題：

1. 開發、運維、測試登陸生產環境，須要進行二次跳轉，操做繁雜；
2. 開發、運維、測試登陸各類環境服務器，強烈依賴帳戶密碼，一旦管控有疏漏，很容易致使密碼泄露，帶來極大的安全隱患；
3. 爲配合審計，運維須要在服務器上額外部署操做記錄審計、遠程記錄等操做，給運維工做帶來了額外的負擔；
4. 基礎運維須要花費額外精力維護訪問控制策略；
5. 頻繁因輸錯密碼致使從新認證，浪費沒必要要的登陸時間；
6. 對於運維團隊新成員，須要花費很大的力氣去熟悉業務相關服務器，延長了融入團隊的時間；

傳統管理方式除在使用上不方便外，更主要的是因爲資產零散，其實對團隊新成員極其不友好，給繁雜的運維工做帶來了額外的壓力。

Jumpserver管理方式

在基於測試環境、生產環境隔離的基礎上，JumpServer登陸體系將基於不一樣環境進行統一的登陸管理，能夠有效的對運維、開發、測試進行權限分離。具體以下：

1. 對接LDAP實現統一的用戶管理，運維只需針對用戶進行資產分配，沒必要再單首創建用戶；
2. 用戶登陸密碼和服務器登陸密碼隔離，用戶使用過程當中不會涉及到服務器相關密碼，能夠有效避免密碼的泄露；
3. 支持多種形式的操做記錄，歷史命令記錄與錄像，可直接用於審計；
4. 資產按業務、功能分組，能夠方便團隊成員瞭解並熟悉組件及業務分佈；
5. 支持命令過濾、免密權限提高，方便使用與管理；

由上，JumpServer給咱們不只帶來管理上的便捷，並且經過有效管理給團隊進行賦能，給相關使用人員帶來更好的體驗。

實施規劃

JumpServer能夠支持各類環境100+、甚至上千臺服務器，如何快速將帳戶不統一的服務器中歸入JumpServer管理，不是一蹴而就的，整個過程建議規劃爲如下幾個階段：

1. 服務器帳戶規劃，統一分爲管理帳戶、應用帳戶、日誌帳戶三類帳戶；
2. 配置自動化，採用開源自動化工具做爲統一的配置中心對三類帳戶進行分批次部署，極大的提升了工做效率；
3. 資產分配，在環境分離或隔離前，集中對各個業務開通進行服務器分配，保證開發可以正常登陸服務器；
4. 對開發、測試人員的資產進行查漏補缺，保證資產到位；

其實以上每一個階段都是要耗費了很大的精力額，要考慮長遠的規範、長效的管理，而不是爲了簡單應用而上線。

ps: 在此實施過程能夠藉助於ansible、saltstack等自動化運維工具實現資產的集中化管理，這樣能夠快速納管服務器。

總結

在咱們堅持不懈的努力下，一套由運維規範支撐、可有效管控服務器的初始框架體系，就能夠正式對開發、測試開放了。

但美中不足的是，當JumpServer的投入使用後，最大的不足仍是資產的分類管理，主要體現：

1. 按系統分組，沒法有效和業務進行對應，致使分類比較混亂。
2. 按業務分組，必須有一份開發、運維、測試共同承認的組織分類，所以這個分類最終會對開發、測試開放的。良好的組織分類能夠給不一樣團隊更快的熟悉服務器的業務分佈，並且極大的提升了登陸體驗。

固然JumpServer的資產分組與CMDB的資產分組是否應該保持一致，也是咱們須要考慮的一個問題，這個就交給你們發散的思考下吧！