中國專業(yè)IT外包服務(wù)

加入收藏??

公司微博

網(wǎng)站地圖??

IT外包價格計(jì)算器

您當(dāng)前位置：主頁 > 資訊動態(tài) > 艾銻分享 >

2020年 DevOps 領(lǐng)域值得推薦的工具-網(wǎng)絡(luò)運(yùn)維

2020-06-10 21:33 作者：admin

2020年 DevOps 領(lǐng)域值得推薦的工具-網(wǎng)絡(luò)運(yùn)維

網(wǎng)絡(luò)運(yùn)維保姆級的IT外包,2小時內(nèi)上門,專業(yè)工程師7*24h隨叫隨到,提供整體的IT解決方案,兼職網(wǎng)管,桌面運(yùn)維,it外包

從今天開始，讓我們使用最佳 DevOps 工具。
DevOps 革命已然成為主流，各類 DevOps 工具的人氣一路飆升。根據(jù) Google Trends 的統(tǒng)計(jì)，互聯(lián)網(wǎng)用戶對“DevOps 工具”的搜索量一直在穩(wěn)定增長，而且整體發(fā)展趨勢也相當(dāng)穩(wěn)定。
由于 DevOps 涵蓋整個軟件開發(fā)生命周期，期間涉及多種可選工具選項(xiàng)。沒有哪種工具能夠適合所有情況，但是針對各類應(yīng)用場景都有對應(yīng)的、發(fā)展較為成熟的工具。我們把整個 DevOps 實(shí)踐過程中使用到的工具分為以下幾類：
· 開發(fā)與構(gòu)建工具
· 自動化測試工具
· 部署工具
· 運(yùn)行時 DevOps 工具
· 協(xié)作 DevOps 工具
一個成熟且成功的 DevOps 實(shí)踐必須建立一套完整的工具管道，以上五類工具就包含在其中。

小程序開發(fā)1. 開發(fā)與構(gòu)建工具

這類工具是 CI/CD 管道堆棧的基礎(chǔ)，一切也以此作為起點(diǎn)。
開發(fā)與構(gòu)建工具需要協(xié)調(diào)多個事件流，并能與外部工具輕松集成。根據(jù)軟件開發(fā)生命周期，這類工具又可以分為三個子類別：
· 源代碼控制管理（SCM）
· 持續(xù)集成（CI）
· 數(shù)據(jù)管理
2020 年，我們最推薦的 SCM 技術(shù)是 Git，所以建議選擇的 SCM 工具最好提供出色的 Git 支持能力。在 CI 方面，最重要的是在臨時容器化環(huán)境中運(yùn)行及執(zhí)行構(gòu)建任務(wù)的能力。至于數(shù)據(jù)管理，我們希望工具能夠變更數(shù)據(jù)庫架構(gòu)，并使其與應(yīng)用程序版本保持一致。
SCM+CI工具：Gitlab與Gitlab-CI

