ジャンゴ+ Gunicorn + nginxのデプロイ道路

序文

最近、私はから私の個人的なウェブサイトを成功したフラスコに移行ジャンゴ、との最初の接触のDjango約4年前の時間、私はその時覚えDjangoのルーティング設定を使用して正则実施することを、私はこの事は特に迷惑持っていますその決定的ピットを放棄しました。そして、今年の初め、私が使用フラスコは私の個人的なウェブサイトを書いて、関数の先頭には、決定的に採用ルーティング設定と簡単な展開ルール、見て、比較的簡単です。私はより多くの機能を追加したい、私はそれを制御するために、より多くの困難があった、とつい最近、私は少しジャンゴを見て、過去数年間に変更しかし、その後、最新のバージョン2.2は、まだ非常に良い、ルーティングですフラスコとルールが合意されているので、私はピットを再入力します。

現時点では私の個人的なウェブサイトの基本的な機能は完成移行しました。しかし、デプロイ時に、私はあまりにも個人的に適用されていると感じ、いくつかの問題に遭遇し、オンラインいくつかのソリューションを読んで、またはあまりにも乱雑、または古すぎます。だからここに私の記録の展開プロセスです。

配備します

そこに多くのオンラインが使用されているUWSGI展開する方法を、私は個人的に好むGunicornをので、私はちょうど、次の記録ジャンゴ+ Gunicorn + nginxののUbuntu上の展開に関連するコンテンツ。

ステップ1

ターゲット・サーバーにWebサイトのソースをアップロード

私のソースコードはGitHubのに上にホストされているので、私は、サーバーへの私の元のサイトにクローン化されるように直接、次のコマンドを実行することができます。

git clone https://github.com/your-name/repo-name.git

# 进入项目目录
cd repo-name

# 创建并激活虚拟环境
python3 -m virtualenv venv
source venv/bin/activate

# 安装项目依赖
pip install -r requirements.txt

次のように現在使用されている依存パッケージ私のウェブサイトは以下のとおりです。

autopep8
Django
django-bootstrap4
django-ckeditor
gunicorn
Markdown
Pillow
python-slugify
requests

穴注記は、あなたが使用している場合、ある恐ろしい-slugifyを、使用してみてくださいPythonの-slugifyを一部のサーバーが正しくインストールされない可能性があるため、恐ろしい-slugify特定のバグを参照してください:用のPython-slugifyパッケージ変更との衝突

ステップ二つ

プロジェクトの設定、および静的リソースのコレクションを変更します

私は、本番環境への私のサイトを展開する必要があるので、私は、Djangoのデバッグモードを閉じて、静的リソースの設定を変更する必要があるので、サンプルの構成を以下に示します。

  • settings.py
SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')

DEBUG = os.environ.get('DJANGO_DEBUG', False)

TEMPLATE_DEBUG = os.environ.get('DJANGO_TEMPLATE_DEBUG', False)

ALLOWED_HOSTS = ["*"]

TEMPLATES = [
    {
        'BACKEND': 'django.template.backends.django.DjangoTemplates',
        'DIRS': [os.path.join(BASE_DIR, 'templates')],
        'APP_DIRS': True,
        'OPTIONS': {
            'context_processors': [
                'django.template.context_processors.debug',
                'django.template.context_processors.request',
                'django.contrib.auth.context_processors.auth',
                'django.contrib.messages.context_processors.messages',
            ],
        },
    },
]

STATIC_URL = '/static/'
STATIC_ROOT = os.path.join(BASE_DIR, 'staticfiles')
STATICFILES_DIRS = [
    os.path.join(BASE_DIR, 'static'),
]

MEDIA_URL = '/media/'
MEDIA_ROOT = os.path.join(BASE_DIR, 'media')

次に、以下のコマンド静的リソースの収集を実行します。

python manage.py collectstatic

その後、私も作成する必要がGunicornの設定プロセスを、サンプルの構成を以下に示します。

  • gunicorn.conf.py
# 安装
# sudo pip3 install gunicorn

import sys
import os
import logging
import logging.handlers
from logging.handlers import WatchedFileHandler
import multiprocessing

BASE_DIR = '/home/hippie/hippiezhou.fun/src'
sys.path.append(BASE_DIR)

LOG_DIR = os.path.join(BASE_DIR, 'log')
if not os.path.exists(LOG_DIR):
    os.makedirs(LOG_DIR)

# 绑定的ip与端口
bind = "0.0.0.0:8000"

# 以守护进程的形式后台运行
daemon = True

# 最大挂起的连接数,64-2048
backlog = 512

# 超时
timeout = 30

# 调试状态
debug = False

# gunicorn要切换到的目的工作目录
chdir = BASE_DIR

# 工作进程类型(默认的是 sync 模式,还包括 eventlet, gevent, or tornado, gthread, gaiohttp)
worker_class = 'sync'

# 工作进程数
workers = multiprocessing.cpu_count()

# 指定每个工作进程开启的线程数
threads = multiprocessing.cpu_count() * 2

# 日志级别,这个日志级别指的是错误日志的级别(debug、info、warning、error、critical),而访问日志的级别无法设置
loglevel = 'info'

