Come configurare Django con Postgres, Nginx e Gunicorn su Ubuntu 18.04

introduzione

Django è un potente framework web che può aiutarti a far decollare la tua applicazione Python o il tuo sito web. Django include un server di sviluppo semplificato per testare il tuo codice in locale. Se preferisci qualcosa anche leggermente legato alla produzione, ti consigliamo un server web più sicuro e potente.

In questo tutorial, installerai e configurerai alcuni componenti su Ubuntu 18.04 per supportare e servire le applicazioni Django, configurare un database PostgreSQL invece di utilizzare il database SQLite predefinito, quindi configurare il server delle applicazioni Gunicorn per interfacciarsi con le tue applicazioni. Infine, configurerai Nginx per invertire il proxy su Gunicorn, dandoti accesso alle sue funzionalità di sicurezza e prestazioni per servire le tue applicazioni.

Prerequisiti

Per completare questo tutorial avrai bisogno di un server Ubuntu 18.04 configurato, un utente non root con privilegi sudo configurati e un firewall abilitato. Segui la nostra guida alla configurazione iniziale del server Ubuntu 18.04 per iniziare.

Passaggio 1: installazione dei pacchetti dai repository Ubuntu

Inizia scaricando e installando tutti gli elementi necessari dai repository di Ubuntu. Usa il gestore di pacchetti Python pip per installare componenti aggiuntivi in seguito.

Per prima cosa, aggiorna l'indice del pacchetto apt locale, quindi scarica e installa i pacchetti:

sudo apt update

Successivamente, installa i tuoi pacchetti. Questo dipende dalla versione di Python che verrà utilizzata dal tuo progetto.

Se stai usando Django con Python 3, esegui quanto segue:

sudo apt install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx curl

Django 1.11 è l'ultima versione di Django che supporterà Python 2. Se stai avviando nuovi progetti, ti consigliamo vivamente di scegliere Python 3. Se hai ancora bisogno di usare Python 2, esegui quanto segue:

sudo apt install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx curl

Questo installerà pip, i file di sviluppo Python necessari per compilare successivamente Gunicorn, il sistema di database Postgres e le librerie necessarie per interagire con esso, e il server web Nginx.

Passaggio 2: creazione del database e dell'utente PostgreSQL

In questo passaggio, creerai un database e un utente del database per la tua applicazione Django con PostgreSQL, noto anche come \Postgres.

Per impostazione predefinita, Postgres utilizza uno schema di autenticazione chiamato autenticazione peer per le connessioni locali. Ciò significa che se il nome utente del sistema operativo dell'utente corrisponde a un nome utente Postgres valido, quell'utente può accedere senza ulteriore autenticazione.

Durante l'installazione di Postgres, è stato creato un utente del sistema operativo denominato postgres per corrispondere all'utente amministratore PostgreSQL postgres. È necessario utilizzare questo utente per eseguire attività amministrative. Accedi a una sessione interattiva di Postgres utilizzando sudo e passa il nome utente con l'opzione -u:

sudo -u postgres psql

Riceverai un prompt PostgreSQL in cui puoi impostare i tuoi requisiti. Innanzitutto, crea un database per il tuo progetto:

CREATE DATABASE myproject;

Nota: ogni istruzione Postgres deve terminare con un punto e virgola. Assicurati che il tuo comando termini con uno se riscontri problemi.

Successivamente, crea un utente del database per il tuo progetto e seleziona una password sicura:

CREATE USER myprojectuser WITH PASSWORD 'password';

OutputCREATE ROLE

Successivamente, modifica alcuni dei parametri di connessione per l'utente che hai creato. Ciò velocizzerà le operazioni del database in modo che i valori corretti non debbano essere interrogati e impostati ogni volta che viene stabilita una connessione.

Imposta la codifica predefinita su UTF-8, che Django si aspetta:

ALTER ROLE myprojectuser SET client_encoding TO 'utf8';

OutputALTER ROLE

