基于Docker的Online Judge容器設(shè)計(jì)與實(shí)現(xiàn)

韋俊宇 王宇英

基于Docker的Online Judge容器設(shè)計(jì)與實(shí)現(xiàn)

韋俊宇 王宇英

（桂林電子科技大學(xué)計(jì)算機(jī)與信息安全學(xué)院，廣西 桂林 541004）

在LeetCode、ACWing等各大Online Judge網(wǎng)站中，每時(shí)每刻都有無數(shù)的代碼在編譯運(yùn)行。但這些網(wǎng)站上提交的代碼都是為了解決該網(wǎng)站題庫中給定的某一道算法題，不僅規(guī)定了程序的標(biāo)準(zhǔn)輸入輸出，還限制了運(yùn)行時(shí)長(zhǎng)和內(nèi)存占用，有一定局限性。在新冠疫情期間，開設(shè)計(jì)算機(jī)課程的大學(xué)也急需搭建符合學(xué)校教學(xué)需求的Online Judge以正常開展線上課程。針對(duì)上述兩個(gè)問題，文章設(shè)計(jì)并實(shí)現(xiàn)了基于Docker技術(shù)的Online Judge容器。其能編譯程序源代碼和運(yùn)行程序二進(jìn)制文件，期間能動(dòng)態(tài)地更改程序的標(biāo)準(zhǔn)輸入、運(yùn)行時(shí)長(zhǎng)與內(nèi)存占用，并對(duì)容器作了一定的防護(hù)，具有一定的安全性，還易于分布式拓展。

在線判題容器；Online Judge；Docker

引言

線上教育是將教育與多媒體充分地結(jié)合起來，一同打造的新式教學(xué)法，由于其便利、快捷等特點(diǎn)，目前在各大高校興起。大多數(shù)高校計(jì)算機(jī)專業(yè)的教學(xué)不同于高中傳統(tǒng)理論課程，其實(shí)踐課程多數(shù)為上機(jī)操作，但因?yàn)閹熒皇敲鎸?duì)面交流，使教師難以了解學(xué)生對(duì)知識(shí)的掌握情況以及時(shí)更改自己的教學(xué)計(jì)劃，影響教學(xué)質(zhì)量。網(wǎng)絡(luò)上針對(duì)教學(xué)實(shí)施的Online Judge[1]少之又少，擁有教學(xué)功能的Online Judge提供的功能難以根據(jù)計(jì)算機(jī)教學(xué)需求設(shè)計(jì)問題，當(dāng)下急需易搭建、易拓展具有一定安全性的Online Judge容器以供給學(xué)校根據(jù)教學(xué)需求[2]自主開發(fā)Online Judge。

Docker采用鏡像包的形式，將不同的代碼和運(yùn)行環(huán)境固定成了一個(gè)整體，能以鏡像包為基礎(chǔ)啟動(dòng)容器，標(biāo)準(zhǔn)化運(yùn)行程序，穩(wěn)定且可靠。Linux 內(nèi)核提供了getrusage和setrlimit系統(tǒng)調(diào)用，能在運(yùn)行時(shí)訪問系統(tǒng)內(nèi)核內(nèi)部數(shù)據(jù)結(jié)構(gòu)、改變系統(tǒng)內(nèi)核設(shè)置的機(jī)制，以達(dá)到程序運(yùn)行時(shí)限制資源的效果。本文基于Docker和Linux系統(tǒng)調(diào)用，以C++作為目標(biāo)語言舉例，設(shè)計(jì)并實(shí)現(xiàn)了Online Judge容器，其消除了不同運(yùn)行環(huán)境的差異，且極易搭建部署在任意一臺(tái)擁有Docker運(yùn)行環(huán)境Linux服務(wù)器上。該Online Judge容器模塊功能顆粒度小，方便二次開發(fā)進(jìn)行拓展，供給開設(shè)計(jì)算機(jī)專業(yè)的高?；騽?chuàng)業(yè)人員，針對(duì)新冠疫情帶來的問題，搭建自主的Online Judge。

1 Online Judge概述

Online Judge中文名是在線判題，用戶在網(wǎng)頁上編寫程序源代碼，提交到服務(wù)器上運(yùn)行并給出一定的結(jié)果，這是Online Judge一個(gè)基本的流程。

使源代碼在服務(wù)器上進(jìn)行編譯運(yùn)行操作的，被稱之為判題機(jī)。判題機(jī)不僅需要對(duì)用戶的源代碼進(jìn)行編譯運(yùn)行，還需要對(duì)編譯運(yùn)行期間可能出現(xiàn)的安全問題進(jìn)行處理，以防止部分用戶故意提交具有安全漏洞的代碼影響服務(wù)器運(yùn)作。大多數(shù)服務(wù)器與判題機(jī)是1∶n的比例，必須將判題機(jī)作為分布式集群，否則難以應(yīng)對(duì)判題需求激增的情況以致服務(wù)器無法及時(shí)正常響應(yīng)請(qǐng)求。

目前主流Online Judge網(wǎng)站的判題機(jī)能對(duì)可能在編譯或運(yùn)行時(shí)出現(xiàn)的錯(cuò)誤歸類成以下四類[1]：

（1）編譯失敗：編譯時(shí)出錯(cuò)。

（2）運(yùn)行時(shí)錯(cuò)誤：程序異常終止，可能的原因是：段錯(cuò)誤，被零除或用非0的代碼退出程序。

（3）運(yùn)行超時(shí)：程序使用的CPU時(shí)間已超出限制。

（4）內(nèi)存超限：程序?qū)嶋H使用的內(nèi)存已超出限制。

本文實(shí)現(xiàn)的Online Judge容器可作為判題機(jī)獨(dú)立處理單個(gè)編譯運(yùn)行任務(wù)。它對(duì)上述可能出現(xiàn)的四類錯(cuò)誤進(jìn)行處理，但不涉及對(duì)輸入輸出的判定。Online Judge容器只對(duì)程序的標(biāo)準(zhǔn)輸入輸出作重定向，目的是實(shí)現(xiàn)更小顆粒化的容器，方便拓展與二次開發(fā)。

為了解決軟件開發(fā)中環(huán)境配置繁瑣的問題，本文使用Docker技術(shù)，將Online Judge核心的編譯模塊和運(yùn)行模塊分別獨(dú)立設(shè)計(jì)成兩個(gè)Docker容器。Docker將會(huì)提供一個(gè)程序運(yùn)行的獨(dú)立環(huán)境，使用namespace、cgroup等安全隔離機(jī)制措施，讓Docker容器內(nèi)與宿主機(jī)完全隔離[3]。若將程序必需的環(huán)境和文件整合在輕量級(jí)的Docker容器中，就可以快速地部署在任意一臺(tái)擁有Docker運(yùn)行環(huán)境Linux主機(jī)上。

不同于傳統(tǒng)的在線判題系統(tǒng)設(shè)計(jì)復(fù)雜度高、實(shí)現(xiàn)困難，本文設(shè)計(jì)的在線判題容器因采用了Docker技術(shù)，擁有輕量、易用、安全的特點(diǎn)。

2 系統(tǒng)設(shè)計(jì)

2.1 編譯容器

在世界上最大Docker容器鏡像分享庫Docker Hub中，提供了主流程序設(shè)計(jì)語言的完整編譯環(huán)境的鏡像。例如GCC（GNU Compiler Collection，GNU編譯集）的Docker鏡像可以在Docker Hub中找到，它可以用來編譯C、C++等程序設(shè)計(jì)語言。在擁有Docker運(yùn)行環(huán)境Linux主機(jī)上，使用docker pull gcc命令即可將該鏡像拉取到本地。

編譯容器的作用是對(duì)每一個(gè)程序的源文件進(jìn)行編譯并產(chǎn)生對(duì)應(yīng)的可執(zhí)行文件。雖然Docker啟動(dòng)一個(gè)容器的開銷極小，但是先將需要編譯的源文件與編譯環(huán)境打包成一個(gè)新鏡像，再以該鏡像啟動(dòng)容器編譯出可執(zhí)行文件，對(duì)擁有源源不斷提交編譯運(yùn)行請(qǐng)求的服務(wù)器而言，這樣將會(huì)反復(fù)地創(chuàng)建新鏡像，造成極大的系統(tǒng)資源的浪費(fèi)。

為了避免這種問題，使用sleep infinity命令啟動(dòng)編譯容器后，便會(huì)使該容器進(jìn)程永久進(jìn)入休眠狀態(tài)。同時(shí)將宿主機(jī)某個(gè)文件目錄掛載到編譯容器內(nèi)。在有新的編譯請(qǐng)求到來后，使用docker exec <容器id> <編譯命令>，依附于休眠狀態(tài)的編譯容器，在編譯容器內(nèi)部以新進(jìn)程的形式執(zhí)行新的編譯任務(wù)。該編譯進(jìn)程產(chǎn)生的程序可執(zhí)行文件需輸出到宿主機(jī)掛載到編譯容器內(nèi)的目錄下，宿主機(jī)上的Online Judge服務(wù)訪問掛載的文件目錄，即可獲取該程序可執(zhí)行文件。以這種方式編譯源程序，不需要反復(fù)地打包鏡像、創(chuàng)建容器，就可以簡(jiǎn)單、快速地編譯源文件。

以編譯C++程序?yàn)槔?，編譯容器整體結(jié)構(gòu)如圖1所示。

圖1 編譯容器整體結(jié)構(gòu)

2.2 運(yùn)行容器

除了某些如JavaScript、TypeScript、Python等動(dòng)態(tài)腳本語言需要解釋器外，多數(shù)靜態(tài)語言如C、C++、Go在編譯產(chǎn)生程序可執(zhí)行文件后，即可在編譯時(shí)指定的目標(biāo)系統(tǒng)下運(yùn)行。以已經(jīng)獲得了C++可執(zhí)行文件main. exe，編譯時(shí)指定的目標(biāo)系統(tǒng)為L(zhǎng)inux為前提，開始整個(gè)運(yùn)行容器的設(shè)計(jì)。

運(yùn)行容器將會(huì)不斷地創(chuàng)建并周期性地刪除，以保證服務(wù)器在不斷地運(yùn)行請(qǐng)求壓力下，將內(nèi)存和磁盤占用維持一個(gè)良好的水平。如果使用GCC的Docker鏡像，雖然它也能執(zhí)行C++可執(zhí)行文件，但它擁有近1 GB的磁盤占用，開銷極大。所以一個(gè)精簡(jiǎn)的Docker鏡像非常有必要，對(duì)于運(yùn)行容器，最后選擇使用了非常輕量的ubuntu的Docker鏡像。

往往一個(gè)程序的運(yùn)行時(shí)間都以毫秒為單位。Docker雖然提供了docker status命令監(jiān)控每個(gè)容器的資源占用，但是一旦容器停止了便無法再獲取。而且docker status命令是Docker使用客戶端-服務(wù)器（C/S）架構(gòu)模式來通信的[3]，中間具有一定的時(shí)延。在運(yùn)行的過程中往往運(yùn)行容器已經(jīng)停止了，而docker status命令還沒獲取到容器信息。此外，docker status命令獲取的是一整個(gè)容器內(nèi)的資源占用，不是某一個(gè)進(jìn)程的資源占用。顯然它不能滿足精確監(jiān)控某個(gè)進(jìn)程占用系統(tǒng)資源的需求。

Linux系統(tǒng)的getrusage系統(tǒng)調(diào)用，可以得到相關(guān)進(jìn)程的資源使用信息，如進(jìn)程占用內(nèi)存、進(jìn)程在用戶態(tài)下的執(zhí)行時(shí)間、進(jìn)程在系統(tǒng)態(tài)下執(zhí)行的時(shí)間。類似的，setrlimit系統(tǒng)調(diào)用可以對(duì)某個(gè)進(jìn)程進(jìn)行資源限制。使用getrusage和setrlimit這兩個(gè)系統(tǒng)調(diào)用，運(yùn)行容器可以精準(zhǔn)地監(jiān)控和限制進(jìn)程的資源。

為此，可以編寫一個(gè)資源監(jiān)控程序，它將在運(yùn)行容器內(nèi)部，以子進(jìn)程的形式運(yùn)行目標(biāo)程序可執(zhí)行文件，并重定向輸入輸出流，期間通過getrusage和setrlimit系統(tǒng)調(diào)用不斷地對(duì)其進(jìn)行監(jiān)控和限制。若在過程中子進(jìn)程使用資源超出了給定的限制，例如內(nèi)存超限、運(yùn)行超時(shí)，則直接停止子進(jìn)程的運(yùn)行，并將結(jié)果記錄下來。若子進(jìn)程平穩(wěn)地運(yùn)行結(jié)果，則在子進(jìn)程結(jié)束時(shí)返回相關(guān)資源使用信息。該監(jiān)控程序也將被整合在Docker鏡像內(nèi)。

運(yùn)行容器整體結(jié)構(gòu)如圖2所示。

圖2 運(yùn)行容器整體結(jié)構(gòu)

2.3 聚合編譯容器與運(yùn)行容器

就像兩臺(tái)通信設(shè)備需要基站作為中轉(zhuǎn)一樣，為了聚合編譯容器與運(yùn)行容器，必須擁有一個(gè)Server容器。該Server容器提供友好交互的前端界面與對(duì)外訪問的Web服務(wù)，將用戶的源代碼和輸入流遞交到Docker容器中，并將輸出流發(fā)還給用戶。從在用戶的角度看，Server容器就是一個(gè)普通的服務(wù)器應(yīng)用，如圖3所示。

圖3 用戶視角的服務(wù)器

編譯容器和運(yùn)行容器將宿主機(jī)上的某一目錄共同作為工作區(qū)，分別掛載到各自的容器內(nèi)部，就達(dá)到了編譯容器和運(yùn)行容器同時(shí)訪問宿主機(jī)工作區(qū)內(nèi)文件的效果。服務(wù)器向該工作區(qū)目錄寫入程序源代碼，編譯容器根據(jù)程序源代碼生成程序可執(zhí)行文件，運(yùn)行容器讀取程序可執(zhí)行文件并給出標(biāo)準(zhǔn)輸入后輸出的結(jié)果。上述容器獨(dú)立的任務(wù)和之間相互通信都在該目錄下進(jìn)行。

在用戶提交程序源代碼后，通過docker exec <容器id> <編譯命令> <資源限制參數(shù)> 啟動(dòng)編譯容器執(zhí)行編譯命令，屆時(shí)可以向編譯容器內(nèi)的監(jiān)控程序傳遞資源限制的參數(shù)。編譯結(jié)束后會(huì)在工作區(qū)目錄下產(chǎn)生對(duì)應(yīng)程序的可執(zhí)行文件。通過docker run <容器id> <運(yùn)行參數(shù)> <資源限制參數(shù)> 啟動(dòng)運(yùn)行容器執(zhí)行運(yùn)行命令。

聚合架構(gòu)如圖4所示。

圖4 聚合架構(gòu)

3 安全問題的解決

3.1 編譯一個(gè)永遠(yuǎn)讀不完的文件

以C++為例，代碼如下。在程序源代碼的中引入一個(gè)永遠(yuǎn)也讀不完的文件，會(huì)使編譯容器永久停留在編譯階段。

Docker編譯容器在運(yùn)行時(shí)可以傳遞資源限制參數(shù)，限制編譯時(shí)長(zhǎng)，就可以避免這種情況。

3.2 編譯產(chǎn)生巨大文件

對(duì)于服務(wù)器，增加一點(diǎn)磁盤空間或內(nèi)存空間開銷代價(jià)都是昂貴的，所以在線測(cè)評(píng)網(wǎng)站上提交的代碼允許磁盤空間占用不會(huì)太大。但也不懷有人惡意編譯巨大文件[4]，導(dǎo)致服務(wù)器的磁盤占用迅速上升造成宕機(jī)的嚴(yán)重后果，必須要在編譯容器執(zhí)行編譯任務(wù)時(shí)，通過資源限制參數(shù)限制編譯文件的大小。

3.3 運(yùn)行時(shí)系統(tǒng)調(diào)用

System("shutdown now")會(huì)使系統(tǒng)直接關(guān)機(jī)，fork()可以讓程序遞歸地創(chuàng)建自身進(jìn)程副本，還有很多此類直接影響整個(gè)服務(wù)器的操作，可以在編譯時(shí)簡(jiǎn)單地使用字符串匹配去檢測(cè)這些危險(xiǎn)的命令，檢測(cè)到這些命令后直接停止整個(gè)編譯容器的運(yùn)行并返回錯(cuò)誤結(jié)果[4]。但是如果有人惡意宏定義，就繞過了字符串匹配。所以這種方式是不可行的。

