前言

前几天，一个小伙伴找到我。说自己按照官网部署的wookey，遇到了问题。再上传文件时，直接失败，然后百度，google，官方文档，SQA找遍了。还是没有解决。
那我来看看吧。说实话，第一次听说wookey，也没用过。但作为运维，遇到各种稀奇古怪的问题是工作常态。不能被困难所吓倒，硬着头皮直接上吧。
首先，百度了一下。wookey是个什么东西。第一项就出来了。原来是一个为python脚本自动webui 的Django 应用。好吧，平时用惯了命令行，确实感觉跟这个隔着十万八千里。

title=

问小伙伴，怎么搭建的。问题可复现么？小伙伴说可以。然后找了一台闲着的vps。没多久，就弄好了。
废话不多说，开始干活。
远程登录vps，首先查看启动了哪些服务。

ps aux

发现，服务运行在docker 容器中。列出系统中正在运行的容器，进入容器查看，运行的服务。

docker ps -a
docker exec -it d56f7c1923b0 /bin/bash
ps aux | grep python

然后按照小伙伴的方法，上传脚本,运行。出现了小伙伴描述的情况。前端点击提交，报了一个400的错误。然后没有反应了。后端抛出了一个异常。如下图

问题复现后，我第一反应是配置错误。
然后自己按照，官方的安装步骤，自己安装了一遍。然后遇到了相同的问题。官方文档：

wooey官方文档

第一种安装和配置方法

这就比较闹心了。找到项目的github地址，翻看issues。关于上传文件的问题。从头翻到尾也没有相同的情况！郁闷增加中....
wooey的issues
没办法，因为是开源的项目，打开debug设置，定位到页面代码。前端js打印日志捕捉异常代码。error代码段是新添加的

cd site-packages/wooey/templates/wooey/scripts
vim script_view.html

然后捕捉到了异常。

问题出在了文件名上。意思就是参数包含路径。郁闷了，还是不知道怎么解决。

第二种方法用docker启动

然后继续读官方文档，看到官方docker的运行方式。又用docker方法运行起来。

服务启动后，上传脚本。测试，正常了。说明自己按照第一种方法，做的有地方没有想到。继续刨根问底。对比两种方式的区别和差异。首先查看python版本，然后查看django版本。好家伙，都不一样。
第一种方法，系统自动安装的版本，版本号如下。
而用docker方式安装，一切正常的版本 python是3.7.10 ，Django是3.2.3
然后先升级python，去python官网下载特定版本。

wget https://www.python.org/ftp/python/3.7.10/Python-3.7.10.tgz
tar -xvJf Python-3.7.0.tgz
cd Python-3.7.10
./configure --prefix=/usr/local/python3710
make && make install

替换后，问题依旧。继续升级Django

wget https://media.djangoproject.com/releases/3.2/Django-3.2.3.tar.gz
tar xvf Django-3.2.3.tar.gz
python -m pip install -e Django-3.2.3/

重启服务，恢复正常。然后按照第一种方法重新配置，问题又出现了。这次直接升级Django，问题解决。说明是Django版本导致的兼容性问题。
这就是整个排查过程，最后解决好像简单的很。但是整个过程持续了一天半的时间，死了脑细胞无数，无数次想砸键盘！
运维的工作就是这样，不断的试错，填坑。线上服务的升级更要谨慎。测试可以随便搞，正在运行的业务，动之前，也测试回滚！重要的事情多说几遍！