6 files changed, 36 insertions(+), 4 deletions(-)

M Sections/2.Backgrounds.tex
M Sections/4.Architecture.tex
A assets/web-helm-install-name.png
A assets/web-helm-install-repo.png
A assets/web-helm-install-values.png
A assets/web-helm-list.png

@@ 69,7 69,7 @@ Helm 用來產生 Kubernetes resources 的模板稱為 Helm Chart，Helm Charts 
     \caption{Helm 原理示意圖}
 \end{figure}
 
-Helm 使得在 Kubernetes 叢集上安裝軟體變得相當簡便，Helm Chart 已經成為相當常見的軟體交付手段。在生態系上，軟體開發者通常會於自己架設的 Helm Repository 提供產品的 Helm Chart。另外也存在第三方的業者對常見的開放原始碼軟體進行包裝，大量的提供 Helm Charts。
+Helm 使得在 Kubernetes 叢集上安裝軟體變得相當簡便，Helm Chart 已經成為相當常見的軟體交付手段。在生態系上，軟體開發者通常會於自己架設的 Helm Repository 提供產品的 Helm Chart。另外也存在第三方的業者（如 Bitnami）對常見的開放原始碼軟體進行包裝，大量的提供 Helm Charts。
 
 \section{Single-Page Application}
 

@@ 89,15 89,12 @@ Pods 作為 Kubernetes 中的重要角色之一，表示叢集上運行的容器
 
 \subsection{Helm 頁面與 Helm 功能實做}
 
-% TODO 圖
-
 對於 Helm 功能，我們希望保持 SPA 架構將部份邏輯推往瀏覽器端在運行成本上優勢，規劃在瀏覽器內實做。起初我們將 Helm 的函式庫直接透過 WebAssembly 包裝，並提供其以指令操作為切分單位的函式接口與 TypeScript 串接，但我們發現以此方式實做效能不佳，於列出已安裝的 Helm Release 等基本操作在低資料量下已產生足以影響使用者體驗的延遲。
 
 Helm Release 一般的儲存格式需要經過 Base64\footnote{Base64: 一個編碼格式，可將任何形式資料轉為文字表示。} 與 gzip\footnote{gzip: 一個被廣泛利用的資料壓縮演算法。} 等操作，如果將 Helm Release 的解讀透過 WebAssembly 處理，在不經調整的情況下呼叫的會是來自 Go 語言基本函式庫編譯成 WebAssembly 的 Base64 與 gzip 實做。WebAssembly 雖然設計上已經較為接近硬體，但仍是虛擬機架構，在運算上仍然有額外負擔。而 Base64 與 gzip 作為常用的算法，瀏覽器本身有提供高效能的實做。另外將資料傳送進出 WebAssembly 環境也有一定的執行成本。
 
 面對這個情景，我們面臨兩個可能的解法：抽換 Go 語言基本函式庫相關演算法改為呼叫瀏覽器的實做，或者將容易影響使用者體驗的區塊以 TypeScript 重新實做。抽換的方法仍然無法避免資料傳輸的負擔。而分析 Helm 架構可發現，除了模板引擎因為基於 Go 基本函式庫的模板框架，其設計容易牽涉語言特性而不易重新實做外，剩餘的區塊皆為一般的資料處理與 Kubernetes API 的串接。其中需要模板引擎的操作只有安裝、升級等使用者會預期需要時間的情景，不包含對使用者體驗影響重大的列出 Helm Release。綜上考量，我們將 Helm 模板引擎外的部份由 TypeScript 重新實做。
 
-% TODO 可能差異不是很明顯
 \begin{figure}[htb]
     \centering
     \includegraphics[width=\textwidth]{assets/web-helm-impl.png}