Gitlab 無疑是 2020 年最強(qiáng)大的 DevOps 生命周期工具，并將在可預(yù)見的未來將成為創(chuàng)新領(lǐng)域的領(lǐng)導(dǎo)者。
Gitlab 的核心定義是在于提供一款完美的 Git repo 管理工具，其基于 Web 的用戶界面詳盡且易于使用。更重要的是，即使是 Gitlab 的免費(fèi)版本也足以解決用戶的各類需求，且分別提供 SaaS 與本地設(shè)施版本。
目前市面上的 SCM 工具多種多樣，但沒有哪位競爭者能夠像 Gitlab 那樣多年來一直堅(jiān)持將“持續(xù)集成”能力引入 repo 當(dāng)中。我們只需要將.gitlab-ci.yml 文件粘貼至 repo 的根目錄當(dāng)中，Gitlab-CI 即可根據(jù)用戶在文件中作出的定義觸發(fā)各類操作。總而言之，這兩款工具彼此配合、成為代碼持續(xù)集成領(lǐng)域當(dāng)之無愧的領(lǐng)導(dǎo)者。
主要優(yōu)勢
成熟—該產(chǎn)品于 2013 年正式投放市場，表現(xiàn)穩(wěn)定且提供良好的支持服務(wù)。
開源— Gitlab 的免費(fèi)版本并沒有削減開發(fā)團(tuán)隊(duì)所需要的各項(xiàng)核心功能。而不同付費(fèi)選項(xiàng)又進(jìn)一步提供了更多附加功能，可根據(jù)組織的具體規(guī)模與需求帶來更大的價值。
易用且強(qiáng)大的 CI— 目前市面上沒有哪款工具能夠像 Gitlab-CI 一樣將持續(xù)集成直接嵌入 SCM 當(dāng)中。用戶可以利用 Docker build 輕松完成構(gòu)建任務(wù)，內(nèi)置報告功能也讓 build 故障調(diào)試變得簡便易行。總之，無需復(fù)雜的集成與業(yè)務(wù)流程，即可對多種必要工具進(jìn)行編排。
無限集成— Gitlab 還能輕松集成 DevOps 各核心類別中的不同工具選項(xiàng)。如此一來，開發(fā)人員與運(yùn)營人員將可立足任意環(huán)境通過真實(shí)來源獲取與其應(yīng)用程序相關(guān)的信息。
與競爭對手的比較
市面上的同類工具有很多，但大多無法與 Gitlab 相比肩。
GitHub — GitHub 是一套面向小型及早期開發(fā)群體的 SaaS 源代碼管理系統(tǒng)，但對于需要在網(wǎng)絡(luò)當(dāng)中保留知識產(chǎn)權(quán)資產(chǎn)的大型企業(yè)，GitHub 提供的唯一選項(xiàng)只有.OVA 虛擬機(jī)。由于這款工具不支持高可用性保障，on-prem 部署的維護(hù)難度會比較高，且在業(yè)務(wù)規(guī)模增長到一定程度后必然引發(fā)服務(wù)器崩潰。另外，GitHub Actions（最近剛剛推出，但仍不提供本地版本）與 CI-as-Code 的長期缺席，迫使用戶自行準(zhǔn)備 CI 工具以管理集成。最后，GitHub 的使用成本要遠(yuǎn)高于一切 Gitlab 版本。
Jenkins — 雖然 Jenkins 已經(jīng)成為持續(xù)集成工具中的默認(rèn)標(biāo)準(zhǔn)，但它卻始終缺少源代碼控制元素。換句話說，Jekins 一直無法與 SCM 工具真正統(tǒng)一起來。相比之下，Gitlab 這樣的工具能夠同時兼顧這兩大功能，消除不必要的復(fù)雜性因素。另外，與目前的現(xiàn)代 Web 應(yīng)用程序相比，Jenkins 糟糕的用戶體驗(yàn)可能讓很多朋友不堪忍受。
BitBucket/Bamboo — 恕我直言，在大家考慮使用兩種工具來完成 Gitlab 本身就能完成的任務(wù)的同時，這套方案就已經(jīng)落入下風(fēng)了。雖然 BitBucket 云已經(jīng)能夠支持 Gitlab-CI/GitHub Action 功能，但還沒有哪家成熟企業(yè)（超過初創(chuàng)公司的規(guī)模）能夠輕松進(jìn)行部署與使用。更夸張的是，本地版本的 BitBucket 服務(wù)器甚至不支持 BItBucket Pipelines！
2020 年頭號數(shù)據(jù)管理工具：FlywayDB

Web 應(yīng)用程序開發(fā)中最容易被忽視的方面就是數(shù)據(jù)庫的自動化需求。人們往往是事后才想起需要為應(yīng)用程序的新版本部署數(shù)據(jù)庫 schema 變更。Schema 變更往往會添加或重命名多個列或表。如果應(yīng)用程序版本與 schema 版本不匹配，還有可能徹底破壞應(yīng)用程序的正常運(yùn)行。最后，由于存在兩套不同的系統(tǒng)，通過應(yīng)用程序升級來協(xié)調(diào)數(shù)據(jù)庫變更也比較困難。好消息是，F(xiàn)lyWayDB 自己就足以解決以上所有的問題。
主要優(yōu)勢
數(shù)據(jù)庫版本控制 — FlyWay 允許用戶輕松創(chuàng)建各數(shù)據(jù)庫版本、跟蹤數(shù)據(jù)庫遷移并輕松完成 schema 變更的前滾與回滾——整個過程無需配合定制構(gòu)建解決方案。
二進(jìn)制或內(nèi)置—大家可以選擇在應(yīng)用程序的啟動過程中、或者以二進(jìn)制可執(zhí)行文件的形式運(yùn)行 Flyway。用戶可以在代碼中直接使用此工具，使其在啟動時能夠檢查版本功能并運(yùn)行適當(dāng)遷移，從而令數(shù)據(jù)庫與應(yīng)用程序的版本保持同步。當(dāng)然也可以臨時運(yùn)行 cmd 行，在無需重建整體應(yīng)用程序的前提下為現(xiàn)有數(shù)據(jù)庫提供良好的靈活性。
與競爭對手的比較
與 FlyWay 處于同一定位的競爭對手不太多，但我們?nèi)杂斜匾治鲭p方的實(shí)力差距：
LiquiBase — Liquibase 跟 FlyWay 非常相似。事實(shí)上，如果能找到經(jīng)驗(yàn)豐富的專項(xiàng)負(fù)責(zé)人員，我其實(shí)更傾向于將 LiquiBase 選定為標(biāo)準(zhǔn)解決方案。
Flocker — 這款工具更多強(qiáng)調(diào)對容器化應(yīng)用程序的管理——相信很多朋友都有切身體會，在容器當(dāng)中運(yùn)行數(shù)據(jù)庫往往非常困難，需要精心規(guī)劃才能達(dá)成目標(biāo)。我建議大家使用 RDS 這類數(shù)據(jù)庫服務(wù)，最好不要輕松嘗試在容器之內(nèi)運(yùn)行關(guān)鍵數(shù)據(jù)存儲。

