開啟 JupyterLab
開啟按鈕
部署一個啟動模式為 jupyter 的範本，等執行個體進入 running，然後從 執行個體 開啟它。連線 頁籤上有一個 開啟 JupyterLab 按鈕。它會在新分頁中直接把你帶進一個已通過驗證的工作階段。
這個按鈕是官方支援的進入方式。不要自己拼出網址，也不要依賴書籤：執行個體發布所在的主機與連接埠可能在停止再啟動後改變，屆時書籤就指向不存在的東西。
如果按鈕不見了，檢查你部署的範本的啟動模式。只有 jupyter 會啟動 notebook 伺服器。ssh 模式的執行個體給你的是一個 shell，不是 notebook。請見啟動模式。
按鈕開啟的網址
按鈕開啟哪個網址，取決於這台主機能不能從外部直接連上：
| 路徑 | 網址 | 什麼時候用 | 憑證 |
|---|---|---|---|
| 直連 | https://<IP>:<連接埠>/lab?token=… | 主機上發布的連接埠可以從外部直接連上 | 容器自己產生的憑證，瀏覽器會警告（請見憑證警告） |
| 中繼 | https://<工作負載 ID>-<Jupyter 連接埠>.relay.superheat.cloud/lab?token=…（預設 8080） | 主機位於 NAT 之後，外部無法直接連上 | 正式簽發的憑證，瀏覽器不會警告 |
執行個體進入 running 時，平台會檢測一次這台主機能否從外部直接連上。連得上，按鈕就用直連網址；連不上，按鈕就改走中繼。中繼要等 Superheat CN 啟用 superheat.cloud 網域之後才會開啟；在那之前，按鈕開啟的一律是直連網址。
兩條路徑進入的是同一個 JupyterLab，用的是同一個權杖。SSH 不走中繼，一律直連。請見透過 SSH 連線。
關於權杖
存取權杖由平台在部署執行個體時簽發，並往下傳給容器，容器再以該權杖作為唯一憑證啟動 JupyterLab。你無法自行選擇它。你的組織讀得到它：執行個體的 連線 分頁會在 存取權杖 底下顯示它，API 則以 access_token 回傳。範本其他應用程式連接埠要求的也是同一個權杖 —— 請參閱執行個體存取權杖。
由此可以得出兩件事：
- 從主控台開啟 JupyterLab。按鈕會替你帶上權杖，你不必自己拼出網址。請像對待密碼一樣對待這個權杖和按鈕的連結。
- 自己在環境中設定
JUPYTER_TOKEN沒有任何作用。平台的環境變數覆寫一律優先於承租者提供的值，所以你填的內容會被蓋掉。GPU_COUNT也是一樣。請見環境變數。
你的檔案在哪裡
JupyterLab 的根目錄是 JUPYTER_DIR，預設為 /workspace。檔案瀏覽器無法瀏覽到該目錄之上，所以任何你想在側邊欄看到的東西都要放在它底下。
| 設定 | 預設值 | 來源 |
|---|---|---|
JUPYTER_DIR | /workspace | 範本的 jupyter_dir 欄位 |
JUPYTER_PORT | 8080 | jupyter 模式所發布的容器連接埠 |
JUPYTER_LAB | true (Lab) | 範本的 use_jupyter_lab 欄位；false 會提供傳統版 notebook |
/workspace 位於你在部署時決定容量的那顆硬碟上，所以它會在停止再啟動後留存，並在銷毀時被刪除。寫在容器其他位置的檔案也在同一顆硬碟上，命運相同 — 這個目錄只是慣例，不是獨立的磁碟區。
分頁在伺服器就緒之前就打開了
執行個體一回報 running，開啟 JupyterLab 按鈕就會出現。notebook 伺服器要在那之後片刻才綁定它的連接埠，所以太早點下去可能會落在瀏覽器錯誤上 — 連線遭拒，或是一個永遠載不完的頁面。
等幾秒鐘再重新整理分頁。基礎映像檔會先啟動 JupyterLab，再執行範本的 onstart 指令碼，所以拖住 notebook 伺服器的並不是冗長的 onstart。如果重新整理仍然失敗，透過 SSH 讀取伺服器自己的日誌：
tail -f /var/log/superheat/jupyter.log
憑證警告
這一節只適用於直連網址。直連時，JupyterLab 以 HTTPS 提供服務，用的是容器自己產生的憑證，所以你的瀏覽器會警告它無法驗證這個網站。在全新的執行個體上，這個警告是預期中的。加密本身正常運作；只有身分無法驗證，因為不會有任何公開憑證機構，替一台幾分鐘前才誕生的機器簽發憑證。
中繼網址用的是為 *.relay.superheat.cloud 正式簽發的憑證，瀏覽器不會警告。