第四章 系統實作
第一節 開發設計 J UPYTER H UB
JupyterHub 是由 Python 撰寫而成的 module，其安裝方法即參照官網上的教 學，分為Python 原生 pip 以及 Anaconda 環境下的 conda 指令兩種下載形式，雖 然conda 下載較為便利迅速，但當 JupyterHub 要提供多人存取的功能，必須在 root 權限下執行，而 Anaconda 本身並無設置在 root 環境變數底下，因此在執行 多人存取時，環境配置會比較繁瑣，所以本研究選擇使用pip 的下載方式。
JupyterHub 採用輸入帳號密碼的登入形式，基於登入安全性，JupyterHub 在 0.7 版後就限制用戶建立平台時，必須透過 SSL 憑證機制，來確保使用者帳密不 會洩漏的風險。 本研究使用 Let’s Encrypt 網站來申請 SSL 憑證，不過 Let’s Encrypt 本身有時效，需要定期上去更新已申請的憑證序號。
使用者登入後，JupyterHub 會透過 Spawner 產生 Notebook Server 供使用者 使用，以伺服器角度來看，即為一個運行在伺服器上的程序(Proccess)，因此，
每個Notebook Server 的環境全都指向同一台伺服器，一旦有使用者不小心更改 到環境或是有惡意使用者想破壞環境，都會連坐影響到其他使用者，將會讓平台 的安全及穩定性大大降低。因此，透過Docker Cotainer 來包裝每個 Notebook Server，資源彼此隔離的概念則因應而生。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Docker Spawner
DockerSpawner [38]是讓原本生成於伺服器端的 Spawner，虛擬化後運行在 container 上，好處是除了能做到資源隔離外，還可以建立與伺服器截然不同的環 境，要如何辦到呢？即是Docker 映像檔的撰寫，而 Jupyter 已開發各式不同取向 的映像檔對應到notebook，像是適合開發科學計算的 Scipy notebook、開發神經 網絡的Tensorflow notebook、做統計分析的 R notebook 等。
以下為本研究改寫DockerSpawner Singleuser Dockefile 內容，透過以下內容 將notebook server 製成 image，形成平台使用者所需的環境，並透過 JupyterHub 進行分散式部署。
圖 四-1 DockerSpawner Single-user Dockerfile
（資料來源：本研究繪製）
‧
注意到上面有一行註解為「Disable Terminal」，由於 Jupyter Notebook 功能 十分強大，除了提供IPython 互動式介面外，也提供終端機服務，讓 Jupyter 平 要讓每個Container 都能安裝驅動程式並偵測出 GPU。以往要做到這點，中間過 程十分不方便，因為Docker 過去本身不支援 GPU，如果要在 Docker 上安裝 GPU，就需要在 Container 裡安裝 GPU 的驅動程式，最後再將主機上的 GPU 設 備映射至Container 上。由此可知，GPU 在 Container 上不具移植性，當要大量 產生含有GPU 的 Container，只能手動一個個安裝。
Nvidia Docker [39]則是上述問題的最佳解，直接去編寫 Docker Engine，讓 Docker 能支援 GPU 的 CUDA 驅動程式，就像是把 GPU 容器化一樣。透過 Nvidia Docker 讓開發者不需任何硬體上的修改即可輕易將應用程式包裝在能用 GPU 加 速的容器中，唯一只需確保此Docker 部署在有啟用 GPU 的伺服器上。下圖四-2 即顯示Nvidia Docker 的基礎架構。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 四-2 Nvidia Docker Architecture
（資料來源：[39]）
此外，在Dockerhub 上可以找到已裝好 CUDA 與 Cudnn 的映像檔，提供的 作業系統有Ubuntu、CentOS，而 CUDA 與 Cudnn 驅動程式的版本也是一應俱全，
因此，只要套用此映像檔再改寫先前DockerSpawner Singleuser 的 Dockerfile，即 能生成具有GPU 環境的 Jupyter Notebook。
以下為本研究二次改寫DockerSpawner Singleuser Dockefile 內容（僅節錄部 分內容），透過以下內容將notebook server 製成映像檔，形成具有 GPU 運行環 境的容器，並透過JupyterHub 進行分散式部署。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 四-3 Single-user with GPU Dockerfile
（資料來源：[39]）
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
Docker Swarm
JupyterHub 提供多個使用者存取，不過一旦使用者數目太高，伺服器的負載 能力就相對重要許多，若是Spawner 能遠端在其他伺服器端生成 Container，平 台本身的負擔將會大大降低，且增加其擴展性，使之成為足以負載數以萬計名使 用者的分散式架構平台。
Docker Swarm 是官方推出的容器集群平台，目的即是提高 Docker 的可擴展 性，技術架構採master-slave 形式，透過主節點的 Swarm Manager 去向子節點的 Swarm Node 溝通協商，並做到資源生成及調度等工作，而 Swarm 中建立彼此溝 通橋樑的後端服務有Consul、Zookeeper、etcd 等，甚至也能直接使用 DockerHub 作為後端服務。下圖為Docker Swarm 的結構圖：
圖 四-4 Docker Swarm 結構圖
（資料來源：[40]）
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
本研究使用Consul 作為後端服務，啟動 Consul 服務容器後，將之映射到主 機的8500 埠口上，再來分別啟動主節點的 Swarm Manger 及子節點的 Swarm Node，確保它們都有聆聽 8500 埠口，並讓 Manger 開啟主機的 4000 埠口，只要 訪問4000 埠口，即可得知 Swarm 所有節點的資訊及容器狀態。下圖分別表示集 群節點的資訊、Swarm 容器以及正在運行中的容器狀態。
圖 四-5 Swarm 集群的節點資訊
（資料來源：本研究繪製）
圖 四-6 Swarm Container 的運行狀態
（資料來源：本研究繪製）
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 四-7 所有 Container 的運行狀態
（資料來源：本研究繪製）
Shell Script 批次匯入
JupyterHub 使用者創建的方式分為兩種，一種是直接使用本機建立的使用者 做登入，另一種則是與Github 帳號互通並透過第三方認證做登入，基於管理上 的便利，本研究採第一種方式。當要建立多名使用者時，可以將Linux 指令寫成 Shell Script，如此一來就能輕鬆達到大量建立使用者的目的。
此外，為了避免使用者容器被破壞，導致notebook 裡的資料遺失，平台將每名 使用者容器均掛載到伺服器端的硬碟內，以保護使用者的檔案，而此動作也會一 併寫入Shell Script 中。
建立完的使用者要如何匯入JupyterHub 呢？Jupyterhub 裡有一個 whitelist 名 單，只要將使用者的帳號存進名單內，即可匯入至資料庫而被平台的
Authenticator 認證。因此，在 Shell Script 內，本研究會將建立好的使用者寫入至 userlist 檔案，再讓 Jupyterhub 定期輪詢 userlist，隨時更新已寫入使用者到平台 上。下圖為本研究為大量匯入使用者所撰寫的Shell Script。
‧ 國
立 政 治 大 學
‧
N a tio na
l C h engchi U ni ve rs it y
圖 四-8 創建使用者的 Shell Script
（資料來源：本研究繪製）