宝塔的Python项目管理器将于2023年12月31日下架，新装的宝塔再上架django项目需要从网站->Python项目中创建了，这里记录一下全新Debian部署宝塔安装项目的一些小坑。
镜像市场安装Debian，实测此系统比Centos占用内存要小一些，宝塔目前安装推荐的第一系统也是Debian。
一、安装mysql
安装完成后首先安装mysql 8，django4.0之后支持的mysql也是8，这里需要注意的是4G内存版本的服务器，是不允许编译安装mysql的，会提示至少需要[3700M]内存才可以安装，这就尴尬了，ECS给到的内存只有3655M，差一点点，需要更改两个地方。
1、解除 mysql 的限制，运行命令：
touch /www/server/panel/install/i_mysql.pl2、解除宝塔的提示限制，/www/server/panel/class/panelPlugin.py中，搜索至少需要四个字，将此三行代码注释，并重启面板才生效。
# if len(limit_list) > 0:
# err_msg = '至少需要' + '、'.join(limit_list) + '才能安装'
# return public.returnCode(False, err_msg, -1)做完这两步就可以编译安装mysql了，这里最好提重启下，或者先不要安装别的，让多余的内存空出来给安装mysql用，实测使用centos9编译安装mysql到一半左右会因为爆内存死机，不知是否是个例，编译安装时需要占用大量内存，内存不足时就卡住了。这可能也是为什么宝塔和mysql都默认禁止4G以下内存禁止编译安装的原因吧。
二、部署项目
www/wwwroot/创建一个文件夹，将项目文件上传到此目录，在网页/python项目中添加一个python项目，这里比原来的python项目管理器省事太多了，基本不需要设置，默认的就OK
启动方式选uwsgi，入口文件选wsgi.py，不要选asgi.py，貌似对asgi.py支持不是很好，别的默认就OK了
安装完看一下，如没有意外就能正常启动了。但是，如果项目里面有mysqlclient库的，可能就会发现无法成功安装。django的启动日志也会提示Error loading MySQLdb module.
这类问题在Debian或别的linux中算是常见了，原因是缺少必要的MySQL开发库和编译工具，导致mysqlclient无法正常安装，解决方案是安装必要的系统依赖
apt-get update
apt-get install python3-dev default-libmysqlclient-dev build-essential pkg-config接下来就可以正常安装mysqlclient库了，但是，，，如果不出意外的话很可能又出意外了。
需要注意mysqlclient的版本，测试时使用的最新的2.2.6是不兼容的，安装也无法正常使用，版本降到2.1.1可以正常使用。
接下来就可以正常访问网站了，但是发现所有静态文件都无法访问，这里有两种处理方案：
plan A：
利用Nginx 做静态规则，找到伪静态，或者直接在配置文件中编辑：
location /static/ {
alias /www/wwwroot/doubao.com/static/;
}planB：python项目设置的uwsgi.ini配置中加入
static-map = /static=/www/wwwroot/doubao.com/staticstatic-map是uwsgi的一个配置指令，用于映射静态文件路径。/static 是URL路径（与STATIC_URL对应）=/www/wwwroot/doubao.com/static 是服务器上实际的静态文件目录路径这样配置后，访问 http://doubao.com/static/xxx.css 时，uwsgi会直接从 /www/wwwroot/doubao.com/static/xxx.css 提供文件，不需要经过Django应用处理。
这里呢，当然是nginx做静态规则更好，因为静态文件的请求会被Nginx直接处理，不会传递给uwsgi。Nginx在处理静态文件方面性能更好。
三、访问测试
操作到这，常规的域名绑定好，外网映射打开，就可以打开网站测试下了，不出意外的可以正常访问了，看一下django后端的日志，发现一点点小问题：
后台访问日志的IP都变成127.0.0.1，而不是实际访问者的IP，这样看起来就不太方便了，解决方案，在uwsgi.ini中增加：
# 后端日志显示正确的访问IP而不是127.0.0.1
log-x-forwarded-for = true
log-x-forwarded-for = true，是uwsgi的一个特定配置指令，整个IP传递的流程是：
1. 客户端（真实IP：1.2.3.4）访问您的网站
2. nginx接收请求，添加各种header：
X-Real-IP: 1.2.3.4
X-Forwarded-For: 1.2.3.4
3. uwsgi通过log-x-forwarded-for = true识别这些header
4. Django最终收到真实IP信息
# 在不同的地方，这个IP相关的配置会有不同的写法：
# 在uwsgi.ini中
# log-x-forwarded-for = true
# 在nginx配置中
# proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
# 在Django代码中
# print("X-Forwarded-For:", request.META.get('HTTP_X_FORWARDED_FOR'))这样后端日志就会显示正确访问者IP地址信息了。
四、小优化
网站在实际的运行过程中，经常会发现uwsgi.log的日志里出现一些类似扫描器的痕迹，在日志里看着也不美观。有没有办法禁止掉呢，答案是有的，利用Nginx +openresty 做动态黑名单，由于openresty集成了lua，所以直接安装这个省事。 发现有扫描这些特殊链接的，就直接把IP加到nginx黑名单里去，这样在uwsgi.log 的日志中就看到不到此类链接了，到nginx时就被拦截了，也减少一些服务器请求压力。接下来是nginx配置：
# lua动态黑名单，此设置在最顶层
lua_shared_dict ip_blacklist 10m;
server
{
listen 80;
server_name www.doubao.com *.doubao.com ;
# ... 其他server配置
location / {
access_by_lua_block {
-- 获取共享内存字典
local blacklist = ngx.shared.ip_blacklist
-- 获取客户端IP
local client_ip = ngx.var.remote_addr
-- 检查是否在黑名单中
if blacklist:get(client_ip) then
ngx.exit(403)
end
-- 检查可疑URL
local suspicious_paths = {
"^/system",
"^/env",
"^/wp%-admin",
"^/phpMyAdmin"
}
local uri = ngx.var.uri
for _, pattern in ipairs(suspicious_paths) do
if ngx.re.match(uri, pattern, "jo") then
-- 将IP加入黑名单，24小时过期
blacklist:set(client_ip, true, 86400)
ngx.exit(403)
end
end
}
# 下面是正常的nginx代理设置 <<<
proxy_pass http://127.0.0.1:8900;
# ... 其他server配置
}
# HTTP反向代理相关配置结束 <<<
}此设置是利用lua在内存创建一个10M的黑名单，获取客户端的IP，检查是否在黑名单，如果就直接返回403错误， 不在的话，检查请求链接是否在suspicious_paths列表中，如果匹配也叫加入黑名单。 这样就实现了一个动态加入黑名单的列表，由于黑名单是内存里，重启nginx也黑名单会丢失，如需持久存在可以改放到redis中做持久化。
原文链接：http://www.itawp.com/536.html，转载请注明出处。
