如果你是 DevOps 新人,請檢視這 5 個步驟來構建你的第一個 DevOps 流水線。
DevOps 已經成為解決軟體開發過程中出現的緩慢、孤立或者其他故障的預設方式。但是當你剛接觸 DevOps 並且不確定從哪開始時,就意義不大了。本文探索了什麼是 DevOps 流水線並且提供了建立它的 5 個步驟。儘管這個教學並不全面,但可以給你以後上手和擴充套件打下基礎。首先,插入一個小故事。
我曾經在花旗集團的雲小組工作,開發基礎設施即服務網頁應用來管理花旗的雲基礎設施,但我經常對研究如何讓開發流水線更加高效以及如何帶給團隊積極的文化感興趣。我在 Greg Lavender 推薦的書中找到了答案。Greg Lavender 是花旗的雲架構和基礎設施工程(即 Phoenix 專案)的 CTO。這本書儘管解釋的是 DevOps 原理,但它讀起來像一本小說。
書後面的一張表展示了不同公司部署在發布環境上的頻率:
公司 | 部署頻率 |
---|---|
Amazon | 23,000 次/天 |
5,500 次/天 | |
Netflix | 500 次/天 |
1 次/天 | |
3 次/周 | |
典型企業 | 1 次/9 個月 |
Amazon、Google、Netflix 怎麼能做到如此之頻繁?那是因為這些公司弄清楚了如何去實現一個近乎完美的 DevOps 流水線。
但在花旗實施 DevOps 之前,情況並非如此。那時候,我的團隊擁有不同構建階段的環境,但是在開發伺服器上的部署非常手工。所有的開發人員都只能存取一個基於 IBM WebSphere Application 社群版的開發環境伺服器。問題是當多個使用者同時嘗試部署時,伺服器就會宕機,因此開發人員在部署時就得互相通知,這一點相當痛苦。此外,還存在程式碼測試覆蓋率低、手動部署過程繁瑣以及無法根據定義的任務或使用者需求跟蹤程式碼部署的問題。
我意識到必須做些事情,同時也找到了一個有同樣感受的同事。我們決定合作去構建一個初始的 DevOps 流水線 —— 他設定了一個虛擬機器和一個 Tomcat 伺服器,而我則架設了 Jenkins,整合了 Atlassian Jira、BitBucket 和程式碼覆蓋率測試。這個業餘專案非常成功:我們近乎全自動化了開發流水線,並在開發伺服器上實現了幾乎 100% 的正常執行,我們可以追蹤並改進程式碼覆蓋率測試,並且 Git 分支能夠與部署任務和 jira 任務關聯在一起。此外,大多數用來構建 DevOps 所使用的工具都是開源的。
現在我意識到了我們的 DevOps 流水線是多麼的原始,因為我們沒有利用像 Jenkins 檔案或 Ansible 這樣的高階設定。然而,這個簡單的過程運作良好,這也許是因為 Pareto 原則(也被稱作 80/20 法則)。
如果你問一些人,“什麼是 DevOps?”,你或許會得到一些不同的回答。DevOps,就像敏捷,已經發展到涵蓋著諸多不同的學科,但大多數人至少會同意這些:DevOps 是一個軟體開發實踐或一個軟體開發生命週期(SDLC),並且它的核心原則是一種文化上的變革 —— 開發人員與非開發人員呼吸著同一片天空的氣息,之前手工的事情變得自動化;每個人做著自己擅長的事;同一時間的部署變得更加頻繁;吞吐量提升;靈活度增加。
雖然擁有正確的軟體工具並非實現 DevOps 環境所需的唯一東西,但一些工具卻是必要的。最關鍵的一個便是持續整合和持續部署(CI/CD)。在流水線環境中,擁有不同的構建階段(例如:DEV、INT、TST、QA、UAT、STG、PROD),手動的工作能實現自動化,開發人員可以實現高品質的程式碼,靈活而且大量部署。
這篇文章描述了一個構建 DevOps 流水線的五步方法,就像下圖所展示的那樣,使用開源的工具實現。
閒話少說,讓我們開始吧。
首先你需要的是一個 CI/CD 工具,Jenkins,是一個基於 Java 的 MIT 許可下的開源 CI/CD 工具,它是推廣 DevOps 運動的工具,並已成為了事實標準。
所以,什麼是 Jenkins?想象它是一種神奇的萬能遙控,能夠和許多不同的伺服器和工具打交道,並且能夠將它們統一安排起來。就本身而言,像 Jenkins 這樣的 CI/CD 工具本身是沒有用的,但隨著接入不同的工具與伺服器時會變得非常強大。
Jenkins 僅是眾多構建 DevOps 流水線的開源 CI/CD 工具之一。
名稱 | 許可證 |
---|---|
Jenkins | Creative Commons 和 MIT |
Travis CI | MIT |
CruiseControl | BSD |
Buildbot | GPL |
Apache Gump | Apache 2.0 |
Cabie | GNU |
下面就是使用 CI/CD 工具時 DevOps 看起來的樣子。
你的 CI/CD 工具在本地主機上執行,但目前你還不能夠做些別的。讓我們緊隨 DevOps 之旅的腳步。
驗證 CI/CD 工具可以執行某些魔術的最佳(也可能是最簡單)方法是與原始碼控制管理(SCM)工具整合。為什麼需要原始碼控制?假設你在開發一個應用。無論你什麼時候構建應用,無論你使用的是 Java、Python、C++、Go、Ruby、JavaScript 或任意一種語言,你都在程式設計。你所編寫的程式程式碼稱為原始碼。在一開始,特別是只有你一個人工作時,將所有的東西放進本地資料夾裡或許都是可以的。但是當專案變得龐大並且邀請其他人共同作業後,你就需要一種方式來避免共用程式碼修改時的合併衝突。你也需要一種方式來恢復一個之前的版本——備份、複製並貼上的方式已經過時了。你(和你的團隊)想要更好的解決方式。
這就是 SCM 變得不可或缺的原因。SCM 工具通過在倉庫中儲存程式碼來幫助進行版本控制與多人共同作業。
儘管這裡有許多 SCM 工具,但 Git 是最標準恰當的。我極力推薦使用 Git,但如果你喜歡這裡仍有其他的開源工具。
名稱 | 許可證 |
---|---|
Git | GPLv2 & LGPL v2.1 |
Subversion | Apache 2.0 |
Concurrent Versions System (CVS) | GNU |
Vesta | LGPL |
Mercurial | GNU GPL v2+ |
擁有 SCM 之後,DevOps 流水線看起來就像這樣。
CI/CD 工具能夠自動化進行原始碼檢入檢出以及完成成員之間的共同作業。還不錯吧?但是,如何才能把它變成可工作的應用程式,使得數十億人來使用並欣賞它呢?
真棒!現在你可以檢出程式碼並將修改提交到原始碼控制,並且可以邀請你的朋友就原始碼控制進行共同作業。但是到目前為止你還沒有構建出應用。要想讓它成為一個網頁應用,必須將其編譯並打包成可部署的包或可執行程式(注意,像 JavaScript 或 PHP 這樣的解釋型程式語言不需要進行編譯)。
於是就引出了自動化構建工具。無論你決定使用哪一款構建工具,它們都有一個共同的目標:將原始碼構建成某種想要的格式,並且將清理、編譯、測試、部署到某個位置這些任務自動化。構建工具會根據你的程式語言而有不同,但這裡有一些通常使用的開源工具值得考慮。
名稱 | 許可證 | 程式語言 |
---|---|---|
Maven | Apache 2.0 | Java |
Ant | Apache 2.0 | Java |
Gradle | Apache 2.0 | Java |
Bazel | Apache 2.0 | Java |
Make | GNU | N/A |
Grunt | MIT | JavaScript |
Gulp | MIT | JavaScript |
Buildr | Apache | Ruby |
Rake | MIT | Ruby |
A-A-P | GNU | Python |
SCons | MIT | Python |
BitBake | GPLv2 | Python |
Cake | MIT | C# |
ASDF | Expat (MIT) | LISP |
Cabal | BSD | Haskell |
太棒了!現在你可以將自動化構建工具的組態檔放進原始碼控制管理系統中,並讓你的 CI/CD 工具構建它。
一切都如此美好,對吧?但是在哪裡部署它呢?
到目前為止,你有了一個可執行或可部署的打包檔案。對任何真正有用的應用程式來說,它必須提供某種服務或者介面,所以你需要一個容器來發布你的應用。
對於網頁應用,網頁應用伺服器就是容器。應用程式伺服器提供了環境,讓可部署包中的程式設計邏輯能夠被檢測到、呈現介面,並通過開啟通訊端為外部世界提供網頁服務。在其他環境下你也需要一個 HTTP 伺服器(比如虛擬機器)來安裝服務應用。現在,我假設你將會自己學習這些東西(儘管我會在下面討論容器)。
這裡有許多開源的網頁應用伺服器。
名稱 | 協定 | 程式語言 |
---|---|---|
Tomcat | Apache 2.0 | Java |
Jetty | Apache 2.0 | Java |
WildFly | GNU Lesser Public | Java |
GlassFish | CDDL & GNU Less Public | Java |
Django | 3-Clause BSD | Python |
Tornado | Apache 2.0 | Python |
Gunicorn | MIT | Python |
Python Paste | MIT | Python |
Rails | MIT | Ruby |
Node.js | MIT | Javascript |
現在 DevOps 流水線差不多能用了,幹得好!
儘管你可以在這裡停下來並進行進一步的整合,但是程式碼品質對於應用開發者來說是一件非常重要的事情。
實現程式碼測試件可能是另一個麻煩的需求,但是開發者需要儘早地捕捉程式中的所有錯誤並提升程式碼品質來保證終端使用者滿意度。幸運的是,這裡有許多開源工具來測試你的程式碼並提出改善品質的建議。甚至更好的,大部分 CI/CD 工具能夠整合這些工具並將測試過程自動化進行。
程式碼測試分為兩個部分:“程式碼測試框架”幫助進行編寫與執行測試,“程式碼品質改進工具”幫助提升程式碼的品質。
名稱 | 許可證 | 程式語言 |
---|---|---|
JUnit | Eclipse Public License | Java |
EasyMock | Apache | Java |
Mockito | MIT | Java |
PowerMock | Apache 2.0 | Java |
Pytest | MIT | Python |
Hypothesis | Mozilla | Python |
Tox | MIT | Python |
名稱 | 許可證 | 程式語言 |
---|---|---|
Cobertura | GNU | Java |
CodeCover | Eclipse Public (EPL) | Java |
Coverage.py | Apache 2.0 | Python |
Emma | Common Public License | Java |
JaCoCo | Eclipse Public License | Java |
Hypothesis | Mozilla | Python |
Tox | MIT | Python |
Jasmine | MIT | JavaScript |
Karma | MIT | JavaScript |
Mocha | MIT | JavaScript |
Jest | MIT | JavaScript |
注意,之前提到的大多數工具和框架都是為 Java、Python、JavaScript 寫的,因為 C++ 和 C# 是專有程式語言(儘管 GCC 是開源的)。
現在你已經運用了程式碼覆蓋測試工具,你的 DevOps 流水線應該就像教學開始那幅圖中展示的那樣了。
正如我之前所說,你可以在虛擬機器(VM)或伺服器上發布你的應用,但是容器是一個更好的解決方法。
什麼是容器?簡要的介紹就是 VM 需要佔用作業系統大量的資源,它提升了應用程式的大小,而容器僅僅需要一些庫和設定來執行應用程式。顯然,VM 仍有重要的用途,但容器對於發布應用(包括應用程式伺服器)來說是一個更為輕量的解決方式。
儘管對於容器來說也有其他的選擇,但是 Docker 和 Kubernetes 更為廣泛。
名稱 | 許可證 |
---|---|
Docker | Apache 2.0 |
Kubernetes | Apache 2.0 |
了解更多資訊,請檢視 Opensource.com 上關於 Docker 和 Kubernetes 的其它文章:
我們的 DevOps 流水線大部分集中在共同作業構建與部署應用上,但你也可以用 DevOps 工具完成許多其他的事情。其中之一便是利用它實現基礎設施管理(IaC)工具,這也是熟知的中介軟體自動化工具。這些工具幫助完成中介軟體的自動化安裝、管理和其他任務。例如,自動化工具可以用正確的設定下拉應用程式,例如網頁伺服器、資料庫和監控工具,並且部署它們到應用伺服器上。
這裡有幾個開源的中介軟體自動化工具值得考慮:
名稱 | 許可證 |
---|---|
Ansible | GNU Public |
SaltStack | Apache 2.0 |
Chef | Apache 2.0 |
Puppet | Apache or GPL |
獲取更多中介軟體自動化工具,檢視 Opensource.com 上的其它文章:
這只是一個完整 DevOps 流水線的冰山一角。從 CI/CD 工具開始並且探索其他可以自動化的東西來使你的團隊更加輕鬆的工作。並且,尋找開源通訊工具可以幫助你的團隊一起工作的更好。
發現更多見解,這裡有一些非常棒的文章來介紹 DevOps :
使用開源 agile 工具來整合 DevOps 也是一個很好的主意: