[DevOps] 維運日記1 — 契機

什麼？我也要做維運？

最近在公司開始接下小小的 DevOps 任務，試著熟悉一些常用的工具如 Docker、Kubernetes、Grafana、Gitlab CI/CD 等。乍看是一堆 yaml 檔與指令，看似單純卻也在過程中也採了不少雷，因此寫幾篇文章紀錄一下。

先回憶一下前輩的歷史課

過去團隊在草創初期，為了快速做出 prototype 來 demo，在人員配置少的情況下是單體式架構（Monolithic）的開發，其實就很像在 bootcamp 時期學習的全端開發方式，追求快速的迭代跟佈署，測試市場接受度。

但幾年來產品功能漸趨完整、開始擴充更多更複雜的邏輯，團隊中的工程師也變多了，大家都在改同一份 code，雖然利用 Git 的特性做版本控管，協作起來是沒什麼大問題，但要佈署時，整包很肥大的 code base、過程中動輒改到別人的 code 、改一壞百，變成了大家的惡夢。於是團隊開始進行前後分離，後端也漸漸從「一個客戶一包 code 」的開發方式做收隴，將產品架構定義好，整併成一包，以 customer config 的方式區別不同客戶。但依然是 Monolithic 架構，開發上等來等去、debug 到崩潰，佈署曠日耗時。

自我開始有記憶時

菜雞我入職後，團隊正開始進行架構的遷移，從 Monolithic 遷移到 Microservices 架構、從人工部署改用 Gitlab CI/CD、也開始導入 Kubernetes 來管理軟硬體的節點。於是我也獲得了重構的機會，將 Monolithic 裡的功能模組一點一點抽出改寫，做成 Microservices 的架構，各個不同 service 之間透過 API 互相聯繫、傳送資料。最有感的是功能解耦後，各團隊成員的工作也變明確了，負責的模組切的乾淨、service 部署各自分離，改我的壞你的的情況也鮮少發生。整體開發動能和佈署速度變快，開發時程也能各自調配了。

當開發者的角色點了維運技能

但使用 microservices 架構意味著增加維運成本，需要有一個 DevOps 的角色來處理自動化佈署，監測 app log 、甚至壓測等等。由於目前人手較緊，在爭取過後，原本就是 DevOps 的主管開始給我學習 Gitlab CI/CD、Docker、Kubernetes 的任務，當我在本地開發完新的 service 就能馬上進入 QA server 中練習佈署服務，再透過設定好的 Gitlab CI ，進行後續自動化的佈署。而雖然前人設定的 k3s 已經將基礎設施佈署的差不多，但透過佈署小小的 service 我也是收穫滿滿，也更能從一個宏觀的架構去看待公司的產品。DevOps 的世界博大精深，要玩可以玩得很複雜，雖然目前只是幾份 yaml 檔、幾行指令的事情，但看到自己的 app 佈署上去被其他 service 呼叫API 有成功時，還是覺得很內心澎湃 XD 要好好珍惜這份菜雞的心情

半年沒有在 medium 發文，因為主要都在寫刷題文所以都發在 hexo 那邊，決定重啟 medium 來督促自己發一些學習技術相關的分享。這系列會著重在學習 Docker、Kubernetes 的途中遇到的問題和一些情境，以及如何去解決它。因為沒報到鐵人賽，所以這邊算是給自己的小小挑戰，雖然沒有限定完成的期限（？）但希望能寫出來～預計目錄：

我對 DevOps 的理解以及我目前學到什麼

Gitlab CI/CD 簡單分享

什麼是容器？什麼是 microservices？

Docker 概念

Docker 基本指令

Docker 跑起來

Kubernetes 概念

Kubernetes 基本指令

簡單佈署 app 到 Kubernetes

Grafana Loki 的導入 （monitor logs）

未來想繼續充值的技能