什麼是 DevOps？

DevOps 是結合 Develop 以及 Operations 的概念，將開發與維運整合在一塊，可提升專案的交付效率與服務能力，相較於傳統的作法，DevOps 有以下好處：

• 更快的交付能力
• 更好的容錯、除錯能力
• 讓每一個程式碼的更動可以最快的整合進現有的生產環境中（不產生任何 side effect）
• 降低同一個組織內跨部門的溝通成本
  

上圖取自 AWS 官方網站。

現今的軟體工程最常聽的名詞有：CI/CD、DevOps、Cloud Native...等等，但大家往往很難摸清楚它們到底在說什麼，甚至在 google 搜尋 DevOps 與 CI/CD 的時候會查到類似的解釋。就筆者不專業的角度來看，我認為 CI/CD 最強調的就是交付到客戶手上的速度（持續交付），為了達到這個目的，軟體專案能夠持續的整合新的功能、新的程式碼改動（code refactor）的能力就十分重要。再來是 DevOps，它涵蓋了 CI/CD 的概念，並且把更多的現實情境考慮進來（降低跨部門溝通成本），那些常見的 CI/CD、DevOps 工具集不過是為了實踐快速且持續交付的幫手，如果只是把這些東西都加入現有專案但是缺乏整合，那麼這些工具並不會為我們帶來太多的益處。

進入正題

接續前面的話題，為了加速系統整合與交付的速度，工程師們開始將大量的技術應用在生產環境中，像是：容器化、微服務、分散式架構。
可以想像一個情境：如果我將一個服務拆分成多個互享協作的子服務，有些服務使用 node.js 開發、有些服務使用 Go...每個子服務可能都仰賴不同的系統環境、系統工具或是三方套件，如果每一次更新子服務的版本或是將子服務遷移到不同的主機上，維運人員可能會需要花費大量的時間準備執行環境。

這時候，一個隔離系統環境、隔離檔案系統、隔離系統的網路環境這樣複雜且龐大的需求誕生了，也正是這樣的需求促成了 Container 技術的發展。

Docker

以 docker 為例，其實 docker 並不是 container 的唯一代表，它與其他容器化技術的解決方案基本上都是遵照 Open Container Initiative (OCI) 的實作。

關於 OCI，可以參考 [Day3] 淺談 Container 實現原理, 探討 OCI 實作一文。

有了 docker，維運人員基本上可以無痛的部署服務，開發人員也可以使用容器化技術隔離自己的開發環境與測試環境，避免套件之間產生衝突。

部署多個 container

有了容器化的技術，開發者可以隨意的將開發環境+應用程式打包成一個個 Container，但如果開發者想要將這些服務部署在同一個主機上，甚至是讓容器之間彼此能夠使用網路溝通呢？
針對以上問題，使用 Docker 仍可以滿足我們的需求，不過手動的啟動這些容器、設置 volume、設置私人網路環境其實蠻浪費時間的。
為了更好的解決問題，像是 Docker-compose 這樣的解決方案就冒出來了，它可以讓我們透過描述 Service 做到：

• 一次啟動多個 container
• 設置容器之間的私人網路
• 設置容器的 volume、權限、啟動的執行命令、容器的啟動順好
• Replica Set

那麼，如果我希望一個服務的子服務分散的在不同電腦執行，要怎麼辦呢？

看到這裡，我們不難猜出 K8s 到底可以滿足什麼樣的需求：

1. 分散式架構
2. 動態的編排服務節點（可以分配每一個子服務的資源、設定子服務的 replica 數量）
3. 服務對外（port forwarding、service、ingress）

除了上述的特點，K8s 還能結合 CI/CD tool，當程式碼有任何更動或是觸發特定條件時觸發 pipeline，讓它幫助我們做到：

1. 測試：包含但不限於單元測試、端對端測試
2. 整合：測試完成後，要將這些服務整合成方便部署的形式（如：編譯執行檔案與 docker image，並且推送至 image registry）
3. 部署：由於服務的整合方式有很多種，部署的方式也就會隨著不同的整合方式改變（使用 IaC、使用 Ansible、使用 docker-compose、使用 k8s）
4. 部署後的測試：當服務部署至生產環境或是一個暫時性的測試環境後，我們應該要對這個環境上的服務執行第一步驟執行的測試，以確保服務是以我們預期的狀態下執行。

DevOps with 5GC

除了上面提到的 CI/CD、DevOps，筆者會在這裡提到 Cloud Native 是因為時下 NFV 的技術正夯，在大家紛紛將 Network Function 從早期的黑盒子轉變成能夠跑在 PC 上的應用程式以後，部署 Network Function 的方式就變得十分多元化，包含：部署在公有雲/私有雲、個人工作站、甚至是樹莓派上。
考慮到核心網路在運作時可能會因為不同的乘載壓力需要引入相對應的解決辦法，我們也可以將雲原生服務的概念套用到 Network Function 上。

上圖出自 SD Core Technical White Paper

參考上圖，這是 ONF 在 SD Core 白皮書提到的 CI/CD pipeline 架構，透過 CI/CD Tool 測試並且產生 Docker image 放到私有的 container registry。接著再配合 docker-compose 或是 k8s 做到自動部署，部署完成的應用可以視情況用於 QA 測試/實際產品的發布，加快整個開發工作的整合效率。

總結

本篇文章介紹了常見的容器解決方案，並且用實際案例讓大家理解 K8s 的優勢。不過，筆者認為並不是所有的服務都必須要使用 K8s 來建置，docker-compose 幾乎可以應付日常的開發需求，在某些時候，我認為 docker-compose 更為方便一些：

1. 設計了一個系統雛形，進入概念性驗證階段時

個人認爲在個人專案的初期幾乎不需要 K8s，因為一個概念性的專案或是服務並不會有動態調整資源的需求。在這個情況下，docker 或是 docker-compose 會是你的好夥伴。

2. 整合性測試、端對端測試

當一個服務上線時可能會在 CI/CD pipeline 上做一些端對端的測試，如果一個服務被拆分成多個元件，我們可以使用 docker-compose 實作整個網路拓墣。

3. 生命週期短暫的專案

如果是沒有上線需球或是只需要存在幾天的軟體，那導入 K8s 毫無疑問是拿石頭砸自己的腳！在這個場境下，使用 docker 會是更好的方案。