学校重构之后的OJ终于进入了前后端对接的阶段，经过了一周的紧张对接环境，项目依然是(正在稳定推进的阶段)，和前端对接口的一周里，我感觉到自己之前工作的不足，在此做出反思，以后要改掉这些错误。同时在和运维一起部署的过程中，也发现了许许多多的问题，在此一并记录一下。

Access to Judger Ana In Docker

因为OJ要防止恶意代码的提交，解决办法就是使用docker，为了让评测机稳定于是又要在docker里跑一个docker。 直接docker run评测机，用了一下judge_test的模块，发现返回的结果全是AC，这就非常奇怪了。问了一下hr发现ana是用grpc通信的，好，没有学过，于是开始看怎么测试grpc是否正常，初步定位问题是没接上。也去docker里配了一下环境，加了工作目录，放行端口，发现还是不行。当hr进入服务器的时候，才发现真正的问题所在。直接docker pull的时候是跑的master分支的镜像，而新评测机接口是在另一个分支的。于是把锅甩给了嘎嘎豪。

NPM throw error

后端采用了go语言的gin+gorm框架搭建，直接go build然后丢到后台守护进程，前端使用了vue框架，要先用npm build一下，但是我本意是想直接npm run serve的，无奈npm一直疯狂报错。最初我也是打算现在本地run serve然后只测试后台的，但是npm先是依赖问题没有解决，最后重装了全局的依赖之后发现报错有个字段为darwin-arm64，看到这个我就感觉不对劲，可能是M1芯片没有合适的包可以下载，于是才决定丢到服务器上。在服务器上也是遇到了依赖的问题，直接尝试删除所有包，包括全局包，发现一个报错，大概就是说npm要没钱了，快来funding，好家伙，我直接npm uninstall * --no-fund删除了所有依赖，然后重新npm install，跑完之后在此run serve，显然还是不行，问了王哥之后他给出了一个解决办法，先build然后用nginx反代到build之后生成的dist文件夹中。于是开始build，很不错，这回没有报错。于是开始了nginx反代。

Nginx

服务器没有绑定域名，因此直接将服务器的某个端口直接映射到前端渲染出来的dist文件夹中去，需要现在安全组放行端口，这里就不得不提一下宝塔界面了，最初接触服务器的时候感觉宝塔确实很方便，今天运维也吐槽了一下，有些地方宝塔反而做复杂了，我就感觉上传或者下载文件比较方便，懒得用ftp。还不得不提yum包管理器是我用过最难用的，不如pacman，也没apt包全，但是总不能在服务器上跑arch吧 Orz。 在宝塔上装了Nginx，开始做反代。 先是监听一下888端口,并反代/请求到dist文件夹,设置首页为index.html

1
2
3
4
5
6

server 
{
    listen 888;
    index index.html index.htm index.php;
    root   /root/dev/OnlineJudge/front_end/dist;
}

好，重载一下nginx的配。 咦，发现403 forbidden，运维猜测是nginx没有权限访问那个目录。 这就开始打算直接chmod 777了，仔细一看发现，没改nginx配置里的user。

1

user  root root;

正常情况下建议分一个用户单独给nginx。 然后发现访问首页是空白内容，打开F12看看，发现是js和css的请求全阻塞了，又去看了一眼nginx的配置，发现正则匹配的js和css文件目录不对。

1
2
3
4
5
6
7
8
9

 location ~ .*\.js?$
{
    root   /root/dev/OnlineJudge/front_end/dist;
}

location ~ .*\.css?$
{
    root   /root/dev/OnlineJudge/front_end/dist;
}

这里要注意，一开始我是分别代理到/dist/js和/dist/css文件夹的，这样是不对的，因为请求的uri里是带有js和css字段的，于是就造成了路径不对，成了/js/js/**。 至此，首页可以成功进入了。 开始测试喜闻乐见的登录环节，发现请求没发出去，前端的请求之前是发送到远程服务器的，现在应该是访问本机localhost，于是进行代理转发请求

1
2
3
4

location /api
{
    proxy_pass http://127.0.0.1:5000;
}

终于可以登录了。到了八点多，感觉要下班了，又发现后台登录不进去了，又发现是只有我自己的chrome登录不进去，看日志的报错是interface提取的时候出问题了，uint和int之间产生了冲突，但是感觉事情没有那么简单，定位到出错的代码之后，发现异常是用_接收的，于是又对id打了log，再次运行。 这个id怎么这么熟悉。原来是前端的session里的id，看来是因为前台后台共用了session，导致id混用了。

End

此时已经到了晚上八点多了，看似已经解决了不少bug，但是很多问题都是和OJ无关的配置问题，真正的debug才刚刚开始。

项目正在稳定的向前推进。