Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Symfony 4, .env files and production

.env files are very handy with docker, kubernetes, etc

But what if I have simple nginx server without any orchestration and a pack of cron workers and a pack of daemons(systemd/supervisord/etc)?
I can write these env variables to nginx server section, but I have to set up hundreds of env variables to each cron worker or daemon.

I found a quick solution: using symfony/dotenv component in production.
But it seems to me dirty. Who can suggest better solution?

like image 230
Dmitry Avatar asked Mar 09 '18 08:03

Dmitry


People also ask

Should you use .env in production?

Using environment variables is a somewhat common practice during Development but it is actually not a healthy practice to use with Production. While there are several reasons for this, one of the main reasons is that using environment variables can cause unexpected persistence of variable values.

What is env file in Symfony?

env Files. Instead of defining env vars in your shell or your web server, Symfony provides a convenient way to define them inside a . env (with a leading dot) file located at the root of your project. The . env file is read and parsed on every request and its env vars are added to the $_ENV & $_SERVER PHP variables.

What should .env files contain?

The . env file contains the individual user environment variables that override the variables set in the /etc/environment file. You can customize your environment variables as desired by modifying your .

When should I use an .env file?

This. env. example file documents the application's necessary variables and can be committed to version control. This serves as a helpful reference and speeds up the onboarding process for new team members by reducing the amount of time spent digging through the coding to figure out what needs to be set up.


2 Answers

First of all, not all variables need to be specified using environment variables. Keep variables that do not differ per system in a separate yaml file.

When you have just one environment per server you can specify the environment variables globally in /etc/environment. (Might be different depending on your Linux flavour)

Personally I find that using DotEnv poses more difficulties than solutions when you run multiple environments on the same server. Specifying the variables in a global configuration like /etc/environment doesn't work in that case.

Specifying the environment variables in nginx isn't a solution either since, as you mentioned, they won't be picked up by cron, supervisor, the console, etc. For me, this was the reason to completely remove DotEnv and work with the good old parameters.yaml file again. Nothing will stop you from doing that.

Another solution however is to keep using DotEnv in your development environment and to include a separate parameters.yaml in production. You can then define the environment variables as follows:

parameters:
  env(APP_ENV): prod
  env(APP_SECRET): 3d05afda019ed4e3faaf936e3ce393ba
  ...

A way to include this file is to put the following in your services.yaml file:

imports:
    - { resource: parameters.yaml, ignore_errors: true }

This way, the import will be ignored when no parameters.yaml file exists. Another solution is to add a line to configureContainer() in your Kernel class:

$loader->load($confDir.'/parameters'.self::CONFIG_EXTS, 'glob');
like image 99
Xatoo Avatar answered Sep 21 '22 05:09

Xatoo


if you want to centralize your environment variables for cli and fpm you can define them once in your system. And then reference them all in your php-fpm.conf:

....
[www]
env[APP_VAR1] = $APP_VAR1
env[APP_VAR2] = $APP_VAR2
...

In that way you can avoid using DotEnv in production which is encouraged by best practices.

Hope this helps.

like image 34
Webnet.fr Avatar answered Sep 25 '22 05:09

Webnet.fr