但本文設(shè)計(jì)的編譯容器和運(yùn)行容器都是運(yùn)行在Docker里的，Docker容器內(nèi)部和宿主機(jī)已經(jīng)完全隔離開，通過Docker限制整個(gè)容器的資源，即可解決這個(gè)問題。

3.4 故意運(yùn)行超時(shí)

可能會(huì)有那么一種情況，在源代碼里寫sleep(1000)（該代碼在C++中會(huì)使程序休眠1000秒），每次程序必定超時(shí)，后被強(qiáng)制退出。這非常像類似于DDoS的攻擊方式。解決方案也和DDoS類似，要么提高服務(wù)器的配置，要么限制這個(gè)這類惡意提交運(yùn)行超時(shí)代碼用戶的正常使用[5]。前者費(fèi)用昂貴，后者經(jīng)濟(jì)實(shí)惠。可以在Server容器內(nèi)規(guī)定，如果某個(gè)用戶提交超時(shí)的代碼連續(xù)超過N次，則在后續(xù)一定時(shí)間內(nèi)，該用戶的代碼不給予編譯運(yùn)行。

4 分布式拓展

Online Judge網(wǎng)站有一特點(diǎn)，通常情況下比如夜晚或節(jié)假日，基本上不會(huì)有大量的編譯運(yùn)行請(qǐng)求。但在某些特殊的時(shí)間點(diǎn)上，比如承辦一個(gè)民間或官方在線比賽，或組織一場(chǎng)校內(nèi)或校外的編程考試時(shí)，服務(wù)器編譯運(yùn)行請(qǐng)求會(huì)迅速增加。如果此時(shí)服務(wù)器在高負(fù)載下宕機(jī)了，將會(huì)給網(wǎng)站帶來難以估量的損失。傳統(tǒng)單體B/S架構(gòu)的服務(wù)器難以動(dòng)態(tài)地增加配置，且當(dāng)用戶請(qǐng)求量到達(dá)一定程度時(shí)，客戶端和服務(wù)器之間的網(wǎng)絡(luò)資源分配也成了一大問題，再怎么提高服務(wù)器的性能都無濟(jì)于事。所以不得不尋求其他的方案，解決單臺(tái)服務(wù)器性能上限和網(wǎng)絡(luò)資源分配的問題。

為了解決上述問題，將Online Judge容器部署在多臺(tái)服務(wù)器上，不僅可以應(yīng)對(duì)用戶量激增帶來的巨額并發(fā)訪問量，而且在容災(zāi)方面，當(dāng)其中一臺(tái)判題服務(wù)器遭遇意外問題宕機(jī)時(shí)，整個(gè)系統(tǒng)也能正常地運(yùn)行下去。

在2004年，Google公司提出了一種用于大規(guī)模數(shù)據(jù)的編程模型MapReduce[6]。參考其編程模型的核心思想“分而治之”，可以將每個(gè)用戶的判題任務(wù)分發(fā)到不同的服務(wù)器上，再統(tǒng)一收集結(jié)果返回給用戶。這一過程，將在一臺(tái)服務(wù)器上的并行任務(wù)轉(zhuǎn)換成在多臺(tái)服務(wù)器上的并行任務(wù)。轉(zhuǎn)化前后并行執(zhí)行效果如圖5、圖6所示。

可以非常直觀地看到，通過多臺(tái)服務(wù)器同時(shí)開展并行任務(wù)，單臺(tái)服務(wù)器需要承載的壓力會(huì)被均分到其他服務(wù)器上。同時(shí)可根據(jù)用戶在線訪問量的波動(dòng)，動(dòng)態(tài)地增加或減少服務(wù)器集群內(nèi)的主機(jī)的數(shù)量，減少高昂的服務(wù)器資源費(fèi)用的支出。

圖5 原始并行圖

圖6 分布并行圖

4.1 任務(wù)分發(fā)

