Qual è il modo corretto per impostare le variabili ENV in Laravel 5?

Question

In laravel 4 abbiamo avuto:

$env = $app->detectEnvironment(array(
    'local' => array('homestead') 
)); 

per impostazione predefinita.

Ma in laravel 5 è cambiato a:.

$env = $app->detectEnvironment(function() 
{ 
    return getenv('APP_ENV') ?: 'production'; 
}); 

Inoltre, essi hanno escluso .env * linea in .gitignore, ora ha:

.env 

E file aggiunto. env.example:

APP_ENV=local 
APP_KEY=SomeRandomString 
DB_USERNAME=homestead 
DB_PASSWORD=homestead 

Quindi, se ho più di 2 ambienti , devo impostarli tutti in un unico file .env ora? Es .:

APP_ENV=local 
DB_PASSWORD=123 

APP_ENV=alpha 
DB_PASSWORD=456 

se avrei alcun file .env, come laravel saprà quale ambiente sto usando?

Answer 1

Si può fare esattamente lo stesso come in laravel 4:

$env = $app->detectEnvironment(array(
    'local' => array('homestead') 
)); 

*.env di file sono solo utilizzati per mettere i dati sensibili che non dovrebbero essere messi in VCS. Lo stesso è a laravel 4

ma è sembra che negli ultimi giorni di default detectEnvironment è stato cambiato in:

$env = $app->detectEnvironment(function() 
{ 
    return getenv('APP_ENV') ?: 'production'; 
}); 

in modo da poter utilizzare sia variabile impostazione dal nome del PC o dal file ENV.

Se si utilizza il rilevamento ambiente basato ENV nel file di ENV principale (per impostazione predefinita .env di file è necessario aggiungere:

APP_ENV=local 

Naturalmente local qui è l'ambiente locale, è possibile cambiare in production o dev

Al momento il problema più importante che vedo è che è necessario ricordare quando si va in produzione per modificare questo contenuto di file .env da APP_ENV=local a APP_ENV=production quindi secondo me il metodo migliore è il vecchio defa metodo ult basato su nomi di PC.

Ora file ENV. Se si utilizza il rilevamento ambiente basato ENV, si dovrebbe mettere nel file ENV solo:

APP_ENV=local 

Ora è possibile creare file ENV separati per i vostri diversi ambienti, ad esempio:

.local.env:

MY_DB=testdb 

.produzione.env:

MY_DB=productiondb 

e ora in bootstrap.environment.php file, è possibile modficare:

if (file_exists(__DIR__.'/../.env')) 
{ 
    Dotenv::load(__DIR__.'/../'); 
} 

in:

if (file_exists(__DIR__.'/../.env')) 
{ 
    Dotenv::load(__DIR__.'/../'); 

    if (getenv('APP_ENV') && file_exists(__DIR__.'/../.' .getenv('APP_ENV') .'.env')) { 
     Dotenv::load(__DIR__ . '/../', '.' . getenv('APP_ENV') . '.env'); 
    } 
} 

caricare il file ENV in più sulla base di APP_ENV dal file env principale.

Ora si sarà in grado di utilizzare nel vostro altri file di configurazione, come sempre: $_ENV['MY_DB']

Answer 2

È possibile controllare su come impostare correttamente. How to Setup Multiple Environment for Laravel 5 Developers Way

Sulla base di Marcin Nabiałek, ho rimosso una parte di esso, e lo mise in file corretto per caricarlo destra.

Answer 3

Per coloro che hanno appena aggiornato a 5.2:

Non è possibile utilizzare più il metodo statico Dotenv::load(). Utilizzare il seguente invece:

$dotenv = new Dotenv\Dotenv(__DIR__ . '/../', '.' . getenv('APP_ENV') . '.env'); // Laravel 5.2 
$dotenv->load(); 

in bootstrap/app.php.

// modifica Soo .. dopo aver scavato in questo da un'ora potrei anche aggiungere alcune informazioni aggiuntive su:

• laravel utilizza file .env per la configurazione
• Per impostazione predefinita, il file ".env" nella directory principale dell'applicazione viene caricato
• È possibile accedere ai valori all'interno di tali file .env tramite la funzione helper env() o direttamente tramite la funzione nativa di PHP getenv(). Anche se dovresti farlo solo per riempire i tuoi file di configurazione (vedi /config/*.php), perché those can be cached.
• i file .env sono caricati nella classe DetectEnvironment. Ho trovato utile questo durante il debug per impostare i punti di interruzione. Si prega di prendere nota della linea (new Dotenv($app->environmentPath(), $app->environmentFile()))->load();: Poiché utilizza load(), qualsiasi valore di ambiente che è già stato impostato non verrà sovrascritto! (Si dovrà utilizzare overload() a farlo - questo mi ha spinto noci perché fattoria imposta la variabile APP_ENV al local nella configurazione php-fpm /etc/php/7.0/fpm/php-fpm.conf e non si può cambiare tramite .env file)
• durante la scrittura di unit test , di solito si eredita dai TestCase, che imposta la variabile APP_ENV al test (via refreshApplication() - utilizzando putenv() per ignorare il valore di default local)

Answer 4

volevo solo di contribuire la mia soluzione per laravel 5.1, che è leggermente più semplice IMHO . In bootstrap/app.php, ho (subito dopo in cui viene creata un'istanza l'Application):

$app->beforeBootstrapping(\Illuminate\Foundation\Bootstrap\DetectEnvironment::class, function() use ($app) { 
    $suffix = (env('APP_ENV')) 
     ? '.'.env('APP_ENV') 
     : ''; 
    $app->loadEnvironmentFrom('.env'.$suffix); 
}); 

Non c'è bisogno di alcuna gestione o di controllo degli errori. Laravel imposterà automaticamente "produzione" se il file non viene trovato.

Questo è tutto.

Answer 5

Il fatto che non si può avere più di un .env di file di default e che è esclusa nel .gitignore è intenzionale ed è il modo previsto per gestire ambienti. Il file .env non deve essere nel controllo della versione e deve essere configurato per ambiente. .env imposta l'ambiente e tutte le variabili di ambiente.

Quindi, se ho più di 2 ambienti, devo impostare tutti loro in un singolo file .env ora?

No. Avresti un file .env in ogni posto in cui è installata l'applicazione. La differenza è in ciò che è all'interno di quel file.

Inoltre, poiché il file .env è semplicemente un archivio di valori-chiave, eventuali dichiarazioni successive sovrascriveranno quelle precedenti. Nel tuo esempio, Laravel non vedrebbe mai le tue impostazioni "locali".

All'inizio sembra strano, ma questo nuovo sistema predefinito è in realtà più semplice e meno soggetto ai problemi che il "modo 4.2" ha/ha, poiché non c'è spazio per gli errori logici.

Se non avessi alcun file .env, come laravel saprà quale ambiente sto usando?

Non funzionerebbe affatto. Nel file .env c'è anche una dichiarazione APP_KEY, che Laravel non eseguirà senza. Senza un file .env, si otterrebbe un errore di 500 server.