CircleCI 專案夠多且每個專案都有相關權限要存取時，推薦使用 Context 的概念來簡化設定。 Context 是一個抽象化的物件，其可以描述

1. 所有的環境變數
2. 限制使用的專案

而所有運行 CircleCI 的專案都可以繼承該 Context 來自動獲取所有環境變數

假設環境需要存取雲端資源，可以把用到的所有資訊寫到一個 Context 內，並且設定好所有環境變數 接下來每個專案的 CircleCI 就只需要使用類似下面的語法

workflows:
  test:
    jobs:
      - test:
          filters:
            branches:
              only: master
          context:
            - AWS

就會把 AWS Context 內的環境變數都繼承近來，因此未來要維護只需要針對 Context 去維護，就不需要每個專案都去設定

使用上不要使用任何員工的帳號去綁定 Project，不然員工離職很麻煩，最好創建一個 machine account，用該 account 的 ssh key 來串連 GitHub 與 CircleCI，這樣離職才不會產生太多問題

標題: 「DevOps is a failure」 類別: others 連結: https://leebriggs.co.uk/blog/2022/06/21/devops-is-a-failure

本篇文章作者從不同的角度來聊聊 DevOps 這個詞所代表的含義與實作意義

第一段作者先閒聊一下自己與 DevOps 詞的歷史，接者直接拋出一個作者長期好奇的觀點 「每個人都一定聽過 DevOps 是一個需要 Dev + Ops 共同參與的文化，但是作者自己參與的 DevOps 相關會議與討論，與會者大部分都是 Ops 人員，而不是那些真正參與開發的 Dev 人」

困惑時期

接者作者聊聊自身多年前的經驗，當時的開發團隊宣稱該團隊是「true devops」，同時不跟作者的維運團隊討論各種維運需求，這過程讓作者非常困惑，為什麼對方會說自己是 true devops 而又不找自己探討維運需求

作者後來與該開發團隊深聊後終於理解對方的意思，原來該開發團隊身兼開發與維運，該團隊使用 boto3 加上一些腳本來管理應用程式的生命週期，同時該團隊招募的 「full stack engineer」除了基本的後端技術外，也要對 AWS 有不少的熟悉與經驗。

對方的舉動更加困惑了作者，畢竟公司當時採取類似 Netflix 的方式來打造一個平台來讓所有開發者可以更輕鬆的去管理這些東西，而該開發團隊的舉動完全是反其道而行，到底為什麼要這麼做？？

Pulumi 時期

當作者加入 Pulumi 時期時，作者開始使用一些知名工具如 GitLab, Terraform, Kubernetes 等工具來打造一個適合開發者的好用平台，然而每次想要將該平台給推廣給開發者時總是屢屢碰壁，總是會聽到如「你們的東西我不熟悉，我們還是習慣自己打造的工具」等類似說詞給打發掉。

作者接下來不斷嘗試說服開發團隊來使用自己打造的超級平台，鼓勵他們參加 DevOps 相關活動等各種方式，最終得到的還是類似「我們會按照我們自己的方式去嘗試～謝囉」之類的回覆

回顧

回顧過往，作者發現錯的是自己，一直以來相信的 DevOps 願景「讓 Ops 停止說 No, 讓 Dev 停止說"yo~ 今天部署吧"」 其實並不真實，作者認為 2022 的今天， DevOps 真正的含義是 「維運端的人努力說服開發人員按照維運人員的想法去做事情」

綜觀所有號稱跟 DevOps 有關的工具，你會發現幾乎都跟維運有關，每個跟 DevOps 有關的職缺列舉的技能也是滿滿的跟維運有關，對作者來說， DevOps 工程師跟過往的 System Admin 根本沒有太大分別，差異只有把「實體機房建置，上架機器」 v.s 「雲端機器建置，創立VM」而已。

文章內後半部分還有一些作者的想法，有興趣的可以閱讀完畢

本篇文章的想法滿有趣的，譬如作者提到想要幫開發團隊建立一個維運平台卻屢屢碰壁。