小程序開發(fā)2. 自動化測試工具

我們首先需要將自動化工具引入整個測試“金字塔”體系，然后才能對自動測試工具進(jìn)行評估。
整個測試金字塔分為 4 層：
· 單元測試 — 這是所有自動化測試的基礎(chǔ)。單從數(shù)量角度來看，單元測試的數(shù)量應(yīng)該遠(yuǎn)遠(yuǎn)高于其他測試類型。單元測試應(yīng)由軟件開發(fā)人員負(fù)責(zé)編寫與運(yùn)行，以確保應(yīng)用程序中的特定組成部分（即「單元」）符合設(shè)計(jì)要求并能夠按照預(yù)期方式運(yùn)行。
· 組件測試 — 組件測試的主要目標(biāo)在于驗(yàn)證測試對象的輸入 / 輸出行為。這能確保測試對象的功能以符合必要規(guī)范的形式正常運(yùn)作。
· 集成測試 — 在這一測試階段，我們需要將各個軟件模塊組合起來并共同進(jìn)行測試。
· 端到端測試 — 這一層的測試目標(biāo)非常明確了，我們需要從頭到尾跟蹤應(yīng)用程序流程，保證其與預(yù)期結(jié)果保持一致。
由于單元與組件層測試單純由應(yīng)用程序開發(fā)人員負(fù)責(zé)，且通常根據(jù)具體編程語言而有所區(qū)別，因此這部分工作不在 DevOps 的討論范圍之內(nèi)。
2020 年頭號集成測試工具：Cucumber

Cucumber 將規(guī)范與測試文檔合并為統(tǒng)一的動態(tài)文件。Cucumber 能夠自動完成測試，因此能夠保證用戶規(guī)范將始終保持更新。如果大家希望構(gòu)建 Web 自動化測試框架并在 Web 應(yīng)用程序之上模擬用戶行為，不妨在項(xiàng)目當(dāng)中使用帶有 Java 與 Cucumber BDD 的 Selenium WebDriver——這將是您學(xué)習(xí)并實(shí)現(xiàn) Cucumber 測試功能的良好起點(diǎn)。
主要優(yōu)勢
行為驅(qū)動型開發(fā)（BDD） — 適用于 BDD 測試，而且已經(jīng)成為這一領(lǐng)域中的首選測試框架（相較于傳統(tǒng)測試驅(qū)動型開發(fā)）。
動態(tài)文件 —文檔記錄一直是項(xiàng)令人頭痛的工作，但在以代碼形式對測試內(nèi)容進(jìn)行定義之后，Cucumber 測試可以自動生成文件以匹配測試需求，并保證各項(xiàng)需求始終保持同步。
支持 —目前市面上有多種支持工具可供選擇，但對于規(guī)模較大的嚴(yán)肅項(xiàng)目來說，工具維護(hù)者的態(tài)度將決定方案的可靠性與可持續(xù)性。Cucumber 團(tuán)隊(duì)擁有充足的資金與支持架構(gòu)，足以在可預(yù)見的未來保持這款工具的健康發(fā)展。
與競爭對手的比較
這一領(lǐng)域中有著多種框架與面向特定技術(shù)場景的工具，但只有 Cucumber 最接近“普適性”解決方案的層次。
2020 年頭號端到端測試工具
進(jìn)行端到端測試時，我們需要重點(diǎn)關(guān)注以下兩個核心問題：
· 功能測試
· 負(fù)載測試
功能測試，顧名思義是要測試我們需要的一切是否按預(yù)期正常發(fā)生。在點(diǎn)擊 SPA 上的某些頁面、填寫不及格并單擊 Submit 時，數(shù)據(jù)將顯示在數(shù)據(jù)庫當(dāng)中，且屏幕顯示提交成功！
此外，我們還需要測試在同一場景下，數(shù)量為 x 的用戶發(fā)出的同時操作是否得到了正確處理。
如果缺少這兩種重要的測試類型，最終 CI/CD 管道運(yùn)行表現(xiàn)將出現(xiàn)巨大差異。
功能測試：SoapUI Pro

