緯育 2026-0529.2

本次系列課程全面回顧並實作了軟體開發與部署的完整生命週期，從傳統的一次性部署、版本控制（Git）、容器化（Docker），一路演進到雲端服務的整合與應用（AWS S3、EC2、App Runner、ECS）。課程的核心目標是讓學員掌握從開發、封裝、部署到維運的現代化流程，並引入了系統監控與安全的關鍵概念。 課程內容涵蓋了以下主要階段：

1. 基礎開發與部署：複習了從傳統部署到容器化的演進，以及使用 Git 進行版本控制與團隊協作的流程，並預告了可能發生的版本衝突問題。

2. 系統監控與告警：引入 AWS CloudWatch，模擬產品上線後因使用者增多導致的高 CPU 負載情境，指導學員設定監控指標與告警通知。

3. 自動化與問題排查：介紹使用 EC2 User Data 實現自動化安裝，並釐清常見的連線與埠號映射（Port Mapping）問題，強調紀錄與回報的重要性。

4. 資安事件模擬與追蹤：透過「第五個故事線」，模擬內部攻擊（IAM 帳號被竊），並利用 AWS CloudTrail 追蹤與調查惡意操作，學習如何從日誌中找出事件行為者與時間點。

5. 部署模式演進：比較了傳統 EC2 虛擬機部署與現代容器化託管服務（如 App Runner、ECS Fargate）在監控思維、成本效益與維護性上的根本差異，強調容器化「順開順關」、「用後即毀」的優勢。

6. 雲端產業生態與 AI 應用導入：探討了雲服務產業鏈（原廠、代理商、客戶）、稅務發票問題，並實際操作部署一個多容器 AI 應用平台（Dify），指導學員建立 AI 引擎、配置大型語言模型（LLM）與知識庫，並透過 AWS Bedrock 取得雲端 AI 算力。

總體而言，課程透過一系列的「故事線」與實作練習，讓學員從技術操作、業務目標、系統監控到安全防護，建立起一套完整的雲端 DevOps 知識體系與實戰能力。

軟體開發與部署演進

• 從傳統到容器化：課程回顧了從早期一次性部署的不穩定性，到導入容器（Container）以確保環境一致性的演進過程。
• 版本控制 (Git)：
  • 基礎流程：涵蓋 git init、git add、commit，以及與遠端儲存庫的互動。
  • 分支管理：為開發新功能開設新分支（feature branch），以確保主分支（main/master）的穩定性，開發完成後再合併。
  • 團隊協作衝突：當多位開發者同時工作時，若本地儲存庫未及時與遠端同步，提交時會發生版本衝突。解決方案包括使用 git fetch 和 git pull 同步遠端最新狀態。
• 容器化 (Docker)：
  • 核心概念：為了解決開發、測試與生產環境不一致及相依性問題，採用 Docker 將應用程式封裝成映像檔（Image）。
  • Docker Compose：用於整合並管理多個 Docker 容器，透過 docker-compose.yaml 設定檔，可在本地一鍵啟動包含應用、資料庫等多個服務的複雜系統，完整模擬生產環境。
  • 映像檔儲存庫：打包好的映像檔需上傳至容器映像檔儲存庫（Container Registry），如公開的 Docker Hub 或企業內部的私有儲存庫（如 AWS ECR）。

雲端部署與架構 (AWS)

• 部署模式比較：
  • 傳統虛擬機 (EC2)：監控整台機器的資源（CPU、網路），成本基於運行時長計算，需長期維護，壓力較大。
  • 容器化託管 (ECS Fargate, App Runner)：監控轉向以「請求」為中心（請求次數、成功/失敗率、反應時間），成本基於容器實際運行的「計次」或「計時」模式。容器「用時即開，用完即毀」，大幅降低維護壓力與閒置成本。
• EC2 自動化與設定：
  • User Data：可利用 EC2 的 User Data 功能，在實例啟動時自動執行腳本（如安裝軟體、拉取程式碼），減少手動重複操作與錯誤。
  • 連線與埠號映射：需釐清應用程式實際監聽的埠號與對外映射的網路埠號，避免因設定混亂導致服務無法訪問。
