一、運維痛點直擊服務(wù)器越多手動踩坑越多于服務(wù)器運維工作里, 針對單臺Linux服務(wù)器的管理而言, 是頗為簡單的, 像常規(guī)出現(xiàn)的安裝軟件、修改配置以及更新系統(tǒng)等諸般操作, 通過手動去操作, 便能夠輕易達(dá)成, 這同樣是多數(shù)運維新手入門時的常見情形, 然而, 這樣一種順暢的體驗, 僅僅是限定于少量服務(wù)器的場景范圍之內(nèi), 一旦設(shè)備數(shù)量進(jìn)行了規(guī)模上的擴(kuò)增, 那么其中存在的弊端就會被毫無限制地予以放大。不少運維從業(yè)者都有過切身體會, 當(dāng)服務(wù)器數(shù)量擴(kuò)充至5臺, 進(jìn)而擴(kuò)充到20臺, 甚至擴(kuò)充到50臺之后, 原本簡單的日常運維工作, 就會演變成耗費時間且費力的重復(fù)性勞作, 甚至?xí)S為純粹的全職打雜事務(wù)。更讓人苦惱不已的是, 長時間進(jìn)行手動運維, 會滋生出大量隱性問題, 這些問題包括不同服務(wù)器軟件版本存在差異、配置文件修改未能同步、系統(tǒng)用戶權(quán)限并不一致, 時間一長服務(wù)器環(huán)境變得雜亂無序。相當(dāng)多的運維人員會陷入最終極的焦慮, 在經(jīng)過一次次反復(fù)的手動操作之后, 完全沒辦法確定每一臺服務(wù)器的配置是不是規(guī)范的, 其狀態(tài)是不是正常的。這種人工操作所存在的不確定性, 是手動運維最為顯著的短板所在, 也使得運維工作的容錯率低到了極點。的出現(xiàn), 恰恰精妙地化解了這一行業(yè)難題疼處, 全然重新構(gòu)建了多服務(wù)器運維方式形態(tài), 而異于傳統(tǒng)運維工具物件, 其最大的關(guān)鍵優(yōu)勢點在于無代理架構(gòu)構(gòu)造, 不需要在每一臺被管控服務(wù)器之上安裝客戶端程序, 僅僅憑借SSH協(xié)議便可達(dá)成批量管控操作作用, 具備輕量化、零部署成本的特質(zhì)特點, 使得其成為運維自動化的優(yōu)先選擇工具物品。根據(jù)開源資質(zhì)而言, 它屬于紅帽旗下全然免費開源的企業(yè)級運維相關(guān)工具, 不存在任何商用收費方面的限制條件, 能夠適配各種各樣的個人開發(fā)者以及企業(yè)的運維情形情況。當(dāng)下, 這個項目有著64.5k的星標(biāo)數(shù)量, 長時間穩(wěn)穩(wěn)處于運維開源工具的榜單靠前位置, 歷經(jīng)好多好多年的重復(fù)不斷迭代去精心打磨, 其穩(wěn)定性、兼容性已經(jīng)獲得來自世界各地數(shù)目達(dá)到千萬的運維相應(yīng) 團(tuán)隊的實驗驗證, 至于它的實用性以及可靠性那是不用加以懷疑的。但是, 我們同樣需要以理性的態(tài)度去看待它, 它并非那種具備全方位解決能力的神奇工具, 它沒辦法將運維過程中出現(xiàn)的各種故障從根本上予以完全消除, 它僅僅是把依靠人工進(jìn)行操作時所產(chǎn)生的具有隨機(jī)性特征的失誤, 轉(zhuǎn)變成為能夠預(yù)先進(jìn)行判斷、可以展開排查工作的程序方面的問題, 進(jìn)而在較大程度上降低了運維工作所面臨的風(fēng)險水平。這一點也是值得所有從事運維工作的人員深入思索的: 自動化運維的關(guān)鍵要點, 向來都不是為了圖省事而偷懶, 而是運用標(biāo)準(zhǔn)化的方式去取代人工操作所存在的隨意特性。二、核心實操拆解從零上手批量運維存在著一種運維邏輯, 它簡單且清晰, 其核心架構(gòu)被劃分成控制節(jié)點以及被控節(jié)點, 操作流程固定成為這樣的模式, 即首先安裝工具, 接著配置主機(jī)清單, 隨后測試連通性, 再編寫執(zhí)行腳本, 最后批量執(zhí)行任務(wù), 新手依據(jù)這樣的流程也能夠快速上手。接下來完整地還原實操的步驟, 每一段代碼都可以直接進(jìn)行復(fù)用。1. 安裝控制端只需在一臺主控設(shè)備上進(jìn)行安裝就行, 所有被控制的服務(wù)器都不需要開展任何部署方面的操作, 系統(tǒng)能夠直接依照下面的命令來實施安裝:sudo apt update sudo apt install ansible安裝完成后輸入以下命令驗證是否安裝成功ansible --version進(jìn)行終端輸出, 從而輸出版本信息, 輸出版本, 輸出Jinja模板版本等內(nèi)容, 當(dāng)此輸出達(dá)成時, 則意味著安裝呈現(xiàn)正常狀態(tài), 可以進(jìn)入后續(xù)配置環(huán)節(jié)。2. 配置服務(wù)器主機(jī)清單主機(jī)清單, 那可是核心配置文件了, 其作用, 是去告知工具需要管控哪一些服務(wù)器, 并且, 還支持針對服務(wù)器進(jìn)行分組管理, 以此能夠方便開展差異化運維。首先得創(chuàng)建專屬項目目錄, 把配置文件呀統(tǒng)一存放起來喲:mkdir ansible-lab cd ansible-lab新建并編輯主機(jī)清單文件nano inventory向服務(wù)器分組以及 IP 配置當(dāng)中寫入相關(guān)內(nèi)容, 能夠伴著本身業(yè)務(wù)場景去增添分組, 下面是示例配置:[webservers] web01 ansible_host192.168.1.101 web02 ansible_host192.168.1.102 web03 ansible_host192.168.1.103 [databases] db01 ansible_host192.168.1.110 db02 ansible_host192.168.1.111配置中對于自定義的服務(wù)器, 進(jìn)行分組, 之后能夠單獨針對某一組的服務(wù)器, 去執(zhí)行運維任務(wù), 不用逐一臺地進(jìn)行操作, 帶來極大的運維效率提升。3. 測試服務(wù)器連通性在著手編寫格外復(fù)雜的運維腳本之前, 務(wù)必要先去對主控節(jié)點以及所有被控服務(wù)器的連通狀態(tài)展開測試, 以此來防止后續(xù)執(zhí)行的時候出現(xiàn)報錯情況。借助自帶的ping模塊去進(jìn)行批量檢測:ansible webservers -i inventory -m ping出現(xiàn)以下返回結(jié)果代表服務(wù)器連通、權(quán)限配置正常web01 | SUCCESS { changed: false, ping: pong }若有部分服務(wù)器連接呈現(xiàn)失敗狀況無需急著去修改腳本, 應(yīng)去優(yōu)先把那核心方面來排查: 就是看一下其服務(wù)器網(wǎng)絡(luò)是不是通暢, 還要弄清楚SSH的服務(wù)是不是在正常運行著, 再者要確認(rèn)登錄賬號密碼或者密鑰是不是有效的, 另外還要瞧瞧防火墻有沒有攔阻SSH端口, 最后判斷賬號權(quán)限是否充足, 等等情況。4. 編寫并執(zhí)行首個運維劇本“運維對象”由主機(jī)清單進(jìn)行定義, “運維動作”則由運維劇本予以定義, 它們是達(dá)成批量自動化的關(guān)鍵核心文件, 新建一個名為setup.yml的腳本文件。nano setup.yml置入基礎(chǔ)運維任務(wù), 達(dá)成批量更新系統(tǒng)緩存, 開展安裝Git工具, 進(jìn)行安裝curl工具。--- - name: Configure web servers hosts: webservers become: true tasks: - name: Update apt cache apt: update_cache: yes - name: Install Git apt: name: git state: present - name: Install curl apt: name: curl state: present在腳本里頭, true的核心作用在于開啟權(quán)限提升, 不用直接登錄root賬號, 就能夠去執(zhí)行安裝軟件、修改系統(tǒng)配置這類高危操作, 同時兼顧運維的安全性以及便捷性。保存文件后執(zhí)行以下命令批量運行運維任務(wù)ansible-playbook -i inventory setup.yml5. 批量安裝常用運維工具這里有著能夠借助其快速達(dá)成多個服務(wù)器批量裝包的情況體現(xiàn), 以下所呈現(xiàn)的是那種用于監(jiān)控運維場景工具的安裝腳本, 它具備能夠直接進(jìn)行復(fù)用的特性:nano monitoring.yml--- - name: Install monitoring tools hosts: webservers become: true tasks: - name: Install htop apt: name: htop state: present - name: Install curl apt: name: curl state: present - name: Install vim apt: name: vim state: present執(zhí)行腳本完成批量安裝ansible-playbook -i inventory monitoring.yml三、深度辯證分析的核心優(yōu)勢與使用邊界能成為主流自動化運維工具, 其核心價值在于, 解決了人工運維的兩大致命缺陷, 即低效性與不穩(wěn)定性, 用標(biāo)準(zhǔn)化代碼替換人工隨意操作, 使多服務(wù)器運維達(dá)成統(tǒng)一管控。它最為核心的亮點是冪等性機(jī)制, 而這也是自動化運維的關(guān)鍵邏輯所在。簡單來講 , 同一套運維劇本多次重復(fù)執(zhí)行 , 不會出現(xiàn)重復(fù)安裝 , 不會出現(xiàn)配置錯亂 , 不會出現(xiàn)文件冗余等問題。比如說 , 在腳本中將Git設(shè)定為已安裝狀態(tài)之后 , 重復(fù)運行腳本不會再次安裝Git , 僅僅會去校驗系統(tǒng)狀態(tài)是否達(dá)到標(biāo)準(zhǔn) , 能夠徹底避免人工反復(fù)執(zhí)行命令所帶來的冗余操作以及系統(tǒng)故障 , 這是手動運維永遠(yuǎn)都沒辦法達(dá)成的。一方面有無代理架構(gòu)的特性, 另一方面具備開源免費的特點, 再者還有輕量化部署的優(yōu)勢, 這些特性大幅度地降低了中小團(tuán)隊以及個人開發(fā)者的運維門檻, 既無需進(jìn)行額外付費, 又無需開展復(fù)雜的部署工作, 哪怕是零基礎(chǔ)的情況下, 也能夠快速實現(xiàn)自動化運維落地。但我們也要客觀地認(rèn)清其使用邊界, 它并非適配于所有的運維場景。首先, 它僅能對已知的常規(guī)運維操作進(jìn)行標(biāo)準(zhǔn)化處理, 而無法處理突發(fā)的、非常規(guī)的服務(wù)器故障, 自動化并不能替代運維人員的排查思維。其次, 它僅僅只是一種工具, 若劇本編寫不規(guī)范、配置不合理, 仍舊會導(dǎo)致批量運維故障, 甚至?xí)霈F(xiàn)多服務(wù)器統(tǒng)一出錯的批量事故, 其影響范圍相較于人工操作而言更大。這便值得每一位運維從業(yè)者去深入思考, 自動化運維并非是要將雙手徹底解放, 而是要讓運維人員從那些重復(fù)的打雜性質(zhì)的工作里脫離出來, 進(jìn)而聚焦于故障排查、架構(gòu)優(yōu)化等具有高價值的工作, 工具始終只是起到輔助作用, 規(guī)范的流程以及嚴(yán)謹(jǐn)?shù)乃季S才是其中的核心所在。四、1. 落地實用價值在于, 重塑運維工作模式以及行業(yè)標(biāo)準(zhǔn), 其中涵蓋規(guī)避技術(shù)債務(wù)并且保障運維一致性。最大隱患在于長期積累的技術(shù)債務(wù)的是那人工運維, 不同的運維人員, 操作習(xí)慣不一樣, 操作時間也不一樣, 這就會致使多臺服務(wù)器的配置變得參差不齊, 后續(xù)進(jìn)行擴(kuò)容、遷移以及排查故障的時候, 難度會成倍增加。而借助代碼去固化運維標(biāo)準(zhǔn), 不管運行多少次, 也不管是由誰來操作, 服務(wù)器最終的狀態(tài)都是完全統(tǒng)一的, 能夠從根源上杜絕環(huán)境混亂的問題。哪怕相隔半年重新搭建服務(wù)器, 只要運行劇本就能還原標(biāo)準(zhǔn)配置, 不需要人工去記憶那些繁瑣操作。2. 規(guī)范運維流程降低生產(chǎn)事故率它支持預(yù)檢模式, 在正式去執(zhí)行運維操作之前, 可以對此提前檢測腳本會對服務(wù)器帶去什么樣的修改, 來避免直接進(jìn)行操作從而致使生產(chǎn)環(huán)境引發(fā)故障, 是為了適配企業(yè)正式環(huán)境的運維需求。預(yù)檢命令如下:ansible-playbook -i inventory setup.yml --check與此同時, 運維劇本能夠被納入Git版本管理, 對每一次運維變更予以記錄, 達(dá)成運維操作具備可追溯性、可回滾性, 從而完全告別那種人工運維時無記錄、無溯源的混亂狀況, 完美地適配標(biāo)準(zhǔn)化的工作流程。3. 高效排錯提升運維效率在運維故障實施排查期間, 整個排查過程邏輯展現(xiàn)清晰, 當(dāng)出現(xiàn)具體報錯狀況的時刻, 能夠借助增添用于日志輸出的粒度以求實現(xiàn)精準(zhǔn)定位相關(guān)問題, 進(jìn)而防止出現(xiàn)盲目展開排查的情形, 基礎(chǔ)的排錯命令呈現(xiàn)如下:# 基礎(chǔ)日志排查 ansible-playbook -i inventory setup.yml -v # 詳細(xì)日志排查復(fù)雜故障使用 ansible-playbook -i inventory setup.yml -vvv同時, 行業(yè)普遍采用的能最大程度規(guī)避生產(chǎn)事故的穩(wěn)妥落地流程是, 先在本地開展編寫劇本工作, 接著于本地進(jìn)行測試, 隨后對服務(wù)器展開灰度測試, 再進(jìn)而校驗變更內(nèi)容, 之后實施線上執(zhí)行操作, 最后全程予以監(jiān)控, 這樣一套流程適用于絕大多數(shù)企業(yè)的運維場景。五、互動話題你的運維工作踩過哪些坑不少運維從業(yè)者都遭遇過手動運維的崩潰瞬間, 那是要逐臺更新幾十臺服務(wù)器, 要在半夜排查批量配置出現(xiàn)錯亂的故障, 還要因人工操作失誤致使業(yè)務(wù)出現(xiàn)異常。而其核心價值在于, 能用標(biāo)準(zhǔn)化、自動化去解決這些重復(fù)性的痛點, 從而讓運維工作變得更高效、更規(guī)范。它的核心思路實際上是這樣的: 避免一下子就達(dá)成全自動化, 而是先將重復(fù)性高、繁雜且易出現(xiàn)差錯的人工行為代換作腳本運行, 之后按照一定順序逐步對運維體系進(jìn)行改進(jìn), 并非一廂情愿地追求一步到位實現(xiàn)全自動化。在互動提問環(huán)節(jié), 你平常管理著好多臺Linux服務(wù)器, 那最讓你感到頭疼的運維方面的問題是什么, 有沒有去嘗試過自動化運維, 在使用自動化運維的過程當(dāng)中碰到過什么樣子的bug以及難題, 歡迎在評論區(qū)域留言交流, 一塊兒去探討高效的運維技巧