數位部《公部門開源軟體應用參考手冊》:Rails + PostgreSQL + Docker 自主開發重點
數位發展部開源軟體手冊摘要,聚焦以 Ruby on Rails、PostgreSQL、Docker 自主開發時的授權、資安、SBOM、上游優先、監控等實務注意事項。
數位部《公部門開源軟體應用參考手冊》:Rails + PostgreSQL + Docker 自主開發重點
來源:數位發展部(MODA)《公部門開源軟體應用參考手冊 / Public Sector Open-Source Software Playbook》,共 90 頁。
📄 原始文件:公部門開源軟體應用參考手冊(PDF)
手冊架構速覽
| 章節 | 內容 |
|---|---|
| 第一章 | 開源軟體介紹:背景、國際趨勢、授權條款類型、公共程式 |
| 第二章 | 應用評估:專有 vs 開源差異、效益風險、三種導入模式 |
| 第三章 | 導入方法:需求/開發/上線各階段注意事項、成果開源釋出 |
| 第四章 | 維護與營運:維運七重點、永續經營 |
三種導入模式
| 模式 | 說明 | 適用情境 |
|---|---|---|
| 應用(Adopt) | 直接採用現有成熟開源方案 | 通用功能(CMS、部落格、監控) |
| 整合(Integrate) | 組合多個開源方案客製開發 | 需求明確但無現成完整方案 |
| 自主開發(Self-built) | 從頭開發,技術完全掌控 | 關鍵或主權系統(Critical/Sovereign) |
手冊明確指出:醫療資訊系統、AI 模型、安全基礎設施等關鍵系統,建議以自主開發 + 開放優先為核心策略,確保技術自主性與長期維護彈性。
以 Rails + PostgreSQL + Docker 自主開發的注意事項
1. 授權風險(License)
手冊特別警示 GPL 授權的傳染性:若整合 GPL 元件,可能強制要求整個系統開源。
| 技術 | 授權 | 評估 |
|---|---|---|
| Ruby on Rails | MIT | 無限制,可私有部署 |
| PostgreSQL | PostgreSQL License(BSD-like) | 無 copyleft 風險 |
| Docker Engine | Apache 2.0 | 無限制 |
| Gem 相依套件 | 各自不同 | 需逐一掃描 |
實務做法:
# 掃描所有 gem 的授權
gem install license_finder
bundle exec license_finder
# 掃描安全漏洞
bundle exec bundler-audit check --update
2. 資安風險與 CVE 追蹤
開源軟體漏洞修補依賴社群,機關需主動建立監控機制,而非被動等待廠商通知。
graph TD
subgraph ci[CI/CD 管線]
A[git push] --> B[bundler-audit Gem 漏洞掃描]
B --> C[trivy Docker image 掃描]
C --> D[license_finder 授權合規掃描]
D --> E{全部通過?}
end
E -->|是| F[Deploy]
E -->|否| G[阻擋 + 通知]
訂閱安全公告:
- Rails:rubyonrails.org/security
- PostgreSQL:pgsql-announce mailing list
- Docker:docs.docker.com/security
自動化更新:啟用 Dependabot 或 Renovate Bot 自動提 PR。
3. SBOM(軟體物料清單)
手冊 54 頁:美國能源部要求資助的開源專案部署前必須提供完整 SBOM。台灣政府採購未來可能跟進。
SBOM 記錄系統所有直接與間接相依套件的名稱、版本、授權,是供應鏈安全的基礎。
# 產生 Rails 應用的 CycloneDX SBOM
gem install cyclonedx-ruby
cyclonedx-ruby -p . -o sbom.xml
4. 上游優先(Upstream First)
手冊 53 頁核心原則:避免「分支疲勞(Fork Fatigue)」。
若修改了 Gem 並維護自己的 fork,長期將面臨:
- 無法接收上游安全更新
- 與上游 API 漂移,升級成本激增
- 最終被迫自行維護整個套件
正確做法:
1. 優先將 bugfix/feature 貢獻回上游
2. 若必須 fork,設定每季 rebase 計畫
3. 避免在 Gemfile 用 path: 長期覆蓋套件
5. 版本控制與自動化治理
| 項目 | Rails 專案做法 |
|---|---|
| 版本控制 | Git + 清晰分支策略(main / staging / feature) |
| SBOM + CI/CD | 每次 PR 自動產生並比對 sbom.xml 差異 |
| 授權掃描 | CI 跑 license_finder,建立允許清單 |
| 漏洞掃描 | bundler-audit + trivy 掃 Docker image |
| 測試覆蓋率 | RSpec + SimpleCov,coverage ≥ 80% 才允許 merge |
6. 系統監控(維運階段)
手冊第四章推薦的開源監控工具組合:
graph TD
subgraph stack[監控技術棧]
Rails[Rails App] -->|yabeda-rails| Prom[Prometheus]
PG[PostgreSQL] -->|postgres_exporter| Prom
Docker[Docker containers] -->|cAdvisor| Prom
Prom --> Grafana[Grafana 儀表板]
Prom -->|alerting rules| Alert[AlertManager]
Alert --> Discord[Discord 通知]
end
# docker-compose 加入監控服務
services:
prometheus:
image: prom/prometheus
grafana:
image: grafana/grafana
ports:
- "3001:3000"
postgres-exporter:
image: prometheuscommunity/postgres-exporter
7. 關鍵或主權系統的特殊要求
手冊明確點名醫療資訊系統屬於關鍵系統,需額外注意:
- 分層設計:區隔公開部分與敏感資料層(對應 FHIR Gateway 作為 Outpost 的架構)
- 技術自主:避免單一廠商依賴,優先採用可替換的開放標準元件
- 個資保護:資料不得流出既定邊界,Docker 容器網路隔離
實務 Checklist
- [ ]
bundle exec license_finder建立授權允許清單 - [ ] CI/CD 加入
bundler-audit+trivy掃描 - [ ] 設定 Dependabot 自動更新相依套件
- [ ] 產生初始
sbom.xml並納入版本控制 - [ ] Prometheus + Grafana 監控環境就緒
- [ ] 訂閱 Rails / PostgreSQL 安全公告
- [ ] 確認無長期維護的私有 Gem fork
相關頁面
- DHH Citadel 架構 — 醫療系統採 Citadel 模式,Rails 為核心城堡
- SMART on FHIR 方法論 — FHIR Gateway 作為 Outpost 的技術背景