參考MapReduce，它會(huì)先將用戶的原始數(shù)據(jù)進(jìn)行切割，然后分發(fā)給不同的Map任務(wù)處理[6]。用戶提交到服務(wù)器的數(shù)據(jù)只有源代碼和輸入文本，對(duì)這些數(shù)據(jù)進(jìn)行切割并沒有什么意義。Online Judge需要切割的是存儲(chǔ)在服務(wù)器上的隱藏測(cè)試樣例，這些輸入輸出樣例的數(shù)量，根據(jù)題目的不同，有的幾十，有的甚至上千。這些不同的輸入輸出樣例的空間占用大小，有的只有幾kB，有的可達(dá)1 MB。

在分布式集群中，每一臺(tái)機(jī)器的性能可能都是不一樣的。對(duì)此，可以選擇一種較為簡(jiǎn)單、靜態(tài)的負(fù)載均衡算法——加權(quán)輪詢調(diào)度算法[7]。它用不同的權(quán)值記錄了每一臺(tái)服務(wù)器的處理能力，在請(qǐng)求到來后，權(quán)值高的服務(wù)器將會(huì)處理更多的請(qǐng)求。分發(fā)任務(wù)后，權(quán)值會(huì)根據(jù)資源占用和請(qǐng)求處理的情況進(jìn)行改變。

服務(wù)器選擇任務(wù)分發(fā)時(shí)，這些占用空間大，運(yùn)行時(shí)間較長(zhǎng)的輸入輸出樣例，將會(huì)被分發(fā)到性能較高的服務(wù)器上。而那些占用空間小，運(yùn)行時(shí)間短的樣例將會(huì)被分發(fā)到性能較差的服務(wù)器上。因?yàn)槊總€(gè)服務(wù)器的權(quán)值都會(huì)被加權(quán)輪詢調(diào)度算法動(dòng)態(tài)的更改，所以一批開始于相同時(shí)間的任務(wù)，在經(jīng)過集群分發(fā)處理后，等待結(jié)束同步的時(shí)間不會(huì)相差太大。如圖7所示。

圖7 任務(wù)分發(fā)

4.2 任務(wù)歸并

任務(wù)歸并的過程只需要將之前分發(fā)的任務(wù)取回，取回過程的順序不需要根據(jù)任務(wù)分發(fā)的順序或是分發(fā)時(shí)間順序來定。在這一過程中，專門用于任務(wù)分發(fā)的線程會(huì)通過遠(yuǎn)程過程調(diào)用[8]調(diào)取集群內(nèi)Online Judge容器暴露出來的功能函數(shù)。該線程在等待Online Judge容器編譯運(yùn)行的過程中，會(huì)進(jìn)入等待狀態(tài)，直至所有任務(wù)的運(yùn)行結(jié)果都獲取。

遠(yuǎn)程過程調(diào)用[8]是一個(gè)計(jì)算機(jī)通信協(xié)議，可基于HTTP或TCP協(xié)議實(shí)現(xiàn)，越接近底層的協(xié)議數(shù)據(jù)傳輸更快。使用遠(yuǎn)程過程調(diào)用，會(huì)在服務(wù)器集群內(nèi)部會(huì)產(chǎn)生一定內(nèi)部網(wǎng)絡(luò)資源消耗。因?yàn)榧和獾木W(wǎng)絡(luò)資源比集群內(nèi)的網(wǎng)絡(luò)資源要更加昂貴，所以在整個(gè)集群內(nèi)部進(jìn)行的遠(yuǎn)程過程調(diào)用，對(duì)整個(gè)系統(tǒng)來說是可以接受的。

4.3 分發(fā)與歸并總結(jié)

對(duì)Online Judge容器嘗試分布式拓展后，將高并發(fā)下單臺(tái)服務(wù)器性能上限問題轉(zhuǎn)換成了多臺(tái)服務(wù)器組成集群的性能上線問題；將高并發(fā)下客戶端與服務(wù)器之間網(wǎng)絡(luò)資源分配問題，轉(zhuǎn)換成了客戶端與多臺(tái)服務(wù)器之間的網(wǎng)絡(luò)資源分配問題。這些問題在分布式領(lǐng)域仍面對(duì)著許多的問題與挑戰(zhàn)，等待著更好的解決方案的提出。

5 結(jié)束語

