DevOps

AWS 跨區域遷移後的技術債清理：Strapi URL 的隱藏陷阱

接手專案，先看帳單因為老闆信用卡到期了要換新卡，我順便看了一下 AWS 帳單金額，發現比預期高。之前詢問外包商技術長（已離職），得到的回覆是：「服務都已經從新加坡遷移到台北了，除了 S3 有保留做備份，其他都刪除了。」身為工程師，最不能接受的就是「應該是這樣」。我決定親自盤點。名詞解釋在繼續之前，先解釋一下會提到的 AWS 服務：服務說明費用特性 S3 (Simple Storage Service) 物件儲存服務，用來存放檔案、圖片、影片按儲存容量和請求次數計費 NAT Gateway 讓私有子網路的資源能存取網際網路按小時計費，即使沒流量也要錢 Elastic IP 固定的公開 IP 位址使用中免費，未關聯則收費 VPC (Virtual Private Cloud) 虛擬私有網路，隔離你的雲端資源 VPC 本身免費，但相關資源收費 Network Load Balancer 負載平衡器，分散流量到多台伺服器按小時和處理的資料量計費 ECR (Elastic Container Registry) Docker 映像檔儲存庫按儲存容量計費重點是：有些資源即使沒有流量，只要存在就會收費。NAT Gateway 和未關聯的 Elastic IP 就是典型的「隱形殺手」。盤點遺留資源 # 檢查 EKS 叢集（Kubernetes 服務） aws eks list-clusters --region ap-southeast-1 # 結果：空的 ✓ # 檢查 RDS（資料庫） aws rds describe-db-instances --region ap-southeast-1 # 結果：空的 ✓ # 檢查 NAT Gateway aws ec2 describe-nat-gateways --region ap-southeast-1 \ --filter "Name=state,Values=available" # 結果：2 個還在跑完整盤點結果： ...

Kubernetes Staging 環境省錢術：從踩坑到正確實作

起因：老闆想省錢「Staging 環境平常沒人用，每個月還要燒 $45-60 美金，能不能想辦法省一點？」 Staging 環境的成本來自兩個地方：RDS 資料庫（約 $15-20/月）和 EKS 節點（約 $30-40/月）。既然平常沒在用，我想到了一個方案：不用的時候關掉，需要的時候再打開。於是我寫了兩個腳本： staging-start.sh：啟動 RDS、擴充節點、部署應用 staging-stop.sh：刪除部署、縮減節點、停止 RDS # staging-stop.sh 核心邏輯 kubectl delete deployment app-strapi-stg app-web-stg aws eks update-nodegroup-config \ --cluster-name my-cluster \ --nodegroup-name my-nodegroup \ --scaling-config minSize=0,maxSize=2,desiredSize=1 # 從 2 縮到 1 aws rds stop-db-instance --db-instance-identifier my-stg-rds 看起來很合理，但這裡有個問題：Production 和 Staging 共用同一個 nodegroup。踩坑：AWS 隨機選擇刪除節點執行 staging-stop.sh 縮減節點時，AWS 會隨機選擇要終止哪個節點。當時的配置：節點 A：運行 Production pods 節點 B：運行 Staging pods 我期望刪除節點 B，但 AWS 選了節點 A。Production pods 被強制遷移，觸發了重新調度。 ...

15 次 Build Failed：一場 Jenkins + Flutter CI/CD 的史詩級除錯之旅

前言：當 Build Failed 成為日常在過去的 19 個小時裡，我經歷了 15 次 build failed，產生了 15 個 fix commits。如果你覺得這很誇張，讓我告訴你更誇張的：最後一個 bug 是 git describe 在多個 tag 指向同一 commit 時會隨機返回其中一個。是的，隨機。在 CI/CD Pipeline 裡。這篇文章完整記錄這場除錯馬拉松，從最初的 Fastlane 版本問題，到 Discord 通知功能的實作與修復，再到 Ruby 相容性地獄，最後揭開 git 鮮為人知的行為。泡杯咖啡，這會是一段旅程。第一章：Fastlane 與 Bundler 的糾葛問題 1：Fastlane 版本不一致 Commit: fix(jenkins): use bundle exec for fastlane to ensure version consistency Jenkins 機器上有全域安裝的 Fastlane，但版本與 Gemfile.lock 指定的不同。這導致某些 action 行為不一致。 // Before: 使用全域 fastlane sh 'fastlane ios build' // After: 透過 Bundler 執行，確保版本一致 sh 'bundle exec fastlane ios build' 學習：在 CI 環境中，永遠使用 bundle exec 執行 Ruby 工具，確保版本與 lockfile 一致。 ...

在 Kubernetes 上部署 OV SSL 證書：完整實戰指南

為什麼選擇 TWCA OV 證書在生產環境中，使用自簽憑證會導致瀏覽器顯示不安全警告，影響使用者信任。雖然 Let’s Encrypt 提供免費的自動化證書，但某些企業或政府專案需要台灣在地的認證機構簽發證書以符合法規要求。 SSL 證書的三個等級 SSL 證書依據驗證強度分為三個等級：證書類型驗證內容適用場景信任標記價格 DV (Domain Validation) 僅驗證網域所有權個人網站、部落格 🔒 基本鎖頭免費～低 OV (Organization Validation) 驗證組織身份企業網站、SaaS 服務 🔒 組織名稱中 EV (Extended Validation) 嚴格驗證企業金融、電商、政府 🟢 綠色網址列高本文使用的是 TWCA OV SSL 證書，它提供： ✅ 組織身份驗證（瀏覽器可顯示公司名稱） ✅ 完整的證書鏈（受所有主流瀏覽器信任） ✅ 12 個月有效期 ✅ 台灣在地技術支援 HTTPS 與 SSL/TLS 運作原理在深入部署之前，先理解 HTTPS 如何保護資料傳輸： sequenceDiagram participant Browser as 瀏覽器<br/>(內建 TWCA 根憑證) participant Server as Web Server Note over Browser,Server: 1. TLS 握手階段 Browser->>Server: ClientHello (支援的加密套件) Server->>Browser: ServerHello (選擇的加密套件) Server->>Browser: 傳送證書鏈<br/>(伺服器證書 + 中繼憑證) Note over Browser: 2. 證書驗證（完全離線） Browser->>Browser: 用中繼憑證驗證伺服器證書 Browser->>Browser: 用內建根憑證驗證中繼憑證 Browser->>Browser: 檢查證書有效期與網域 Note over Browser: ✓ 證書有效 Note over Browser,Server: 3. 金鑰交換 Browser->>Server: 用公鑰加密的 session key Server->>Server: 用私鑰解密 session key Note over Browser,Server: 4. 加密通訊 Browser->>Server: 加密的 HTTP 請求 Server->>Browser: 加密的 HTTP 回應關鍵機制說明： ...

Vue.js SPA 社交分享完整指南：解決 Facebook/LINE OpenGraph 爬蟲問題

引言：當精美的網站變成分享時的「無名氏」在現代 Web 開發中，社交媒體分享功能是不可或缺的一部分。當用戶在 Facebook、LINE 或其他社交平台分享你的網站連結時，你希望顯示的是精美的預覽卡片，而不是空白或錯誤的資訊。然而，對於使用 Vue.js、React、Angular 等前端框架開發的單頁應用程式（SPA），這個看似簡單的需求卻隱藏著技術挑戰。本文將完整記錄從問題發現、原因分析、到解決方案實作的全過程。問題發現：為什麼分享連結總是顯示預設值？場景描述我的平台 www.abc.com 是一個基於 Vue.js 3 + Strapi CMS 的網站。某天，我發現一個嚴重問題：當用戶分享服務頁面（如 https://www.abc.com/service-us/6）到 Facebook 或 LINE 時，顯示的預覽資訊總是預設值，而非該服務的實際標題和描述。實際情況對比：情境期望結果實際結果分享服務頁面顯示「專業網站開發服務」顯示「ABCDEFG（預設標題）」分享部落格文章顯示文章標題與摘要顯示網站預設描述分享產品頁面顯示產品圖片與名稱顯示網站 Logo 診斷工具測試使用 Facebook Open Graph Debugger 測試後發現：爬蟲抓取到的 HTML： <!DOCTYPE html> <html lang="zh-TW"> <head> <meta charset="UTF-8"> <title>ABCDEFG</title> <meta property="og:title" content="ABCDEFG"> <meta property="og:description" content="預設網站描述">  </head> <body> <div id="app"></div> <script src="/assets/index.js"></script> </body> </html> ⚠️ 關鍵發現：爬蟲只看到靜態的 HTML 模板，完全沒有 JavaScript 執行後動態生成的 meta 標籤。 ...

深入理解 Kubernetes Pod：從基礎概念到實戰應用

前言：為什麼需要 Pod？在 Kubernetes 的世界裡，Pod 是一切的基礎。如果把 Kubernetes 比喻成一座城市，那麼 Pod 就是城市中的「最小住宅單位」。但為什麼 Kubernetes 不直接管理容器（Container），而要多一層 Pod 的抽象？簡單回答：因為容器太小，Pod 剛剛好。想像你要管理一座城市的住宅：如果直接管理每個「房間」（容器）→ 太細碎，管理成本太高如果直接管理整棟「大樓」（Node）→ 太粗糙，缺乏彈性所以我們需要「住宅單位」（Pod）→ 大小適中，便於管理本文將深入探討： Pod 的核心概念與設計哲學 Pod 的內部架構與運作機制 Pod 網路模型與通訊方式 Pod 生命週期與狀態管理 Pod 設計模式與最佳實踐實戰範例與 YAML 配置 Pod 核心概念：容器的邏輯主機什麼是 Pod？官方定義： Pod 是 Kubernetes 中最小的可部署計算單元，可以包含一個或多個容器，這些容器共享網路、儲存和其他資源。生活化比喻： graph TB subgraph "傳統虛擬機世界" VM1[虛擬機 VM] VM1 --> App1[應用程式 1] VM1 --> App2[應用程式 2] VM1 --> App3[應用程式 3] end subgraph "Kubernetes Pod 世界" Pod[Pod = 邏輯主機] Pod --> C1[容器 1] Pod --> C2[容器 2] Pod --> C3[容器 3] end style Pod fill:#4ade80 style VM1 fill:#60a5fa Pod 就像一個「邏輯主機」： ...

從 GitLab CI 到 Kubernetes 自動化部署：完整 CI/CD Pipeline 實戰指南

引言：打破手動部署的迷思「為什麼我的 CI 已經產出 prod-0.54，卻還得手動去跑 kubectl apply -f deployment.yaml？那不是多此一舉嗎？」如果你也曾陷入這樣的疑問，本文將從根本理清 CI/CD 與 Kubernetes 之間的分工，並學會如何「一鍵從程式碼到雲端服務」完全自動化。 CI/CD vs. Kubernetes：各司其職的完美搭檔在軟體開發的世界裡，GitLab CI/CD 和 Kubernetes 常常被搭在一起討論，卻扮演著截然不同的角色。 CI/CD 的職責：生產線 flowchart LR A[原始碼] --> B[Build Image] B --> C[Tag Version] C --> D[Push to Registry] D --> E[Docker Image Ready] GitLab CI/CD 的工作內容：建置（Build）：將程式碼打包成 Docker 映像標記（Tag）：為映像貼上版本號標籤（例如 0.54、v1.0.0）推送（Push）：把 Docker 映像推到映像庫（AWS ECR、Docker Hub） Kubernetes 的職責：配送中心 Kubernetes 的工作內容：部署（Deploy）：在叢集裡建立 Pod 並執行容器監控（Monitor）：監控運行狀況，Pod 死掉自動重啟更新（Update）：滾動更新（Rolling Update）時保證服務不中斷維運（Operate）：調整副本數量、健康檢查、網路規則分工比喻如果把軟體交付比喻成流水線： ...

如何使用 psql 連線 AWS RDS PostgreSQL 並在容器與 Pod 中操作

前言在現代雲端架構中，資料庫通常部署在受保護的私有網路環境（Private Subnet）中，以提升安全性。AWS RDS（Relational Database Service）作為主流的托管資料庫服務，提供了多種連線方式，但對於初學者來說，如何在不同環境（本機、Docker、Kubernetes）中正確連線到 RDS 往往充滿挑戰。這篇文章將深入探討： AWS RDS 網路架構：公有子網 vs 私有子網的差異直接連線方式：當 RDS 設為 Publicly Accessible 時 SSH 隧道（SSH Tunneling）：透過 Bastion Host 連線私有 RDS 容器環境連線：在 Docker 和 Kubernetes Pod 中使用 psql psql 完整命令參考：從基礎查詢到進階操作安全最佳實踐：如何保護資料庫連線與憑證常見問題排查：連線失敗的系統化診斷方法無論你是在本機開發、容器化部署、或是 Kubernetes 叢集中操作，這篇文章都能幫助你建立安全可靠的資料庫連線。 AWS RDS 網路架構概覽在開始連線之前，我們需要理解 AWS RDS 的網路架構。RDS 實例可以部署在不同的網路環境中，每種配置都有不同的連線方式和安全考量。公有子網 vs 私有子網 graph TB subgraph "AWS VPC" subgraph "Public Subnet (10.0.1.0/24)" IGW[Internet Gateway] Bastion[Bastion Host<br/>EC2 Instance] RDS_Public[RDS PostgreSQL<br/>Publicly Accessible: Yes<br/>10.0.1.100] end subgraph "Private Subnet (10.0.2.0/24)" RDS_Private[RDS PostgreSQL<br/>Publicly Accessible: No<br/>10.0.2.100] App[Application Servers<br/>ECS/EKS Pods] end subgraph "Security" SG_RDS[Security Group: RDS<br/>Inbound: 5432 from App] SG_Bastion[Security Group: Bastion<br/>Inbound: 22 from MyIP] end end subgraph "外部網路" Developer[開發者本機] Web[網際網路] end Web --> IGW Developer -->|SSH Port 22| Bastion Developer -->|psql Port 5432<br/>⚠️ 不安全| RDS_Public Bastion -.->|SSH Tunnel| RDS_Private App -->|psql Port 5432| RDS_Private RDS_Public -.->|套用| SG_RDS RDS_Private -.->|套用| SG_RDS Bastion -.->|套用| SG_Bastion style RDS_Public fill:#ffe1e1 style RDS_Private fill:#e1ffe1 style Bastion fill:#e1f5ff style Developer fill:#fff3e1 兩種部署方式的比較特性公有子網 (Publicly Accessible) 私有子網 (Private) 直接連線 ✅ 可以從網際網路直接連線 ❌ 無法直接連線安全性 ⚠️ 較低，暴露在公網 ✅ 高，完全隔離連線方式 psql 直連需要 Bastion Host / VPN 適用場景開發測試環境生產環境（推薦）成本 RDS 費用 RDS + Bastion Host 費用維護複雜度低中等（需管理 Bastion）最佳實踐： ...

整合 Google 登入至 Strapi：在 Kubernetes 上解決「Secure Cookie over Unencrypted Connection」的實戰紀錄

