详解通过Nginx部署Django(基于ubuntu)

Django的部署可以有很多方式,采用nginx+uwsgi的方式是其中比较常见的一种方式。

在这种方式中,我们的通常做法是,将nginx作为服务器最前端,它将接收WEB的所有请求,统一管理请求。nginx把所有静态请求自己来处理(这是NGINX的强项)。然后,NGINX将所有非静态请求通过uwsgi传递给Django,由Django来进行处理,从而完成一次WEB请求。

可见,uwsgi的作用就类似一个桥接器。起到桥梁的作用。

Linux的强项是用来做服务器,所以,下面的整个部署过程我们选择在Ubuntu下完成。

一、安装Nginx      

Nginx是一款轻量级的Web 服务器/反向代理服务器及电子邮件(IMAP/POP3)代理服务器,并在一个BSD-like 协议下发行。其特点是占有内存少,并发能力强,事实上nginx的并发能力确实在同类型的网页服务器中表现较好。

Nginx同样为当前非常流行的web服务器。利用其部署Django,我们在此也做简单的介绍。

Nginx官网:http://nginx.org/

打开ubuntu控制台(ctrl+alt+t)利用Ubuntu的仓库安装。

fnngj@ubuntu:~$ sudo apt-get install nginx #安装

启动Nginx:

fnngj@ubuntu:~$ /etc/init.d/nginx start #启动
fnngj@ubuntu:~$ /etc/init.d/nginx stop #关闭
fnngj@ubuntu:~$ /etc/init.d/nginx restart #重启

修改Nginx默认端口号,打开/etc/nginx/nginx.conf 文件,修改端口号。

 server {
  listen    8088;  # 修改端口号
  server_name localhost;

  #charset koi8-r; 

  #access_log logs/host.access.log main;

  location / {
    root  html;
    index index.html index.htm;
  }

大概在文件36行的位置,将默认的80端口号改成其它端口号,如 8088。因为默认的80端口号很容易被其它应用程序占用。

然后,通过上面命令重启nginx。访问:http://127.0.0.1:8088/

  

如果出现如上图,说明Nginx启动成功。

二、安装uwsgi                     

通过pip安装uwsgi。

root@ubuntu:/etc# python3 -m pip install uwsgi

测试uwsgi,创建test.py文件:

def application(env, start_response):
  start_response('200 OK', [('Content-Type','text/html')])
  return [b"Hello World"]

通过uwsgi运行该文件。

fnngj@ubuntu:~/pydj$ uwsgi --http :8001 --wsgi-file test.py

接下来配置Django与uwsgi连接。此处,假定的我的django项目位置为:/home/fnngj/pydj/myweb

代码如下:

fnngj@ubuntu:~/pydj$ uwsgi --http :8001 --chdir /home/fnngj/pydj/myweb/ --wsgi-file myweb/wsgi.py --master --processes 4 --threads 2 --stats 127.0.0.1:9191

常用选项:

http : 协议类型和端口号

processes : 开启的进程数量

workers : 开启的进程数量,等同于processes(官网的说法是spawn the specified number ofworkers / processes)

chdir : 指定运行目录(chdir to specified directory before apps loading)

wsgi-file : 载入wsgi-file(load .wsgi file)

stats : 在指定的地址上,开启状态服务(enable the stats server on the specified address)

threads : 运行线程。由于GIL的存在,我觉得这个真心没啥用。(run each worker in prethreaded mode with the specified number of threads)

master : 允许主进程存在(enable master process)

daemonize : 使进程在后台运行,并将日志打到指定的日志文件或者udp服务器(daemonize uWSGI)。实际上最常用的,还是把运行记录输出到一个本地文件上。

pidfile : 指定pid文件的位置,记录主进程的pid号。

vacuum : 当服务器退出的时候自动清理环境,删除unix socket文件和pid文件(try to remove all of the generated file/sockets)

三、Nginx+uwsgi+Django       

接下来,我们要将三者结合起来。首先罗列一下项目的所需要的文件:

myweb/

├── manage.py

├── myweb/

│  ├── __init__.py

│  ├── settings.py

│  ├── urls.py

│  └── wsgi.py

└── myweb_uwsgi.ini

在我们通过Django创建myweb项目时,在子目录myweb下已经帮我们生成的 wsgi.py文件。所以,我们只需要再创建myweb_uwsgi.ini配置文件即可,当然,uwsgi支持多种类型的配置文件,如xml,ini等。此处,使用ini类型的配置。

# myweb_uwsgi.ini file
[uwsgi]

# Django-related settings

socket = :8000

# the base directory (full path)
chdir      = /home/fnngj/pydj/myweb

# Django s wsgi file
module     = myweb.wsgi

# process-related settings
# master
master     = true

# maximum number of worker processes
processes    = 4

# ... with appropriate permissions - may be needed
# chmod-socket  = 664
# clear environment on exit
vacuum     = true

这个配置,其实就相当于在上一小节中通过wsgi命令,后面跟一堆参数的方式,给文件化了。

socket  指定项目执行的端口号。

chdir   指定项目的目录。

module  myweb.wsgi ,可以这么来理解,对于myweb_uwsgi.ini文件来说,与它的平级的有一个myweb目录,这个目录下有一个wsgi.py文件。

其它几个参数,可以参考上一小节中参数的介绍。

接下来,切换到myweb项目目录下,通过uwsgi命令读取myweb_uwsgi.ini文件启动项目。

fnngj@ubuntu:~$ cd /home/fnngj/pydj/myweb/
fnngj@ubuntu:~/pydj/myweb$ uwsgi --ini myweb_uwsgi.ini
[uWSGI] getting INI configuration from myweb_uwsgi.ini
*** Starting uWSGI 2.0.12 (32bit) on [Sat Mar 12 13:05:06 2016] ***
compiled with version: 4.8.4 on 26 January 2016 06:14:41
os: Linux-3.19.0-25-generic #26~14.04.1-Ubuntu SMP Fri Jul 24 21:18:00 UTC 2015
nodename: ubuntu
machine: i686
clock source: unix
detected number of CPU cores: 2
current working directory: /home/fnngj/pydj/myweb
detected binary path: /usr/local/bin/uwsgi
!!! no internal routing support, rebuild with pcre support !!!
chdir() to /home/fnngj/pydj/myweb
your processes number limit is 15962
your memory page size is 4096 bytes
detected max file descriptor number: 1024
lock engine: pthread robust mutexes
thunder lock: disabled (you can enable it with --thunder-lock)
uwsgi socket 0 bound to TCP address :8000 fd 3
Python version: 3.4.3 (default, Oct 14 2015, 20:37:06) [GCC 4.8.4]
*** Python threads support is disabled. You can enable it with --enable-threads ***
Python main interpreter initialized at 0x8b52dc0
your server socket listen backlog is limited to 100 connections
your mercy for graceful operations on workers is 60 seconds
mapped 319920 bytes (312 KB) for 4 cores
*** Operational MODE: preforking ***
WSGI app 0 (mountpoint='') ready in 1 seconds on interpreter 0x8b52dc0 pid: 7158 (default app)
*** uWSGI is running in multiple interpreter mode ***
spawned uWSGI master process (pid: 7158)
spawned uWSGI worker 1 (pid: 7160, cores: 1)
spawned uWSGI worker 2 (pid: 7161, cores: 1)
spawned uWSGI worker 3 (pid: 7162, cores: 1)
spawned uWSGI worker 4 (pid: 7163, cores: 1)

注意查看uwsgi的启动信息,如果有错,就要检查配置文件的参数是否设置有误。

再接下来要做的就是修改nginx.conf配置文件。打开/etc/nginx/nginx.conf文件,添加如下内容。

……
server {
  listen     8099;
  server_name  127.0.0.1
  charset UTF-8;
  access_log   /var/log/nginx/myweb_access.log;
  error_log    /var/log/nginx/myweb_error.log;

  client_max_body_size 75M;

  location / {
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:8000;
    uwsgi_read_timeout 2;
  }
  location /static {
    expires 30d;
    autoindex on;
    add_header Cache-Control private;
    alias /home/fnngj/pydj/myweb/static/;
   }
 }
……

listen 指定的是nginx代理uwsgi对外的端口号。

server_name  网上大多资料都是设置的一个网址(例,www.example.com),我这里如果设置成网址无法访问,所以,指定的到了本机默认ip。

在进行配置的时候,我有个问题一直想不通。nginx到底是如何uwsgi产生关联。现在看来大概最主要的就是这两行配置。

include uwsgi_params;

uwsgi_pass 127.0.0.1:8000;

include 必须指定为uwsgi_params;而uwsgi_pass指的本机IP的端口与myweb_uwsgi.ini配置文件中的必须一直。

现在重新启动nginx,翻看上面重启动nginx的命令。然后,访问:http://127.0.0.1:8099/

通过这个IP和端口号的指向,请求应该是先到nginx的。如果你在页面上执行一些请求,就会看到,这些请求最终会转到uwsgi来处理。

以上就是本文的全部内容,希望对大家的学习有所帮助,也希望大家多多支持我们。

(0)

相关推荐

  • 解决nginx报错信息 client intended to send too large body: 1331696 bytes

    解决nginx报错信息 client intended to send too large body: 1331696 bytes 1,nginx后台error日志报错 2016/02/05 16:23:56 [error] 12024#0: *441106971 connect() failed (111: Connection refused) while connecting to upstream, client: 113.214.1.10, server: localhost, req

  • Nginx服务器安装及配置文件与使用详解

    Nginx 在工作中已经有好几个环境在使用了,每次都是重新去网上找博客,各种编译配置,今天自己也整理一份安装文档和 nginx.conf 配置选项的说明,留作以后参考. 1. 安装nginx 1.1 选择稳定版本 我们编译安装nginx来定制自己的模块,机器CentOS 6.2 x86_64.首先安装缺少的依赖包: 复制代码 代码如下: # yum -y install gcc gcc-c++ make libtool zlib zlib-devel openssl openssl-devel

  • 使用nginx+tomcat实现静态和动态页面的分离

    博主最近在优化一个javaweb项目,该项目之前一直都是使用tomcat处理用户请求的,无论静态还是动态的东西,一律交给tomcat处理.tomcat主要是负责处理servlet的,静态的文件还是交给nginx处理,nginx对静态文件的处理比tomcat不是只快了一点,并且Nginx的使用对项目并发能力有很大的提升.下面主要记录下主要的配置过程: 实验环境:windows 实验工具:Nginx.tomcat windows下安装Nginx非常简单,去官网下载压缩包解压后并且双击解压目录下的ng

  • Nginx配置文件nginx.conf详细说明

    在此记录下Nginx服务器nginx.conf的配置文件说明, 部分注释收集与网络. #运行用户 user www-data; #启动进程,通常设置成和cpu的数量相等 worker_processes 1; #全局错误日志及PID文件 error_log /var/log/nginx/error.log; pid /var/run/nginx.pid; #工作模式及连接数上限 events { use epoll; #epoll是多路复用IO(I/O Multiplexing)中的一种方式,但

  • Nginx解决转发地址时跨域的问题

    一.什么是跨域问题 在一个服务器A里放置了json文件,另一个服务器B想向A发送ajax请求,获取此文件,会发生错误. Chrome提示: XMLHttpRequest cannot load ******. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access. 这就是跨域问题.解决方案有不少,比较好的

  • python正则分析nginx的访问日志

    前言 本文的脚本是分析nginx的访问日志, 主要为了检查站点uri的访问次数的,检查的结果会提供给研发人员做参考,因为谈到分析嘛,那肯定要用到正则表达式了,所以请没有接触过正则的小伙伴自行补脑,因为涉及正则的内容,实在没法展开写,正则的内容太过庞大,根本不是一篇两篇能写清楚的. 开始前,我们先看看要分析的日志结构: 127.0.0.1 - - [19/Jun/2012:09:16:22 +0100] "GET /GO.jpg HTTP/1.1" 499 0 "http://

  • Linux下安装配置nginx详解

    一.Linux下安装配置nginx 第一次安装nginx,中间出现的问题一步步解决. 用到的工具secureCRT,连接并登录服务器. 1.1 rz命令,会弹出会话框,选择要上传的nginx压缩包. #rz 1.2 解压 [root@vw010001135067 ~]# cd /usr/local/ [root@vw010001135067 local]# tar -zvxf nginx-1.10.2.tar.gz 1.3 进入nginx文件夹,执行./configure命令 [root@vw0

  • nginx强制使用https访问的方法(http跳转到https)

    需求简介 基于nginx搭建了一个https访问的虚拟主机,监听的域名是test.com,但是很多用户不清楚https和http的区别,会很容易敲成http://test.com,这时会报出404错误,所以我需要做基于test.com域名的http向https的强制跳转 我总结了三种方式,跟大家共享一下 nginx的rewrite方法 思路 这应该是大家最容易想到的方法,将所有的http请求通过rewrite重写到https上即可 配置 server { listen 111:80; serve

  • 使用MongoDB分析Nginx日志的方法详解

    本文我们要从日志文件中找出IP访问最多的10条记录,然后判断其是否合法,从而采取对应的措施.感兴趣的朋友们一起来看看吧. 日志解析流程 正常情况下,关于Nginx日志解析的流程如下所示: 一般情况下我们会对要解析的日志提前进行切分,常用的方式是按照日期,然后保存1个星期的日志.然后接下来就是日志的解析了,在这个过程中会使用到一些工具或编程语言,例如awk.grep.perl.python. 最后的入库和可视化处理一般视业务而定,没有强制的要求. 日志查询的解决方案 而关于Nginx日志解析的常用

  • 详解通过Nginx部署Django(基于ubuntu)

    Django的部署可以有很多方式,采用nginx+uwsgi的方式是其中比较常见的一种方式. 在这种方式中,我们的通常做法是,将nginx作为服务器最前端,它将接收WEB的所有请求,统一管理请求.nginx把所有静态请求自己来处理(这是NGINX的强项).然后,NGINX将所有非静态请求通过uwsgi传递给Django,由Django来进行处理,从而完成一次WEB请求. 可见,uwsgi的作用就类似一个桥接器.起到桥梁的作用. Linux的强项是用来做服务器,所以,下面的整个部署过程我们选择在U

  • 详解实现Nginx+Tomcat实现单IP、多域名、多站点的访问

    详解实现Nginx+Tomcat实现单IP.多域名.多站点的访问 前言: 最近帮朋友做了两个网站,预算很小很小.小到两个网站只能跑在一台512M内存的公网服务器上(tomcat+MySQL,由于内存太小了,只能把两个网站部署在同一个tomcat上),每个网站有自己的域名,初步考虑使有nginx做反向代理,把两个域名映射到相应的应用上.因此就有了标题所说的"nginx多域名单服务器单IP单Tomcat不同应用"上的配置问题.Nginx介绍的废话就不多说了,在这里把配置文件贴出来给大家参考

  • uwsgi+nginx部署Django项目操作示例

    本文实例讲述了uwsgi+nginx部署Django项目操作.分享给大家供大家参考,具体如下: uWSGI概述 uWSGI 是一个全功能的 HTTP 服务器,可以把 HTTP 协议转化成语言支持的网络协议. 安装uwsgi 使用pip安装即可 pip install uwsgi 安装完成后可测试 #vim test.py def application(env, start_response): start_response('200 OK', [('Content-Type','text/ht

  • 详解tomcat热部署和热加载的方法

    详解tomcat热部署和热加载的方法 我在项目开发过程中,经常要改动Java/JSP 文件,但是又不想从新启动服务器(服务器从新启动花时间),想直接获得(debug)结果.有两种方式热部署 和热加载: 1.热加载:在server.xml -> context 属性中 设置 reloadable="true" <Context docBase="xxx" path="/xxx" reloadable="true"/&

  • 详解docker nginx 容器启动挂载到本地

    首先nginx容器内部的结构: 进入容器: docker exec -it b511b6049f57 bash 查看容器的结构目录:其实每一个容器就相当于一个独立的系统. root@b511b6049f57:/# ls bin dev home lib64 mnt proc run srv tmp var boot etc lib media opt root sbin sys usr nginx的结构目录在容器中: 日志位置:/var/log/nginx/ 配置文件位置:/etc/nginx/

  • 详解Pycharm安装及Django安装配置指南

    本文的文字及图片来源于网络,仅供学习.交流使用,不具有任何商业用途,版权归原作者所有,如有问题请及时联系我们以作处理. 以下文章来源于Python实用宝典 ,作者Python实用宝典 Pycharm拥有强大的配置工具.Git版本管理工具.代码补全工具.Debug工具等等,这些都是进行大型项目开发的利器. 尤其是今天的主角Django,由于太过于重要了,Pycharm甚至专门给其提供了配置模板: 能直接在新建项目的时候选择Django并新建一个独立的虚拟环境: 从新建到编码测试,一套流程用起来都极

  • 详解用Nginx搭建CDN服务器方法(图文)

    利用Nginx的proxy_cache搭建缓存服务器一:编译ngx_cache_purge 1.Nginx的Proxy_cache是根据Key值md5哈希存储缓存,支持任意的Key,例如你可以根据"域名.URI.参数"组合成key,也支持非200状态码,如404/302等. 2.要利用Nginx的Proxy_cache,你需要在Nginx编译进ngx_cache_purge 模块,执行:nginx -V,查看有没有ngx_cache_purge 字样,没有的话需要自己手动编译. Ngi

  • 详解Docker+Jenkins+Gitlab+Django应用部署实践

    一.背景介绍 在互联网应用快速更新迭代的大背景下,传统的人工手动或简单脚本已经不能适应此变化,此时Devops为我们提供了良好的解决方案,应用好CI/CD可以大大的方便我们的日常工作,自动化快速的持续集成/持续交付为我们带来了应用开放的更快速度.更好的稳定性和更强的可靠性. 二.拓扑环境 2.1 架构拓扑 如上图实例,简单花了下流程拓扑: 当研发push本地代码到gitlab-server后,webhook自动触发jenkins构建应用 在docker host上部署应用git clone来自g

  • 详解jenkins自动化部署vue

    一.nodejs配置 首先加入nodejs插件 –>–> 在配置里面配置这个插件 –> 这样我们就能在自动构建发布的配置里看到nodejs的编译选项了 二.发布配置 首先新建一个自由风格的项目 然后配置构建保留天数和参数化构建 这里选择在svn上的资源,配置好访问的用户信息 这样我们在构建的时候能看到项目的不同版本 接下来选择构建的数据源位置 echo $PATH node -v npm -v npm install chromedriver --chromedriver_cdnurl=

  • 详解Vue项目部署遇到的问题及解决方案

    写在前面 Vue-Router 有两种模式,默认是 hash 模式,另外一种是 history 模式. hash:也就是地址栏里的 # 符号.比如 http://www.example/#/hello,hash 的值为 #/hello.特点:hash 虽然出现 URL 中,但不会被包含在 HTTP 请求中,对后端不会产生什么影响,改变 URL 不会重载页面. history:利用了 HTML5 History Interface 中新增的 pushState() 和 replaceState()

随机推荐