Strapi

前言：一個簡單的環境變數引發的災難 在部署 Strapi CMS 到 Kubernetes 正式環境時，只是加了一行看似無害的環境變數設定： env: - name: NODE_ENV value: production # 就是這一行！ 結果卻導致整個管理後台變成一片空白，連登入頁面都看不到。更詭異的是： ✅ API 完全正常，GraphQL 和 REST 都能回應 ✅ Pod 狀態正常，沒有任何錯誤訊息 ✅ 日誌顯示 Strapi 成功啟動 ❌ 瀏覽器打開 /admin 卻是一片空白 這種「Schrodinger 的服務」（同時正常又不正常）讓人抓狂。經過一番排查，終於發現罪魁禍首是 CSP (Content Security Policy) 在作怪。 本文將深入探討： 為什麼正式環境會出現空白頁 CSP 的工作原理與安全機制 完整的問題排查步驟 如何正確配置 Strapi 的安全策略 生產環境的安全最佳實踐 問題背景：開發正常，正式環境空白 環境差異對比 問題現象詳細描述 Kubernetes Deployment 設定： apiVersion: apps/v1 kind: Deployment metadata: name: strapi-prod namespace: default spec: replicas: 1 selector: matchLabels: app: strapi template: metadata: labels: app: strapi spec: containers: - name: strapi image: myregistry.com/strapi:v5.0.0 env: - name: NODE_ENV value: production # 問題的起點 - name: DATABASE_HOST valueFrom: secretKeyRef: name: strapi-db-secret key: host - name: ADMIN_JWT_SECRET valueFrom: secretKeyRef: name: strapi-admin-secret key: jwt-secret ports: - containerPort: 1337 部署後的症狀： ...

前言：一次神秘的 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 同時存在，卻只有一個正常運行！ ...

客製化UI & Components Strapi 5 客製化UI & Components 發現: https://design-system.strapi.io/?path=/docs/getting-started-welcome–docs 在@strapi/design-system, 目前無法更改底層 https://docs.strapi.io/dev-docs/customization “Some parts of the admin panel can be customized.” 覆蓋樣式：使用自定義 CSS 或樣式覆蓋，而非直接改動源碼。(目前朝此方向研究)

前言 在開發 Strapi 後台管理系統時，我遇到一個實際的使用者體驗問題：在「已購買課程」列表中，管理員可以用「真實姓名」搜尋到用戶的購課記錄，但用「電話號碼」卻搜尋不到。這個不一致的行為讓管理員感到困惑。 本文將分享如何在 Strapi v5 中實作自訂搜尋邏輯，讓 Admin 面板支援跨關聯的多欄位搜尋。 問題場景 資料結構： purchased-course（已購買課程）：關聯到 user user（用戶）：包含 email、realName、phoneNumber、username、nickname 等欄位 問題現象： ✅ 搜尋「真實姓名」→ 可以找到對應的購課記錄 ❌ 搜尋「電話號碼」→ 找不到任何結果 為什麼會這樣？ 因為 Strapi 預設的搜尋功能只會搜尋當前 Collection 的直接欄位，不會自動搜尋關聯表（relation）的欄位。當我們在 purchased-course 列表搜尋時，Strapi 只會在 purchased-course 本身的欄位中搜尋，而不會去搜尋關聯的 user 資料。 解決方案架構 Strapi 提供了三個層級可以自訂搜尋邏輯： 1. Controller 層（API 端點） 位置： src/api/purchased-course/controllers/purchased-course.ts 用途： 處理前端透過 REST API 的搜尋請求 2. Service 層（業務邏輯） 位置： src/api/purchased-course/services/purchased-course.ts 用途： 封裝可重複使用的業務邏輯 3. Content Manager Plugin Extension（Admin 面板） 位置： src/extensions/content-manager/strapi-server.ts 用途： 最重要！ 這是讓 Admin 面板搜尋生效的關鍵 ...

前言:從本地開發到雲端生產環境 本文將深入解析一個全端專案在 AWS 上的完整基礎設施架構,展示如何透過 Kubernetes (EKS) 實現高可用性、可擴展性和成本效益的生產環境。這個平台提供線上課程、預約服務、會員管理和金流整合等功能。 本文涵蓋內容: 完整的 AWS EKS 叢集架構 Strapi CMS 和 Vue.js 前端的容器化部署 Jenkins CI/CD 自動化部署流程 Ingress NGINX 負載均衡和 SSL 憑證管理 與 AWS RDS、S3、ECR 的整合 第三方服務整合 (Firebase FCM、台灣金流) 監控與日誌管理 架構概覽 整體架構圖 核心技術棧 基礎設施層: AWS EKS 1.32.9 (Kubernetes 託管服務) AWS EC2 (ARM64 架構 - t4g.medium) AWS RDS PostgreSQL (託管資料庫) AWS S3 (物件儲存) AWS ECR (容器映像倉儲) AWS ELB (負載均衡器) CI/CD 層: Jenkins (Mac mini 本地部署) Docker (容器建置) kubectl (Kubernetes 部署工具) 應用層: ...