“認知課堂（Cognitive Class）”是IBM面向全球技術人員提供的高質量課程學習平臺，課程主題包括人工智能（AI）、機器學習、數據科學、大數據、分析和數據庫等，前身為IBM Big Data University。自發布以來，“認知課堂”跨過了一項又一項里程碑，如今已擁有超過100萬名學習者。
這篇文章中將分享IBM“認知課堂”在技術方面的里程碑和演變，特別是平臺是如何從一個靜態基礎架構轉變到現在使用Docker、運行著數十個Open edX實例的動態+可擴展部署的。
OPEN EDX 101
Open edX是edx.org提供的開源代碼。它由幾個存儲庫組成，edx-platform是其主要存儲庫。如果想要部署Open edX實例，官方的方法是使用配置好的repo，通過Ansible playbooks自動安裝。這種方式需要訪問正在運行Ansible playbook的服務器。在這些完成之後，你將獲得一個全新的Open edX部署。
IBM也是這樣運營cognitiveclass.ai（我們的對外網站）的，從2015年開始IBM將“認知課堂”從Moodle部署轉移到了Open edX上。Open edX提供了很好的服務，使得我們每天可以為數百名併發學習者提供超過70門課程。
但我們仍然面臨著一些挑戰：
- Open edX主要針對的是Amazon的AWS服務，但我們要在IBM Cloud上運行我們的基礎架構。
- 需要創建虛擬機來部署新實例。
- Open edX從存儲在服務器中的JSON文件中讀取配置信息，每個實例必須保持這些文件同步。
雖然我們能夠在大型的單一部署中克服這些問題，但對於我們的新目標對象，Cognitive Class Private Portals來說它們會變得很難管理。
商業用途的“認知課堂”
在向其他公司介紹時，我們經常會聽到同樣的問題：“我怎麼樣才能讓我的員工明白並使用這些內容呢？”，這也是我們為“認知課堂”創立“專屬門戶（Private Portals）”的動機所在。
“專屬門戶”是一個專門為客戶創建的專用部署，用戶可以獨享專屬於他的“認知課堂“，可以創建自定義學習路徑、自行定製課程、追蹤學習進度、設置訪問限制、創立競賽等等。“專屬門戶”服務是IBM為團隊、部門、小型企業、大型企業、學術機構和培訓提供商等推出的。從技術角度來看，這就要求我們能夠快速按需推出新的部署。我們回到前文提到的幾點挑戰，隨著部署數量的增長，第二點和第三點尤其具有挑戰性。
為每個部署創建和配置新的虛擬機是一個緩慢而且昂貴的過程。如果某個Portals超出了它的資源，我們不得不需要找到一種方法來擴展它，並且在多個虛擬機中管理它的配置。
使用Docker
與此同時，我們在Virtual Labs（供課程用戶進行實踐操作的環境）的基礎設施中遇到了類似的需求，數百個虛擬機的使用讓管理非常混亂。於是IBM的Virtual Labs團隊開始研究並且實現基於Docker的解決方案。
對我們來說，Docker的主要好處有兩個：
- 提高服務器的使用密度；
- 隔離服務進程以及文件。
這些好處是密切相關的：因為每個容器管理自己runtime和文件，我們能夠在同一個服務器上輕鬆運行不同的軟件，而不會相互干擾。與虛擬機相比，我們這樣做的開銷要低很多，因為Docker在它們之間提供了輕量級的隔離。
通過提高使用密度，我們能夠在少量大型服務器中運行數千個容器，這些服務器可以提前進行配置，而不需要去管理數千個較小的實例。
對於IBM的“認知課堂-專屬門戶“網站來說，這意味著我們可以在幾分鐘內準備好使用新部署。底層的基礎設施已經就位，所以我們只需要啟動一些容器即可。
使用Rancher管理容器
Docker本身就是一項出色的技術，但面對高度可擴展的分佈式生產環境，我們仍需要藉助其他工具或平臺來管理容器的生命週期。在“認知課堂”平臺中，我們決定使用Rancher，它能夠讓我們將基礎設施抽象出來，只需專注於應用程序本身。
簡而言之，Rancher將容器組織成服務，接著服務被分組到stack中。把stack部署到環境中，而環境由主機控制，主機是最終啟動容器的底層服務器。Rancher負責在所有主機上創建專用網絡，以便他們可以相互安全地進行通信。
讓一切運行起來
我們的網站採用微服務架構，都在Rancher中以stack的形式組合在一起。Open edX是主要組成部分，它可以分為較小的服務。除了Open edX之外，我們還有其他幾個組件可以為我們的產品提供額外的功能。下圖是我們的Rancher界面示例：
這裡有非常多的內容，所以我們來快速解釋一下這些內容：
Open edX
- lms：這是學生訪問課程內容的地方
- cms：用於創作課程
- forum：處理課程討論
- nginx：提供靜態資源
- rabbitmq：消息隊列系統
附加組件
- glados：管理員用戶界面，用於控制和自定義Protal
- companion-cube：用於開放Open edX額外功能的API
- compete：運行數據黑客馬拉松的服務
- learner-support：內置的學習者支持系統
- lp-certs：為完成多門課程的學生頒發證書
支持服務
- cms-workers和lms-workers：執行lms和cms的後臺任務
- glados-worker：執行glados的後臺任務
- letsencrypt：使用Let的加密自動管理SSL證書
- load-balancer：根據請求主機名控制路由到服務的流量
- mailer：代理SMTP請求到外部服務器或者以其他方式發送電子郵件
- ops：用於運行特定任務的容器組
- rancher-cron：按照類似cron的計劃啟動容器
數據存儲
- elasticsearch
- memcached
- mongo
- mysql
- redis
其中ops服務的行為和其他服務的行為有所不同，因此我們深入研究一下：
這裡我們可以看到在ops中有幾個容器，通常情況下它們是不運行的。某些容器（如edxapp-migrations）會在部署Portal時運行，但除非在特殊情況下（例如數據庫架構更改），否則不會再次啟動。而其他容器，如backup，由rancher-cron定期啟動，一旦完成就停止。
在這兩種情況下，我們都可以通過單擊啟動按鈕來觸發手動啟動。這樣我們能夠輕鬆地按需運行重要的操作任務，而不需要使用SSH進入特定服務器，確定要運行的腳本來執行。
操作文件
Docker的一個關鍵特性是每個容器的文件系統都是隔離開的。這意味著，如果沒有適當注意，在容器死亡的時候您可能會丟失重要的文件。處理這種情況的方法，是使用Docker的卷將本地文件系統路徑掛載進容器。
此外，當您有多個主機時，最好有一個共享數據層，以避免在容器和服務器之間創建隱式調度依賴關係。換句話說，您希望容器能夠訪問相同的文件，而無論它們運行在哪個主機上。
在我們的基礎架構中，我們使用IBM Cloud NFS驅動器，它安裝在所有主機的相同路徑下。NFS負責存儲Portal生成的任何持久化數據，從數據庫文件到已編譯的靜態資源，比如鏡像、CSS和JavaScript文件。
每個Portal在NFS驅動器中都有自己的目錄，容器會掛載該特定Portal的目錄。因此，一個Portal無法訪問另一個Portal的文件。
其中一個最重要的文件是ansible_overrides.yml。正如我們在文章開頭所提到的，Open edX是由進程啟動時所讀取到的JSON文件配置的。Ansible playbook在執行時生成這些JSON文件。
為了把Portal管理員對glados所做的更改應用到Open edX的lms和cms，我們將ansible_overrides.yml掛載到容器中。當某些內容發生變化時，glados可以將新值寫入此文件，lms和cms可以讀取它們。
接著我們重新啟動lms和cms容器，通過這些容器來運行Ansible playbook，在啟動時重新生成JSON文件。ansible_overrides.yml作為變量文件傳遞給Ansible，這樣在那裡聲明的任何值都可以覆蓋Open edX的默認值。
有了這個共享數據層，我們不必再擔心容器會被重新分配到另一個主機上了，我們確信Docker能夠找到正確的路徑，並將所需要的卷掛載進容器中。
結 論
通過在IBM認知課堂平臺的發展過程中，依靠學到的經驗教訓以及使用最新的技術，我們能夠構建出快速、可靠和可擴展的解決方案，為認知課堂的學生和客戶提供更好的學習體驗。這篇文章中介紹了很多內容，希望能讓您有所收穫。Happy learning！
閱讀更多 RancherLabs 的文章
