概述 本文紀錄如何在已運行一個 API 服務的 IIS 伺服器上，部署第二個（例如測試用）API。 方法：在同一個網站下建立子應用程式 (Sub-application) 這是在現有網站下新增 API 最直接的方法，因為此方法不需要更改 DNS 或防火牆規則（否則你要設定新的 domain name，或是在既有 domain 下使用一個未使用的 port），僅透過 URL 路徑來區分不同的 API。例如： 正式 API 呼叫路徑：http://yourdomain.com/endpoint 測試 API 呼叫路徑：http://yourdomain.com/test-api/endpoint 原理說明：應用程式集區 (Application Pool) 的隔離機制 「應用程式集區」是 IIS 中實現服務隔離的關鍵。它是一個獨立的容器，由 IIS 工作者處理序 (w3wp.exe) 管理。為新的測試 API 建立一個「全新的、獨立的」應用程式集區主要有以下三個好處： 隔離性 (Isolation)：最重要的優點。如果測試 API 因錯誤而崩潰，只會影響其自身的集區，正式運行的 API 服務將完全不受影響，確保了主服務的穩定性。 安全性 (Security)：可以為不同的集區設定不同的執行身分 (Identity)，從而對檔案系統、資料庫等資源進行權限隔離。 獨立設定 (Configuration)：每個集區可以有獨立的設定，如 .NET 版本、記憶體上限、CPU 使用率限制等，讓正式與測試環境的配置完全分開。 IIS 設定步驟 開啟 IIS 管理器，在左側窗格中找到您現有的網站。 在網站上按右鍵，選擇「新增應用程式」。 在「新增應用程式」視窗中，填寫以下資訊： 別名 (Alias)：設定 URL 路徑，例如 test-api。這將成為新 API 的存取路徑的一部分。 實體路徑 (Physical path)：指向您測試 API 發布檔案所在的資料夾。 應用程式集區 (Application Pool)： 點擊「選取…」。 在彈出視窗中，點擊「新增…」來建立一個新集區。 為新集區命名（例如 TestApiAppPool）。 (.NET Core 的設定於後面詳述) 確認選取了這個剛剛建立的新集區。 點擊「確定」完成設定。 部署 .NET Core API 的特別注意事項 部署 .NET Core / .NET 5+ 的應用程式時，其運作模式與傳統 ASP.NET Framework 不同，設定上有一處關鍵差異。 ...

前言 某支 API 要掛載到 APIM 上，我的同事問我這支 API 的後端伺服器有跟 Data plane 同網段嗎？同網段可能會有問題喔～ 我又嗅到新知識的味道了，趕緊來研究跟記錄一下： TCP 4-Tuple 首先必須先簡單提一下這個概念。這概念是指，每個 TCP 連線都是透過四個關鍵資訊組合成唯一識別，分別為： (Client IP, Client Port, Server IP, Server Port) Client IP: 來源 IP 位址 Client Port: 來源埠號 Server IP: 目的地 IP 位址 Server Port: 目的地埠號 或稱 Source & Destination 這四個資訊合起來，可確保網路上每一條 TCP 連線都是獨一無二的。 因此若 TCP 三方交握時，如果接收到的封包其 4-tuple 不符合系統 listen 的條件（如目的 IP 或目的 Port 不正確），該封包會被丟棄，不會產生連線。 情境分析 不同網段（非對稱路由） 假設： Client：10.1.1.10 (網段 A) NLB VIP：10.2.2.100 (網段 B) ...

前言 某天我在公司 Kong 測試環境的 control plane 上作業時，才發現其中一台 control plane 的服務竟然沒啟用。好奇之下問了之前負責維護的同事，結果他說：「本來就只會啟用一台啊！」於是我又多學了一課，身為啥都學來者不拒的工程師，當然要記錄下來。 HA cluster 高可用性叢集 根據 wikipedia 的定義：「高可用性叢集(High-availability clusters)是以最短的中斷時間為目標而可靠地運作的，支撐伺服器應用的一組電腦。它們通過使用高可用性軟體來管理叢集中的冗餘電腦，當系統組件出現故障時，這些電腦可以繼續提供服務。」簡單來說，就是有備援主機能在其中一台掛掉時接手，讓服務不中斷。 在接手 Kong 之前，我手上的系統也幾乎都是一個服務同時掛載在由兩個節點組成的 cluster 上，流量會透過 NLB(Network Load Balancer，網路負載平衡器)分流到兩個 node 上。 HA cluster 常見有兩種運作模式：Active-Passive 和 Active-Active。 Active-Passive 模式：一台節點（主節點）負責運行服務並處理所有流量，另一台節點則處於待命（備援）狀態，只有主節點故障時才會接手服務。 Active-Active 模式：兩台或多台節點同時運行服務，互相備援，平時都在積極處理流量。當其中一台節點故障時，其他節點會接手其服務。 所以，這次 control plane 採用的是 Active-Passive 模式。But why? 一定有什麼原因吧？（後來想起其實同事很久以前有說過，但我忘了，且當時也沒說那麼細，所以說做筆記很重要）。 Control plane v PostgreSQL Kong 的 Control Plane 負責集中管理 API Gateway 的所有設定、認證，以及 policy 和各種 plugins 的管理操作。不過 control plane 本身並不保存資料，只是管理和派送設定任務。所有設定與狀態資料都必須儲存在獨立運行的 PostgreSQL 資料庫裡，control plane 會以資料庫客戶端身份，透過網路連線到 PostgreSQL 資料庫伺服器，每次有設定變更、查詢、同步請求時都會讀寫這個資料庫。 根據官方文件1，PostgreSQL 不支援多台主機或多個資料庫 instance 同時掛載、讀寫同一份 data directory，否則可能會有資料毀損的風險。事實上，有人實驗過2，即使強行繞過 PostgreSQL 的檢查機制，在你啟用另一個 instance 時，原本掛載的 instance 也會被強制斷開。 ...

