django 为生产环境部署的改进点

django在生产环境部署的时候，支持多种部署方式，由于对Nginx比较熟，当前采用的是nginx+uwsgi的方式进行部署。配置完成之后，发现一些问题可能和之前的代码也有相应的关系，需要对代码进行重构和优化，以适应生产部署环境。在这里做一个总结。

static文件

在django的生产环境中，如果使用nginx+uwsgi，这时主要的请求是从uwsig来提供，然后在到nginx。而静态文件则直接通过nginx来访问。所以我们会在nginx里面配置相关的参数来指定nginx 的static目录从哪里走。

但是区别是在django容器中，在每个APP中部署的static文件夹，为默认的集中到同一个static目录中，形成统一的static路径。而nginx主要使用alias来解决单一的路径，这时某些路径可能就被丢掉了。造成部分文件无法访问。对于这种情况，我采用的解决方法是在源文件中将所有的static文件提取到根目录，这样所有的app都可以访问该目录，同时在生产环境时，只需要将nginx指定到这个目录就可以了。

看了一下源代码，不知道这是不是也是大多数工程会被static文件丢到外面来的原因。

static最佳实践

仔细研究了一下static的形成方式，以及相关整理方式，整理了一下static的相关实践方式

static的几个配置的研究

staticfiles的主要相关配置与分析

STATIC_ROOT：运行命令python manage.py collectstatic 之后静态文件将要复制到的目录，这个目录只有在运行collectstatic时候才会用到，不能想当然的以为这个目录和MEDIA_ROOT的作用是相同的，否则在开发环境的时候可能一直无法找到静态文件。

STATIC_URL：设置的static file的起始url，这个只是在template里边引用到，这个参数和MEDIA_URL的含义相同。

STATICFILES_DIRS：和TEMPLATE_DIRS的含义差不多，就是除了各个app的static目录以外还需要管理的静态文件设置，比如项目的公共文件差不多。

这几个项比较清楚了，下面仔细的分析一下python manage.py collectstatic这个命令

collectstatic命令

我们刚才上面有研究一下static文件，由于static文件是散落到各个部分的，我们不容易管理。而且从其他包引入的app，其静态文件还可能在site-package文件目录中，这样导致了文件上线后非常不好维护。

所以有了collectstatic命令，这个命令将所有的静态文件统一的手机到STATIC_ROOT目录所定义的位置，这样就不会在生产部署，如nginx下，需要alias的时候导入一大堆的包了，只需要导入这一个路径便能管理所有的静态文件。

讲一下static和media的区别

static更多的是存放如网页相关 css\javascript\image等文件。

media更多的存放运行时导入的图片、文档等动态文件。

讲讲最佳实践

所以在有collectstatic这个命令之后，我们不需要讲静态文件全部放在一个目录下，static文件还是在每个app中管理，这样对于app级别更加清晰，然后在每次需要发包的时候执行 python manage.py collectstatic就可以将所有的文件都导出到static路径下，这样线上的nginx可以直接使用配置这个路径到static中就可以了。

开发环境和线上环境：

在开发环境上，我们需要不时的修改static文件来满足我们的修改需要，此时如果试用static文件的话，那么每次修改必须要重新collectstatic才能重新发布静态文件。因为静态文件会首先使用static文件夹里面的静态文件来发布。所以不建议在开发环境上做collectstatic来进行static文件的收集。而是到正式环境中后，把所有的静态文件统一收集到这里。这样方便生产环境做静态文件配置化。

问题

发现如果在本地开发库里面就将static导入，运行collectstatic的话，会生成2份静态static文件，对于CSS等路径，在员路径修改就不生效了，会对开发造成一定的麻烦，所以最好还是在开发路径中不适用collectstatic，然后在正式发布环境上进行全路径的collectstatic，这样会更有效。