SoapUI 在 API 測試領(lǐng)域已經(jīng)擁有相當(dāng)豐富的積累，這主要受益于 SOAP Web 服務(wù)的默認(rèn)地位。雖然我們已經(jīng)不再構(gòu)建新的 SOAP 服務(wù)，但這款工具的名稱并未因此改變，且仍在向著用戶的實(shí)際需求不斷發(fā)展。SoapUI 為后端 Web 服務(wù)的自動化功能測試提供了一整套出色的構(gòu)建架構(gòu)，其中一切元素都能輕松與持續(xù)集成工具將結(jié)合，作為 CI/CD 管道中的組成部分協(xié)同運(yùn)行。
主要優(yōu)勢
廣泛的文檔資源 — 這款工具已經(jīng)存在了多年時間，因此大家可以在網(wǎng)上輕松找到用于指導(dǎo)負(fù)載測試配置的學(xué)習(xí)資源。
易用性—盡管目前市面上的 API 測試工具有很多，但 SoapUI 在單一服務(wù)中囊括了多種服務(wù)接口，從而讓測試構(gòu)建變得更加簡單。
與競爭對手的比較
Selenium — Selenium 是另一款重要的測試工具。如果您正在構(gòu)建并運(yùn)行基于 Java 語言的應(yīng)用程序，那么我們其實(shí)更推薦 Selenium。但是，如果您的訴求在于使用多種技術(shù)處理同一款完整的 Web 應(yīng)用程序，那么 Selenium 在非 Java 語言用戶手中顯得有些笨拙。
負(fù)載測試：LoadRunner

在對應(yīng)用程序中各個層面進(jìn)行負(fù)載測試時，LoadRunner 表現(xiàn)出了無可替代的全面優(yōu)勢。雖然 LoadRunner 價格較高且難于上手，但它卻是唯一能夠模擬出極端壓力環(huán)境、并真正讓技術(shù)架構(gòu)師們對新代碼建立起充分信心的測試工具。另外，我也覺得是時候?qū)⒇?fù)載運(yùn)行技巧從 SQA 資源轉(zhuǎn)移到開發(fā)團(tuán)隊(duì)當(dāng)中。
主要優(yōu)勢
廣泛的文檔資源 — 這款工具已經(jīng)存在了多年時間，因此大家可以輕松在網(wǎng)上找到用于指導(dǎo)負(fù)載測試配置的學(xué)習(xí)資源。
協(xié)議支持 — 從 ODBC 到 AJAX、再到 HTTPS 乃至應(yīng)用程序偶爾使用的其他晦澀協(xié)議，LoadRunner 總能提供良好的支持能力。相比之下，為了協(xié)議支持而同時使用多種負(fù)載測試工具只會增加整個流程的復(fù)雜性。
與競爭對手的比較
同樣的，在測試市場上并沒有百試百靈的工具，因此能夠不太費(fèi)心地引入當(dāng)前環(huán)境并直接使用的技術(shù)就算是好技術(shù)了。

小程序開發(fā)3. 部署工具

在應(yīng)用程序開發(fā)當(dāng)中，部署工具往往受到人們的嚴(yán)重忽視。但對運(yùn)營人員而言，如果不深入了解應(yīng)用程序的代碼與功能，將很難順利使用部署工具；在另一方面，開發(fā)人員則開始越來越多地承擔(dān)起代碼部署的職責(zé)，因此需要盡快積累原本匱乏的部署工具使用經(jīng)驗(yàn)。
首先，我們將部署工具分為三個子類：
· 構(gòu)件管理
· 配置管理
· 部署
2020 年頭號構(gòu)件管理工具：Nexus

Nexus 構(gòu)件存儲庫支持幾乎所有的主要技術(shù)，包括 Java、NPM 乃至 Docker 等等。我們可以使用這款工具來存儲所有的可部署構(gòu)件，通過拉近軟件包與構(gòu)建流程之間的距離，Nexus 提供的遠(yuǎn)程軟件包管理器代理功能極大提升了持續(xù)集成速度。這種作法的另一大優(yōu)勢，在于幫助用戶全局查看跨多個軟件項(xiàng)目使用的全部軟件包，從而鎖定不安全的開源軟件包，避免這些軟件包成為惡意人士攻擊代碼的載體。
主要優(yōu)勢
技術(shù)支持 — 自 2013 年投放市場以來，Nexus 一直擁有穩(wěn)定的表現(xiàn)并得到開發(fā)團(tuán)隊(duì)的良好支持。
開源 — Nexus 的免費(fèi)版并沒有削減開發(fā)團(tuán)隊(duì)所需要的各項(xiàng)核心功能。而不同付費(fèi)選項(xiàng)又進(jìn)一步提供更多附加功能，可根據(jù)組織的具體規(guī)模與需求帶來更大的價值。
2020 年頭號配置管理工具：Ansible