目前，線上編程教學(xué)的需求變得愈發(fā)強(qiáng)烈，互聯(lián)網(wǎng)企業(yè)在選人面試招聘也逐漸從線下轉(zhuǎn)變?yōu)榫€上，因此急需免配置系統(tǒng)環(huán)境就可運(yùn)行的編程環(huán)境。本文設(shè)計(jì)的基于Docker的Online Judge容器，功能精巧、易部署、具有一定的安全性，能較好的應(yīng)對(duì)此類急需制作針對(duì)特定功能而使用的Online Judge網(wǎng)站。同時(shí)基于此類在線測(cè)評(píng)的特點(diǎn)，基于MapReduce和遠(yuǎn)程過程調(diào)用協(xié)議提供了一種分布式拓展的方案，以應(yīng)對(duì)高并發(fā)高負(fù)載下的場(chǎng)景。Docker屬于較新的技術(shù)之一，具有天然適應(yīng)云計(jì)算的優(yōu)點(diǎn)。未來隨著云計(jì)算、分布式技術(shù)的發(fā)展，讀者還可以根據(jù)該基于Docker設(shè)計(jì)的Online Judge容器，進(jìn)一步豐富其定制化功能，實(shí)現(xiàn)遠(yuǎn)程線上實(shí)驗(yàn)教學(xué)、互聯(lián)網(wǎng)企業(yè)遠(yuǎn)程編程開發(fā)等，以響應(yīng)工業(yè)和信息化部關(guān)于推動(dòng)5G加快發(fā)展的號(hào)召。

[1] 蔡崇超. 基于Web的在線判題系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J]. 軟件導(dǎo)刊，2016，15(3): 107-109.

[2] 歐陽佳，肖茵茵，劉少鵬，等. 基于在線判題系統(tǒng)的程序設(shè)計(jì)課程群教學(xué)研究[J]. 信息與電腦(理論版)，2021，33(12): 228-231.

[3] 邱建新. 基于Docker容器技術(shù)的Linux在線實(shí)驗(yàn)環(huán)境設(shè)計(jì)[J]. 信息技術(shù)，2022(2): 48-52，58.

[4] 李定才，瞿紹軍，胡爭(zhēng)，等. 基于Windows的在線判題系統(tǒng)的安全性研究[J]. 計(jì)算機(jī)技術(shù)與發(fā)展，2011，21(9): 204-207.

[5] 張彩珍，常元，康斌龍，等. 一種抵御流量型DDoS攻擊的告警閾值系統(tǒng)設(shè)計(jì)[J]. 電子設(shè)計(jì)工程，2021，29(22): 24-27，32.

[6] Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters[C]. Proc of OSDI 2004, USENIX Association, 2004.

[7] Reynolds D A, Quatieri T F, Dunn R B. Speaker verification using adapted Gaussian mixture models[J]. Digital Signal Processing, 2000, 10(1): 19-41.

[8] Gutiérrez G J J, González H M. Prioritizing remote procedure calls in Ada distributed systems[J]. ACM SIGAda Ada Letters, 1999, 19(2): 67-72.

Design and Implementation of Online Judge Container Based on Docker

In major Online Judge websites such as LeetCode and ACWing, countless codes are compiled and run all the time. However, the code submitted on these websites is to solve an algorithm problem given in the website's question bank. It not only stipulates the standard input and output of the program, but also limits the running time and memory usage, which has certain limitations. During the COVID-19, universities offering computer courses also urgently need to build Online Judge that meets our teaching needs in order to run online courses normally. Aiming at the above two problems, this paper designs and implements an Online Judge container based on Docker technology. It can compile the source code of the program and run the binary file of the program, dynamically change the standard input, running time and memory occupation of the program, and protect the container to a certain extent. It has certain security, and is easy to expand distributed.

Online Judge container; Online Judge; Docker

TP311

A

1008-1151(2022)09-0014-04

2022-06-28

廣西區(qū)大學(xué)生創(chuàng)新創(chuàng)業(yè)訓(xùn)練計(jì)劃立項(xiàng)項(xiàng)目（202010595168、202110595158）。

韋俊宇（2001－），男，桂林電子科技大學(xué)計(jì)算機(jī)與信息安全學(xué)院學(xué)生。

王宇英，女，桂林電子科技大學(xué)計(jì)算機(jī)與信息安全學(xué)院正高級(jí)實(shí)驗(yàn)師，碩士，研究方向?yàn)楦叩冉逃芾怼?/p>