TL;DR 概述 Git 上使用主幹開發策略的好處與一些 Trade-off 適用約 30 人左右的開發人數 背景 公司與 Side-project 大量使用短分支策略 近期發現在 Side-Project 沒有好好的說明，這套策略的使用方式 導致出現一些誤用 短分支策策略 主幹開發，最終回到 main 管理 以 feature 劃分，透過 branch 同步管理線...

最簡單的架構 可以用任何第三方 interface 介接，這邊以 Telegram Bot 為例 透過 TG 作為介面，在裡面埋一個 TG-Bot 作為訊息接收的 interface 這樣系統架構會接信下面這樣 而其中 QA Service 對 LLM SaaS 的 訊息發問 中，至少會需要附帶 System Prompt & User Prompt 兩個訊息 使用 LLM Saa...

TL;DR 透過 fluentbit 將服務 log 送到 OpenSearch 背景 公司 RD 發單詢問，想確認相關服務的 log 收集方式以及細節 正巧用這個機會，也讓自己多了解一下不同的 log 收集方式 Logging 在 GKE 用非侵入式的方式來收集 log 大概有兩種 Side Car：服務 Pod 外掛除了服務 container 以外，另一個專門收集 log 的...

TL;DR Techporn 平台對於網路流量管理 背景 我們選擇用 GKE 作為服務部署的平台 流量則透過 ingress-nginx 來做控制 核心：Ingress-Nginx 透過 Helm 部署的 ingress-nginx 會建立一個 ingress-nginx-controller 來管理相關的 ingress 同時，會在 GCP 建立 L4 的 Load-Balancer ...

TL;DR Topology Aware Routing(TAR)的設置 與流量分配機制 背景 公司最近服務開始要從單 zone 上到 multi-zone 起初因為，上到 multi-zone 之後，跨 zone 的傳輸費用暴增 故想透過設置 TAR 除了支援 mult-zone 以外一定程度減少跨 zone 的網路傳輸費用 設置 TAR 設置方式其實很簡單，只需要在服務的 svc 加...

TL;DR 藉由 cloudflare-tunnel 在 Kubernetes 內為 Grafana 搭建臨時的安全通道 背景 自己維護的 GKE 上有部署 kube-prometheus-stack 對服務做 metrics 的監控，但同時又不希望 Grafana 長時暴露在外，故規劃了一套由 事件驅動 來動態建立 cloudflare-tunnel 的 tunnel-worker-co...

TL;DR CI/CD 優化，pipeline 流程加速 背景 公司內部的 CI/CD runner 都是自建的 某個服務的 CI/CD 在 build 流程會需要超過 30 分鐘來完成 經過分析發現 image pull & build-script 兩個流程是比較費時的 而這兩個部分也有很直覺的優化方向 Pull Image 該 ghcr 是 github 上的 cont...

TL;DR Google Secret Manager(GSM) 集中管理機敏資料 Workload Identity(WI) 的方式賦予 External Secret Operator(ESO) 訪問 GSM 的權限 ESO 同步 GKE & GSM 的 secret 背景 有些服務會使用到環境變數 .env 以 kind: secret 的方式部署，在管理上不...

TL;DR 內部線路追查 問題根因確認 背景 公司內部 RD 他們後端為了降低負載，在前端有掛了 CDN 但近一週，卻還是有 client 直接到 server 端取資料的 log 而他們會有 log 有兩個情況 CDN 掛掉 client 端 timeout(2s), 改直接到 server 端取資料 問題追查 先透過 nslookup 確認服務打得 domai...

TL;DR 用 CRD 解決 CI/CD pipeline 可能導致的資源不匹配問題 背景 服務的部署拆成 project CI/CD 與 helmfile 而 project CI/CD 部署是透過 kubectl set image 的方式更新 container image 而當 project 的 GAR 若有更新，會因為 set image 是繞過 helm releas...