Ansible 是這一領(lǐng)域中絕對的王者，理由非常簡單：無狀態(tài)。早期配置管理工具著重于管理配置狀態(tài)，換句話說，如果當(dāng)前狀態(tài)與所需配置狀態(tài)不再同步，則需要進(jìn)行修復(fù)。但在新型應(yīng)用程序當(dāng)中，我們面對的是大量無狀態(tài)組件，新版本的代碼屬于新的構(gòu)件，并用于部署并替換現(xiàn)有構(gòu)件。整個業(yè)務(wù)流程將由眾多生命周期短暫的即席環(huán)境組成。
主要優(yōu)勢
無狀態(tài) — Ansible playbook 將由操作機(jī)器運(yùn)行，并直接命中服務(wù)器目標(biāo)。我們不在乎遠(yuǎn)程對象的狀態(tài)，這讓用戶得以輕松通過 Packer 等工具構(gòu)建出可部署對象。
開源 — 與 CentOS 類似，Ansible 同樣由紅帽公司負(fù)責(zé)維護(hù)。紅帽在業(yè)界擁有良好聲譽(yù)，其高級支持人員在維護(hù)社區(qū)方面擁有豐富經(jīng)驗(yàn)，并確保 Ansible 持續(xù)提供各類高質(zhì)量且易于使用的模塊。
分子測試—配置管理本身與正常編寫出的代碼無區(qū)別，因此如果不對其進(jìn)行測試，我們的測試目標(biāo)也將無從談起。用于測試 Ansible 角色的分子框架能夠無縫運(yùn)作，確保我們的測試配置能夠切實(shí)滿足代碼測試的需求，且同樣遵循應(yīng)用程序代碼使用的同一 CI/CD 管道。
YAML — 與其他工具相比，YAML 的入門門檻更低。對于大多數(shù)剛剛接觸 DevOps 的朋友來說，配置管理都是前所未見的新鮮體驗(yàn)，因此上手難度越低、就越容易被人們所接受。
與競爭對手的比較
OpsCode Chef — 其實(shí)我個人的 DevOps 職業(yè)生涯就是從 OpsCode Chef 起步的。Ruby 與 Chef 都是我的心頭好。但必須承認(rèn)，二者根本沒有應(yīng)對當(dāng)前無狀態(tài)云原生應(yīng)用程序問題的能力。當(dāng)然，對于較為傳統(tǒng)的遺留應(yīng)用程序來說，這仍是一款很好的工具；但就本文討論的應(yīng)用場景，我們還是更多著眼于未來。
Puppet — Puppet 一直缺少成規(guī)模的技術(shù)社區(qū)，因此在支持能力方面完全無法與 Chef 以及 Ansible 相提并論。Puppet 雖然非常適合配置與裸機(jī)使用場景，但卻無法支持 Web 應(yīng)用程序類型的配置管理需求。
2020 年頭號部署工具：Terraform

Terraform 解決了在網(wǎng)絡(luò)組件到實(shí)際服務(wù)器鏡像等各類場景當(dāng)中，如何定義基礎(chǔ)設(shè)施即代碼這個問題。自最初發(fā)布以來，Terraform 已經(jīng)經(jīng)歷了一段時間的發(fā)展，并建立起龐大的插件生態(tài)與支持社區(qū)，能夠?yàn)橛脩艨赡苡龅降膸缀跛胁渴饒鼍疤峁┝己脦椭erraform 擁有對本地、云端或其他類型運(yùn)行環(huán)境的強(qiáng)大支持能力。最后，其最新版本還在 HCL 當(dāng)中提供多種與其他傳統(tǒng)編程語言相同的邏輯函數(shù)與類，這進(jìn)一步降低了開發(fā)人員的上手與學(xué)習(xí)難度。
主要優(yōu)勢
云 / 環(huán)境中立性 — Terraform 能夠在 Terraform 代碼與基礎(chǔ)設(shè)施供應(yīng)方通信時所必需的 API 及后端邏輯之間充當(dāng)接口，這意味著只要學(xué)習(xí)這一款工具，就能隨處實(shí)現(xiàn)其部署功能。
開源 — 同樣的，相信沒人能對免費(fèi)的工具說不，更遑論 Terraform 還擁有良好的支持社區(qū)。
與競爭對手的比較
AWS CloudFormation — 即使大家僅在 AWS 環(huán)境中工作，也可以規(guī)劃自己的學(xué)習(xí)路線，而并不一定把所有希望都寄托在 AWS 服務(wù)家族身上。事實(shí)上，把所有技能與知識都放進(jìn)同一個籃子只會增加職業(yè)風(fēng)險。另外，AWS 的不少新服務(wù)在與 CloudFormation 正式對接之前，都會以 Terraform 模塊的形式存在一段時間。

小程序開發(fā)4. 運(yùn)行時 DevOps 工具

任何開發(fā)項(xiàng)目的最終目標(biāo)都是在生產(chǎn)環(huán)境中運(yùn)行應(yīng)用程序。在 DevOps 領(lǐng)域，我們當(dāng)然希望保證對環(huán)境中的一切潛在問題保持可見性，同時將人工干預(yù)程度降至最低水平。為此運(yùn)行時工具集的正確選擇就成為了良好開發(fā)流程必不可少的條件。
運(yùn)行時工具分為以下幾個子類：
· X 即服務(wù)
· 編排
· 監(jiān)控
· 日志記錄
2020 年頭號 X 即服務(wù)工具：AWS

