uwsgi+nginx項目部署

betacat 發布于2019-07-25 14:26 / 3298人閱讀

摘要：部署項目部署一個的開源框架。輪詢負載均衡在配置文件中添加如下配置，此配置有三臺服務器提供支付服務。缺省配置就是輪詢策略負載均衡支持和協議，只需要修改后面的協議即可支持的負載均衡只需將改為即可。

部署Django項目 Django+uWSGI+nginx 部署

django 一個pyhton的開源web框架。

uWSGI 一個基于自有的uwsgi協議、WSGI協議和http服務協議的web網關

nginx 常用的代理服務器

WSGI：一種實現python解析的通用接口標準/協議，是一種通用的接口標準或者接口協議，實現了python web程序與服務器之間交互的通用性。?
利用它，web.py或bottle或者django等等的python web開發框架，就可以輕松地部署在不同的web server上了；

uwsgi:同WSGI一樣是一種通信協議?
uwsgi協議是一個uWSGI服務器自有的協議，它用于定義傳輸信息的類型，它與WSGI相比是兩樣東西。

uWSGI?:一種python web server或稱為Server/Gateway?
uWSGI類似tornadoweb或者flup，是一種python web server，uWSGI是實現了uwsgi和WSGI兩種協議的Web服務器，負責響應python 的web請求。?
因為apache、nginx等，它們自己都沒有解析動態語言如php的功能，而是分派給其他模塊來做，比如apache就可以說內置了php模塊，讓人感覺好像apache就支持php一樣。?
uWSGI實現了wsgi協議、uwsgi協議、http等協議。 Nginx中HttpUwsgiModule的作用是與uWSGI服務器進行交換。

項目流程

首先客戶端請求服務資源，
nginx作為直接對外的服務接口,接收到客戶端發送過來的http請求,會解包、分析，
如果是靜態文件請求就根據nginx配置的靜態文件目錄，返回請求的資源，
如果是動態的請求,nginx就通過配置文件,將請求傳遞給uWSGI；uWSGI 將接收到的包進行處理，并轉發給wsgi，
wsgi根據請求調用django工程的某個文件或函數，處理完后django將返回值交給wsgi，
wsgi將返回值進行打包，轉發給uWSGI，
uWSGI接收后轉發給nginx,nginx最終將返回值返回給客戶端(如瀏覽器)。
*注:不同的組件之間傳遞信息涉及到數據格式和協議的轉換

? 作用:?

第一級的nginx并不是必須的，uwsgi完全可以完成整個的和瀏覽器交互的流程；?

在nginx上加上安全性或其他的限制，可以達到保護程序的作用；?

uWSGI本身是內網接口，開啟多個work和processes可能也不夠用，而nginx可以代理多臺uWSGI完成uWSGI的負載均衡；?

django在debug=False下對靜態文件的處理能力不是很好，而用nginx來處理更加高效。

安裝與配置

創建項目運行的虛擬環境

virtualenv env --python=python3.6
pip install -r requirements.txt  #安裝django運行環境

運行開發服務器測試

                cd project # 進入項目 project 目錄
                python manage.py runserver

            運行開發服務器測試，確保開發服務器下能正常打開網站。

安裝uWSGI

                # 在普通用戶下安裝
                sudo apt install libpython3.6-dev
                # 虛擬環境中
                pip install uwsgi

測試uWSGI: 新建文件test.py，寫入以下內容

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

運行

                # 0.0.0.0可以省略 
                sudo uwsgi --http 0.0.0.0:8000 --wsgi-file test.py --processes 4 --threads 3

      如果提示端口已經被占用，這時可以把相關的進程 kill 掉。

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

      按照端口進行查詢進程

          lsof -i :8002

      可以查出：

           COMMAND  PID USER   FD   TYPE             DEVICE SIZE/OFF NODE NAME
            uwsgi   2208   tu    4u  IPv4 0x53492abadb5c9659      0t0  TCP *:teradataordbms (LISTEN)
            uwsgi   2209   tu    4u  IPv4 0x53492abadb5c9659      0t0  TCP *:teradataordbms (LISTEN)

      這時根據 PID 可以用下面的命令 kill 掉相關程序：

sudo kill -9 2208 2209

運行django項目

      # --chdir 項目目錄 --home 虛擬環境目錄 project.wsgi 指的是 project/wsgi.py 文件
      uwsgi --http :8000 --chdir=/path/to/project  --home=/path/to/env --module project.wsgi

