No artigo anterior, alguns alunos sentiram que era difícil entender sem detalhes, deixe-me explicar brevemente.
No caso do nosso desenvolvimento:
solicitação do navegador → python manage.py runserver (como 8000) → para o código do aplicativo (Django, Flask, etc.)
Implementado online:
solicitação de nome de domínio → resolução de DNS → IP do servidor → Nginx (porta 80) → encaminhamento de proxy 127.0.0.1: 8000 (IP não é necessariamente 127.0.0.1) → lógica do código do aplicativo para o projeto.
Durante todo o processo de implantação, adicionamos uma camada de docker para implantação isolada, que não só resolveu a inconsistência de vários ambientes em desenvolvimento (dev) teste (teste) online (prod), mas também atingiu o objetivo de empacotar uma vez e rodar em todos os lugares. , Não precisamos usar o virtualenv para isolamento do ambiente de pacote Python todos os dias, o que é muito conveniente no modo de desenvolvimento multijogador.
Na verdade, eu já falei sobre a prática de implantação em contêiner do Docker no capítulo de introdução do docker - get started . Quanto ao novato, se você sentir que não é fácil começar no início, você pode considerar remover o link intermediário do docker e executar o serviço diretamente na máquina Linux.
Depois de explicar o acima, vamos passar ao nosso tópico de hoje:
Implantação de Django + Nginx + Gunicorn
Gunicorn
Gunicorn é "Green Unicorn". Ele veio originalmente do Unicorn na comunidade Ruby. É um servidor Python WSGI HTTP para Unix. Gunicorn é amplamente compatível com vários frameworks da web e é simples e leve.
O motivo pelo qual usamos uWSGI ou Gunicorn é o Flask. O desempenho do serviço WSGI integrado do Django não é bom o suficiente. Geralmente é usado em ambientes de teste e desenvolvimento, e o serviço WSGI de alto desempenho é usado principalmente online.
Como introdução, cito um exemplo oficial:
$ pip install gunicorn
$ cat myapp.py
def app ( amb , start_response):
data = b "Olá, mundo! \ n"
start_response ("200 OK", [
("Content-Type", "text / plain"),
("Content-Length", str (len (data)))
])
return iter ([data])
$ gunicorn -w 4 myapp: app
[2014-09-10 10:22:28 +0000] [30869] [ INFO] Ouvindo em: http://127.0.0.1:8000 (30869)
[2014-09-10 10:22:28 +0000] [30869] [INFO] Usando trabalhador: sincronizar
[2014-09-10 10:22 : 28 +0000] [30874] [INFO] Booting worker com pid: 30874
[2014-09-10 10:22:28 +0000] [30875] [INFO] Booting worker com pid: 30875
[2014-09-10 10:22:28 +0000] [30876] [INFO] Booting worker com pid: 30876
[2014-09-10 10:22:28 +0000] [30877] [INFO] Inicializando trabalhador com pid: 30877
Após a instalação do gunicorn, podemos gunicorn -h ver a configuração. Normalmente, por conveniência, sempre colocamos o gunicorn no arquivo de configuração.
Uma coisa a mencionar aqui é que há um --statsd-host no gunicorn que torna possível rastrear solicitações de outra maneira. Eu mencionei o statsd no artigo de monitoramento anterior. Você pode consultar meu blog anterior "Construindo um sistema de monitoramento da web usando Statsd + Graphite + Grafana" , Clique para ler o texto original.
Como uWSGI, dou um exemplo de supervisor simples:
# gunicorn.conf.py import multiprocessing import socket bind = '0.0.0.0:9527' workers = multiprocessing.cpu_count () * 2 + 1 worker_class = 'gevent' # 搭配 gevent 运行 daemon = False proc_name = 'yourproject' pidfile = ' /data/run/gunicorn.pid ' loglevel =' error ' accesslog =' /data/yourproject/supervisor/gunicorn.access.log ' errorlog =' /data/yourproject/supervisor/gunicorn.error.log ' max_requests = 200000 # StatsD integration # StatsD host é omitido aqui, anexe `--statsd-host` a gunicorn # statsd_host = 'localhost: 8125' statsd_prefix = socket.gethostname ()
O motivo mencionado acima é porque o número de trabalhadores é o número de núcleos de CPU * 2 + 1. Não há muita base científica para isso. Baseia-se principalmente nas operações de leitura e gravação de um trabalho e no processamento de solicitações por outro trabalho. Você pode configurá-lo de acordo com sua própria situação. Para configurações mais especiais, você mesmo pode consultar os documentos.
supervisor & nginx & docker-compose
O supervisor é o mesmo que a implantação do aplicativo Django usando a prática de implantação em contêiner Docker (1) no artigo anterior . A única mudança é que nosso comando foi alterado de uUWSGI para gunicorn. Não listarei a configuração completa do supervisor aqui.
[programa: gunicorn] command = / path / to / gunicorn main: application -c /path/to/gunicorn.conf.py diretório = / path / to / project user = ninguém autostart = true autorestart = true redirect_stderr = true
Nginx é igual ao artigo anterior. Aqui está um exemplo simples:
servidor {
escuta 80;
server_name example.org;
access_log /var/log/nginx/example.log;
localização / {
proxy_pass http://127.0.0.1:8000;
proxy_set_header Host $ host;
proxy_set_header X-Forwarded-For $ proxy_add_x_forwarded_for;
}
}
A configuração docker-compose é a mesma do artigo anterior e há mais conteúdo, portanto, não será listado. Você pode consultar o artigo anterior para a configuração da implantação do aplicativo Django (1) usando as práticas de implantação em contêiner Docker .
No fim
Hoje elaboramos principalmente o segundo método de implantação do Django. Na verdade, esse processo é quase o mesmo que sem o docker. Você pode retirar o docker, o que não terá muito impacto em todo o processo.
Da mesma forma, todo o processo de minha implantação é relativamente simples, mas a situação real será um pouco diferente, será que você entendeu? Bem-vindos a todos para me deixarem uma mensagem e discutiremos juntos.
A implantação em contêiner do Docker está relacionada ao nosso próximo artigo, falaremos sobre o grande assassino dos Kubernets.