Nowadays, most of us have containerized our services, and effectively managing and upgrading containers without affecting existing services is a critical issue. Two steps are required in the CI/CD process: first, packaging the environment as a Docker image and uploading it to the company’s private Docker registry; and second, after the upload is complete, possibly connecting to the machine via SSH, pulling the new image, and restarting the running service via the Graceful Shutdown mechanism. You can learn more about Graceful Shutdown in this article. I am going to introduces Watchtower, a brand new tool that automatically upgrades and updates running containers, allowing for further CD process streamlining. Developers only need to upload the Docker image, and the remote servers can update the running container automatically.

現在大家在部署服務肯定都已經容器化，而如何有效管理及升級容器不影響現有的服務，這就是一個重要的議題，然而在 CI/CD 的流程內，肯定有兩個步驟是必須的，第一就是將環境打包成 Docker Image 並上傳到公司內私有的 Docker Registry，以及上傳完畢後，也許透過 SSH 方式連上機器，並且拉取新的映像檔，再透過 Graceful Shutdown 機制重新啟動正在執行的服務。可以參考這篇了解什麼是 Graceful Shutdown。本篇就是要帶給大家一個全新的工具 Watchtower 用來自動升級更新執行中的容器，讓 CD 流程可以再簡化一步，開發者只要上傳完 Docker Image，遠方的伺服器就可以自動更新。

Ring Buffer Queue 是固定大小記憶體的 FIFO (first in, first out) 資料結構，用來處理不同 Process 之前的資料交換。工作原理就是在一段連續固定大小區間的記憶體用 (head/tail) 兩個指針來決定現在要將資料放在哪個位置。本篇將帶大家用 Go 語言快速實現 Ring Buffer 資料結構。

上一篇『系統設計: 如何取消正在執行的工作任務 (一)』教大家如何用 Go 語言實現 canceler package 來紀錄及取消正在執行的任務。而本篇來實現上圖的 HTTP Server 及 Worker 程式碼，底下直接用 Gin 框架來快速實現 HTTP 兩個 Handle，分別是 Cancel Task 及 Ｗatch Task (如下圖標示的 1 跟 2)。

其中上圖綠色框框 1 是用來接收使用者想要取消的任務，而 2 是用來讓 worker 進行長連接，根據不同的情境可以設定不同的等待時間。大家可能會問，為什麼不讓 Server 主動通知 Worker 就可以了，先解釋這點，這邊我們可能要先假設 Worker 存在的環境是封閉的，不能任意架設服務，故需要主動向 HTTP Server 進行詢問。其中 HTTP Server 跟 Worker 中間可以透過 gRPC 或 RESTful 進行資料交換，本篇先以 RESTful 進行說明。

本篇來聊聊『如何取消正在執行的工作任務』，當系統內有需要處理比較久或較多資源的任務，肯定會將這些任務丟到其他機器再執行，執行過程如果需要取消，會經過如上圖幾個步驟。先假設中間的過程不透過 Message Queue 機制，而是兩個服務進行溝通透過 RESTful 或 gRPC 方式。

不同的服務都會有需要處理比較久的任務，這些任務是不能即時執行完成，才回應給前端，這樣使用者體驗會非常的差。將類型的任務存在資料庫或放在消息對列就是一種處理方式，接著啟動另一個服務來消化非即時性的任務，而常見的處理方式就是在服務內啟動多個 Worker Node 來平行消化任務 (如上圖)。

不管是長官還是同事甚至下屬，在公司無時無刻都需要跨團隊進行溝通，當系統架構或流程越來越複雜的時候，如果沒有按照當下情況記錄下來，對於未來接手的同事，或者是自己都會不小心忘記，而在記憶最清楚的當下用文字或流程圖記錄下來，對團隊及自己是有相當大的幫助。而有沒有工具可以快速畫出系統架構或流程圖？我們可以分幾種情境來討論。

不知道大家在用 Go 語言寫服務的時候，會不會遇到 Components 會有相互依賴的關係，A 物件依賴 B 物件，B 物件又依賴 C 物件，所以在初始化 A 物件前，就必須先將 B 跟 C 初始化完成，這就是錯綜復雜的關係。也許大家會想到另一個做法，就是把每個物件都宣告成全域變數，我個人不推薦這個使用方式，雖然很方便，但是就會讓整體架構變得很複雜。而本篇要介紹一個救星工具，就是 Google 團隊開發的 Wire 工具，官方部落格也可以參考看看。此工具就是為了解決底下兩個問題 (dependency injection)。

1. Components 互相依賴錯綜復雜的關係
2. 不要宣告全域變數

最近在用 Go 語言實作微服務，溝通的接口採用 gRPC，除了可以透過 gRPC 支援的第三方語言來寫客戶端的測試之外，有沒有一些好用的工具來驗證檢查 gRPC 實現的接口。剛好今年看到 Postman 宣布開始支援 gRPC，相信大家對於 Postman 工具並不會太陌生，畢竟測試 Websocket 或 RESTful API 都是靠這工具呢。本篇除了介紹 Postman 之外，還有一套 CLI 工具 grpcurl 及一套 GUI 工具 grpcui 也是不錯用，後面這兩套都是由同一家公司 FullStory 開源出來的專案，底下就來一一介紹。

今年第一場公開的演講 2022 台灣雲端大會，台灣五月開始疫情變嚴重，故延遲了一次到七月才舉辦，這次帶給大家的是『自動化監控網站運行服務 – Gatus』，內容可以拆為兩個部分，第一部分是介紹為什麼要使用 Gatus，用來解決開發團隊哪些問題，我也整理了三大點為什麼我選擇 Gatus，另一部分就是本篇的主軸，Gatus 系統架構跟流程。

1. 監控條件 (客製化回應)
2. 開源專案 (Go 語言)
3. 簡易頁面 (Status Page)

對於使用 Gatus 有興趣的朋友可以參考我之前寫的文章：『自動化監控網站運行服務 - Gatus』，本篇就不介紹怎麼使用 Gatus 了。