緯育 2026-0528

本次講座系列主要探討了軟體開發與部署的演進，從傳統手動部署的挑戰，到引入 CI/CD（持續整合/持續部署）、版本控制（Git）、容器化（Docker）與雲端技術（AWS）後的現代自動化流程。講師透過實作與理論結合的方式，帶領學員完成從程式碼開發、版本控制、容器封裝、雲端部署與權限管理的完整閉環。 系列課程首先介紹了傳統手動部署的痛點，如版本混亂、難以回溯及擴展性差，並引入 CI/CD 與 Jenkins 自動化打包流程以解決這些問題。接著，課程深入講解 Git 的核心概念與實務操作，包括分支管理、Pull Request、合併與認證方式（HTTPS Token）。

隨著課程推進，重點轉向容器化與雲端遷移。講師指導學員撰寫 Dockerfile，將應用程式封裝成 Docker 映像檔（Image），並推送到 Docker Hub。最後，將容器化的應用程式部署到 AWS EC2 實例上，並深入探討雲端環境下的權限管理，強調應使用 IAM 角色（Role）而非寫死金鑰（Access Key）來確保 EC2 與 S3 等服務間的安全通訊。整個過程旨在建立一個標準化、自動化且安全的開發與部署流程，並培養學員的流程思維與雲端架構觀念。

軟體部署的演進與挑戰

• 傳統手動部署流程與挑戰
  • 流程：開發者手動打包程式碼，透過網路磁碟機或訊息通知維運人員，再由維運人員手動登入實體伺服器進行部署。
  • 挑戰：
    • 版本控制脫鉤：打包與上線流程分離，易因人為失誤導致生產環境問題。
    • 擴展性不足：地端實體伺服器硬體擴充不易，缺乏彈性。
    • 回溯困難：版本出錯時，需人工找出舊版檔案重新部署，過程耗時且風險高。
• CI/CD 與雲端技術的導入
  • 初步自動化 (CI)：透過 Jenkins 等工具，監控 Git 倉庫，一旦主分支有更新，便自動拉取、打包並部署程式碼，減少人為介入。
  • 雲端架構：將後端伺服器從實體機遷移至雲端 EC2 實例，利用 CloudWatch 進行監控、IAM 進行權限管理、RDS 管理資料庫、Route 53 處理 DNS。雲端提供隨需擴展的彈性。
  • 容器化 (Docker)：為了解決本地與雲端環境不一致的問題，引入 Docker 將應用程式及其環境封裝成 Image，實現「一次建置，到處運行」。
  • 容器管理：可使用 EKS (Elastic Kubernetes Service) 等服務對容器進行管理。

DevOps 角色與 CI/CD 核心概念

• DevOps 角色與職責
  • Software Engineer (軟體工程師)：主要負責開發商業邏輯與功能。
  • DevOps Engineer (DevOps工程師)：負責系統上線後的持續監控與維運，確保基礎設施穩定。
  • System Architecture (SAA, 系統架構師)：負責規劃整體系統架構。
  • Site Reliability Engineer (SRE, 網站可靠性工程師)：負責確保雲端平台本身的品質與可靠性。
• DevOps 流程
  • 一個將開發（Dev）與維運（Ops）整合的自動化循環流程：規劃 -> 編寫 -> 建置 -> 測試 -> 發布 -> 部署 -> 維運 -> 監控 -> 回到規劃。
• CI (Continuous Integration, 持續整合)
  • 核心精神是頻繁將小的程式碼變更合併到主分支，並確保主分支永遠是「可上線的版本」。每次合併前都需通過自動化測試。
• CD (Continuous Delivery/Deployment, 持續交付/部署)
  • CI 流程的延伸，當 CI 階段成功後，自動化後續的部署工作。

Git 版本控制實務

• 核心概念
  • Repository (儲存庫)：專案資料夾，存放所有程式碼與版本紀錄。
  • Commit (提交)：每一個版本的紀錄點（本地操作）。
  • Branch (分支)：為開發新功能而開立的平行工作區，避免污染主線（main）。
  • Push / Pull：將本地變更推送到遠端 / 將遠端最新變更拉回本地。
  • Pull Request (PR)：開發者完成功能後，發起請求讓同事或主管審核程式碼，通過後才合併回主線。
• 實作流程

 1. git clone：從遠端（如 GitHub）複製專案到本地。
 2. git checkout -b <new-branch>：建立並切換到新的開發分支。
 3. 修改程式碼後，使用 git add . 將變更加入暫存區。
 4. git commit -m "訊息"：建立一個新的版本紀錄。
 5. git push origin <new-branch>：將新分支推送到遠端。
 6. 在 GitHub 上發起 Pull Request 進行程式碼審核。
 7. 審核通過後，執行 Merge 將程式碼合併回 main 分支。
 8. 合併後，應刪除已無用的開發分支。

• 認證方式
  • GitHub 已廢除使用帳號密碼進行 HTTPS 推送的方式。
  • 現在需使用 個人存取權杖 (Personal Access Token) 作為密碼進行認證。Token 僅在生成時顯示一次，需立即複製保存。

容器化 (Docker) 與雲端部署 (AWS)

• 開發與部署完整流程 (第三次部署)

 1. 需求與權限申請：當需要開發新功能（如上傳檔案至 S3），開發人員需向雲端管理員申請對應服務（S3）的操作權限。
 2. 本地環境設定：

• 管理員為開發人員或其群組授予 IAM Policy (如 AmazonS3FullAccess)。
• 管理員為開發人員生成存取金鑰 (Access Key ID & Secret Access Key)。
• 開發人員在本地安裝 AWS CLI，並使用 aws configure 配置金鑰，使本地環境具備操作 AWS 資源的能力。

 3. 本地開發與測試：

• 開發人員撰寫串接 AWS 服務（如 S3）的應用程式程式碼。
• 安全實踐：嚴禁將金鑰寫死在程式碼中。

 4. 容器化封裝：

• 在專案中撰寫 Dockerfile。
• 使用 docker build 將應用程式封裝成 Docker Image。
• 使用 docker run 在本地啟動容器，並透過端口映射 (Port Mapping) 進行功能驗證。

 5. 推送至映像檔倉庫：將驗證通過的 Docker Image 推送到 Docker Hub。
 6. 雲端部署與權限問題：

• 在 AWS 上啟動一台 EC2 實例（如 Amazon Linux 2023）。
• EC2 實例預設沒有權限存取其他 AWS 服務。直接在 EC2 內配置金鑰是不安全且錯誤的做法。
• 正確做法：建立一個 IAM 角色 (Role)，選擇其服務對象為 EC2，並為該角色附加所需權限的 Policy（如 S3 存取權）。
• 將此 IAM 角色指派給目標 EC2 實例。

 7. 遠端測試與驗證：

• 在 EC2 上安裝 Docker。
• 從 Docker Hub 拉取 Image 並啟動容器。
• EC2 上的應用程式會自動繼承實例的 IAM 角色權限，從而能夠安全地存取 S3 等服務。
• 設定 EC2 的安全群組（防火牆），開放相應端口，即可從外部訪問並測試服務。

 8. 版本控制迴圈：遠端測試通過後，回到 GitHub 發起 Pull Request，完成程式碼審核與合併，結束一個開發週期。