• 雲端服務整合：
  • 靜態資源 (S3)：利用 S3 儲存靜態檔案，解決傳統硬碟擴充問題。需注意權限設定與安全配置。
  • 權限管理 (IAM)：
    • IAM Role：透過為 EC2 實例配置 IAM 角色，安全地授予其存取其他 AWS 服務（如 S3）的權限，是雲端服務間互動的標準做法。
    • IAM User：為程式化存取（如本地開發）建立專用 IAM 使用者，並產生 Access Key ID 與 Secret Access Key。
    • 安全性提醒：嚴禁將 Access Key 等敏感憑證硬編碼在程式碼中，以免造成嚴重安全風險。

系統監控與安全

• 系統效能監控 (CloudWatch)：
  • 重要性：當產品上線後，為掌握系統運行狀態、及時發現並處理效能問題（如高 CPU 負載），必須進行監控。
  • 實作：學習瀏覽 AWS CloudWatch，監控 CPU 使用率等指標，並設定當指標超過阈值（如 70-80%）時，自動寄送 Email 的警報規則。
  • 告警延遲：需注意告警的數據回報頻率與觸發條件，這會影響收到通知的延遲時間。
• 帳號行為監控與資安 (CloudTrail)：
  • 情境：模擬駭客透過社交工程等方式盜用公司同仁的 AWS 帳號，並執行惡意操作（如刪除主機）。
  • 目的：當發生資安事件時，需能追查「哪個帳號」在「什麼時間」做了「什麼事」。
  • 工具：使用 AWS CloudTrail 追蹤並記錄帳戶的行為軌跡與管理事件。透過檢視其事件記錄，可以找出異常操作的行為者與時間點，完成事故調查與證據保全。
  • 限制：CloudTrail 的紀錄並非即時，可能需要等待數分鐘才會顯示。

AI 應用平台建構與實作 (Dify)

• AI 引擎概念：
  • 將 AI 引擎比喻為新進員工，其核心組成包括：
    • 智商 (大型語言模型 LLM)：相當於大腦，決定了 AI 的能力與準確度（如 Anthropic Claude、Amazon Titan 等）。
    • 知識 (Knowledge)：相當於產品手冊，需提供專屬的知識庫（如上傳 CSV 檔案），AI 才能根據特定資料回答問題。
• 平台操作 (Dify)：
  • 環境建置：透過 Docker Compose 在本地啟動 Dify 多容器應用平台。
  • 引擎建立：在 Dify 中建立 AI 引擎，為其命名、選擇 LLM，並設定行為指令 (Prompt)。
  • 知識庫整合：建立知識庫並上傳資料檔案，再將其與 AI 引擎關聯，使其具備回答特定領域問題的能力。
  • 混合檢索：可設定為「混合檢索」模式，並配置 Embedding 模型與 Re-rank 模型以優化搜尋結果。
• 連接雲端 AI 算力 (AWS Bedrock)：
  • 原理：本地的 Dify 平台本身不具備 AI 算力，需透過 API 調用外部模型供應商的服務。
  • 設定：在 Dify 平台中安裝並設定模型供應商（如 Bedrock），並配置從 IAM 使用者取得的 Access Key，讓本地應用能安全地調用 AWS 雲端上的 AI 模型進行推理。
• AI Workflow 概念：
  • 單一 AI 引擎不一定會完全按照預設流程執行任務。對於需要特定順序的複雜任務（如工業流水線），未來將學習設計 AI Workflow，將多個 AI 引擎串聯成一條自動化處理流程。

產業生態與實務

• 雲端服務產業鏈：
  • 原廠 (AWS, GCP, Azure)：提供核心服務，但直接購買常因稅務規定無法取得台灣發票。
  • 代理商：在台灣銷售原廠服務，可開立台灣發票以滿足企業報帳需求，並提供在地技術支援（SLA）。
• 技術職涯與行業現況：
  • 討論了教學工作的挑戰、學術界與業界的人才薪資差距，以及部分行業中存在的「套現」（如刷卡賺取點數或里程）文化。
• 多雲端策略：即使是市場領導者也可能出現服務中斷，因此準備備援方案（如 AWS 異常時切換至 GCP）對企業至關重要。