django+nginx+uwsgi搭建踩到的各种坑

  之前实习的时候搭建过一次,当初搭的时候顺风顺水,遇到的小坑也比较容易解决,这次在自己的机器和服务器上踩到了各种各样的坑 我一一列举 希望可以帮到遇到同样问题的人吧。

Error one : 静态文件无法加载

        在项目的开发阶段 django的settings.py里面有个DEBUG 开发过程中我们通常给的值会是True。django版本大于1.8的话 django会自己跑去找静态文件的 不 需要进行其他什么操作了 但是django的版本小于1.8的话 就需要在url中做静态文件的相关配置了 我这边的django版本是2.1 所以django自己对静态文件进行的搜索

        但是在生产环境中 这个True变成False 你再次刷新你的网站 你会发现 我的静态文件都让谁吃了 怎么加载不出来 你F12查看图片的地址 点进去你会发现你看 到的是 404 NOT FOUND 这时候就很难受了 不是说好django版本高会自己找吗 蒙人吗 我在网上查询之后看到 Django 关闭DEBUG模式后 就相当于是生产环境了 Django官网上指出如果是django框架一旦作为生产环境 那么它的静态文件访问接口就不应该从Django框架中找了 应该有独立的web环境 这个环境指什么 就是指 nginx 了

        那好 加载不出来得用nginx对吧 好 那我进行配置(上一篇文章中是正确的配置方法) 配置完之后我再去刷新页面 我擦嘞? 怎么还没有

        下面我列出我的路径 来解释原因

        A /root/foiod/blog/static foiod项目中blog(app)下的静态文件static

        B /root/foiod/static foiod项目下的静态文件static

        {% static 'blog/img/1.jpg'%} HTML中导入静态文件的路径

        我把两条路径分成A B ,在开发过程中 ,HTML会从A路径中寻找静态文件 所以在我们开发测试中 这个项目的静态文件是没有什么问题的

         但是 在生产环境中 HTML访问的路径就会发生变化 他不会从A中寻找 他是从B中去寻找的 这也就是咱们的静态文件被吃了的原因 事实上他只是迷路了 我们需 要给他指出来一条路 django就可以自己找到那些静态文件了 这边我们需要在django下的settings.py中添加一段代码

         STATIC_ROOT = os.path.join(BASE_DIR,'static')

         BASE_DIR是项目根目录 比如我的项目是foiod 那么路径就是/root/foiod/static ,也就是我们的B路径

         现在我们需要收集静态文件到这个位置 记得收集的命令吗?

         是这个 python manage.py collectstatic

         收集完之后重启nginx sudo /etc/init.d/nginx restart 这样 我们的静态文件加载问题算是解决了一大半了吧 然后咱们刷新一下网站 你心里估计已经有说不清的草泥马在奔腾了 为什么还没有 ??? F12开发者工具看下 点击图片链接你发现不报404了 开始403了 心中好歹有点慰藉 这算是给导入了 发生403应该就是权限的问题 因为我这边项目放在root下 所以我得修改root的权限(考虑到安全问题 以后还是不要放root了) 但是你要是自己玩的话 可以来个这条命令

          chmod -R 777 root  包爽

        好了 权限问题咱们解决了 刷新网页 你发现 你的静态文件已经加载出来了 完美!!!

Error two : 端口问题

     报错代码 probably another instance of uWSGI is running on the same address (:8002). bind(): Address already in use [core/socket.c line 769]

     原因 uwsgi启动太多次

     解决方法: 看看是谁把坑给占了 杀了他在整一个

     步骤

     lsof -i :8002 先看看是谁把这个端口给占了

     sudo kill -9 PID PID 根据端口号把他给杀掉

     重新启动项目 uwsgi --ini blog_uwsgi.ini

     OK 问题解决

Error three : buffer-size的限制

     原因:默认的uwsgi分配一个小的buffer(4k)来接收每个请求的头信息 如果在日志中看见"invalid request block size" 说明这个默认值太小了 你的请求头他放不下 你需要给他弄一个大点的

     解决方法 两种:

     1、启动项目时加个参数 uwsgi -b 大小值 blog_uwsgi.ini

     2、在uwsgi.ini 里面加个配置参数 buffer-size = 大小值

     ok~~~

Error four : 防火墙导致页面无法访问以及云平台的端口开放

     原因:我这个项目放在阿里云上面 刚开始的时候配置也没什么问题 就是进不去 后来发现系统的防火墙没关

     解决方法:

     ufw disable 关闭防火墙

     ufw enable 开启防火墙

以上是我搭建过程中遇到的问题 希望可以对一些搭建中的朋友有帮助

猜你喜欢

转载自blog.csdn.net/weixin_43589660/article/details/84938642
今日推荐