Ops 可能會覺得 Dev 一直不停重複打造工具沒有效率，不如使用自己打造的好平台 Dev 可能會覺得 Ops 不懂自己的需求，不如自己根據需求打造

同樣的敘述放到不同的規模，譬如

dev -> 5 人的專職開發團隊 dev -> 50 人的專職產品團隊

後者的角度也許會覺得團隊人數夠多，可以自己處理自己的需求，不需要仰賴公司提供一個萬能平台來處理一切，同時跨 team 合作可能還會使得很多事情效率低落，溝通成本過大。

歡迎留言探討你的想法

標題: 「提升 DevOps 技術的免費書籍」 類別: others 連結: https://vladimir-mukhin.medium.com/free-books-that-will-boost-your-devops-game-to-the-next-level-5940482b0f96

本篇文章的重點很簡單

1. 閱讀書籍提升對於 DevOps 領域的掌握度
2. 所有書籍都是免費

這邊節錄文章中列出的所有書籍

1. Kubernetes Up & Running — Dive into the Future of Infrastructure Kubernetes 從 2014 發行以來的八個年頭席捲全世界，作為一個 DevOps 不論你當下的環境適不適合使用 Kubernetes，你都必須要瞭解到底這個容器管理平台的魅力是什麼 為什麼可以打趴眾多競爭者成為所有容器管理平台的主要首選。 本書從開發者(Dev)以及維運者(Ops)的角度來看到底 Kubernetes 是如何提升整體工作的效率，速度與整體的靈活度

2. Designing Distributed Systems — Patterns and Paradigms for Scalable, Reliable Services 這本由 Brendan Burns 所攥寫的書籍探討了分散式系統架構上幾個常見的設計模式，事實上這些設計模式有些都可以於 Kubernetes 的設計與用法中反覆發現 所以花點時間去研究一下大師所分享的分散式系統模式的設計理念，對於未來去學習理解新系統，或是設計一套系統都會有所幫助

3. 97 Things Every Cloud Engineer Should Know — Collective Wisdom from the Experts 這本有紅帽所發行的免費書籍，書中收集了眾多資深雲端工程師的經驗，列舉了 97 個每個雲端工程師都應該要知道的事情，這 97 項包含很多東西，譬如 資料，自動化，網路，公司文化，個人發展，軟體開發以及雲端預算評估等眾多常見議題

4. Linux — Notes for Professionals

5. Production Kubernetes — Building Successful Application Platforms

6. Git — Notes for Professionals

7. Automate The Boring Stuff with Python — Practical Programming For Total Beginners

剩下的書本也都非常有趣，大家有需要時可以閱讀下列書籍

標題: 「新一代 Helm Chart 的管理套件 helmwave」 類別: tools 連結: https://medium.com/wriketechclub/new-wave-for-helm-b9800733587f

Helm 作為現在包裝與安裝 Kubernetes 應用服務的主流方式，單單使用 Helm 很多時候不能滿足部署需求，譬如公司的業務是由多套 Helm Chart 同時組成的，這時候可能會有幾種做法

1. 使用 Helm Dependency 的方式來產生一個 Umbrella charts 讓你可以安裝一個 Helm 實際上會把相關的服務一起搞定
2. 透過 Helmfile 等相關工具以更上層的概念來管理你的應用，用多套 Helm Chart 來管理與部屬你的應用程式

而作者長期使用 Helmfile 來管理各種 Helm 的安裝方式，而今天作者終於發現一個相對於 Helmfile 來說更容易使用，而且整體使用方式更為簡潔的解決方案，helmwave.

Helmwave 的官方介紹很簡單， Helmwave is like docker-compoose for helm.

其本身的實作更為簡潔，直接使用 Helm Library 於整個實作中，所以下載單獨的 binary 即可，不需要如同 helmfile 一樣還要於系統中先安裝 helm 等相關工具。 文章中透過範例來示範如何滿足

1. 服務需要安裝多套 Helm chart
2. 有兩個不同環境， prod 與 stage 有不同的 values 要使用

