--- title: "Come distribuire con WSGI." version: 4.2 locale: it source: https://docs.djangoproject.com/it/4.2/howto/deployment/wsgi/ canonical: https://djangodocs.dev/it/4.2/howto/deployment/wsgi/ --- # Come distribuire con WSGI. La piattaforma primaria di deploy di Django è [WSGI](https://wsgi.readthedocs.io/en/latest/), lo standard Python per web server ed applicazioni. Il comando di gestione di Django [`startproject`](/it/4.2/ref/django-admin/#django-admin-startproject) imposta una configurazione WSGI di default minima per te, che puoi mettere a punto a seconda di quel necessita il progetto e fare in modo che ogni server di applicazione WSGI compliant la usi. Django comprende la documentazione per iniziare con i seguenti server WSGI: - [Come installare Django con Gunicorn](/it/4.2/howto/deployment/wsgi/gunicorn/) - [Come usare Django con uWSGI](/it/4.2/howto/deployment/wsgi/uwsgi/) - [Come usare Django con Apache e `mod_wsgi`](/it/4.2/howto/deployment/wsgi/modwsgi/) - [Come autenticare da Apache verso il database utenti di Django](/it/4.2/howto/deployment/wsgi/apache-auth/) ## L’oggetto `application` Il concetto chiave del deploy con WSGI è l”`application` richiamabile che il server dell’applicazione usa per comunicare con il tuo codice. Comunemente è fornita come un oggetto di nome `application` in un modulo Python accessibile al server. Il comando [`startproject`](/it/4.2/ref/django-admin/#django-admin-startproject) crea un file `/wsgi.py` che contiene tale `application` richiamabile. E” utilizzato sia da server di sviluppo Django sia da server di produzione WSGI. I server WSGI ottengono il percorso all”`application` chiamabile dalla loro configurazione. Il server built-in di Django, cioè il comando [`runserver`](/it/4.2/ref/django-admin/#django-admin-runserver), lo legge dall’impostazione [`WSGI_APPLICATION`](/it/4.2/ref/settings/#std-setting-WSGI_APPLICATION). Di norma, è impostato a `.wsgi.application`, che punta all”`application` callable in `/wsgi.py`. ## Configura il modulo settings Quando il server WSGI carica la tua applicazione, Django ha bisogno di importare il modulo settings - che è il posto dove la tua intera applicazione è definita. Django usa la variabile d’ambiente envvar:DJANGO\_SETTINGS\_MODULE  per trovare il modulo di impostazioni appropriato. Deve contenere il percorso puntato al modulo delle impostazioni. Puoi usare valori diversi per lo sviluppo e la produzione; dipende tutto da come organizzi le tue impostazioni. Se questa variabile non è impostata, il file predefinito `wsgi.py` lo imposta a `mysite.settings`, dove `mysite` è il nome del tuo progetto. Ecco come di norma [`runserver`](/it/4.2/ref/django-admin/#django-admin-runserver) scopre il file delle impostazioni predefinite. > **Note** > > Dal momento che le variabili d’ambiente sono process-wide, questo non funziona quando fai girare più siti Django nello stesso processo. Questo accade con mod\_wsgi. > > Per evitare questo problema, usa la modalità demone di mod\_wsgi con ogni sito nel proprio processo demone o sovrascrivi il valore dall’ambiente forzando `os.environ["DJANGO_SETTINGS_MODULE"] = "mysite.settings"` nel tuo `wsgi.py`. ## Applicare il middleware WSGI Per applicare [**il middleware WSGI**](https://peps.python.org/pep-3333/#middleware-components-that-play-both-sides) puoi includere l’application object. Per esempio, potresti aggiungere queste linee alla fine di `wsgi.py`: ``` from helloworld.wsgi import HelloWorldApplication application = HelloWorldApplication(application) ``` Puoi anche sostituire l’applicazione Django WSGI con un’applicazione WSGI personalizzata che deleghi successivamente all’applicazione Django WSGI, se desideri combinare un’applicazione Django con un’applicazione WSGI di un altro framework.