Kubernetes

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: strapi_session=...; Secure; HttpOnly 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 設定： ...

解決 Kubernetes 多餘 Pod 問題與 CrashLoopBackOff 的實戰心得

前言：一次神秘的 Pod 複製事件在一次例行的 Strapi CMS 更新部署到 AWS EKS 時，遇到了一個詭異的現象：明明 Deployment 設定檔中清楚寫著 replicas: 1，但實際運行的 Pod 卻有兩個！更奇怪的是，其中一個 Pod 持續處於 CrashLoopBackOff 狀態，而另一個則正常運行。無論怎麼刪除多餘的 Pod，它總是會像打不死的蟑螂一樣再次出現。這種「靈異事件」讓我開始懷疑 Kubernetes 是不是有自己的想法… 本文將深入探討：為什麼會出現多餘的 Pod CrashLoopBackOff 背後的機制 Kubernetes Deployment 和 ReplicaSet 的運作原理實戰排查步驟與解決方案 Secret 編碼陷阱與預防措施問題背景：Deployment 說一個，實際卻有兩個問題現象預期行為： # my-strapi-prod-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: my-strapi-prod spec: replicas: 1 # 只要 1 個 Pod selector: matchLabels: app: my-strapi-prod 實際情況： $ kubectl get pods -n default | grep my-strapi-prod NAME READY STATUS RESTARTS AGE my-strapi-prod-7d4b5c8f9d-x2k4p 1/1 Running 0 10m my-strapi-prod-8c9a6d7e5f-w8n2q 0/1 CrashLoopBackOff 5 5m 兩個 Pod 同時存在，卻只有一個正常運行！ ...