L'ambiente di un sito è il suo file .env: le impostazioni e i segreti che la tua app legge in esecuzione, come la chiave dell'app, la password del database e le chiavi API. In Vimonto Deploy lo modifichi nella pagina Ambiente del sito. Viene salvato cifrato e scritto sul server come un unico file condiviso da tutte le release.
Dato che il .env sta fuori dalle release, resta uguale da un deploy all'altro, e non devi mai mettere segreti nel tuo repository. Ogni versione salvata viene conservata, così puoi vedere cosa è cambiato e ripristinarne una precedente.
Dove viene salvato il .env?
Sul server, il .env si trova in shared/.env nella directory del sito, per esempio /home/vimonto/shop.example.com/shared/.env. Appartiene all'utente del sito e solo quell'utente (e il suo gruppo) può leggerlo.
A ogni deploy, la release riceve un link al file: releases/{release}/.env punta a shared/.env. Per un monorepo, il link viene messo nella directory root dell'app all'interno della release. Ogni release legge quindi lo stesso file, e un rollback non cambia le tue impostazioni.
In Vimonto Deploy, il contenuto viene salvato cifrato nel database. Ciò che salvi nella pagina Ambiente è ciò che viene scritto sul server.
Visualizza e modifica il .env
- Apri il sito e vai su Ambiente.
- Le chiavi sono visibili, ma i valori sono mascherati e sfocati. Clicca su Mostra per caricare il contenuto reale nell'editor.
- Fai le tue modifiche e clicca su Salva e scrivi, oppure premi ⌘ S (Ctrl S).
Il salvataggio scrive subito il file sul server, come task in background che puoi seguire nell'intestazione del sito. Puoi salvare solo dopo Mostra, così non sovrascrivi mai un file che non hai visto.
Aggiorna la cache della configurazione e riavvia i worker quando salvi
Alcune cose leggono il .env solo all'avvio, oppure da una cache. Per un sito Laravel, e per ogni sito con processi o funzionalità del sito, Salva e scrivi apre prima Salva il .env con due scelte:
| Opzione | Cosa fa |
|---|---|
| Aggiorna la cache della configurazione | Solo siti Laravel. Esegue php artisan config:cache nella release live, così una configurazione in cache non mantiene i vecchi valori. |
| Riavvia i worker | I queue worker di Laravel finiscono il loro job e si riavviano (queue:restart); anche Horizon, Reverb e gli altri processi del sito si riavviano, così leggono i nuovi valori. |
La prima volta sono attive entrambe. Vimonto Deploy ricorda le tue scelte per questo sito, per te, e le usa come predefinite la volta successiva. Clicca su Salva e scrivi nella finestra per salvare. Gli altri siti salvano subito, senza la finestra.
Vedi e ripristina le versioni precedenti
Ogni .env salvato diventa una versione, chiunque o qualunque cosa l'abbia cambiato: tu in questa pagina, la creazione del sito, il primo deploy che l'ha costruito sul .env.example, una funzionalità del sito che ha impostato le sue chiavi, oppure un ripristino. Clicca su Cronologia per vederle, dalla più recente. Per ogni sito vengono conservate le 50 versioni più recenti.
Ogni versione mostra da cosa è nata (Sito creato, Costruito su .env.example, Copiato da un altro sito, Modificato o Ripristinato), chi l'ha salvata (Sistema per le modifiche fatte da Vimonto Deploy stesso) e quando, e quali chiavi sono cambiate: + aggiunta, − rimossa e ~ modificata. I valori vengono mostrati solo dopo che hai cliccato su Mostra; prima vedi solo le chiavi.
Per tornare a una versione precedente, clicca su Ripristina accanto a essa e conferma. Il suo contenuto sostituisce il .env attuale e viene scritto sul server. La versione che sostituisci resta nella cronologia, quindi un ripristino si può annullare allo stesso modo. Un ripristino non aggiorna la cache della configurazione né riavvia i worker; rifai il deploy, o salva ancora una volta con quelle opzioni, se la tua app ne ha bisogno.
Cosa contiene il .env di un nuovo sito?
Per i siti Laravel e Statamic, Vimonto Deploy scrive un .env di produzione quando il sito viene creato:
| Chiave | Valore |
|---|---|
APP_NAME |
La prima parte del dominio. |
APP_ENV, APP_DEBUG |
production e false. |
APP_KEY |
Una chiave generata da zero. |
APP_URL |
http:// e il dominio del sito. |
APP_LOCALE, APP_FALLBACK_LOCALE |
en. |
LOG_CHANNEL, LOG_LEVEL |
daily ed error. |
DB_CONNECTION, DB_HOST, DB_PORT, DB_DATABASE, DB_USERNAME, DB_PASSWORD |
Il database collegato alla creazione del sito, se presente. |
SESSION_DRIVER, CACHE_STORE, QUEUE_CONNECTION |
redis su un app server (che ha Redis), altrimenti database. |
REDIS_HOST, REDIS_PORT |
127.0.0.1 e 6379. |
MAIL_MAILER |
log, finché non configuri un servizio di posta. |
Quando il database usa l'utente di database del server e la sua password non è più nota a Vimonto Deploy, DB_PASSWORD resta vuoto con un commento che ti chiede di compilarlo.
Gli altri siti partono senza .env. Puoi scriverne uno nella pagina Ambiente quando la tua app ne ha bisogno. Un sito su un load balancer non ha una pagina Ambiente: imposta il .env del sito su ogni app server dietro il load balancer.
Unione con il .env.example al primo deploy
Se il tuo repository ha un .env.example, il primo deploy ricostruisce il .env su quella base. Il risultato segue le chiavi, l'ordine e i commenti dell'esempio, con i valori generati da Vimonto Deploy già inseriti (anche dove l'esempio ha la chiave commentata, come fa Laravel per DB_HOST). Le chiavi generate che mancano nell'esempio vengono aggiunte in fondo.
In questo modo le chiavi proprie della tua app, come VITE_* o AWS_*, sono già al loro posto e devi solo compilarle. Fino al primo deploy, la pagina Ambiente mostra Completato al primo deploy. L'unione avviene una sola volta, prima che giri lo script di deploy, e compare nella cronologia come Costruito su .env.example; dopo, il .env è esattamente come lo imposti tu.
Devo svuotare la cache della configurazione dopo aver cambiato il .env?
Le app Laravel che mettono in cache la configurazione (php artisan optimize o config:cache, come fa lo script di deploy predefinito) non rileggono il .env da sole. Lascia attiva Aggiorna la cache della configurazione quando salvi, e Vimonto Deploy esegue php artisan config:cache per te. Altrimenti rifai il deploy, così lo script di deploy mette in cache i nuovi valori.
Quali funzionalità modificano il .env?
Alcune funzionalità del sito hanno bisogno di impostazioni nel .env, per esempio Horizon (QUEUE_CONNECTION=redis), Reverb (BROADCAST_CONNECTION e le chiavi REVERB_*) e Nightwatch (NIGHTWATCH_TOKEN). La loro finestra mostra esattamente quali chiavi impostano, prima che tu le attivi.
Quando una funzionalità viene attivata, le chiavi già presenti ricevono il nuovo valore sul posto e quelle mancanti vengono aggiunte in fondo, sotto un commento con il nome della funzionalità. Tutto il resto del file rimane com'era, e la modifica viene conservata nella cronologia. Per i siti Laravel con la configurazione in cache, la cache viene poi ricostruita. Disattivare una funzionalità lascia le sue chiavi nel .env.
Domande frequenti
Il .env è incluso nel mio repository?
No, e non deve esserlo. Il .env è conservato da Vimonto Deploy e scritto in shared/.env sul server. Tieni invece nel tuo repository un .env.example senza segreti.
Salvare il .env riavvia la mia app?
Solo ciò che scegli nella finestra di salvataggio. PHP legge il file alla richiesta successiva, a meno che la configurazione non sia in cache: di questo si occupa Aggiorna la cache della configurazione. I queue worker e gli altri processi mantengono i valori con cui sono partiti finché non si riavviano: Riavvia i worker lo fa subito, e lo fa anche ogni deploy.
Ho salvato un errore. Come lo annullo?
Apri Cronologia, trova la versione precedente alla tua modifica e clicca su Ripristina.
Cosa succede al .env quando elimino il sito?
Viene rimosso dal server insieme alla directory del sito, alle release, ai worker e ai certificati. Copialo prima, se ti serve ancora.