前言

完成了作業系統層級的參數微調與 PostgreSQL 資料庫的穩固建置後，我們現在具備了運行企業級品質掃描器的完整條件。本篇將透過 Docker 技術啟動 SonarQube 伺服器，並深入探討如何配置「品質門禁（Quality Gate）」與「Webhook」，建立起掃描結果與自動化 workflow 之間的連動機制。

持久化架構設計：磁碟區掛載策略

為了確保 SonarQube 的外掛程式、掃描歷史、系統日誌以及配置檔案不會因容器重啟而丟失，我們必須在宿主機建立標準化的掛載路徑。

# 建立結構化的持久化目錄
sudo mkdir -p /home/sonarqube/data /home/sonarqube/extensions /home/sonarqube/logs /home/sonarqube/conf

# 核心技術細節：權限校正
# SonarQube 內部程序以非 root 使用者執行，必須開放適當權限以利 Elasticsearch 寫入
sudo chmod -R 777 /home/sonarqube

啟動 SonarQube 核心容器

使用以下指令啟動 SonarQube LTS 版本。請確保連線字串（JDBC URL）指向我們在 Day 11 建立的 PostgreSQL 17 實例。在生產環境中，我們會將此容器部署在內部伺服器，並透過 <REVERSE_PROXY_IP> 的 IIS Reverse Proxy 對外提供 https://ci-cd.example.com/sonarqube/ 服務。

sudo docker run -d --name sonarqube-server \
    -p 9000:9000 \
    -e SONAR_JDBC_URL="jdbc:postgresql://<REVERSE_PROXY_IP>:5432/sonarqubedb" \
    -e SONAR_JDBC_USERNAME=sonarqube \
    -e SONAR_JDBC_PASSWORD=YourStrongPassword \
    -v /home/sonarqube/data:/opt/sonarqube/data \
    -v /home/sonarqube/extensions:/opt/sonarqube/extensions \
    -v /home/sonarqube/logs:/opt/sonarqube/logs \
    -v /home/sonarqube/conf:/opt/sonarqube/conf \
    sonarqube:lts-community

為了強化審計能力，建議在 extensions/plugins 目錄中預先放置 sonar-cnes-report 插件，以便後續產出合規性報表。

自動化防禦機制：Quality Gate 與 Webhook 深度整合

1. 品質門禁 (Quality Gate)

Quality Gate 是 CI/CD 流程中的「硬性指標」。它定義了專案必須達標的門檻，例如：「新增程式碼的測試覆蓋率必須大於 80%」或「不允許存在任何高等級的安全性漏洞」。這讓品質評估從主觀判斷轉向客觀數據驅動。

2. Webhook 實施反向通知

為了讓 Jenkins 在啟動掃描後能即時獲知結果，我們必須透過 Webhook 實施通知機制。

• 配置路徑：Administration -> Configuration -> Webhooks。
• 核心 URL 設定：https://ci-cd.example.com/jenkins/sonarqube-webhook/。
• 運作機制：當掃描完成且判定產出時，SonarQube 會主動向該 URL 發送 JSON Payload，驅動 Jenkins Pipeline 繼續執行或立即中斷。

安全性憑證：生成 Jenkins 專用 Token

為了確保 Jenkins 能向 SonarQube 推送掃描數據，需生成具備適當權限的 Token。

1. 進入 My Account -> Security -> Generate Tokens。
2. 類型選擇 User Token，並將生成的字串妥善保存於 Secret Store 中。

結語

我們已成功建立了 CI/CD 體系中的品質裁判。透過 Docker 的持久化部署，我們獲得了穩定的基礎；透過 Quality Gate 與 Webhook 的配置，我們則為自動化流程注入了決策靈魂。

在完備了品質管理平台後，明天的文章我們將轉向交付流程的核心，探討如何安裝與建置 Jenkins 核心系統。