配置文件運行

            上面這樣使用一行命令太長了，我們使用 ini 配置文件來搞定，比如項目在 /home/ray/project 這個位置，在其中新建一個 uwsgi.ini 全路徑為 /home/ray/project/uwsgi.ini

                [uwsgi]
                #socket 為上線使用，http為直接作為服務器使用。
                socket = 127.0.0.1:8080 #ip和端口號可以改
                http = 127.0.0.1:8000
                #項目目錄
                chdir=/home/ray/project
                module=project.wsgi
                #虛擬環境目錄
                #home = home/ray/MxOnline/mxonlineEnv
                master = true         
                processes=4
                threads=2
                # 下面的參數不一定要加
                # pidfile=uwsgi.pid   uwsgi.pid 和uwsgi.log會在啟動uwsgi時自動生成在項目目錄下。
                # daemonize=uswgi.log
                # max-requests=2000    
                # chmod-socket=664
                # vacuum=true

# uwsgi啟動
uwsgi --ini uwsgi.ini
#uwsgi 停止
uwsgi --stop uwsgi.pid

安裝nginx,在普通用戶下安裝。

                # 安裝
                sudo apt install nginx 
                #重載
                sudo /etc/init.d/nginx reload
                sudo nginx -s reload
                # 啟動
                sudo /etc/init.d/nginx start
                # 停止
                sudo /etc/init.d/nginx stop
                # 重啟
                sudo /etc/init.d/nginx restart
                #查看nginx是否啟動
                ps -ef | grep nginx
            root     24956     1  0 19:41 ?        00:00:00 nginx: master process /usr/local/nginx/sbin/nginx
            nobody   24957 24956  0 19:41 ?        00:00:00 nginx: worker process
            root     24959 10533  0 19:41 pts/0    00:00:00 grep --color=auto nginx

配置 nginx

        ##### sites-enable 和 sites-available

 These directories are used to define configurations for your websites. Files are generally created in the "sites-available" directory, and thensymbolically linked to the "sites-enabled" directory when they are ready to go live.

? 都是在nginx.conf作修改，因為nginx.conf include指令已經包括了sites-enabled的內容，在site-enabled作修改就相當于在nginx.conf作修改，可維護性高。

