Ricerca nel sito web

Come configurare Django con Postgres, Nginx e Gunicorn su Ubuntu 16.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 localmente, ma per qualsiasi cosa anche leggermente correlata alla produzione, è necessario un server web più sicuro e potente.

In questa guida, dimostreremo come installare e configurare alcuni componenti su Ubuntu 16.04 per supportare e servire le applicazioni Django. Imposteremo un database PostgreSQL invece di utilizzare il database SQLite predefinito. Configuriamo l'application server Gunicorn per interfacciarsi con le nostre applicazioni. Quindi configureremo Nginx per invertire il proxy su Gunicorn, dandoci accesso alle sue funzionalità di sicurezza e prestazioni per servire le nostre app.

Prerequisiti e obiettivi

Per completare questa guida, dovresti avere una nuova istanza del server Ubuntu 16.04 con un utente non root con i privilegi sudo configurati. Puoi imparare come configurarlo eseguendo la nostra guida alla configurazione iniziale del server.

Installeremo Django all'interno di un ambiente virtuale. L'installazione di Django in un ambiente specifico per il tuo progetto consentirà di gestire separatamente i tuoi progetti e i loro requisiti.

Una volta che il nostro database e la nostra applicazione saranno attivi e funzionanti, installeremo e configureremo il server delle applicazioni Gunicorn. Questo fungerà da interfaccia per la nostra applicazione, traducendo le richieste del client in HTTP in chiamate Python che la nostra applicazione può elaborare. Quindi configureremo Nginx davanti a Gunicorn per sfruttare i suoi meccanismi di gestione delle connessioni ad alte prestazioni e le sue funzionalità di sicurezza facili da implementare.

Iniziamo.

Installa i pacchetti dai repository di Ubuntu

Per iniziare il processo, scaricheremo e installeremo tutti gli elementi di cui abbiamo bisogno dai repository di Ubuntu. Useremo il gestore di pacchetti Python pip per installare componenti aggiuntivi un po' più tardi.

Dobbiamo aggiornare l'indice locale del pacchetto apt e quindi scaricare e installare i pacchetti. I pacchetti che installiamo dipendono dalla versione di Python che verrà utilizzata dal tuo progetto.

Se stai usando Python 2, digita:

  1. sudo apt-get update

  2. sudo apt-get install python-pip python-dev libpq-dev postgresql postgresql-contrib nginx

Se stai usando Django con Python 3, digita:

  1. sudo apt-get update

  2. sudo apt-get install python3-pip python3-dev libpq-dev postgresql postgresql-contrib nginx

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.

Creare il database e l'utente PostgreSQL

Entreremo subito e creeremo un database e un utente del database per la nostra applicazione Django.

Per impostazione predefinita, Postgres utilizza uno schema di autenticazione chiamato \autenticazione peer per le connessioni locali. Fondamentalmente, 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. Dobbiamo utilizzare questo utente per eseguire attività amministrative. Possiamo usare sudo e passare il nome utente con l'opzione -u.

Accedi a una sessione interattiva di Postgres digitando:

  1. sudo -u postgres psql

Ti verrà fornito un prompt PostgreSQL in cui possiamo impostare i nostri requisiti.

Innanzitutto, crea un database per il tuo progetto:

  1. CREATE DATABASE myproject;

Ogni istruzione Postgres deve terminare con un punto e virgola, quindi assicurati che il tuo comando termini con uno se riscontri problemi.

Quindi, crea un utente del database per il nostro progetto. Assicurati di selezionare una password sicura:

  1. CREATE USER myprojectuser WITH PASSWORD 'password';

Successivamente, modificheremo alcuni dei parametri di connessione per l'utente che abbiamo appena 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.

Stiamo impostando la codifica predefinita su UTF-8, che Django si aspetta. Stiamo anche impostando lo schema di isolamento delle transazioni predefinito su \read commit, che blocca le letture da transazioni non confermate. Infine, stiamo impostando il fuso orario. Per impostazione predefinita, i nostri progetti Django saranno impostati per utilizzare UTC Queste sono tutte raccomandazioni del progetto Django stesso:

  1. ALTER ROLE myprojectuser SET client_encoding TO 'utf8';

  2. ALTER ROLE myprojectuser SET default_transaction_isolation TO 'read committed';

  3. ALTER ROLE myprojectuser SET timezone TO 'UTC';