亞馬遜一直是云計(jì)算領(lǐng)域的領(lǐng)導(dǎo)者，他們不斷為開發(fā)人員提供更多新的服務(wù)選項(xiàng)，保持整個體系的新陳代謝。如今，我們可以將幾乎一切技術(shù)及模式引入 AWS，進(jìn)而完成構(gòu)建與運(yùn)行工作。與在自有數(shù)據(jù)中心內(nèi)構(gòu)建、管理及維護(hù)傳統(tǒng)硬件相比，云服務(wù)模式的成本更為合理。免費(fèi)服務(wù)層讓每個人都有機(jī)會在實(shí)際購買之前先體驗(yàn)使用感受，并快速摸索出構(gòu)建應(yīng)用程序的正確途徑。更重要的，擺脫了自主采購的壓力，擺脫了以往因預(yù)算有限而被迫做出的種種妥協(xié)。
主要優(yōu)勢
行業(yè)標(biāo)準(zhǔn) — 如果大家曾經(jīng)在 AWS 當(dāng)中構(gòu)建過應(yīng)用程序，那么相關(guān)工作經(jīng)驗(yàn)足以支撐您在任何行業(yè)找到立足之地。
免費(fèi)層 — AWS 最突出的特色在于他們在業(yè)務(wù)層面從不犯錯。他們允許用戶試用服務(wù)并了解其工作原理，然后再決定是否投入資金來批量使用他們提供的解決方案。這種“先嘗后買”的形式非常科學(xué)，我自己就從來沒有貿(mào)然購買過未經(jīng)過概念驗(yàn)證的 AWS 產(chǎn)品。
與競爭對手的比較
Heroku — 簡而言之，除了個人項(xiàng)目之外，我永遠(yuǎn)不會把 Heroku 用在嚴(yán)肅的開發(fā)環(huán)境當(dāng)中。它的透明度實(shí)在有限，企業(yè)沒有理由選擇這樣一套平臺。除了博文當(dāng)中進(jìn)行簡單演示之外，我拒絕對 Heroku 進(jìn)行任何實(shí)際層面的應(yīng)用。不用，謝謝！
2020 年頭號編排工具：OpenShift

大家可能已經(jīng)在自己的應(yīng)用程序堆棧當(dāng)中使用了 Docker 或者容器技術(shù)。無服務(wù)器應(yīng)用程序很棒，但顯然不可能適合所有的架構(gòu)模式。例如，在沒有業(yè)務(wù)流程平臺的情況下，我們根本就沒辦法使用容器。而從案例性與工具豐富度的角度來看，Core Kubernetes 的限制因素也比較多。OpenShift 是目前唯一提供 Kubernetes 平臺的服務(wù)方案，其中包含 Source2Image 構(gòu)建、pod 內(nèi)自動化部署乃至可回溯性與監(jiān)控功能。更重要的是，它能夠在本地、云端乃至二者兼有的情況下運(yùn)行。
主要優(yōu)勢
內(nèi)置安全保障 — K8s 安全性很難管理，甚至可能需要具備相應(yīng)博士學(xué)位的技術(shù)人來管理。而在默認(rèn)情況下，OpenShift 所采用的安全機(jī)制能夠極大減少開發(fā)人員的工作量，并為他們的應(yīng)用程序提供更加安全的平臺。
多合一解決方案 — 與默認(rèn)不包含負(fù)載均衡工具的原始版 K8s 不同，OpenShift 提供所有必要功能。我可以使用它托管自己的容器、構(gòu)建容器、運(yùn)行 CI/CD 工具、協(xié)調(diào)外部流程、管理 secrets 等等。盡管目前的 GUI 還不夠完善，但 API 優(yōu)先的方法意味著所有內(nèi)容都能夠以腳本形式實(shí)現(xiàn)；而且與其他 K8s GUI 不同的是，OpenShift 使得 Kubernetes 的基礎(chǔ)知識學(xué)習(xí)過程變得更為簡單。不用博士學(xué)位了，大家歡呼起來！
與競爭對手的比較
Docker Swarm — Docker swarm 的本意是刪除大量內(nèi)容以簡化 K8s 體系。雖然它在體量較小的應(yīng)用程序中效果不錯，但對于企業(yè)級應(yīng)用程序則根本不起作用。此外，AWS ECS 等服務(wù)也提供類似的方法，且能夠切實(shí)降低與其他服務(wù)（Lambda、IAM 等）之間的交互難度。
2020 年頭號監(jiān)控工具：New Relic

