概覽：
1. 開發環境
使用默認的設置，不改掛載路徑：
可以看到在容器內對掛載的目錄進行文件操作是可以真實記錄到實際的文件目錄內的。
對掛載路徑的另一種設置：
不使用默認的設置，手動更改掛載路徑：
在用戶文件目錄和組共享目錄中可以看到容器內對其進行的操作：
掛載到容器里的文件目錄都是可以在容器里面進行文件操作的，這時的操作會實時的體現在用戶的文件管理上。比如我們將default_group文件目錄掛載在容器上，新建兩個目錄aaa和bbb, 都是可以的，而我們在web管理界面上是沒有權限對 default_group文件目錄進行操作的。
如下，可以發現成功對 default_groupt文件目錄進行操作。
可以說在設置容器的時候選擇的掛載目錄是可以在容器里面對其內的文件進行完全操作的，我們可以遠程上傳或下載文件、代碼、數據集等到掛載文件中，這樣我們在容器里面也是可以完全進行操作的，這樣方便我們在計算的時候使用一些平台上沒有原生給出的資源。
在對容器進行設置的時候我們可以看到有一個選項是數據集路徑，數據路徑可以指定為文件管理目錄下的一個目錄，但是這里不推薦指定用戶的文件目錄，這里就是 /xxxxxx , 該路徑默認是掛載到容器里面的，如果再將該路徑作為數據集目錄掛載到容器里面容易產生錯誤，因此在設置數據集路徑時候選擇不是用戶文件目錄的路徑。如下，將默認掛載的/xxxxxx路徑同時設置為數據集目錄則顯示報錯，提示緩存數據拉取錯誤。
注：平台給出掛載目錄的目的就是為了提供一個路徑使容器和外界文件能夠得到交互，是一個雙向的過程，而數據集路徑的設置是一個單方向的設置，其目的就是多個用戶可以共享一些共同使用的文件，這樣可以減少磁盤空間的浪費和數據多次重復上傳的問題，這里面就要求這個數據集路徑的內容是只讀的，每個用戶對容器設置數據集路徑后只是從平台管理數據的磁盤上復制這個路徑的內容到計算磁盤上，可以說容器里面看到的數據集路徑里面的內容是原文件的影子，我們對其總任何更改也不會影響到原始數據。
掛載目錄和數據集目錄示意圖：
如：將存儲磁盤上的 /default_group作為數據集路徑掛載容器a上，並在容器a上做修改，建立文件 /default_group/x , /default_group/xx , /default_group/xxx 。在存儲磁盤上建立目錄 /default_group/aaa , /default_group/bbb ,將 /default_group/aaa 作為容器b的數據集，將/default_group/bbb 作為容器c的數據集，此時在容器b上建立目錄 /default_group/aaa/x, /default_group/aaa/xx, /default_group/aaa/xxx ，此時在容器c上建立目錄 /default_group/bbb/1, /default_group/aaa/2, /default_group/aaa/3 。然后在容器d上建立數據集路徑 若為 /default_group 那么容器d的/default_group 和容器a是同一文件，如果建立容器d的時候沒有選擇更新，那么容器d上/default_goup下也是x,xx,xxx文件，如果選擇更新那么容器a和容器d的/default_group目錄下內容會和存儲磁盤目錄下保持一致，也就是/default_group/aaa , /default_group/bbb ，並且aaa和bbb下面是空的。
1.1 運算中斷問題：
開發環境下有Jupter和Shell兩種模式，其中Jupter下分為：Notebook、Control和Terminal。
Notebook適合開發和最終展示，Termianl適合做運算，Shell適合做文件操作。
1.1.1 Shell終端下：
開發環境下運行的代碼只要用戶退出（包括網絡突然中斷）就會自動終止。
注意：只要網絡不中斷和用戶不退出（頁面不能刷新和退出）的情況下運算是不會中斷的，這一點和SSH登錄遠程主機進行運算一樣。
1.1.2 Jupyter下的Terminal：
Jupyter下的Terminal不會因為網絡中斷或者用戶退出而導致運算中斷。
1.1.3 Jupyter下的Notebook 和 Control ：
可以看到Notebook和Control的當前目錄都是容器所掛載的目錄，即根目錄下的和賬戶名相同的目錄，這里是 “ /xxxxxx ” 。
這里有一點需要注意：Notebook和Control在網絡斷開或用戶退出時，正在運行運算的計算也將被中斷，同時Control不會保存開發的記錄，而Notebook回保存開發的記錄：
Control：
開發環境是為開發設計的，不過由於這個中斷問題所以更適合做測試，開發環境下唯一可以不被外界原因中斷的只有Teminal ，因此Teminal下適合做最終運算，但是Teminal下不能盡量歷史輸入的查詢因此不是很適合做文件操作。Notebook能夠保存開發記錄並能做到圖片展示等可視化功能，開發使用OK，但是由於會被外界中斷所以不適合做最終的運算操作。Shell下面更適合做數據文件操作，如文件的創建、重命名、刪除等功能，由於不能進行圖片展示，不能保存開發記錄，能夠被外界中斷，因此不適合開發和運算，更適合做數據文件操作。
1.2運行效率對比：
第一組（非科學計算類，效率影響主要為CPU和內存性能）：
運行代碼：（https://gitee.com/devilmaycry812839668/cliff_walking）（設置實驗次數1000）
個人電腦運行（4.8G主頻，i7-10700k CPU單核心， 2666頻率內存）平均時間為511.5秒。
AI_Station平台（單核心CPU）平均運行時間為558.8秒。
平台與個人電腦的運算效率比可以到達91.5%。（對於大型計算平台來講效率已經非常高了）
第二組（科學計算類，效率影響主要為CPU（浮點型矢量計算）和內存性能）：
個人電腦運行（4.8G主頻，i7-10700k CPU 物理核心為8並開啟超線程， 2666頻率內存）運行時間為488.77秒。
AI_Station平台（16核心CPU）平均運行時間為881.11秒。
平台與個人電腦的運算效率比可以到達55.47%。
考慮可能有內存IO的影響，於是測試內存性能（空間申請測試）：
大數據塊：
個人主機時間：110.66秒。
平台運行時間：151.96秒。
平台與個人電腦的運算效率比可以到達72.82%。
小數據塊：
個人主機時間：80.38秒。
平台運行時間：80.09秒。
平台與個人電腦的運算效率比可以到達 100.36%。
使用空間內存較小的對象進行科學計算：
個人主機時間：35.66秒。
平台運行時間：80.17秒。
平台與個人電腦的運算效率比可以到達 44.48%。
1.3 使用ftp工具上傳文件：
1.4 使用SSH工具遠程登入容器：
可以看到我們能夠成功的登入到磁盤存儲主機（管理主機）上，這時我們進入的是物理主機。
可以看到 我們的用戶文件目錄在物理機上實際為 /home/inspurfs/user-fs/xxxxxx, 同時應該也存在另一個賬戶為xxx 。雖然我們可以登錄到管理主機的物理實體上，都是由於我們的賬戶權限太低並沒有什么可以操作的權限，除了在自己的用戶文件路徑下增刪改一些文件。
我們現在有兩個容器在運行：
這兩個容器的IP並不是校園網IP，而是私有IP, 那我們能否通過已經登入的管理主機跳轉進容器系統內呢？
使用ifconfig命令查看網絡配置，在眾多網卡中發現有一個網卡配置IP為14.14.14.100，這說明容器所運行在的主機（計算節點）正是這台磁盤存儲主機（也是管理主機）。
Ping一下：
發現此時網絡包沒有經過一跳路由的損失直接到達目的地，即64跳，說明容器其實運行在這個物理主機的同網段主機上，說明此時我們可以在這台主機上通過ssh跳轉到正在這台主機運行的容器里面，並且本主機物理網卡IP正好是14.14.14.100，這說明容器的IP或者說入口就是這個物理主機上。發現可以成功登入到兩個容器系統里面：
並且兩個容器也是可以相互跳轉到的：
1.5 計算節點的物理配置：
登錄物理主機：
可以發現物理主機上的內存總量為321G，現已用21G。
可以看到物理實體主機上CPU核心數為30個核心，這里應該是實體物理CPU數不為一的原因，查看CPU信息又顯示有96個CPU：
查看主機的域名解析：
可以看到該實體主機IP為14.14.14.100，同時它還連接五個GPU主機分別為gpu01,02,03,04,05 ,IP為14.14.14.1, 14.14.14.2，14.14.14.3，14.14.14.4，14.14.14.5。
也就是說這里的AI_station其實是有五台實體電腦的，一個管理電腦負責內外的文件傳輸和數據存儲功能，其它的五台GPU主機是提供GPU計算服務的。
通過網絡ping和IP設置知道物理本主機和五個GPU主機是同網段互聯的：
注：雖然登錄docker的IP正好是提供存儲服務和管理的主機，但是有可能docker是個集群，這台電腦只是負責調度和一部分計算服務的，docker是否是運行在這台主機上還不能下決定。
在docker內申請300G內存：
Docker監控：
14.14.14.100物理主機內存：
可以看到物理主機14.14.14.100上內存使用只有21GB，也就是說docker所申請的物理內存並不是在這個物理主機上，而是課程有集群在其他主機上申請的。
如果我們在這個物理主機上申請大量內存，此時該物理主機內存情況：
直接對物理主機進行內存申請測試：
個人主機（4.8G主頻，i7-10700k CPU 單核心， 2666頻率內存）運行時間：78.09秒。
14.14.14.100物理主機運行時間：393.39秒。
Docker容器內運行時間：94.59秒。
可以容易的看到不論管理節點（14.14.14.100，物理實體主機）還是docker系統在CPU和內存方面的效率都不是很高，慢的情況下是個人主機的50%性能，快的話也就是80%到90%多，但是這個計算平台的總資源很高，如果進行支持集群計算的話可以獲得較高加速比，當然這需要你本身任務支持集群計算，還有你還得會做這樣的code改寫，平台總資源：
但是如果你的任務不支持集群計算或者你本身不會改寫code和使用平台那么只使用平台上的單機CPU計算性能確實不及個人主機。當然這還和平台的CPU配置有關，這里的平台使用的是性價比較高的服務器CPU至強系列，Intel Xeon Platinum 8168擁有至強二十四核心48線程。
一般服務器平台會有兩個CPU實體，那么一個實體CPU有24個物理核心按照超線程的方式會顯示為48核心，兩個物理CPU實體就是顯示為96核心，正好符合：
2. 訓練管理
注意事項：1.提交的代碼中不要有中文字符，因為docker鏡像中很可能沒有設置UTF-8字符集。
2.提交的python代碼中主文件不要有#!/usr/bin/python或#!/usr/bin/env python
這樣的外部解釋器路徑的指定，因為鏡像系統中很有可能沒有這個路徑，即時有也很可能你沒有權限調用，於是就會報錯。如下：
在設置訓練管理時需要注意選擇啟動文件時最好重新手動指定一下，不然通過歷史訪問有可能選擇的是緩存中的文件，如果這個路徑文件被修改過就會報錯無法預知的錯誤。
使用訓練管理時相當於把計算任務托管給平台，這時如果是長時間運行的任務你不必一直守着web端，都是也有不好的地方，那就是你不像開發環境選項那樣可以在容器里面進行設置，托管給系統的環境是默認的鏡像，沒有一點的改變，如果你的鏡像中沒有設置UTF-8，如果再開發環境中你可以手動的設置一下，但在這種托管的訓練管理中是無法手動設置的。
保存的運行結果：