include /etc/nginx/conf.d/*.conf;

include /etc/nginx/sites-enabled/*;

ites-available是存放當前的server配置, 在這里修改。

sites-enabled是激活并使用的server配置（從sites_available的文件創建快捷方式到sites-enabled）

新建一個網站 test

# 不用sudo沒有權限修改
sudo vim /etc/nginx/sites-available/test.conf

 #配置負載均衡
     # upstream ray {
     #    server 127.0.0.1:8000; # for a web port socket
     #}

     server {
         listen 80;
         server_name www.helloray.cn;#域名或者ip地址
         charset utf-8;
         # Django 的static和 media等靜態資源交給Nginx處理
         location /static {
             # 路徑必須和STATIC_ROOT一樣
             alias /var/www/myApp/static/;
         }
          location /media  {
              #項目下的media路徑
             alias /var/www/myApp/media/; 
         } 
         location /{
             # 必須和uwsgi.ini中socket一樣,配置了upstream可以將uwsgi_pass配置為：http:// +             upstream名稱，即“http://ray”.
             uwsgi_pass 127.0.0.1:8080; 
             #uwsgi_pass http://ray; 
             include uwsgi_params;
         }
     }

激活網站：建立軟鏈接

 sudo ln -s /etc/nginx/sites-available/test.conf  /etc/nginx/sites-enabled/test.conf

nginx創建靜態文件目錄，并更改權限

 sudo mkdir -vp /var/www/myApp/static/
 sudo chmod 777 /var/www/myApp/static/

在項目下setting.py 文件中

 STATIC_URL = "static"
 STATIC_ROOT = "/var/www/myApp/static/"
 STATICFILES_DIRS = [
   os.path.join(BASE_DIR,"static"),
 ]
 MEDIA_URL = "/media/"
 MEDIA_ROOT = os.path.join(BASE_DIR,"media")

在項目目錄下遷移靜態文件

 python manage.py collectstatic

Django中settings.py中的五個設置參數的一些故事：

1、MEDIA_ROOT與MEDIA_URL

事實上MEDIA_ROOT和MEDIA_URL代表的是用戶上傳后的文件一般保存的地方。我的理解是，可變文件的文件夾。

與這兩個參數有聯系的，是在Django的FileField和ImageField這樣的Model類中，有upload_to參數可選。當upload_to設置相關的地址后，如：upload_to="username"；文件上傳后將自動保存到 os.path.join(MEDIA_ROOT, upload_to)。

而MEDIA_URL,，則代表用戶通過URL來訪問這個本地地址的URL。如本機http://127.0.0.1/， MEDIA_URL設置為"/site_media/"，那么通過 http://127.0.0.1/site_media/***  就可以訪問相關的上傳圖片或者其他資源。

2、STATIC_ROOT與STATIC_URL

STATIC_ROOT和STATIC_URL則是網站中，用于網站顯示的靜態圖片、CSS、JS等文件的保存地址。我的理解是，運行中不會再變文件的文件夾（即不會刪除或者新增）

2.1 STATIC_URL

 同MEDIA_URL類似；STATIC_URL為"/static/"時候，通過http://127.0.0.1/static/***就可以訪問相關的靜態文件了。

2.2 STATIC_ROOT

STATIC_ROOT是一個比較特殊的文件夾。這是區別Django的開發模式和部署模式下最大的地方了。

通常我們在開發模式下，可以在我們所在的project下建立相應的app， 然后每個app下都建立相應的static文件夾。在開發模式下（Debug=True），Django將為我們自動查找這些靜態文件（每個app）并在網頁上顯示出來。然而，在部署模式下，Django認為這些工作交由web服務器來運行會更有效率。

因此，在部署時，我們需要運行一下python manage.py collectstatic 這個命令。這個命令將會把每個app里的static目錄下的文件copy到STATIC_ROOT這個文件夾下，這時候如果在部署模式下（Debug=False），網頁中相關的，如： http://127.0.0.1/static/*** 的訪問，將不會訪問Django下各個App中的static，而是STATIC_ROOT中所指定的文件夾。

3、Debug=False后，為何無法訪問圖片和js等文件了？

其實這個問題，是在于web服務器沒有對STATIC_ROOT以及MEDIA_ROOT這兩個文件夾進行映射所導致的。

以apache為例，假定：

STATIC_ROOT="/home/user/static/" 

STATIC_URL="/static/"

 MEDIA_ROOT="/home/user/media/"

MEDIA_URL="/media/"

那么可以在apache的配置文件中，增加以下：



Order deny,allow
Allow from all
Satisfy Any

Alias /static/     "/home/user/static"

Order deny,allow
Allow from all
Satisfy Any

Alias /media/      "/home/user/media/"


4、STATICFILES_DIRS：和TEMPLATE_DIRS的含義差不多，就是除了各個app的static目錄以外還需要管理的靜態文件，添加到這里的文件會在collectstatic時 copy到STATIC_ROOT中

負載均衡的設置

網站的訪問量越來越大，服務器的服務模式也得進行相應的升級，比如分離出數據庫服務器、分離出圖片作為多帶帶服務，這些是簡單的數據的負載均衡，將壓力分散到不同的機器上。有時候來自web前端的壓力，也能讓人十分頭痛。怎樣將同一個域名的訪問分散到兩臺或更多的機器上呢？這其實就是另一種負載均衡了，nginx自身就可以做到，只需要做個簡單的配置就行。

　　nginx不單可以作為強大的web服務器，也可以作為一個反向代理服務器，而且nginx還可以按照調度規則實現動態、靜態頁面的分離，可以按照輪詢、ip哈希、URL哈希、權重等多種方式對后端服務器做負載均衡，同時還支持后端服務器的健康檢查。

nginx 的 upstream目前支持 4 種方式的分配?

輪詢：將請求依次輪詢發給每個服務器，如果后端服務器down掉，能自動剔除。

最少鏈接：將請求發送給持有最少活動鏈接的服務器。

ip哈希：通過ip的哈希函數結果決定請求發送給哪個服務器。這樣每個訪客固定訪問一個后端服務器，可以解決session的問題。

權重：服務器的權重越高，處理請求的概率越大。用于后端服務器性能不均的情況。

輪詢負載均衡

在nginx.conf配置文件中添加如下配置，此配置有三臺服務器提供支付服務。

缺省配置就是輪詢策略;

nginx負載均衡支持http和https協議，只需要修改 proxy_pass后面的協議即可;

nginx支持FastCGI, uwsgi, SCGI,memcached的負載均衡,只需將 proxy_pass改為uwsgi_pass, fastcgi_pass, scgi_pass,memcached_pass即可。

此策略適合服務器配置相當，無狀態且短平快的服務使用。

http {
    upstream CashServers {
        server CashServers1.com;
        server CashServers2.com;
        server CashServers3.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://CashServers;
        }
    }
}

最少鏈接負載均衡

最少鏈接負載均衡通過least_conn指令定義;

此負載均衡策略適合請求處理時間長短不一造成服務器過載的情況;

http {
    upstream CashServers {
      least_conn;
        server CashServers1.com;
        server CashServers2.com;
        server CashServers3.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://CashServers;
        }
    }
}

ip哈希負載均衡

ip哈希負載均衡使用ip_hash指令定義;

nginx使用請求客戶端的ip地址進行哈希計算，確保使用同一個服務器響應請求;

此策略適合有狀態服務，比如session;

http {
    upstream CashServers {
      ip_hash;
        server CashServers1.com;
        server CashServers2.com;
        server CashServers3.com;
    }

    server {
        listen 80;

        location / {
            proxy_pass http://CashServers;
        }
    }
}

?權重負載均衡

權重負載均衡需要使用weight指令定義;

權重越高分配到需要處理的請求越多;

此策略可以與最少鏈接負載和ip哈希策略結合使用;

此策略比較適合服務器的硬件配置差別比較大的情況;

http {
    upstream CashServers {      
        server CashServers1.com weight=3;
        server CashServers2.com weight=2;
        server CashServers3.com weight=1;
    }

    server {
        listen 80;
        location / {
            proxy_pass http://CashServers;
        }
    }
}

附錄：參數說明

   >----------------附錄:uwsgi參數說明----------------
   >
   >- 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）。實際上最常
   >  用的，還是把運行記錄輸出到一個本地文件上。
   >- daemonize ： 使進程在后臺運行，并將日志打到指定的日志文件或者udp服務器（daemonize uWSGI）。實際上最常
   >  用的，還是把運行記錄輸出到一個本地文件上。
   >- vacuum ： 當服務器退出的時候自動清理環境，刪除unix socket文件和pid文件（try to remove all of the generated file/sockets）

GPU云服務器云服務器 uWSGI nginx部署https 部署前端到云服務器nginx 部署項目

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/40089.html

在阿里云上Ubuntu環境通過nginx+uwsgi部署Django項目

年前阿里云打折，1核1G的云服務器一年只要300多塊，果斷就租了1年的。既然服務器已經到手，怎么能不把自己寫的項目部署上去呢，其實網上關于nginx+uwsgi部署Django項目的文章有很多，但是這些文章要不就是很久之前的，要不就是互相抄襲，一路過來都是坑，這里重點吧在部署時候遇到的坑著重介紹一下： 1.首先部署django項目首先是django項目，由于我是使用Anaconda來進行版本控制...

asce1885 2019-07-31 11:03 評論0 收藏0
親身驗證切實可行的python項目部署方案

摘要：目標在瀏覽器輸入回車進入到項目主頁概念項目應用該文章中的項目為服務高并發處理的好穩定是服務器與框架之間一種簡單而通用的接口項目部署部署環境準備確保項目能夠運行安裝服務用去安裝安裝啟動驗證打開瀏覽器輸入安裝務必用去安裝安裝驗證目標 : 在瀏覽器輸入 www.python1.com 回車進入到Django項目主頁概念 Django項目(Web應用)該文章中的django項...

siberiawolf 2019-07-31 10:03 評論0 收藏0
親身驗證切實可行的python項目部署方案

摘要：目標在瀏覽器輸入回車進入到項目主頁概念項目應用該文章中的項目為服務高并發處理的好穩定是服務器與框架之間一種簡單而通用的接口項目部署部署環境準備確保項目能夠運行安裝服務用去安裝安裝啟動驗證打開瀏覽器輸入安裝務必用去安裝安裝驗證目標 : 在瀏覽器輸入 www.python1.com 回車進入到Django項目主頁概念 Django項目(Web應用)該文章中的django項...

dackel 2019-07-25 14:37 評論0 收藏0
django+uwsgi+nginx部署web項目

摘要：腳本啟動服務器方便起見，我們可以設置腳本啟動重啟服務器，在目錄下新建腳本，命名為，內容如下修改文件權限腳本啟動配置完成，如果發布新版本之后記得執行該腳本才能生效。系統需求 centos7 minimal python2.7 部署前的準備工作 centos7 minimal是精簡版本，需要手動去配置一些設置。 1. 配置網絡，設置固定ip ip可以自動獲取，我這...

Ali_ 2019-07-30 14:47 評論0 收藏0