New Relic 的早期發(fā)行版確實(shí)在 APM 監(jiān)控方面帶來了良好的表現(xiàn)。如今，它已經(jīng)發(fā)展成一套完善的監(jiān)控工具，允許用戶輕松監(jiān)控服務(wù)器性能、容器性能、數(shù)據(jù)庫性能、最終用戶體驗(yàn)以及 APM 等等。
主要優(yōu)勢
易于使用 — 作為曾經(jīng)的系統(tǒng)工程師，我使用過不少監(jiān)控工具，但沒有一款能夠在易用性方面與 New Relic 比肩。這是一項(xiàng) SaaS 服務(wù)，用戶無需設(shè)置任何服務(wù)器組件即可直接使用。
端到端可見性 — 其他工具往往只關(guān)注應(yīng)用程序中某個特定層面的監(jiān)控。但無論強(qiáng)調(diào) CPU 利用率還是網(wǎng)絡(luò)流量，這些元素都必須協(xié)同運(yùn)作才能讓應(yīng)用程序保持正常運(yùn)行。New Relic 則允許用戶將所有數(shù)據(jù)組合起來，了解應(yīng)用程序中真實(shí)發(fā)生的一切。
與競爭對手的比較
Zabbix— Zabbix 是我最早使用過、而且非常喜愛的一款監(jiān)控工具。但由于缺乏對云原生環(huán)境及 APM 方向的支持與發(fā)展規(guī)劃，目前它的水平已經(jīng)相對滯后。誠然，它仍能夠很好地監(jiān)控傳統(tǒng)服務(wù)器基礎(chǔ)設(shè)施，但也就僅此而已了。
DataDog — 這款工具過分側(cè)重于管理生產(chǎn)應(yīng)用程序的流程，而對代碼本身的關(guān)注度不足。在真正的 DevOps 團(tuán)隊(duì)當(dāng)中，開發(fā)人員也需要深度參與生產(chǎn)，因此我們并不需要這樣一套單純強(qiáng)調(diào)流程監(jiān)控的解決方案。
2020 年頭號日志記錄工具：Splunk

Splunk 同樣有著令人難以拒絕的魅力。長期以來，Splunk 一直是日志聚合領(lǐng)域的領(lǐng)導(dǎo)者，同時也在努力維持自己的統(tǒng)治地位。借助本地與 SaaS 產(chǎn)品版本，用戶已經(jīng)能夠隨時隨地享受由它帶來的便利。但 Splunk 也不是沒有缺點(diǎn)——它難以運(yùn)行的老毛病到現(xiàn)在也沒能根治。
主要優(yōu)勢
行業(yè)標(biāo)準(zhǔn)— 企業(yè)喜歡 Splunk，也擁有充足的財力使用這套解決方案。雖然初創(chuàng)企業(yè)往往難以證明 Splunk 的成本合理性，但其中的不少概念與功能已經(jīng)在開源替代方案中實(shí)現(xiàn)了。
支持效果— 簡單來說，Splunk 能用、而且效果不錯。其中提供多種默認(rèn)的設(shè)置與即用型功能，大家無需投入大量時間閱讀文檔或者反復(fù)試錯，即可讓 Splunk 發(fā)揮其應(yīng)有的作用。
與競爭對手的比較
ELK Stack — ElasticSearch、LogStash 以及 Kibana 似乎都挺酷的，畢竟它們不會向用戶收取任何費(fèi)用；但隨著日志集的增長與應(yīng)用程序數(shù)量的提升，我們越來越難以依靠內(nèi)置工具維護(hù)這些日志記錄方案。與 Splunk 相比，這類工具永遠(yuǎn)要耗去更多學(xué)習(xí)和上手的時間，之后才能構(gòu)建起正常可用的儀表板。

小程序開發(fā)5. 協(xié)作 DevOps 工具

DevOps 的第一步就是在組織內(nèi)部掀起一波文化變革。雖然外來工具不可能在一夜之間改變文化傳統(tǒng)，但卻能夠幫助我們培養(yǎng)起與同事協(xié)作的新方法。
協(xié)作工具分為以下幾個子類：
· 問題跟蹤
· ChatOps
· 文檔
2020 年頭號問題跟蹤工具：Jira

盡管這一領(lǐng)域的競爭變得日益激烈，但 Jira 仍然穩(wěn)坐頭把交椅。Jira 內(nèi)置的強(qiáng)大靈活性足以幫助開發(fā)團(tuán)隊(duì)與運(yùn)營團(tuán)隊(duì)輕松管理項(xiàng)目中的日常工作與沖刺任務(wù)。另外，內(nèi)置的標(biāo)準(zhǔn)敏捷術(shù)語也有助于企業(yè)逐步完成由傳統(tǒng)工作方法到精準(zhǔn)流程文化的轉(zhuǎn)變。
主要優(yōu)勢
行業(yè)標(biāo)準(zhǔn)—與之前提到的多種其他工具一樣，Jira 的應(yīng)用范圍極廣。小型團(tuán)隊(duì)可以使用價格低廉的許可并獲得必要功能，而大型企業(yè)也會在購買許可之后獲得物有所值的體驗(yàn)。
集成— 在這一領(lǐng)域處于領(lǐng)先地位并快速增長，意味著其他第三方工具也會優(yōu)先選擇 Jira 構(gòu)建本機(jī)集成，從而進(jìn)一步增加 Jira 的價值。我們可以從現(xiàn)成列表中挑選需要的集成工具選項(xiàng)，整個過程一氣呵成、完全無需任何特別定制。
與競爭對手的比較
Trello— 作為一款免費(fèi)使用的看板工具，Trello 同樣迅速積累起可觀的人氣。但隨著業(yè)務(wù)規(guī)模的擴(kuò)展，需要跟蹤的問題也由數(shù)十個增長至數(shù)千個，這時 Trello 難以導(dǎo)航、搜索與報告的短板就開始暴露出來。
Pivotal Tracker— 在初創(chuàng)企業(yè)工作期間，我其實(shí)非常喜歡這款工具。但它更多關(guān)注產(chǎn)品管理，而非技術(shù)任務(wù)。相比之下，Jira 的產(chǎn)品管理功能也比較難上手，但至少可用而且足以替代其他獨(dú)立的產(chǎn)品管理工具。
2020 年頭號CHatOps 工具：MatterMost