整個使用的方式跟 docker-compose 有點類似，可以透過 helmwave up, helmwave down 的概念來啟動與停止服務，只不過所有的服務都是基於 k8s + helm-charts 來完成。

有使用 helmfile 的人可能會對這類型的工具比較有感覺，也許可以看看其差異性是否真的有如作者所提這麼好

標題: 「DevOps 的 2022 學習之路」 類別: others
連結: https://medium.com/faun/devops-roadmap-2022-340934d360f9

本篇文章是作者根據自己的觀察與經驗，列出 2022 需要繼續學習與觀察的 13 項技能與概念，希望讓每個 DevOps(SRE) 相關領域的人有一個方向去精進自己。

1. Network Technologies 網路的概念短時間內很難被顛覆，所以掌握基本的 L4/L7, HTTP2/, HTTP3/(QUIC), DNS, BGP, Load-Balancing 等基本網路概念絕對不吃虧，作為一個熟悉架構的專家，能夠描述環境中的封包流向是不可缺少的能力。

2. OS, particularly Linux Linux 很重要，請學習系統上的各種基本概念， CPU/Memory 基本概念, Init, cgroup 等

3. CI/CD Jenkins 作為老牌的解決方案，能夠使用其實也很好，不過要注意的是現在有愈來愈多的環境嘗試使用其他的 pipeline 來搭建，所以有時間的話也可以學習一下其他的解決方式，讓自己能夠有能力去面對各種需求

4. Containerlization/Virtualization 除了最知名的 Docker 環境外，也嘗試看看 containerd, podman 等不同專案，同時也考慮如何將 container security 的概念給導入到日常生活中

5. Container Orchestration K8s 幾乎變成容器管理維運的 de facto 標準，單純的 k8s 叢集還不足以面對所有正式環境的問題，所以還需要搭配各個面向的概念將其整合才可以打造出一個適合團隊的 k8s 叢集。

6. Observability at Scale 除了最基本常見的 Prometheus 之外，也看一下其他基於 Prometheus 所打造更適合大規模的架構，如 Thanos, Cortex, VictoriaMetrics 等 此外可以試試看 Continuous Profiling 等持續觀察系統效能的工具，如 Parca, Pyroscope, hypertrace 以及順便試試看導入 Open Telemetry。

7. Platform team as a Product team 稍微有規模的團隊可能會慢慢的感覺到 Platform 逐漸轉型成為一個 Product 的概念，只不過該 Product 的面向對象是內部開發與測試人員而並非外部使用者。 整體目標就是打造一個更好的協同平臺，讓開發與測試人員能夠更有效地去滿足日常工作需求，同時 Platform team 除了維護產品之外也要教授使用人員讓他們有能力去使用該平台來滿足需求 而不是所有問題都要一直讓 Platform 的人來幫忙處理，這種模式小團隊可行，但是當團隊過大時就沒有辦法處理。

8. Security

9. Programming

10. Infrastructure as Code

11. Cloud

12. Technical Writing

13. Site Reliability Engineering

剩下的內容就留給有興趣的人自行到文章去觀看，每個類別都有舉出幾個趨勢與值得關注的專案，其中特別注意的是 Technical Writing 這項技能非常重要 遠端工作的趨勢使得透過文字交流的機會比過往多很多，所以如何寫出一個有效不會浪費彼此時間的設計文件，架構，開發文件等則是一個很重要的技能，所以即使是個開發人員也要努力練習 將腦中的想法有系統地呈現出來

標題: 「 取代 Docker Desktop 的高效率開發環境」 類別: Container 連結: https://medium.com/partoo/replacing-docker-desktop-with-a-more-efficient-development-environment-582c61c50984

作者認為 Docker Desktop 是一個非常好的開發環境工具，能夠簡化很多設定讓開發者更容易的開發應用程式，但是對於 Windows/Mac 的使用者來說 Docekr Desktop 實際上也是先運行一個基於 Linux 的 VM 並且於其中運行 Docker Container。這種架構實際上帶來了一些使用上的缺陷，包含

1. FileSystem 的處理效能非常不好，不論是使用 cahced 或是 gRPC-fuse 檔案系統還是沒有辦法得到很好的效能。
2. 資源使用有問題不如預期，作者設定希望最多使用 6GB 結果最後卻使用到了 15GB，幾乎吃光系統所有記憶體
3. 官方幾乎沒有文件去探討該 VM 的存取方式(雖然滿多人會用 nsenter 進入)，所以很難把一些本地檔案給直接放到 VM 內來提昇儲存相關的問題，變成所有的儲存都只能用 docker volume 來處理。

作者的公司 Partoo 採取了 VM + Vagrant + Ansible 的方式來創建開發者環境，讓每個加入團隊的開發者都可以輕鬆簡單的建設期開發環境 並且文章中也探討如何於本地端使用 Vistual Studio Code, PyCharm 來編輯 VM 的檔案並且順利的進行應用程式開發。

從效率來看，相對於直接使用 Dodcker Desktop 來看，作者團隊的測試程式基於自己的 VM 提升了將近 30% 的效能，主要的問題就是儲存系統與 Docker Container 之間的掛載關係差異。

標題: 「透過 Crossplane 與 ArgoCD 來達成應用程式與基礎建設的 GitOps 部署方式」 類別: cicd 連結: https://medium.com/containers-101/using-gitops-for-infrastructure-and-applications-with-crossplane-and-argo-cd-944b32dfb27e

作者表示過往很多教學文章當探討到 Kubernetes 部署議題的時候，通常都不會去探討如何部署 Kubernetes 而是專注於應用程式的部署， 理由非常直觀，文章就是要專注於 Deployment 的議題，能夠讓讀者更容易地去閱讀與參考，另外一個背後的原因其實是因為 Kubernetes 部署的方式 太多種，常見的方式使用 Terraform 透過 IaC 的概念來管理，而應用程式都使用 Helm/Kustomize 完全不同的方式來管理

而作者今天想要探討的是如何透過 ArgoCD 來建設一個 GitOps 的環境，並且於上面使用 Crossplan 這個解決方案來處理各種底層基礎建設的需求，如此一來 就可以統一透過 Helm/Kustomize 的方式來描述這些基礎建設

Crossplan 很類似 Terraform 但是有者一些些微的差異

1. Crossplan 本身是 Kubernetes 的應用程式，所以本身的描述方式就是 Kubernetes 的 YAML 方式
2. 可以使用 kubectl, Helm/Kustomize 等方式來部署這些描述並且讓 Crossplan 來幫忙創建描述的基礎建設

由於整個 Crossplan 可以視為一個 Kubernetes 應用程式，所以直接使用 ArgoCD 的方式來部署 有興趣的可以閱讀全問

標題: 「The pains of GitOps 1.0」 類別: cicd 連結: https://codefresh.io/about-gitops/pains-gitops-1-0/

作者認為很多文章都闡述 GitOps 對於部署帶來的好處，但是軟體世界沒有十全十美的東西，所以作者就探討了 12 個其認為 GitOps 的缺點

註:

1. 本篇文章是 2020 年底的文章，所以文章探討的內容也許當年沒有很好的解決方式，但是現在已經有了比較好的處理方式。
2. 我個人覺得文章的某些部分有點太牽強，已經假設 GitOps 是個萬能解法，什麼問題都要靠這個。就這個問題是不管有沒有 GitOps 都會存在的問題，有點為了反對而反對，與其說 GitOps 的缺點不如說沒有解決的問題。

這邊就節錄幾個文章中探討的議題，剩下有興趣的可以閱讀全文

GitOps covers only a subset of the software lifecycle

作者認為 GitOps 的精神「我想要將 Git 專案內的所描述的狀態給同步到叢集中」這點只能處理應用程式部署的問題，但是其他的流程 譬如編譯程式碼，運行單元測試，安全性檢查，靜態掃描等過程都沒有辦法被 GitOps 給處理。