Quindi imposta lo schema di isolamento della transazione predefinito su read commit per bloccare le letture da transazioni non confermate:

ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';

OutputALTER ROLE

Poiché i tuoi progetti Django saranno impostati per utilizzare UTC per impostazione predefinita, imposta il fuso orario pertinente:

ALTER ROLE myprojectuser SET timezone TO 'UTC';

OutputALTER ROLE

Queste sono tutte raccomandazioni del progetto Django.

Ora dai al tuo nuovo accesso utente per amministrare il tuo nuovo database:

GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

OutputGRANT

Quando hai finito, esci dal prompt di PostgreSQL eseguendo quanto segue:

\q

Postgres è ora configurato correttamente in modo che Django possa connettersi e gestire le informazioni del suo database.

Passaggio 3: creazione di un ambiente virtuale Python per il tuo progetto

Ora che hai il tuo database, puoi iniziare a preparare il resto dei requisiti del tuo progetto. Ciò comporta l'installazione dei requisiti Python all'interno di un ambiente virtuale per una gestione più efficiente. L'installazione di Django in un ambiente virtuale specifico per il tuo progetto consentirà di gestire separatamente i tuoi progetti e i loro requisiti.

Per fare ciò, avrai bisogno di accedere al comando virtualenv. Inizia installandolo con pip.

Se stai usando Python 3, aggiorna pip:

sudo -H pip3 install --upgrade pip

Quindi installa il pacchetto:

sudo -H pip3 install virtualenv

Se stai usando Python 2, aggiorna pip:

sudo -H pip install --upgrade pip

Quindi installa il pacchetto:

sudo -H pip install virtualenv

Con virtualenv installato, puoi iniziare a formare il tuo progetto. Per prima cosa crea la directory in cui puoi conservare i tuoi file di progetto. Qui lo chiameremo myprojectdir, sentiti libero di chiamarlo come preferisci:

mkdir ~/myprojectdir

Quindi spostati in quella directory:

cd ~/myprojectdir

All'interno della directory del progetto, crea un ambiente virtuale Python:

virtualenv myprojectenv

Questo creerà una directory chiamata myprojectenv all'interno della tua directory myprojectdir. All'interno installerà una versione locale di Python e una versione locale di pip. Puoi usarlo per installare e configurare un ambiente Python isolato per il tuo progetto.

Ma prima di installare i requisiti Python del tuo progetto, devi attivare l'ambiente virtuale:

source myprojectenv/bin/activate

Il tuo prompt dovrebbe cambiare per indicare che stai operando all'interno di un ambiente virtuale Python. Sarà simile al seguente: (myprojectenv)user@host:~/myprojectdir$.

Con il tuo ambiente virtuale attivo, installa Django, Gunicorn e l'adattatore psycopg2 PostgreSQL con l'istanza locale di pip:

Nota: quando l'ambiente virtuale è attivato (quando il tuo prompt è preceduto da (myprojectenv)), usa pip invece di pip3, anche se stanno usando Python 3. La copia dello strumento dell'ambiente virtuale è sempre denominata pip, indipendentemente dalla versione di Python.

pip install django gunicorn psycopg2-binary

Ora hai tutto il software necessario per avviare un progetto Django.

Passaggio 4: creazione e configurazione di un nuovo progetto Django

Con i tuoi componenti Python installati, ora puoi creare i file di progetto Django effettivi. Dato che hai già una directory del progetto, dì a Django di installare i file qui. Creerà una directory di secondo livello con il codice effettivo, che è normale, e inserirà uno script di gestione in questa directory. Questo è importante perché stai definendo la directory in modo esplicito invece di consentire a Django di prendere decisioni relative alla tua directory corrente:

django-admin.py startproject myproject ~/myprojectdir

A questo punto, la directory del tuo progetto (~/myprojectdir in questo caso) avrà il seguente contenuto:

~/myprojectdir/manage.py: uno script di gestione del progetto Django.
~/myprojectdir/myproject/: Il pacchetto del progetto Django. Questo conterrà i file __init__.py, settings.py, urls.py e wsgi.py.
~/myprojectdir/myprojectenv/: la directory dell'ambiente virtuale che hai creato in precedenza.

La prossima cosa da fare con i file di progetto appena creati è regolare le impostazioni. Apri il file delle impostazioni nel tuo editor di testo preferito. Qui useremo nano:

nano ~/myprojectdir/myproject/settings.py

Inizia individuando la direttiva ALLOWED_HOSTS. Questo definisce un elenco di indirizzi o nomi di dominio del server che possono essere utilizzati per connettersi all'istanza Django. Qualsiasi richiesta in arrivo con un'intestazione Host non presente in questo elenco solleverà un'eccezione. Django richiede di impostarlo per prevenire una certa classe di vulnerabilità della sicurezza.

Tra parentesi quadre, elenca gli indirizzi IP o i nomi di dominio associati al tuo server Django. Ogni elemento deve essere elencato tra virgolette con voci separate da una virgola. Se preferisci le richieste per un intero dominio ed eventuali sottodomini, anteponi un punto all'inizio della voce. Nel seguente frammento, ci sono alcuni esempi commentati usati per dimostrare:

Nota: assicurati di includere localhost come una delle opzioni poiché eseguirai il proxy delle connessioni tramite un'istanza Nginx locale.

. . .
# The simplest case: just add the domain name(s) and IP addresses of your Django server
# ALLOWED_HOSTS = [ 'example.com', '203.0.113.5']
# To respond to 'example.com' and any subdomains, start the domain with a dot
# ALLOWED_HOSTS = ['.example.com', '203.0.113.5']
ALLOWED_HOSTS = ['your_server_domain_or_IP', 'second_domain_or_IP', . . ., 'localhost']

Quindi, trova la sezione che configura l'accesso al database. Inizierà con DATABASES. La configurazione nel file è per un database SQLite. Poiché hai già creato un database PostgreSQL per il tuo progetto, dovrai modificare queste impostazioni.

Aggiorna le impostazioni con le informazioni del tuo database PostgreSQL. Poi dì a Django di usare l'adattatore psycopg2 che hai installato con pip. È inoltre necessario fornire il nome del database, il nome utente dell'utente del database appena creato, la password dell'utente del database e specificare che il database può essere trovato sul computer locale. Puoi lasciare l'impostazione PORT come una stringa vuota:

. . .

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'myproject',
        'USER': 'myprojectuser',
        'PASSWORD': 'password',
        'HOST': 'localhost',
        'PORT': '',
    }
}

. . .

Successivamente, vai verso la fine del file e aggiungi un'impostazione che indica dove devono essere posizionati i file statici. Ciò è necessario affinché Nginx possa gestire le richieste per questi elementi. La seguente riga dice a Django di metterli in una directory chiamata static nella directory del progetto di base:

. . .

STATIC_URL = '/static/'
import os
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

Salva e chiudi il file quando hai finito. Se stai usando nano, puoi farlo premendo CTRL + X quindi Y e INVIO.

Passaggio 5: completamento della configurazione iniziale del progetto

Il passaggio successivo sarà la migrazione dello schema del database iniziale al database PostgreSQL utilizzando il seguente script di gestione:

~/myprojectdir/manage.py makemigrations
~/myprojectdir/manage.py migrate

Creare un utente amministrativo per il progetto:

~/myprojectdir/manage.py createsuperuser

Dovrai selezionare un nome utente, fornire un indirizzo e-mail e scegliere quindi confermare una password.

Raccogli tutto il contenuto statico nella posizione della directory configurata eseguendo quanto segue:

~/myprojectdir/manage.py collectstatic

I file statici verranno quindi inseriti in una directory chiamata static all'interno della directory del progetto.

