使用開源工具構建 DevOps Pipeline 的初學者指南
DevOps 生態需要考慮各種需求,例如持續整合方案、源控制管理、自動化構建、伺服器選擇、測試覆蓋率等。本文通過 5 個關鍵步驟,向 DevOps 初學者介紹如何通過流行的開源工具來解決這些需求。
DevOps 在修復緩慢、孤立或其他功能失調方面已成為軟體開發過程的首選方案。如果剛接觸 DevOps 並且不確定從哪裡開始,可以參考本文 DevOps Pipeline 的內容,以及建立一個 Pipeline 的五個步驟。
DevOps 之旅
我曾經在花旗集團的雲團隊工作,開發基礎架構即服務(IaaS)Web 應用程式來管理花旗的雲基礎架構,但總想找到方法來提高開發流程效率,併為開發團隊帶來積極的文化變革。我在 Greg Lavender 推薦的一本書中找到了答案,他是花旗雲架構和基礎設施工程的首席技術官,書名叫 The Phoenix Project ,它像一本小說一樣闡釋了 DevOps 的原則。
下面的表格顯示了不同公司部署到釋出環境的頻率:
Amazon、Google 和 Netflix 的頻率是如何做到的?這是因為這些公司已經找到了製作一個近乎完美的 DevOps Pipeline 的方法。
花旗在實施 DevOps 之前,情況並非如此良好。那時候,團隊有不同的階段性環境,但是開發伺服器的部署是非常手動的。所有開發人員只能訪問基於 IBM WebSphere Application Server Community Edition 的一個開發伺服器。問題是,當試圖為多個使用者同時進行部署時,伺服器就會崩潰,因此開發人員不得不在即將進行部署時讓對方知道,這點讓人非常痛苦。此外,還存在程式碼測試覆蓋率低、手動部署過程繁瑣,以及無法繫結已定義的任務或使用者故事來跟蹤程式碼部署的問題。
我意識到必須要做一些改變,並找到了志同道合的同事。我們決定合作構建一個初始 DevOps 管道 - 他在 Jenkins 工作期間設定了虛擬機器和 Tomcat 應用伺服器,與 Atlassian Jira 和 BitBucket 整合等。之後,該專案取得了巨大成功:幾乎完全自動化了開發流程,在開發伺服器上實現了近 100%的正常執行時間,可以跟蹤和改進程式碼測試覆蓋率,Git 分支可以與部署和 Jira 任務相關聯。並且,用於構建 DevOps 管道的大多數工具都是開源的。我現在意識到,DevOps 管道還存在不足,因為沒有利用類似 Jenkins 檔案或 Ansible 這樣的高階配置。然而,這個簡單的過程運作良好,可能是由於 帕累託 原則(也稱為 80/20 規則)。
DevOps 和 CI/CD Pipeline 簡要介紹
如果隨便問幾個人,“什麼是 DevOps?”,可能會得到幾個不同的答案。與敏捷開發一樣,DevOps 已經發展到包含許多不同學科,但是大多數人會認可:DevOps 是一個軟體開發實踐或者軟體開發生命週期(SDLC),核心原則是一種文化變革,開發人員和非開發人員都在一個原本是手動操作、現在是自動化的環境中工作,每個人都做最擅長的事情,每個時期的部署數量都在增加,吞吐量也在增加,靈活性則逐漸提高。
雖然合適的軟體工具並不是實現 DevOps 環境所需的唯一辦法,但有些工具是必需的。關鍵是持續整合和持續部署(CI/CD)。Pipeline 構建了一個環境,具有不同的階段(例如,DEV,INT,TST,QA,UAT,STG,PROD),手工部分被自動化,開發人員可以實現高質量、高靈活性的程式碼,並允許大量部署。
本文介紹了使用開源工具建立 DevOps Pipeline 的五步方法,如下圖所示:
第 1 步:CI/CD 框架
第一件事是找一款 CI/CD 工具。Jenkins 是一個基於 Java 開源的、基於 MIT 許可證的 CI/CD 工具,已成為 DevOps 的標準。
Jenkins 是什麼?想象一種神奇的通用遙控器,Jenkins 可以與許多不同的服務和工具互動協調。類似 Jenkins 這樣的 CI/CD 工具本身沒多大用,但隨著插入不同的工具和服務,將變得越來越強大。
Jenkins 只是眾多開源 CI/CD 工具中的一種,可以利用它來構建 DevOps Pipeline。
以下是使用 CI/CD 工具的 DevOps 流程:
現在本地主機中運行了 CI/CD 工具,可以開始 DevOps 之旅的下一步。
第 2 步:源控制管理
驗證 CI/CD 工具是如何運作最佳(也可能是最簡單)方法是與源控制管理(SCM)工具整合。為什麼需要原始碼管理?假設正在開發一個應用程式,無論何時要構建應用程式,都需要程式設計,無論是 Java、Python、C ++、Go、Ruby、JavaScript 還是其他任何一種程式語言,所編寫的程式設計程式碼稱為原始碼。
一開始,尤其是獨自工作時,開發者將所有內容放在本地目錄可能是可以的。但是,當專案變得更大並且需要邀請其他人協作時,需要一種方法來避免合併衝突,同時有效共享程式碼修改,還需要一種方法來恢復以前的版本,備份、複製和貼上就顯得比較落伍,開發者可能需要更好的東西。
這就是 SCM 幾乎成為必需品的原因,SCM 工具通過將程式碼儲存在儲存庫中,對程式碼進行版本控制,在專案成員之間進行協調來提供幫助。
實際上,有很多 SCM 工具,Git 是一個標準。強烈建議使用 Git,但如果願意,還有其他開源可選:
以下是新增 SCM 後 DevOps 管道的樣子:
CI/CD 工具可以自動執行原始碼遷入和遷出,執行跨成員協作任務。但是,如何將其變成一個有效的應用程式,以便數十億人可以使用和欣賞呢?
第 3 步:自動化構建工具
開發者可以檢視程式碼並將更改提交到原始碼管理,然後邀請朋友進行原始碼管理開發和協作。如果到目前還沒有構建應用程式,要使其成為一款 Web 應用程式,必須進行編譯並放入可部署的包或作為可執行檔案執行。(請注意,像 JavaScript 或 PHP 這樣的解釋型語言不需要編譯)
現在來看看自動化構建工具。無論決定使用哪種構建工具,都有一個共同目標:將原始碼構建為某種所需格式,並自動執行任務來清理、編譯、測試並部署到特定位置。構建工具將根據程式語言而有所不同,這裡有一些常見的開源選項可以考慮:
現在,可以將自動化構建工具的配置檔案放入原始碼管理,然後讓 CI/CD 工具構建它:
一切都很好,對吧?但是,在哪裡進行部署呢?
第 4 步:Web 應用程式伺服器
到目前為止,開發者有一個可執行或可部署打包檔案。對於任何真正有用的應用程式,必須提供某種服務或介面,但還需要一個容器來託管應用程式。
對於 web 應用程式,web 伺服器就是這類容器。應用程式伺服器提供了這樣一個環境,可以檢測可部署包內的程式設計邏輯、公開介面,通過 socket 向外部提供 web 服務。HTTP 伺服器以及其他一些環境(如虛擬機器)可以用來安裝應用程式伺服器。
有許多可用的開源 web 應用程式伺服器:
現在,DevOps Pipeline 基本可以使用:
雖然可以就此進行下一步整合,但程式碼質量對於應用程式開發人員來說是一件很重要的事情。
第 5 步:程式碼測試覆蓋率
另一個繁瑣的要求可能是實現程式碼測試,開發人員需要儘早捕獲應用程式中的任何錯誤,提高程式碼質量以確保終端使用者滿意。幸運的是,有許多開源工具可用於測試程式碼並提出改進其質量的方法。更好的訊息是,大多數 CI/CD 工具可以插入這些工具並將這個過程自動化。
程式碼測試分為兩部分:協助編寫、執行測試的程式碼測試框架,以及有助於提高程式碼質量的程式碼質量建議工具。
程式碼測試框架:
程式碼質量建議工具:
請注意,上面提到的大多數工具和框架都是針對 Java、Python 和 JavaScript 編寫的,因為 C ++ 和 C# 是專有程式語言(儘管 GCC 是開源的)。
現在已經實現了程式碼測試覆蓋工具,DevOps Pipeline 應該類似於本教程開頭所示的 DevOps Pipeline 圖。
可選的步驟
容器
如上所述,可以在虛擬機器或伺服器上託管應用程式伺服器,但容器是一種流行的解決方案。
什麼是容器 ?簡短的解釋就是 VM 自身需要佔用作業系統的巨大空間,這會佔用應用程式的大小,而容器只需要一些庫和配置就可以執行應用程式。顯然 VM 仍有重要的用途,但容器是託管應用程式(包括應用程式伺服器)的輕量級解決方案。
雖然有多種容器可選擇,但 Docker 和 Kubernetes 是最受歡迎的:
中介軟體自動化工具
DevOps Pipeline 主要側重於協作構建和部署應用程式,還可以使用 DevOps 工具執行許多其他操作。其中之一是利用 Infrastructure as Code(IaC)工具,也稱為中介軟體自動化工具。這些工具有助於自動化中介軟體軟體的安裝、管理和其他任務。例如,自動化工具可以通過正確的配置提取應用程式(如 Web 應用程式伺服器、資料庫和監視工具),並將它們部署到應用程式伺服器。
以下是幾個可以考慮的開源中介軟體自動化工具:
原文連結: A beginner’s guide to building DevOps pipelines with open source tools