作者不滿的點主要是很多 GitOps 的工具好像都會宣傳自己是個全能的解決方案，能夠處理所有事情，但是實際上卻沒有辦法。 實際上其專注的點就是應用程式部署策略為主的部分，其餘部分還是團隊要有自己的方式去處理

Splitting CI and CD with GitOps is not straightforward

過往很多團隊都會將 CI/CD 給整合到相同的 pipeline 中去處理，通常是最後一個階段就會將應用程式給部署到目標叢集，然而有外部 Controller 實作的 GitOps 解決方案會使得 CI/CD 兩者脫鉤，好處來說就是 pipeline 不需要去處理部署，只需要專心維護 Git 內的資訊，後續都讓 Controller 來處理。

然後某些團隊本來的 CI/CD 流程會於部署完畢後還會進行一些測試或是相關操作，這部分會因為 GitOps 將部署給弄走導致整個流程不太好處理，畢竟要如何讓 GitOps 部署完畢後又要可以觸發其他的工作也是額外要處理的事情

There is no standard practice for GitOps rollbacks

雖然 GitOps 的核心是透過 Git Commit 去控制當前部署的版本，那發生問題時到底該怎麼處理，如何去 rollback? 作者舉兩種範例

1. 讓 GitOps 去指向之前的 Git Commit
2. 針對 Git 使用 Git revert 等相關操作來更新最新的內容 作者認為沒有一個標準來告訴使用者該怎麼使用以及處理

Observability for GitOps (and Git) is immature

作者認為目前現有的 GitOps 工具都沒有辦法提供下列答案

1. 目前生產環境是否有包含 Feature X
2. Bug X,Y 是否只有存在於 Staging 環境？ 還是生產環境也有？

註: 有什麼概念是天生就可以有這些東西的..? GitOps 有點無妄之災

標題: 「Meta 如何打造一個供多團隊使用的 SLI/SLO 設定與觀測平台」 類別: usecase 連結: https://engineering.fb.com/2021/12/13/production-engineering/slick/

本篇文章是 Meta 公司的技術分享文，探討內部如何搭建一個觀測 SLO 的大平台，讓不同的應用程式團隊都可以更方便地去觀察是否有達到其設定的 SLO。

文章內容有點長，這邊稍微節錄一些重點，非常推薦大家花點時間看完全文

1. Meta 的產品多，同時規模又大，背後又有數千的工程師不停地部署新版本，因此維運團隊必須要有一個好的方式來維運這些服務，包含預期狀態，當前狀態以及有能力去分析問題。
2. 團隊決定從 SLI/SLO 為基準點去設定預期狀態以及量測所有服務的效能。
3. 團隊決定打造一個名為 SLICK 的系統來視覺化與控管所有服務的 SLI/SLO
4. 沒有 SLICK 以前，每個服務的團隊都有各自的處理與儲存方式，所以都要花費很多時間去研究每個開發團隊的文件與用法，整體工作效率會下降
5. 過去的系統也沒有維護超過一週以上的資料，所以後續團隊也沒有辦法針對這些部分去分析。

透過 SLICK 可以讓整個 Meta 達到

1. 每個服務都可以用一個統一的方式去定義 SLO
2. 可以維持資料長達兩年且資料的細度達到每分鐘等級
3. 有個標準化的視覺方式來呈現 SLI/SLO
4. 定期地將當前服務狀態發送到內部群組，讓團隊可以用這些報告來檢視服務的穩定度並進行改善

文章後半部分包含

1. SLICK 用法介紹，包含 UI 的呈現樣子，定期的報告內容以及相關的 CLI 介紹
2. SLICK 的架構，團隊是如何設計 SLICK 這個服務，用到哪些元件以及這些元件之間個溝通流向
3. 兩個使用 SLICK 來改善穩定度的案例，這兩個案例都有簡單的去識別化，主要是介紹這些團隊發生什麼問題，如何透過 SLICK 來改善以及改善後的效能。