Ora possiamo dare al nostro nuovo accesso utente per amministrare il nostro nuovo database:

  1. GRANT ALL PRIVILEGES ON DATABASE myproject TO myprojectuser;

Quando hai finito, esci dal prompt di PostgreSQL digitando:

  1. \q

Crea un ambiente virtuale Python per il tuo progetto

Ora che abbiamo il nostro database, possiamo iniziare a preparare il resto dei requisiti del nostro progetto. Installeremo i nostri requisiti Python all'interno di un ambiente virtuale per una gestione più semplice.

Per fare ciò, dobbiamo prima accedere al comando virtualenv. Possiamo installarlo con pip.

Se stai usando Python 2, aggiorna pip e installa il pacchetto digitando:

  1. sudo -H pip install --upgrade pip

  2. sudo -H pip install virtualenv

Se stai usando Python 3, aggiorna pip e installa il pacchetto digitando:

  1. sudo -H pip3 install --upgrade pip

  2. sudo -H pip3 install virtualenv

Con virtualenv installato, possiamo iniziare a formare il nostro progetto. Crea e spostati in una directory in cui possiamo conservare i nostri file di progetto:

  1. mkdir ~/myproject

  2. cd ~/myproject

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

  1. virtualenv myprojectenv

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

Prima di installare i requisiti Python del nostro progetto, dobbiamo attivare l'ambiente virtuale. Puoi farlo digitando:

  1. source myprojectenv/bin/activate

Il tuo prompt dovrebbe cambiare per indicare che stai operando all'interno di un ambiente virtuale Python. Sarà simile a questo: (myprojectenv)user@host:~/myproject$< /codice>.

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

Indipendentemente dalla versione di Python che stai usando, quando l'ambiente virtuale è attivato, dovresti usare il comando pip (non pip3).

  1. pip install django gunicorn psycopg2

Ora dovresti avere tutto il software necessario per avviare un progetto Django.

Crea e configura un nuovo progetto Django

Con i nostri componenti Python installati, possiamo creare i file di progetto Django effettivi.

Crea il progetto Django

Poiché abbiamo già una directory del progetto, diremo 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. La chiave di ciò è che stiamo definendo la directory in modo esplicito invece di consentire a Django di prendere decisioni relative alla nostra directory corrente:

  1. django-admin.py startproject myproject ~/myproject

A questo punto, la directory del tuo progetto (~/myproject nel nostro caso) dovrebbe avere il seguente contenuto:

  • ~/myproject/manage.py: uno script di gestione del progetto Django.
  • ~/myproject/myproject/: Il pacchetto del progetto Django. Dovrebbe contenere i file __init__.py, settings.py, urls.py e wsgi.py.
  • ~/myproject/myprojectenv/: la directory dell'ambiente virtuale che abbiamo creato in precedenza.

Regola le impostazioni del progetto

La prima cosa che dovremmo fare con i nostri file di progetto appena creati è regolare le impostazioni. Apri il file delle impostazioni nel tuo editor di testo:

  1. nano ~/myproject/myproject/settings.py

Inizia individuando la direttiva ALLOWED_HOSTS. Questo definisce un elenco di indirizzi del server o nomi di dominio che possono essere utilizzati per connettersi all'istanza di 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 desideri richiedere un intero dominio ed eventuali sottodomini, anteponi un punto all'inizio della voce. Nello snippet qui sotto, ci sono alcuni esempi commentati usati per dimostrare:

. . .
# 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', . . .]

Quindi, trova la sezione che configura l'accesso al database. Inizierà con DATABASES. La configurazione nel file è per un database SQLite. Abbiamo già creato un database PostgreSQL per il nostro progetto, quindi dobbiamo regolare le impostazioni.

Modifica le impostazioni con le informazioni del tuo database PostgreSQL. Diciamo a Django di usare l'adattatore psycopg2 che abbiamo installato con pip. Dobbiamo fornire il nome del database, il nome utente del database, la password dell'utente del database e quindi specificare che il database si trova 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, spostati in fondo al file e aggiungi un'impostazione che indichi dove posizionare 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/'
STATIC_ROOT = os.path.join(BASE_DIR, 'static/')