@@ 106,6 103,41 @@ Helm Release 一般的儲存格式需要經過 Base64\footnote{Base64: 一個編
 
 除此之外，瀏覽器執行程式碼的方式主要為單執行緒，不論 JavaScript 或 WebAssembly 邏輯皆是在與畫面繪製相同的執行緒執行，唯 JavaScript 語言上具有異步 IO 的特性，使得一般負擔主要在 IO 與事件處理的網頁程式碼具備可接受的效能。但我們的場景不同，Helm 的模板引擎運算量較多，在執行時容易拖累到畫面繪製，造成卡頓。對此，我們進一步採用 WebWorker 技術。WebWorker 提供一個較侷限的執行環境，但在獨立的執行緒運行，可以避面上述影響繪製的窘境，使用上開發者需自行處理 WebWorker 與瀏覽器的一般執行緒間的溝通。我們將安裝、升級、回滾、解除安裝的耗時的操作，包含 WebAssembly 的使用，在 WebWorker 環境下實做以改善使用者體驗。
 
+\begin{figure}[htb]
+    \centering
+    \includegraphics[width=\textwidth]{assets/web-helm-list.png}
+    \caption{CSKloud V3 網頁界面 Helm Releases 列表頁面}
+\end{figure}
+
+\begin{figure}[htb]
+    \centering
+    \begin{subfigure}{0.5\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/web-helm-install-repo.png}
+        \caption{選擇 Helm Chart}
+    \end{subfigure}%
+    ~
+    \begin{subfigure}{0.5\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/web-helm-install-values.png}
+        \caption{填寫 Helm Values}
+    \end{subfigure}
+    \begin{subfigure}{0.5\textwidth}
+        \centering
+        \includegraphics[width=\textwidth]{assets/web-helm-install-name.png}
+        \caption{命名 Helm Release}
+    \end{subfigure}
+    \caption{CSKloud V3 網頁界面 Helm Releases 安裝流程}
+\end{figure}
+
+界面上以 Helm Releases 表格呈現為主，可以展開觀看版本歷史，在每個項目旁有解除安裝、回滾、更新等按鈕，解除安裝會保留歷史，仍然可以將其裝回，也可以選擇刪除歷史。在畫面的右下角則是有浮動式的按鈕，可以觸發安裝新 Helm Release 的流程。
+
+在安裝的部份，由於我們是在瀏覽器內實做，能存取的 HTTP 服務受到對端的跨域政策影響。除非對端主動的表示允許，瀏覽器預設會限制網頁邏輯對其他域名服務的存取，作為增強安全性的一個手段。由於 Helm 傳統上並非在瀏覽器環境執行，Helm Repositories 大多不會特別放寬跨域政策，因此我們無法直接使用市面上大多數的 Helm Repositories。針對 CSKloud 的場景，因為可以預期部份 Charts 會因為平台加固等策略影響無法安裝，我們採用自行架設 Helm Repositories，並且只納入批量測試過可以安裝的 Helm Charts，目前共提供 32 個來自 Bitnami 的 Helm Charts。
+
+對於安裝的流程，在按下浮動式按鈕後，會跳出對話框進行三個步驟。第一是選擇要安裝的 Helm Chart，由一個可搜尋的列表選取。第二是填入 Helm Values，如同 Helm CLI 以 YAML\footnote{YAML: 一個資料標記語言，在 Kubernetes 生態系頗為常用，尤其是用來表達 Kubernetes resources。} 的形式填入，這裡界面上提供三個頁簽，一是填 Helm Values 的編輯器，二是顯示來自 Helm Chart 的 README 檔案，通常會在此提供常用選項的說明，三是 Helm Chart 內的 Helm Values 預設值檔案，慣例在此以註解的形式完整地對選項欄位說明。以 CSKloud 的場景，在編輯器上，會自動帶入針對 CSKloud 的第二層預設值，這個預設值來自測試安裝時所帶入的參數，調整如資源配額用量等選項，以確保在平台的限制下得以安裝，使用者也可以進一步進行修改。最後的步驟則是為此 Helm Release 命名，界面會自動預設一個隨機的名字。
+
+調整 Helm Values 的編輯器採用 CodeMirror 開源編輯器專案，除了 YAML 的基本語法高亮以外，我們採用 codemirror-json-schema 擴充元件提供進一步的資料驗證與欄位名稱自動補全。codemirror-json-schema 收取 JSON Schema 作為欄位定義，JSON Schema 是一個描述 JSON\footnote{JSON: 資料標記語言，與 YAML 的模型類似，語法較為容易以程式解析。} 資料的定義框架，但由於大多數 YAML 應用場景描述的資料也都可以由 JSON 的形式表達，也常用來描述 YAML 資料。部份 Helm Chart 會提供對其 Helm Values 的 JSON Schema 定義檔。
+
 \subsection{Quota 視覺化頁面}
 
 \subsection{Tokens 管理頁面}