☰

Beste Möglichkeit, Gunicorn und Nginx mit Django zu konfigurieren?

tag-icon • tag-icon nginx django gunicorn
Beste Möglichkeit, Gunicorn und Nginx mit Django zu konfigurieren?

Ich versuche, Django mit Gunicorn und Nginx auf Heroku bereitzustellen, und bin etwas verwirrt über die Art und Weise, Gunicorn und Nginx zu konfigurieren. Als ich im Internet gesucht habe, wurde normalerweise gunicorn.socket erstellt.

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

und gunicorn.service

[Unit]
Description=gunicorn daemon
Requires=gunicorn.socket
After=network.target

[Service]
User=sammy
Group=www-data
WorkingDirectory=/home/sammy/myprojectdir
ExecStart=/home/sammy/myprojectdir/myprojectenv/bin/gunicorn \
          --access-logfile - \
          --workers 3 \
          --bind unix:/run/gunicorn.sock \
          myproject.wsgi:application

[Install]
WantedBy=multi-user.target

und die nginx-Konfigurationsdatei in /etc/nginc/site-enabled/

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/administrator/Documents/Dashboard/dashboardBackend;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/run/gunicorn.sock;
    }
}

aber wenn ich zu den Gunicorn-Dokumenten gehe:https://docs.gunicorn.org/en/stable/deploy.html. nginx hat eine Konfigurationsdatei wie diese

worker_processes 1;

user nobody nogroup;
# 'user nobody nobody;' for systems with 'nobody' as a group instead
error_log  /var/log/nginx/error.log warn;
pid /var/run/nginx.pid;

events {
  worker_connections 1024; # increase if you have lots of clients
  accept_mutex off; # set to 'on' if nginx worker_processes > 1
  # 'use epoll;' to enable for Linux 2.6+
  # 'use kqueue;' to enable for FreeBSD, OSX
}

http {
  include mime.types;
  # fallback in case we can't determine a type
  default_type application/octet-stream;
  access_log /var/log/nginx/access.log combined;
  sendfile on;

  upstream app_server {
    # fail_timeout=0 means we always retry an upstream even if it failed
    # to return a good HTTP response

    # for UNIX domain socket setups
    server unix:/tmp/gunicorn.sock fail_timeout=0;

    # for a TCP configuration
    # server 192.168.0.7:8000 fail_timeout=0;
  }

  server {
    # if no Host match, close the connection to prevent host spoofing
    listen 80 default_server;
    return 444;
  }

  server {
    # use 'listen 80 deferred;' for Linux
    # use 'listen 80 accept_filter=httpready;' for FreeBSD
    listen 80;
    client_max_body_size 4G;

    # set the correct host(s) for your site
    server_name example.com www.example.com;

    keepalive_timeout 5;

    # path for static files
    root /path/to/app/current/public;

    location / {
      # checks for static file, if not found proxy to app
      try_files $uri @proxy_to_app;
    }

    location @proxy_to_app {
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_set_header X-Forwarded-Proto $scheme;
      proxy_set_header Host $http_host;
      # we don't want nginx trying to do something clever with
      # redirects, we set the Host: header above already.
      proxy_redirect off;
      proxy_pass http://app_server;
    }

    error_page 500 502 503 504 /500.html;
    location = /500.html {
      root /path/to/app/current/public;
    }
  }
}

Ich frage mich also, was der Unterschied zwischen diesen ist und wie man Gunicorn bzw. Nginx am besten einrichtet. Danke

Antwort1

Haben Sie vielleicht angenommen, dass dies unterschiedliche Ansätze sind? Es handelt sich um eine Konfiguration für Nginx, die es anweist, eine Verbindung zum /tmp/gunicorn.sockSocket herzustellen, und eine Konfiguration für systemd, die es anweist, Gunicorn auf demselben Socket einzurichten /tmp/gunicorn.sock.

Sie arbeiten in Kombination: Einer richtet einen Socket zum Hosten der Anwendung ein, einer richtet den HTTP-Server ein, um über diesen Socket den öffentlichen Zugriff auf diese Anwendung zu ermöglichen.

verwandte Informationen