Salva e chiudi il file quando hai finito.

Completa la configurazione iniziale del progetto

Ora possiamo migrare lo schema del database iniziale al nostro database PostgreSQL utilizzando lo script di gestione:

  1. ~/myproject/manage.py makemigrations

  2. ~/myproject/manage.py migrate

Crea un utente amministrativo per il progetto digitando:

  1. ~/myproject/manage.py createsuperuser

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

Possiamo raccogliere tutto il contenuto statico nella posizione della directory che abbiamo configurato digitando:

  1. ~/myproject/manage.py collectstatic

Dovrai confermare l'operazione. 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, dovremo consentire l'accesso alla porta che useremo.

Crea un'eccezione per la porta 8000 digitando:

  1. sudo ufw allow 8000

Infine, puoi testare il nostro progetto avviando il server di sviluppo Django con questo comando:

  1. ~/myproject/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 vedere la pagina indice di 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 di amministrazione predefinita di Django:

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

Testare la capacità di Gunicorn di servire il progetto

L'ultima cosa che vogliamo fare prima di lasciare il nostro ambiente virtuale è testare Gunicorn per assicurarci che possa servire l'applicazione. Possiamo farlo entrando nella directory del nostro progetto e usando gunicorn per caricare il modulo WSGI del progetto:

  1. cd ~/myproject

  2. 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'app.

Nota: l'interfaccia di amministrazione non avrà alcuno stile applicato poiché Gunicorn non è a conoscenza del contenuto CSS statico responsabile di ciò.

Abbiamo passato a Gunicorn un modulo specificando il percorso della directory relativa al file wsgi.py di Django, che è il punto di ingresso alla nostra applicazione, utilizzando la sintassi del modulo di Python. All'interno di questo file è definita una funzione chiamata application, che viene utilizzata per comunicare con l'applicazione. Per ulteriori informazioni sulla specifica WSGI, fare clic qui.

Quando hai finito di testare, premi CTRL-C nella finestra del terminale per fermare Gunicorn.

Ora abbiamo finito di configurare la nostra applicazione Django. Possiamo uscire dal nostro ambiente virtuale digitando:

  1. deactivate

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

Crea un file di servizio Gunicorn systemd

Abbiamo testato che Gunicorn può interagire con la nostra applicazione Django, ma dovremmo implementare un modo più robusto per avviare e arrestare il server delle applicazioni. Per fare ciò, creeremo un file di servizio systemd.

Crea e apri un file di servizio systemd per Gunicorn con i privilegi sudo nel tuo editor di testo:

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

Inizia con la sezione [Unit], che viene utilizzata per specificare metadati e dipendenze. Inseriremo qui una descrizione del nostro servizio e diremo al sistema init di avviarlo solo dopo che l'obiettivo di rete è stato raggiunto:

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

Successivamente, apriremo la sezione [Service]. Specifichiamo l'utente e il gruppo che vogliamo elaborare per l'esecuzione. Daremo al nostro account utente regolare la proprietà del processo poiché possiede tutti i file pertinenti. Daremo la proprietà del gruppo al gruppo www-data in modo che Nginx possa comunicare facilmente con Gunicorn.

Quindi mapperemo la directory di lavoro e specificheremo il comando da utilizzare per avviare il servizio. In questo caso, dovremo specificare il percorso completo dell'eseguibile Gunicorn, che è installato all'interno del nostro ambiente virtuale. Lo collegheremo a un socket Unix all'interno della directory del progetto poiché Nginx è installato sullo stesso computer. Questo è più sicuro e veloce rispetto all'utilizzo di una porta di rete. Possiamo anche specificare eventuali tweak Gunicorn opzionali qui. Ad esempio, in questo caso abbiamo specificato 3 processi di lavoro:

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

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

Infine, aggiungeremo una sezione [Install]. Questo dirà a systemd a cosa collegare questo servizio se gli abilitiamo l'avvio all'avvio. Vogliamo che questo servizio venga avviato quando il normale sistema multiutente è attivo e funzionante:

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

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