Se hai seguito la guida alla configurazione iniziale del server, dovresti disporre di un firewall UFW a protezione del tuo server. Per testare il server di sviluppo, dovrai consentire l'accesso alla porta che utilizzerai. In questo caso, crea un'eccezione per la porta 8000:

sudo ufw allow 8000

Infine, testa il tuo progetto avviando il server di sviluppo Django con il seguente comando:

~/myprojectdir/manage.py runserver 0.0.0.0:8000

Nel tuo browser web, visita il nome di dominio o l'indirizzo IP del tuo server seguito da :8000:

http://server_domain_or_IP:8000

Dovresti ricevere la seguente pagina indice Django predefinita:

Se aggiungi /admin alla fine dell'URL nella barra degli indirizzi, ti verrà richiesto il nome utente e la password dell'amministratore che hai creato con il comando createsuperuser:

Dopo l'autenticazione, puoi accedere all'interfaccia amministrativa predefinita di Django:

Al termine dell'esplorazione, premi CTRL + C nella finestra del terminale per arrestare il server di sviluppo.

Passaggio 6: testare la capacità di Gunicorn di servire il progetto

Prima di lasciare il tuo ambiente virtuale, prova Gunicorn per assicurarti che possa servire l'applicazione. Puoi farlo spostandoti prima nella directory del tuo progetto:

cd ~/myprojectdir

Quindi esegui gunicorn per caricare il modulo WSGI del progetto:

gunicorn --bind 0.0.0.0:8000 myproject.wsgi

Questo avvierà Gunicorn sulla stessa interfaccia su cui era in esecuzione il server di sviluppo Django. Puoi tornare indietro e testare nuovamente l'applicazione.

Nota: l'interfaccia amministrativa non avrà alcuno stile applicato poiché Gunicorn non sa come trovare il contenuto CSS statico responsabile di ciò.

Ricapitolando, hai passato a Gunicorn un modulo specificando il percorso della directory relativa al file wsgi.py di Django, che è il punto di ingresso alla tua applicazione, usando la sintassi del modulo di Python. Gunicorn funge da interfaccia per la tua applicazione, traducendo le richieste del client da HTTP a chiamate Python che la tua applicazione può elaborare. All'interno di questo file è stata definita una funzione chiamata application, che viene utilizzata per comunicare con l'applicazione. Se sei interessato, puoi saperne di più sulla specifica WSGI.

Al termine del test, premi CTRL + C nella finestra del terminale per arrestare Gunicorn.

Ora hai finito di configurare la tua applicazione Django e puoi disattivare il tuo ambiente virtuale:

deactivate

L'indicatore dell'ambiente virtuale nel prompt verrà rimosso.

Passaggio 7: creazione di socket systemd e file di servizio per Gunicorn

Ora che hai verificato che Gunicorn può interagire con la tua applicazione Django, dovresti implementare un modo più robusto per avviare e arrestare il server delle applicazioni. Per fare ciò, creerai il servizio systemd e i file socket.

Il socket Gunicorn verrà creato all'avvio e ascolterà le connessioni. Quando si verifica una connessione, systemd avvierà automaticamente il processo Gunicorn per gestire la connessione.

Inizia creando e aprendo un file socket systemd per Gunicorn con privilegi sudo nel tuo editor di testo preferito:

sudo nano /etc/systemd/system/gunicorn.socket

All'interno, crea una sezione [Unit] per descrivere il socket, una sezione [Socket] per definire la posizione del socket e una sezione [Install] sezione per assicurarsi che il socket venga creato al momento giusto:

[Unit]
Description=gunicorn socket

[Socket]
ListenStream=/run/gunicorn.sock

[Install]
WantedBy=sockets.target

Salva e chiudi il file quando hai finito.

Successivamente, crea e apri un file di servizio systemd per Gunicorn con i privilegi sudo nel tuo editor di testo preferito. Il nome del file del servizio deve corrispondere al nome del file del socket ad eccezione dell'estensione:

sudo nano /etc/systemd/system/gunicorn.service

