Keycloak.X 更新

如前所述，我們將更加關注您使用 Keycloak 的體驗。考慮到這一點，我們確定了一些我們認為涵蓋廣泛不同用例的體驗

我們正在切換到 Quarkus 作為建構 Keycloak 的平台。與 WildFly 相比，這提供了更快的啟動時間和更低的記憶體佔用。它還提供了一種更簡單的 Keycloak 配置方法，使用命令列引數和環境變數，而不是複雜的 XML 檔案。Quarkus 的另一個優點是，它可以讓我們更好地控制發行版中包含哪些外部函式庫，包括更快地升級依賴項，這應該可以顯著改善 CVE 周圍的情況。

我們正在對 Keycloak.X 的儲存層進行重大重新架構，以解決當前架構中發現的一些缺點。零停機升級、可擴展性和可用性將是這個新架構的重點，並且從長遠來看，它將更容易支援其他儲存類型。

以目前 Keycloak 中的配置方法，在容器周圍建立良好的體驗是有問題的，因為容器必須從環境變數轉換為複雜的 XML 配置檔案。透過我們在 Quarkus 周圍所做的工作，使用環境變數配置 Keycloak 成為一種原生方式，使其更容易提供絕佳的容器體驗。

同樣地，Operator 也可以更簡單，因為配置 Keycloak 會更容易，並且從基本發行版中獲得更好的見解配置，這會從 Zip 發行版、容器，最後到 Operator。為了更對齊程式碼庫，我們還使用 Java SDK 和 Quarkus 從頭開始重寫 Operator。

指標、追蹤、記錄和健康檢查是雲原生應用程式的所有重要方面。這些都是在生產環境中管理和偵錯 Keycloak 的重要功能，尤其是在 Kubernetes 或 OpenShift 上執行時。

在 GitOps 或 CI/CD 環境中，管理 Keycloak 內的執行階段配置可能會出現問題。由於所有配置（例如領域和用戶端）都位於資料庫中，並且只能透過 REST API 進行管理，因此很難作為 GitOps 流程的一部分進行可靠的管理。

隨著儲存重新架構的到來，一種非常強大的功能可以從多個來源聯合配置，我們計劃利用它來使用基於檔案的儲存，Keycloak 可以從檔案系統（當然是 YAML）讀取更多靜態/不可變的配置，並將其與來自資料庫的動態/可變配置結合起來。

此外，這使得您可以將靜態配置檢入 Git 儲存庫，並根據需要將其部署到您的開發、測試和生產環境。

Keycloak 今天有大量的擴充點，稱為 SPI。透過 Java（在某些情況下是 JavaScript），可以使用這些 SPI 的自訂提供者來客製化 Keycloak。雖然功能強大且靈活，但在以現代 Kubernetes 為中心的架構中，這並非理想。由於擴充功能與 Keycloak 共置，因此更難以部署、升級和擴展擴充功能。擴充功能也不能用任何語言或框架編寫，這使得非 Java 開發人員擴充 Keycloak 的成本更高。

考慮到這一點，我們計劃更加關注透過遠端擴充來擴充和整合 Keycloak 的能力，並且正在研究 REST、gRPC、Knative、Kafka 等作為實現此目的的途徑。此外，我們還希望達到可以擁有「無頭」Keycloak 的程度，允許您以任何想要的方式建構前端，這將為當前自訂 UI 的主題方法帶來巨大的補充。

最後但並非最不重要。我們還計劃能夠分解 Keycloak，並在 Keycloak 的程式碼庫和功能上帶來更好的隔離。我們不打算在這裡採用完整的微服務架構，而是一種合理的妥協方案，允許一切作為單一程序執行，並能夠將 Keycloak 的某些部分分離到外部服務中。