宝塔的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.pl
2、解除宝塔的提示限制,/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/static
static-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,转载请注明出处。