[Install]
WantedBy=multi-user.target

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

Ora possiamo avviare il servizio Gunicorn che abbiamo creato e abilitarlo in modo che si avvii all'avvio:

  1. sudo systemctl start gunicorn

  2. sudo systemctl enable gunicorn

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

Controlla il file Gunicorn Socket

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

  1. sudo systemctl status gunicorn

Successivamente, verifica l'esistenza del file myproject.sock all'interno della directory del tuo progetto:

  1. ls /home/sammy/myproject



Output
manage.py  myproject  myprojectenv  myproject.sock  static

Se il comando systemctl status indica che si è verificato un errore o se non trovi il file myproject.sock nella directory, è un'indicazione che Gunicorn non è stato in grado di avviarsi correttamente. Controlla i registri del processo Gunicorn digitando:

  1. sudo journalctl -u gunicorn

Dai un'occhiata ai messaggi nei log per scoprire dove Gunicorn ha riscontrato problemi. Ci sono molte ragioni per cui potresti aver riscontrato problemi, ma spesso, se Gunicorn non è stato in grado di creare il file socket, è per uno di questi motivi:

  • I file di progetto sono di proprietà dell'utente root anziché di un utente sudo
  • Il percorso WorkingDirectory all'interno del file /etc/systemd/system/gunicorn.service non punta alla directory del progetto
  • Le opzioni di configurazione fornite al processo gunicorn nella direttiva ExecStart non sono corrette. Controlla i seguenti elementi:
    • Il percorso del binario gunicorn punta alla posizione effettiva del binario all'interno dell'ambiente virtuale
    • La direttiva --bind definisce un file da creare all'interno di una directory a cui Gunicorn può accedere
    • Il myproject.wsgi:application è un percorso accurato per il richiamabile WSGI. Ciò significa che quando ti trovi nella WorkingDirectory, dovresti essere in grado di raggiungere il callable denominato application cercando in myproject Modulo .wsgi (che si traduce in un file chiamato ./myproject/wsgi.py)

    Se apporti modifiche al file /etc/systemd/system/gunicorn.service, ricarica il demone per rileggere la definizione del servizio e riavvia il processo Gunicorn digitando:

    1. sudo systemctl daemon-reload

    2. sudo systemctl restart gunicorn

    Assicurati di risolvere uno qualsiasi dei problemi di cui sopra prima di continuare.

    Configura Nginx su Proxy Passa a Gunicorn

    Ora che Gunicorn è configurato, dobbiamo configurare Nginx per trasferire il traffico al processo.

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

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

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

    server {
    listen 80;
    server_name server_domain_or_IP;
}

    Successivamente, diremo a Nginx di ignorare eventuali problemi con la ricerca di una favicon. Gli diremo anche dove trovare le risorse statiche che abbiamo raccolto nella nostra directory ~/myproject/static. Tutti questi file hanno un prefisso URI standard di \/static, quindi possiamo 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/myproject;
    }
}

    Infine, creeremo un blocco location/{} per soddisfare tutte le altre richieste. All'interno di questa posizione, includeremo il file proxy_params standard incluso nell'installazione di Nginx e poi passeremo il traffico al socket creato dal nostro processo 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/myproject;
    }

    location / {
        include proxy_params;
        proxy_pass http://unix:/home/sammy/myproject/myproject.sock;
    }
}

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

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

    Testa la tua configurazione Nginx per errori di sintassi digitando:

    1. sudo nginx -t

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

    1. sudo systemctl restart nginx

    Infine, dobbiamo aprire il nostro firewall al traffico normale sulla porta 80. Poiché non abbiamo più bisogno di accedere al server di sviluppo, possiamo rimuovere anche la regola per aprire la porta 8000:

    1. sudo ufw delete allow 8000

    2. 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.

    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ù semplice per ottenere un certificato SSL per proteggere il tuo traffico è utilizzare Let's Encrypt. Segui questa guida per configurare Let's Encrypt con Nginx su Ubuntu 16.04.

    Se non disponi di un nome di dominio, puoi comunque proteggere il tuo sito per test e apprendimento con un certificato SSL autofirmato.

    Risoluzione dei problemi di Nginx e Gunicorn

    Se quest'ultimo passaggio non mostra la tua applicazione, dovrai 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 il server_name per determinare quale blocco del server utilizzare per rispondere alle richieste. Se vedi la pagina Nginx predefinita, è un segno che Nginx non è stato in grado di abbinare la richiesta a un blocco 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 in cui cercare ulteriori informazioni è nei log degli errori di Nginx. In genere, questo ti dirà quali condizioni hanno causato problemi durante l'evento proxy. Segui i log degli errori di Nginx digitando:

    1. 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 vedere un nuovo messaggio di errore scritto nel registro. Se guardi il messaggio, dovrebbe aiutarti a restringere il problema.

    Potresti visualizzare alcuni dei seguenti messaggi:

    connect() a unix:/home/sammy/myproject/myproject.sock fallito (2: nessun file o directory)

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

    Se non riesci a trovare un file myproject.sock nella directory del tuo progetto, generalmente significa che il processo gunicorn non è stato in grado di crearlo. Torna alla sezione sul controllo del file socket Gunicorn per seguire i passaggi di risoluzione dei problemi per Gunicorn.

    connect() a unix:/home/sammy/myproject/myproject.sock fallito (13: Autorizzazione negata)

    Ciò indica che Nginx non è stato in grado di connettersi al socket Gunicorn a causa di problemi di autorizzazione. Di solito, questo accade quando la procedura viene seguita utilizzando l'utente root invece di un utente sudo. Mentre il processo Gunicorn è in grado di creare il file socket, Nginx non è in grado di accedervi.

    Questo può accadere se ci sono permessi limitati in qualsiasi punto tra la directory principale (/) e il file myproject.sock. Possiamo vedere i permessi e i valori di proprietà del file socket e di ciascuna delle sue directory padre passando il percorso assoluto del nostro file socket al comando namei:

    1. namei -nom /home/sammy/myproject/myproject.sock

    

    Output
    f: /home/sammy/myproject/myproject.sock
 drwxr-xr-x root  root     /
 drwxr-xr-x root  root     home
 drwxr-xr-x sammy sammy    sammy
 drwxrwxr-x sammy sammy    myproject
 srwxrwxrwx sammy www-data myproject.sock

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

    Nell'esempio sopra, il file socket e ciascuna delle directory che portano al file socket 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 assicurarsi che la proprietà del gruppo sia assegnata a un gruppo di cui Nginx fa parte Di. Per posizioni sensibili come la directory /root, entrambe le opzioni di cui sopra sono pericolose. È meglio spostare i file di progetto all'esterno della directory, dove è possibile controllare in modo sicuro l'accesso senza compromettere la sicurezza.

    Django sta visualizzando: impossibile connettersi al server: connessione rifiutata

    Un messaggio che potresti vedere 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. Assicurati che l'istanza di Postgres sia in esecuzione digitando:

    1. sudo systemctl status postgresql

    Se non lo è, puoi avviarlo e abilitarlo all'avvio automatico all'avvio (se non è già configurato per farlo) digitando:

    1. sudo systemctl start postgresql

    2. sudo systemctl enable postgresql

    Se i problemi persistono, assicurati che le impostazioni del database definite nel file ~/myproject/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 a turno e cerca i messaggi che indicano le aree problematiche.

    I seguenti log possono essere utili:

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

    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 digitando:

    1. sudo systemctl restart gunicorn

    Se modifichi il file di servizio systemd gunicorn, ricarica il demone e riavvia il processo digitando:

    1. sudo systemctl daemon-reload

    2. sudo systemctl restart gunicorn

    Se modifichi la configurazione del blocco del server Nginx, prova la configurazione e quindi Nginx digitando:

    1. sudo nginx -t && sudo systemctl restart nginx

    Questi comandi sono utili per rilevare le modifiche mentre modifichi la configurazione.

    Conclusione

    In questa guida, abbiamo impostato un progetto Django nel proprio ambiente virtuale. Abbiamo configurato Gunicorn per tradurre le richieste dei clienti in modo che Django possa gestirle. Successivamente, abbiamo configurato 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 semplifica 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 articolo, puoi servire facilmente le applicazioni che crei da un singolo server.

Articoli correlati: