文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载本篇是 90DaysOfDevOps 2022 學習挑戰第 3 天的核心內容以「應用程式視角」縱覽 DevOps 生命週期從一無所有的應用構想出發歷經開發、測試、整合、部署到監控再循環回起點。讀完本文你將能完整描述一條應用程式在 DevOps 世界中的旅程理解每個階段的工具與職責邊界並知道 Git 版本控制、CI/CD 自動化、組態管理、Kubernetes 與監控工具分別落在生命週期的哪個位置為後續 87 天的學習建立全景地圖。在接下來的幾週裡你 100% 會一再遇到這些關鍵詞Continuous Development持續開發、Testing測試、Deployment部署、Monitor監控。若你正朝 DevOps 角色邁進會逐漸習慣「重複性」——同一套流程反覆執行——但真正讓工作保持有趣的是每一次循環都在持續增強。本章先以高視角看待應用程式「從起點到終點、再繞回起點」的完整旅程如同一條永不停歇的迴圈就像上圖的無限符號所呈現的那樣。開發階段Development從需求到第一行程式碼想像一個全新的應用程式專案此刻什麼都還沒建立。作為開發者首先需要與客戶或最終使用者討論需求整理出一份計畫或需求清單然後根據這些需求著手建立全新的應用程式。這個階段的工具需求其實很低只需選擇你的 IDE整合開發環境與撰寫應用程式所用的程式語言即可。作為 DevOps 工程師請記得你通常不是負責撰寫需求計畫或替最終使用者寫程式的那個人那是專業開發者的職責。但對你來說具備閱讀部分程式碼的能力仍然很有價值——唯有讀得懂應用程式在做什麼未來才能為它做出最佳的基礎設施決策。版本控制開發階段不可妥協的基石應用程式可以用任何語言撰寫但有一件事至關重要它必須透過版本控制系統Version Control System來維護。在 Day 35「概述Git - 版本控制」 中作者深入介紹了為什麼需要版本控制版本控制最明顯且重要的功能是追蹤專案的歷史——可用git log指令回顧儲存庫repository內過去的提交紀錄與註解知道發生什麼事、何時發生、又是誰審稿。它讓你能對同一個專案同時管理多個版本例如免費版與付費版透過**分支Branching與合併Merging**處理不同程式碼分流。請注意作者特別強調版本控制不是備份兩者目的完全不同。多數專案不會只有一位開發者即使只有一個人最佳實務也要求使用程式碼儲存庫來存放與協作程式碼。這個儲存庫可以是私有或公開、可託管或自行部署一般來說你會聽到GitHub 或 GitLab作為程式碼儲存庫這些同樣會在 Day 35 起的 Git 章節中詳細探討。這份 90DaysOfDevOps 儲存庫本身就是「用版本控制協作專案」的最好例子——你可以查看根目錄的 README.md了解整個挑戰的 90 天學習地圖是如何被多人協作維護的。測試階段Testing在多種環境中驗證程式碼有了需求與正在開發的應用程式之後接下來必須確保程式碼能在我們可用的各種不同環境中通過測試——或至少針對所選程式語言所對應的環境進行驗證。這個階段讓 QA品質保證人員能夠找出 bug。越來越常見的做法是使用容器Container來模擬測試環境這在整體上能改善實體或雲端基礎設施的成本負擔。測試階段也很可能在下一個環節——持續整合Continuous Integration——中被自動化。自動化測試的價值不言而喻與讓 10 位、100 位甚至 1000 位 QA 工程師手動測試相比自動化能讓這些工程師把精力轉移到堆疊中的其他部分確保團隊移動得更快、開發更多功能而不是被困在測試 bug 與軟體上——後者正是傳統瀑布式Waterfall軟體發布流程最主要的瓶頸。從倉庫的 Day 70「The Big Picture: CI/CD Pipelines」 可以看到自動化測試有三種典型型別單元測試Unit testing測試原始碼的各個獨立單元。驗證測試Validation testing確保軟體符合或適用於其預期用途。格式測試Format testing檢查語法與其他格式錯誤。這些測試會被建立成一個工作流程並在每次推送程式碼時執行——幾乎每個大型開發團隊都擁有某種 CI/CD 工作流程因為新程式碼可能來自世界各地、不同時區、不同專案的開發者透過自動化測試工作流程確保程式碼在被接受前所有人都站在同一頁上這遠比每次由人類逐一檢查來得高效。整合階段Integration生命週期的中樞整合位在 DevOps 生命週期的中間位置相當重要。它是一種實務要求開發者更頻繁地提交變更到原始碼——可能是每天或每週。每一次 commit應用程式都可以走過自動化測試階段這讓問題或 bug 能在進入下一個階段之前被及早發現。換句話說整合階段是把「開發→測試」串成自動化迴圈的樞紐也是讓「持續整合」得以成立的關鍵。關於外購軟體Off-the-Shelf的一點提醒你也許會說「可是我們不開發應用程式我們是從軟體供應商買現成的。」別擔心很多公司都是這樣做、未來也會繼續這樣做——在這種情況下上述開發、測試、整合三個階段會由軟體供應商負責。但你仍然應該採用接下來的部署階段因為它能讓你的外購軟體部署更快、更有效率。作者也建議光是具備上述知識本身就非常重要——你今天也許買現成的軟體但明天呢未來呢或下一份工作呢部署階段Deployment把程式碼送上生產環境好現在我們的應用程式已經依照最終使用者需求建置並測試完畢接下來需要將它部署到生產環境讓最終使用者消費。這是程式碼被部署到生產伺服器的階段也是整個流程開始「變得極度有趣」的地方——後續 86 天將深入探索這些領域。因為不同應用程式可能需要不同的硬體或組態此時應用程式組態管理Application Configuration Management與基礎架構即程式碼Infrastructure as CodeIaC可能在你的 DevOps 生命週期中扮演關鍵角色。你的應用程式可能是**容器化Containerised**的同時也能在虛擬機器上執行這接著把我們導向Kubernetes這類平台——它負責編排那些容器確保最終使用者能取得你想要的目標狀態desired state。這些粗體主題都會在接下來的幾週深入探討建立「它們是什麼、何時該用」的基礎知識。部署階段的兩大支柱基礎架構即程式碼IaC從 Day 56 起的 IaC 章節 開始探討如何用程式碼描述與建立基礎設施。而 Day 63「The Big Picture: Configuration Management」 進一步說明組態管理與 IaC 的重疊IaC 確保基礎設施處於目標狀態但 Terraform 這類工具不會負責作業系統設定或應用程式層級的目標狀態——這正是組態管理工具的用武之地確保系統與應用程式在變更發生時仍能如預期運作。該篇也給出了 Ansible 與 Terraform 的關鍵對照表AnsibleTerraform型別組態管理工具編排orchestration工具基礎設施支援可變基礎設施支援不可變基礎設施語言程序式procedural語言宣告式declarative語言佈建部分佈建VM、網路、儲存廣泛佈建VM、網路、儲存封裝完整支援封裝與模板化部分支援封裝與模板化生命週期管理無生命週期管理高度依賴生命週期與狀態管理容器編排KubernetesDay 49「The Big Picture: Kubernetes」 指出單靠容器在擴展與編排上有所不足Kubernetes 作為容器編排器能依應用程式負載自動或手動地擴展、縮減。它提供服務發現與負載平衡、儲存編排、自動化發布與回滾、自動放置bin packing、自我修復self-healing以及祕密與組態管理——本質上就是以「宣告式組態 自動化」持續把實際狀態推向你的目標狀態。監控階段Monitoring確保使用者體驗與回饋循環事情進展很快我們有持續加入新功能與新特性的應用程式有確保「沒有小惡魔gremlins溜進來」的測試應用程式也正運行在能持續維持所需組態與效能的環境中。但現在我們必須確認最終使用者是否得到了他們所要求的體驗。在這裡我們要確保應用程式效能Application Performance被持續監控——這個階段能讓開發者在未來版本中針對應用程式的增強做出更明智的決策以更好地服務最終使用者。回饋循環與可靠性監控也是捕捉「回饋之輪」的地方關於已實作的功能最終使用者希望如何讓它們變得更好。可靠性Reliability在這裡是關鍵因素——歸根究柢我們希望應用程式在需要它的所有時刻都保持可用。這接著延伸到其他可觀測性observability、安全性security與資料管理data management領域這些都應被持續監控而回饋總是可以被用來持續地增強、更新與發布應用程式。從倉庫的 Day 77「The Big Picture: Monitoring」 可以看到監控的具體樣貌假設我們管理一千台伺服器涵蓋應用程式伺服器、資料庫伺服器、Web 伺服器甚至混入公有雲與 Kubernetes——手動登入逐一檢查、或寫腳本代為登入檢查兩者都需要相當大的工作量第三種選項是採用市場上現成的監控解決方案如該篇提到的 Nagios、Zabbix讓我們把監控基礎設施擴展到任意數量的伺服器。監控要回答的關鍵問題包括系統是否被充分利用磁碟是否正在持續膨脹、會在未來數日內耗盡何時該發出警示、讓我們在停機發生前採取行動來自社群的補充FinOps 也要參與社群成員 _ediri 特別提到在這個持續過程中FinOps 團隊也應該參與其中。應用程式與資料運行並儲存在某個地方你應該持續監控它們——確保當資源使用狀況發生變化時成本不會在你的雲端帳單上造成重大的財務痛苦。換言之監控不只是技術指標還包含成本指標。誰該擁抱 DevOps超越「DevOps 工程師」這個頭銜雖然現實中存在許多掛著「DevOps 工程師」職稱的職位但這其實不是定位 DevOps 流程的理想方式。作者與社群交流後的觀點是「DevOps 工程師」這個頭銜不應是任何人的目標因為實際上任何職位都應該採用本文所闡述的 DevOps 流程與文化。DevOps 應該被應用在許多不同的職位上例如雲原生工程師架構師Cloud-Native engineer/architect、虛擬化管理員virtualisation admin、雲端架構師工程師cloud architect/engineer、基礎設施管理員infrastructure admin——這只是其中幾個例子。本文前面使用「DevOps 工程師」一詞用意其實是突顯上述任何職位以及更多職位所使用的流程範圍。小結生命週期是循環不是直線如果我們把視角拉高DevOps 生命週期可以更細粒度地展開Day 5「Plan Code Build Testing Release Deploy Operate Monitor」 將流程拆成八個步驟並用無限迴圈呈現即本文開頭那張圖Plan規劃開發團隊決定下一個 sprint 要推出哪些功能與 bug 修正——這是 DevOps 角色參與其中、提早了解即將到來的工作、並引導他們與你建立的基礎設施協作的機會記住開發團隊軟體工程團隊就是你的客戶。Code編碼撰寫程式碼並合併進儲存庫。Build建置第一個自動化環節——依語言進行轉譯編譯或從程式碼建立 Docker 映像。Testing測試執行測試最小化把問題帶進生產環境的機率——不引入新 bug、不破壞原本能運作的功能。Release發布把編譯後的程式碼或 Docker 映像放進 registryrepository供生產伺服器取得。Deploy部署把程式碼放上生產環境——直到此時業務才真正從團隊投入的時間與心血中實現價值。Operate維運處理使用者回報、建立自動擴展、把生產環境的關鍵事件回饋給維運團隊並盡可能讓部署自動化。Monitor監控涵蓋記憶體、CPU 使用率、磁碟空間、API 端點回應時間以及日誌logs——讓開發者無需登入生產系統就能看到正在發生什麼。Rinse Repeat重複回到規劃階段再來一輪。對應到「持續」系列Day 5 還給出了簡潔的公式持續交付Continuous Delivery Plan Code Build Test持續整合Continuous Integration Plan Code Build Test Release持續部署Continuous Deployment Deploy Operate Monitor前提是 CI 的 Release 成功正如 Day 70 所說CI/CD Pipeline 是現代 DevOps 環境的骨幹——它透過自動化建置、測試與部署應用程式橋接開發與維運之間的鴻溝。在接下來的 90 天中你將陸續深入 Git、容器、Kubernetes、IaC、組態管理、CI/CD 與監控等主題而本文就是承載這一切的總覽骨架。延伸閱讀倉庫內相關資源Day 4DevOps 與 Agile——理解 DevOps 與敏捷開發的異同以及兩者如何互相成就。Day 5Plan Code Build Testing Release Deploy Operate Monitor——逐步驟拆解生命週期與 CI/CD 的持續系列公式。Day 35概述 Git - 版本控制——開發階段最重要的版本控制工具入門。Day 49The Big Picture: Kubernetes——部署階段的容器編排平台全貌。Day 63The Big Picture: Configuration Management——部署階段的組態管理工具含 Ansible 與 Terraform 對照。Day 70The Big Picture: CI/CD Pipelines——整合與部署階段的自動化骨幹。Day 77The Big Picture: Monitoring——監控階段的具體工具與方法。2022 繁體中文版 README——完整的 90 天學習地圖與章節導覽。如果你讀到這裡你應該已經知道自己是否想留在這個領域。下一站Day 4 - DevOps 與 Agile。赞分享文档/教程【免费下载链接】90DaysOfDevOpsThis repository started out as a learning in public project for myself and has now become a structured learning map for many in the community. We have 3 years under our belt covering all things DevOps, including Principles, Processes, Tooling and Use Cases surrounding this vast topic.项目地址https://gitcode.com/gh_mirrors/90/90DaysOfDevOps点击查看免费下载相关推荐90DaysOfDevOps 第3天以应用为核心的 DevOps 生命周期全景解读90DaysOfDevOps 第3天以应用为核心的 DevOps 生命周期全景解读 本文是 90DaysOfDevOps 学习计划中 第 3 天 https:文档/教程Bruno 開源 API IDE以檔案系統與純文字 Bru 為本的 API 探索測試工具Bruno 開源 API IDE以檔案系統與純文字 Bru 為本的 API 探索測試工具 Bruno 是一款以檔案優先file first為核心設計的開源开发工具接口测试桌面应用CLI90DaysOfDevOps 第 3 天以应用为核心的 DevOps 生命周期——从开发到监控的闭环90DaysOfDevOps 第 3 天以应用为核心的 DevOps 生命周期——从开发到监控的闭环 导读 本文是 90DaysOfDevOps 系列第 3文档/教程创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考