這可能是這份榜單中最讓我驚喜的上榜成員，MatterMost 繼承了以往優(yōu)秀工具的特性，同時引入本地部署支持以擴(kuò)大自身普及范圍。對于企業(yè)而言，這一點(diǎn)非常重要，因?yàn)樗粌H能夠控制數(shù)據(jù)、還可以幫助用戶與本地工具相集成——換言之，我們不必為了引入新功能而被迫跨出防火墻。
主要優(yōu)勢
開源— MatterMost 的開源版本非常適合小型或者大型團(tuán)隊(duì)。與 Slack 免費(fèi)版會丟失歷史記錄的情況不同，MatterMost 允許用戶運(yùn)行自有服務(wù)器，因此所有數(shù)據(jù)也都將保存在本地位置。
集成— MatterMost 的 API 幾乎 100% 基于 Slack API，因此 Slack 生態(tài)中的幾乎所有集成都能夠無縫對接 MatterMost。
與競爭對手的比較
Slack— Slack 很棒，但項(xiàng)目的體量已經(jīng)過于龐大，需要認(rèn)真考慮盈利問題。可以預(yù)見，Slack 將很快推出全面付費(fèi)政策，并在免費(fèi)版本當(dāng)中閹割掉大量極具價值的功能——最重要的當(dāng)然是保存聊天記錄功能。
Microsoft Teams— 大家可以嘗試把微軟產(chǎn)品與非微軟本地產(chǎn)品集成一下——祝各位好運(yùn)！我要說的就這么多。
2020 年頭號文檔工具：Confluence

無論使用哪種工具，我們都很難創(chuàng)建并維護(hù)高質(zhì)量的技術(shù)文檔。盡管最近市面上出現(xiàn)了不少 SaaS 文檔工具，但我還是很難接受把關(guān)于關(guān)鍵應(yīng)用程序核心技術(shù)的敏感文檔存儲在第三方平臺當(dāng)中。沒錯，我還是想把數(shù)據(jù)和文檔保存在本地，而 Conluence 正好解決了我的這個痛點(diǎn)。
主要優(yōu)勢
易于管理—大多數(shù)自托管工具在啟動與運(yùn)行階段都具有一定的復(fù)雜性，而且在規(guī)模化維護(hù)場景下會對專業(yè)技能提出要求。Conluence 服務(wù)器在這方面表現(xiàn)不錯，能夠以開箱即用的方式支持 10 到 10000 名用戶。
插件— Confluence 默認(rèn)創(chuàng)建出的美觀、易于瀏覽、可導(dǎo)航文檔已經(jīng)足以令人滿意，而豐富多彩的插件選項(xiàng)更是將 Wiki 的潛力發(fā)揮到了極致。
與競爭對手的比較
Read the docs— 很棒的開源項(xiàng)目，但我完全不會考慮在這里存儲與關(guān)鍵應(yīng)用程序相關(guān)的敏感信息。
MarkDown— 這款工具特別適合記錄與代碼相關(guān)的內(nèi)容，但我們很難將架構(gòu)、過程或者其他類型的文檔直接保存為 MarkDown 格式。
Jekyll— 在記錄技術(shù)信息時，我并不想簡單構(gòu)建一個靜態(tài)站點(diǎn)并在每次更新時調(diào)整其中的內(nèi)容。Confluence 提供簡單易用的版本管理系統(tǒng)，極大降低了內(nèi)部文檔的管理難度。

小程序開發(fā)6. 2020 年最佳 DevOps 工具總結(jié)

時至今日，市場上提供多達(dá)數(shù)百種 DevOps 工具，剛剛接觸的朋友可能難以弄清它們到底是干嘛用的、在特定場景下具體該如何選擇。希望今天這份簡單的指南，能夠幫助大家明確自己的 DevOps 工具堆棧需求，并快速建立起完整的 CI/CD 管道。
最后讓我們以一句共勉作結(jié)：能自動化，就自動化！

以上文章由北京艾銻無限科技發(fā)展有限公司整理

分享到:

上一篇：辦公設(shè)備：VGA線的顯示系統(tǒng)

下一篇：地攤熱新思考：互聯(lián)網(wǎng)思維還有用嗎？-網(wǎng)絡(luò)運(yùn)維

相關(guān)文章