Inizia con la sezione [Unit], che viene utilizzata per specificare metadati e dipendenze. Aggiungi qui una descrizione del tuo servizio e comunica al sistema init di avviare questo servizio solo dopo che l'obiettivo di rete è stato raggiunto. Poiché il tuo servizio si basa sul socket del file socket, devi includere una direttiva Requires per indicare tale relazione:

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

Successivamente, aggiungi una sezione [Service] e specifica l'utente e il gruppo con cui desideri eseguire il processo. Fornisci al tuo normale account utente la proprietà del processo poiché possiede tutti i file pertinenti. Quindi assegna la proprietà del gruppo al gruppo www-data in modo che Nginx possa comunicare con Gunicorn.

Successivamente, traccia la directory di lavoro e specifica il comando da eseguire per avviare il servizio. In questo caso, specificare il percorso completo dell'eseguibile Gunicorn, installato all'interno del proprio ambiente virtuale. Quindi collega il processo al socket Unix che hai creato all'interno della directory /run in modo che il processo possa comunicare con Nginx. Registra tutti i dati sullo standard output in modo che il processo journald possa raccogliere i log di Gunicorn. Puoi anche specificare eventuali tweak Gunicorn opzionali qui. Per il nostro esempio, abbiamo specificato 3 processi di lavoro:

[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

Infine, aggiungi una sezione [Install]. Questo dirà a systemd a cosa collegare questo servizio se lo abiliti per l'avvio all'avvio. Vuoi che questo servizio venga avviato quando il normale sistema multiutente è attivo e funzionante:

[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

Con ciò, il tuo file di servizio systemd è completo. Salva e chiudi il file ora.

Quindi, avvia la presa Gunicorn. Questo creerà il file socket in /run/gunicorn.sock ora e all'avvio:

sudo systemctl start gunicorn.socket

Quindi abilitalo in modo che quando viene stabilita una connessione a quel socket, systemd avvierà automaticamente gunicorn.service per gestirlo:

sudo systemctl enable gunicorn.socket

È possibile confermare che l'operazione è andata a buon fine controllando il file socket.

Passaggio 8: verifica del file socket Gunicorn

Controlla lo stato del processo per scoprire se è stato possibile avviarlo:

sudo systemctl status gunicorn.socket

Output● gunicorn.socket - gunicorn socket
     Loaded: loaded (/etc/systemd/system/gunicorn.socket; enabled; vendor prese>
     Active: active (listening) since Thu 2021-12-02 19:58:48 UTC; 14s ago
   Triggers: ● gunicorn.service
     Listen: /run/gunicorn.sock (Stream)
      Tasks: 0 (limit: 1136)
     Memory: 0B
     CGroup: /system.slice/gunicorn.socket

Dec 02 19:58:48 gunicorn systemd[1]: Listening on gunicorn socket.

Successivamente, verifica l'esistenza del file gunicorn.sock all'interno della directory /run:

file /run/gunicorn.sock

Output/run/gunicorn.sock: socket

Se il comando systemctl status indica che si è verificato un errore o se non trovi il file gunicorn.sock nella directory, è un'indicazione che il socket Gunicorn non è stato creato correttamente . Controlla i log del socket Gunicorn eseguendo quanto segue:

sudo journalctl -u gunicorn.socket

Controlla il tuo file /etc/systemd/system/gunicorn.socket per correggere eventuali problemi prima di continuare.

Passaggio 9: test dell'attivazione del socket

Se hai avviato solo l'unità gunicorn.socket, gunicorn.service non sarà ancora attivo poiché il socket non ha ricevuto alcuna connessione. Controlla lo stato:

sudo systemctl status gunicorn

Output● gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset: enabled)
   Active: inactive (dead)

Per testare il meccanismo di attivazione del socket, invia una connessione al socket tramite curl:

curl --unix-socket /run/gunicorn.sock localhost

Dovresti ricevere l'output HTML dalla tua applicazione nel terminale. Ciò conferma che Gunicorn è stato avviato ed è in grado di servire la tua applicazione Django. Puoi verificare che il servizio Gunicorn sia in esecuzione controllando nuovamente lo stato:

sudo systemctl status gunicorn

Output●  gunicorn.service - gunicorn daemon
   Loaded: loaded (/etc/systemd/system/gunicorn.service; disabled; vendor preset
   Active: active (running) since Tue 2021-11-23 22:55:12 UTC; 11s ago
 Main PID: 11002 (gunicorn)
    Tasks: 4 (limit: 1151)
   CGroup: /system.slice/gunicorn.service
           ├─11002 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           ├─11018 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           ├─11020 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
           └─11022 /home/sammy/myprojectdir/myprojectenv/bin/python /home/sammy/
. . .

Se l'output di curl o l'output di systemctl status indica che si è verificato un problema, controlla i log per ulteriori dettagli:

sudo journalctl -u gunicorn

Controlla il tuo file /etc/systemd/system/gunicorn.service per eventuali problemi. Se apporti modifiche al file /etc/systemd/system/gunicorn.service, ricarica il demone per rileggere la definizione del servizio:

sudo systemctl daemon-reload

Quindi riavviare il processo Gunicorn:

sudo systemctl restart gunicorn

Se si verificano problemi come questi, risolverli prima di continuare.

Passaggio 10: configurare Nginx su Proxy Pass su Gunicorn

Ora che Gunicorn è configurato, successivamente configurerai Nginx per trasferire il traffico al processo.

Inizia creando e aprendo un nuovo blocco server nella directory sites-available di Nginx:

sudo nano /etc/nginx/sites-available/myproject

All'interno, apri un nuovo blocco server. Inizia specificando che questo blocco dovrebbe essere in ascolto sulla porta normale 80 e che dovrebbe rispondere al nome di dominio o all'indirizzo IP del tuo server:

server {
    listen 80;
    server_name server_domain_or_IP;
}

Quindi, chiedi a Nginx di ignorare eventuali problemi con la ricerca di una favicon. Inoltre, digli dove trovare le risorse statiche che hai raccolto nella tua directory ~/myprojectdir/static. Tutti questi file hanno un prefisso URI standard di /static, quindi puoi creare un blocco di posizione per soddisfare tali richieste:

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }
}

Infine, crea un blocco location/{} per soddisfare tutte le altre richieste. All'interno di questa posizione, includi il file proxy_params standard dall'installazione di Nginx e quindi passa il traffico direttamente al socket Gunicorn:

server {
    listen 80;
    server_name server_domain_or_IP;

    location = /favicon.ico { access_log off; log_not_found off; }
    location /static/ {
        root /home/sammy/myprojectdir;
    }

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

Salva e chiudi il file quando hai finito. Ora puoi abilitare il file collegandolo alla directory sites-enabled:

sudo ln -s /etc/nginx/sites-available/myproject /etc/nginx/sites-enabled

Testa la tua configurazione Nginx per errori di sintassi:

sudo nginx -t

Se non vengono segnalati errori, vai avanti e riavvia Nginx:

sudo systemctl restart nginx

Poiché non hai più bisogno di accedere al server di sviluppo, modifica le impostazioni del firewall rimuovendo la regola per aprire la porta 8000:

sudo ufw delete allow 8000

Quindi consenti il normale traffico sulle porte 80 e 443 — consentendo così le connessioni HTTP e HTTPS, rispettivamente — con il seguente comando:

sudo ufw allow 'Nginx Full'

Ora dovresti essere in grado di accedere al dominio o all'indirizzo IP del tuo server per visualizzare la tua applicazione.

Nota: dopo aver configurato Nginx, il passaggio successivo dovrebbe essere la protezione del traffico verso il server tramite SSL/TLS. Questo è importante perché senza di esso tutte le informazioni, comprese le password, vengono inviate in rete in formato testo.

Se hai un nome di dominio, il modo più rapido per ottenere un certificato SSL per proteggere il tuo traffico è utilizzare Let's Encrypt. Puoi configurarlo seguendo la nostra guida su Come proteggere Let's Encrypt con Nginx su Ubuntu 18.04. Segui la guida utilizzando il blocco del server Nginx che hai creato in questa guida.

Se non disponi di un nome di dominio, puoi comunque proteggere il tuo sito per test e apprendimento con un certificato SSL autofirmato. Ancora una volta, segui il processo utilizzando il blocco del server Nginx che hai creato in questo tutorial.

Passaggio 11: risoluzione dei problemi con Nginx e Gunicorn

Se riscontri problemi con la tua applicazione, le sezioni seguenti forniscono indicazioni su come risolvere i problemi dell'installazione.

Nginx mostra la pagina predefinita invece dell'applicazione Django

Se Nginx visualizza la pagina predefinita invece di inviare un proxy alla tua applicazione, di solito significa che devi modificare server_name all'interno di /etc/nginx/sites-available/myproject in modo che punti all'indirizzo IP o al nome di dominio del tuo server.

Nginx utilizza la direttiva server_name per determinare quale blocco del server utilizzare per rispondere alle richieste. Se ricevi la pagina Nginx predefinita, è un segno che Nginx non è stato in grado di abbinare la richiesta a un blocco del server in modo esplicito, quindi sta ricadendo sul blocco predefinito definito in /etc/nginx/sites-available /predefinito.

Il nome_server nel blocco server del tuo progetto deve essere più specifico di quello nel blocco server predefinito da selezionare.

Nginx mostra un errore 502 Bad Gateway invece dell'applicazione Django

Un errore 502 indica che Nginx non è in grado di inoltrare correttamente la richiesta. Un'ampia gamma di problemi di configurazione si esprime con un errore 502, pertanto sono necessarie ulteriori informazioni per una corretta risoluzione dei problemi.

Il posto principale per trovare ulteriori informazioni è nei log degli errori di Nginx. In genere, questo ti dirà quali condizioni hanno causato problemi durante l'evento proxy. Controlla i log degli errori di Nginx eseguendo quanto segue:

sudo tail -F /var/log/nginx/error.log

Ora, fai un'altra richiesta nel tuo browser per generare un nuovo errore (prova ad aggiornare la pagina). Dovresti ricevere un nuovo messaggio di errore scritto nel registro. Se leggi il messaggio, dovrebbe aiutarti a restringere il problema.

Potresti ricevere un messaggio simile al seguente:

connect() a unix:/run/gunicorn.sock fallito (2: Nessun file o directory)

Ciò indica che Nginx non è riuscito a trovare il file gunicorn.sock nella posizione specificata. Dovresti confrontare la posizione proxy_pass definita all'interno del file /etc/nginx/sites-available/myproject con la posizione effettiva di gunicorn.sock file generato dall'unità systemd gunicorn.socket.

Se non riesci a trovare un file gunicorn.sock all'interno della directory /run, generalmente significa che il file socket systemd non è stato in grado di crearlo. Ritorna alla sezione sul controllo del file socket Gunicorn per seguire i passaggi della risoluzione dei problemi per Gunicorn.

Un altro messaggio potrebbe essere simile al seguente:

connect() a unix:/run/gunicorn.sock fallito (13: Autorizzazione negata)

Ciò indica che Nginx non è stato in grado di connettersi al socket Gunicorn a causa di problemi di autorizzazione. Questo può accadere quando la procedura viene seguita utilizzando l'utente root invece di un utente sudo. Sebbene systemd sia in grado di creare il file socket Gunicorn, Nginx non è in grado di accedervi.

Questo può accadere se ci sono permessi limitati in qualsiasi punto tra la directory root (/) e il file gunicorn.sock. Puoi rivedere i permessi e i valori di proprietà del file socket e di ognuna delle sue directory principali passando il percorso assoluto del tuo file socket al comando namei:

namei -l /run/gunicorn.sock

Outputf: /run/gunicorn.sock
drwxr-xr-x root root /
drwxr-xr-x root root run
srw-rw-rw- root root gunicorn.sock

L'output visualizza le autorizzazioni di ciascuno dei componenti della directory. Esaminando i permessi (prima colonna), il proprietario (seconda colonna) e il proprietario del gruppo (terza colonna), puoi capire quale tipo di accesso è consentito al file socket.

In questo esempio, il file socket e ciascuna delle directory che lo precedono hanno permessi di lettura ed esecuzione universali (la colonna dei permessi per le directory termina con r-x invece di ---). Il processo Nginx dovrebbe essere in grado di accedere correttamente al socket.

Se una qualsiasi delle directory che portano al socket non dispone dell'autorizzazione di lettura ed esecuzione mondiale, Nginx non sarà in grado di accedere al socket senza consentire le autorizzazioni di lettura ed esecuzione mondiale o assegnando la proprietà del gruppo a un gruppo di cui Nginx fa parte .

Django sta visualizzando: impossibile connettersi al server: connessione rifiutata

Un messaggio che potresti ricevere da Django quando tenti di accedere a parti dell'applicazione nel browser web è:

OperationalError at /admin/login/
could not connect to server: Connection refused
    Is the server running on host "localhost" (127.0.0.1) and accepting
    TCP/IP connections on port 5432?

Ciò indica che Django non è in grado di connettersi al database Postgres. Verifica che l'istanza di Postgres sia in esecuzione:

sudo systemctl status postgresql

In caso contrario, puoi avviarlo e abilitarlo per l'avvio automatico all'avvio (se non è già configurato per farlo):

sudo systemctl start postgresql
sudo systemctl enable postgresql

Se i problemi persistono, assicurati che le impostazioni del database definite nel file ~/myprojectdir/myproject/settings.py siano corrette.

Ulteriore risoluzione dei problemi

Per un'ulteriore risoluzione dei problemi, i registri possono aiutare a restringere le cause principali. Controlla ciascuno di essi e prendi nota di eventuali messaggi che indicano aree problematiche.

I seguenti log possono essere utili:

Controlla i log del processo Nginx: sudo journalctl -u nginx
Controlla i log di accesso Nginx: sudo less /var/log/nginx/access.log
Controlla i log degli errori di Nginx: sudo less /var/log/nginx/error.log
Controlla i log dell'applicazione Gunicorn: sudo journalctl -u gunicorn
Controlla i log del socket Gunicorn: sudo journalctl -u gunicorn.socket

Man mano che aggiorni la configurazione o l'applicazione, probabilmente dovrai riavviare i processi per adeguarti alle modifiche.

Se aggiorni la tua applicazione Django, puoi riavviare il processo Gunicorn per raccogliere le modifiche eseguendo quanto segue:

sudo systemctl restart gunicorn

Se modifichi il socket Gunicorn o i file di servizio, ricarica il demone e riavvia il processo eseguendo quanto segue:

sudo systemctl daemon-reload
sudo systemctl restart gunicorn.socket gunicorn.service

Se modifichi la configurazione del blocco del server Nginx, testa la configurazione e quindi Nginx eseguendo quanto segue:

sudo nginx -t && sudo systemctl restart nginx

Questi comandi sono utili per applicare le modifiche durante la regolazione della configurazione.

Conclusione

In questa guida, imposti un progetto Django nel proprio ambiente virtuale e configuri Gunicorn per tradurre le richieste dei client in modo che Django possa gestirle. Successivamente, imposti Nginx in modo che funga da proxy inverso per gestire le connessioni client e servire il progetto corretto in base alla richiesta del client.

Django rende conveniente la creazione di progetti e applicazioni fornendo molti dei pezzi comuni, permettendoti di concentrarti sugli elementi unici. Sfruttando la catena di strumenti generale descritta in questo tutorial, puoi servire le applicazioni che crei da un singolo server.