# 日志格式
access_log_format = '%(t)s %(p)s %(h)s "%(r)s" %(s)s %(L)s %(b)s %(f)s" "%(a)s"'
# 其每个选项的含义如下:
'''
h          remote address
l          '-'
u          currently '-', may be user name in future releases
t          date of the request
r          status line (e.g. ``GET / HTTP/1.1``)
s          status
b          response length or '-'
f          referer
a          user agent
T          request time in seconds
D          request time in microseconds
L          request time in decimal seconds
p          process ID
'''

# 访问日志文件
accesslog = os.path.join(LOG_DIR, 'gunicorn_access.log')
# 错误日志文件
errorlog = os.path.join(LOG_DIR, 'gunicorn_error.log')
# pid 文件
pidfile = os.path.join(LOG_DIR, 'gunicorn_error.pid')

# 访问日志文件,"-" 表示标准输出
accesslog = "-"
# 错误日志文件,"-" 表示标准输出
errorlog = "-"

# 进程名
proc_name = 'hippiezhou_fun.pid'

# 更多配置请执行:gunicorn -h 进行查看

当社のウェブサイトの立ち上げ後、以下の方法を介して利用できます。

# 启动方式(首先需要切换到项目根目录,即和 manage.py 在同级目录下):

gunicorn -c gunicorn.conf.py website.wsgi:application

# 或
gunicorn website.wsgi:application -b 0.0.0.0:8000 -w 4 -k gthread

# 或
gunicorn website.wsgi:application -b 0.0.0.0:8000 -w 4 -k gthread  --thread 40 --max-requests 4096 --max-requests-jitter 512

# 查看进程
ps aux | grep gunicorn

ステップスリー

nginxの設定

最初の2つのステップを経て、我々が正常に当社のウェブサイトのアップとは、実行されていることができますが、内部でのみがアクセスすることができますので、我々は、外部ネットワークへのアクセスのために、nginxのでリバースプロキシを行う必要があります。

インストールおよび構成するためのコマンドを実行します

sudo apt-get install nginx

sudo service nginx start

# 备份默认配置
sudo cp /etc/nginx/sites-available/default /etc/nginx/sites-available/default.bak

# 启动 Vim 修改我们的网站配置
sudo vim /etc/nginx/sites-available/default

次のように例示的な構成です。

server{
        ...
        server_name hippiezhou.fun *.hippiezhou.fun;
        access_log /var/log/nginx/access.log;
        error_log /var/log/nginx/error.log;
        ...

        location / {
                # First attempt to serve request as file, then
                # as directory, then fall back to displaying a 404.
                # try_files $uri $uri/ =404;
                proxy_pass         http://127.0.0.1:8000; #此处要和你 gunicore 的 ip 和端口保持一致
                proxy_redirect     off;

                proxy_set_header   Host                 $host;
                proxy_set_header   X-Real-IP            $remote_addr;
                proxy_set_header   X-Forwarded-For      $proxy_add_x_forwarded_for;
                proxy_set_header   X-Forwarded-Proto    $scheme;
        }

        location /static {
                alias /root/hippiezhou.fun/src/staticfiles; # 此次需要配置为你的网站对应的静态资源的绝对路径
        }

        location /media {
                alias /root/hipiezhou.fun/src/media; # 如果你的网站有上传功能,需要配置该结点并指向目标路径
        }

        ...
}

コンフィギュレーションは、当社のウェブサイトに次の操作を実行した後に起動し、実行されます

# 若网站未启动执行该命令
gunicorn -c gunicorn.conf.py website.wsgi:application

sudo nginx -t
sudo service nginx restart

何もないならば、あなたはまだ、静的リソースにアクセスする間違っているものを見て開発ツールのサイトを開くことができない場合、このサイトは、通常の訪問する必要があります。

  • それは404個の質問の場合は、上記の構成に関連する設定を一覧表示するようにしてください、と私は同じです。
  • 問題が403である場合は、nginxのは、あなたの指定した静的リソースへのアクセス権を持つべきではない、あなたは、ユーザーnginxのの種類を変更する必要があり、プロには、次のコマンドを実行します
sudo vim /etc/nginx/nginx.conf

user後者の値が変更されroot、その後、nginxのを再起動します。

最後に、HTTPSを設定する方法について、そこにあまりにも多くの記述がなく、直接関係のリストサンプルスクリプト:

sudo apt-get update
sudo apt-get install software-properties-common
sudo add-apt-repository universe
sudo add-apt-repository ppa:certbot/certbot
sudo apt-get update
sudo apt-get install certbot python-certbot-nginx

sudo certbot --nginx

# sudo certbot renew --dry-run

sudo ufw allow https

sudo systemctl restart nginx

概要

展開時には、実際には、私は静的リソースの問題の問題に関するものではありませんが、オンラインの記事の多くを見るために、同じではない、といくつかの書き込みや間違ったほとんどの問題に遭遇しました。そこでここではいくつかをまとめたもの。幸いなことに、すべての最高。4年前に穴を埋めるために考えました。

最後に、広告を作る、私の個人的なウェブサイトを訪問する歓迎:hippiezhou.funを

おすすめ

転載: www.cnblogs.com/hippieZhou/p/11488514.html