CODEWITHSUNDEEP
phpsymfonynginxenvironment-variablessymfony4
Dmitry
Dmitry

Reputation: 7563

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?

Upvotes: 5

Views: 6147

Answers (2)

Webnet.fr
Webnet.fr

Reputation: 59

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.

Upvotes: 2

Sander Toonen
Sander Toonen

Reputation: 3573

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');

Upvotes: 11

Related Questions