前言在現代 Web 應用開發中，提供第三方登入（Social Login）已經成為標準配備。相比傳統的帳號密碼註冊流程，使用 Google、Facebook、GitHub 等服務登入不僅能降低使用者註冊門檻，還能提升安全性（由大廠處理密碼儲存與驗證）。當我們決定為 Strapi CMS 後台加入 Google OAuth 登入時，原本以為只是個簡單的設定任務：在 Google Cloud Console 建立 OAuth 2.0 憑證在 Strapi 填入 Client ID 和 Client Secret 點擊「Login with Google」按鈕，完成！但現實總是更複雜。當應用部署到 Kubernetes 叢集後，我們遇到了一個令人困惑的錯誤訊息： Error: Cannot send secure cookie over unencrypted connection 這個錯誤訊息背後，牽涉到 HTTP/HTTPS 協定、Proxy Trust 機制、Kubernetes Ingress 架構、以及瀏覽器 Cookie 安全策略等多層知識。這篇文章將完整記錄我如何一步步拆解問題、理解根本原因、並最終在生產環境中實現安全可靠的 Google 登入功能。 OAuth 2.0 授權碼流程基礎在深入問題之前，我們先理解 Google OAuth 登入的完整流程。OAuth 2.0 提供了多種授權模式（Grant Types），而 Web 應用最常使用的是「授權碼模式（Authorization Code Flow）」。 sequenceDiagram participant U as 使用者瀏覽器 participant S as Strapi CMS<br/>(你的應用) participant G as Google OAuth Server participant A as Google Authorization Server Note over U,A: 第一階段：取得授權碼 U->>S: 1. 點擊「Login with Google」 S->>U: 2. 重導向到 Google 授權頁 Note right of S: redirect_uri=https://cms.example.com/api/connect/google/callback U->>G: 3. GET /o/oauth2/v2/auth?client_id=...&redirect_uri=... G->>U: 4. 顯示 Google 登入頁面 U->>G: 5. 輸入帳號密碼，同意授權 G->>U: 6. 重導向回應用 (帶著授權碼) Note right of G: https://cms.example.com/api/connect/google/callback?code=AUTH_CODE Note over U,A: 第二階段：用授權碼換取存取權杖 U->>S: 7. GET /api/connect/google/callback?code=AUTH_CODE S->>A: 8. POST /token (帶著 code + client_secret) A->>S: 9. 回傳 access_token + id_token S->>A: 10. 驗證 id_token，取得使用者資料 A->>S: 11. 回傳使用者 email, name 等資訊 Note over U,S: 第三階段：建立 Session (問題發生點！) S->>S: 12. 建立或更新 Strapi 使用者記錄 S->>S: 13. 建立 Session，準備設定 Cookie Note right of S: ⚠️ 這裡檢查連線是否為 HTTPS S->>U: 14. Set-Cookie with Secure and HttpOnly flags U->>S: 15. 後續請求帶著 Cookie 這個流程中有幾個關鍵點： ...

解決 Strapi CMS 正式環境空白頁的踩坑經驗分享

前言：一個簡單的環境變數引發的災難在部署 Strapi CMS 到 Kubernetes 正式環境時，只是加了一行看似無害的環境變數設定： env: - name: NODE_ENV value: production # 就是這一行！結果卻導致整個管理後台變成一片空白，連登入頁面都看不到。更詭異的是： ✅ API 完全正常，GraphQL 和 REST 都能回應 ✅ Pod 狀態正常，沒有任何錯誤訊息 ✅ 日誌顯示 Strapi 成功啟動 ❌ 瀏覽器打開 /admin 卻是一片空白這種「Schrodinger 的服務」（同時正常又不正常）讓人抓狂。經過一番排查，終於發現罪魁禍首是 CSP (Content Security Policy) 在作怪。本文將深入探討：為什麼正式環境會出現空白頁 CSP 的工作原理與安全機制完整的問題排查步驟如何正確配置 Strapi 的安全策略生產環境的安全最佳實踐問題背景：開發正常，正式環境空白環境差異對比 graph LR subgraph "開發環境 (Development)" D1[NODE_ENV=development] D1 --> D2[✅ CSP 寬鬆] D1 --> D3[✅ 詳細錯誤訊息] D1 --> D4[✅ Hot Reload] D2 --> D5[✅ Admin Panel 正常] end subgraph "正式環境 (Production)" P1[NODE_ENV=production] P1 --> P2[🔒 CSP 嚴格] P1 --> P3[⚠️ 精簡錯誤訊息] P1 --> P4[📦 壓縮打包] P2 --> P5[❌ Admin Panel 空白] end style D5 fill:#22c55e style P5 fill:#ef4444 問題現象詳細描述 Kubernetes Deployment 設定： ...