我喜歡在文章裡面放張圖，雖然現在 AI 生圖很方便，但還是喜歡放自然一點的，不論是自己拍的或是網路上看到的(from unsplash) 前言 在 Kong API Gateway 的日常維運中，Control plane 與 Data plane 的同步機制是個蠻值得關注的概念。最近在檢視公司架構圖時，我發現到 Control plane 與 Data plane 之間的 policy sync 方向標示為 Data plane 向 Control plane「拉取」最新設置。 簡單畫，公司實際架構圖沒這麼醜 在看到公司架構圖標示 Data plane 會「拉取」設定時，其實我一開始沒有多想，且防火牆確實只開了 Data plane 到 Control plane 的 8005 port。 但後來仔細思考，覺得這種設計有點奇怪——如果是 Data plane 不斷輪詢 Control plane 是否有設定變更，那輪詢頻率要怎麼抓？萬一設定異動很頻繁，會不會造成不必要的流量和效能浪費？而且從系統設計的角度來看，應該是由管理端（Control plane）主動通知執行端（Data plane）有異動才比較合理。這讓我開始思考，究竟同步機制的實際運作方式是什麼？ 這些疑問促使我去查官方文件，才發現實際上是 Control plane 主動推送設定(如下圖)，和我原本的認知有落差。 Control plane 與 Data plane 先簡單說明一下這兩個東西是什麼。 Kong Gateway 在 hybrid mode 下，有兩個重要的角色，分別為 Controle plane 與 Data plane，其功能分別為： ...

最近聽到幾個沒有聽過的名詞覺得蠻值得記錄一下，也算是跟 DevOps 有關。 綠地專案 vs. 棕地專案: 我們站在什麼樣的基礎上開發？ 這兩個詞彙本來是都市計畫的術語，我查是這樣，但我沒印象我大學時有學過，我記得以前是用「素地」來表示沒有建築物的土地。「素地」與「空地」不同，空地是指已有道路、排水、電力設施，可利用而仍未依法作建築使用，或已作建築使用，其建物價值不及基地申地價的 10%。 好，扯遠了，總之，這兩個詞用來比喻專案開發時所面對的環境。「綠地專案」指的是從頭開始的專案，而「棕地專案」指的是從既有的專案上開發。 對綠地專案而言，一切從頭開始，沒有既有專案的歷史包袱，理論上可以自由地選擇最新的技術、架構與工具，例如新創團隊開啟一個全新的專案，大概是這樣的概念。而相反地，棕地專案則像是在一塊已經開發過、甚至可能受到污染的「棕地」上進行翻新或擴建。開發團隊必須在既有的、可能充滿技術債的程式碼基礎上工作。例如我目前手上的專案全部都是棕地專案，充滿著大量 legacy code，牽一髮動全身的程式碼，讓我改起來膽戰心驚，到最後就很容易抱著能不改就不改的心態(If it works, don’t touch it.)。 總而言之，這表示在評估一個專案時，不能只看要開發的功能，更要理解它所處的狀況。是從零開始的創造？還是在既有框架下的奮鬥？這會影響策略的擬定。 平台工程(Platform engineering) 平台工程(Platform engineering)可將開發人員的部分工作和基礎架構相關手動作業移至 IDP(Internal Developer Platform)，讓團隊能專心開發應用程式及投入創新1。 這聽起來有些抽象，但可以想像如果在一間公司中，AP 人員(開發團隊)需要自己處理伺服器、資料庫、CI/CD 等 infra 上，那就是一種資源的錯置，這會讓開發人員無法真正專注於在開發上2。平台工程團隊的角色，就是將這些繁瑣但必要的工作，整合成一個自助式的平台。開發人員可以透過這個平台，完成環境建置、部署、監控等任務。 在我們的場景，例如伺服器、資料庫這類 infra，是不需要自己建置，我們是透過需求單系統，填寫工單請專責人員建置3，這中間要經過層層關卡（雙方主管）的審核，最後才會成功把需求傳遞到專責人員手上開始作業。而作業過程中依據 SOP 需要留存大量的「軌跡」，這些軌跡最後都有可能會被稽核檢視其是否合規。簡單來說，有平台，但不好用。 至於 CI/CD，我們在導入 Azure DevOps 後算是有完成了這一塊拼圖，建立起一個可用的平台，畢竟我們原本的部署上線方式真的令人太痛苦了，這個有機會以後可以再分享一下。 https://cloud.google.com/solutions/platform-engineering?hl=zh-TW ↩︎ 在敝公司雖然不用自己建置基礎設施，但很多時候都要自己管理，因為我們的角色某種程度上是開發人員兼維運人員。 ↩︎ 在《獨角獸專案》這本書當中看到無極限零件公司裡面也要填寫類似的工單系統時，令我倍感熟悉。 ↩︎