Sorry, pretty simple question:
I can't find any resource that explains the order of evaluation of the ENV variable in Laravel... Usually in Spring Boot if I define a variable in the docker-compose I know for a fact that it overrides the application.properties value.. is the same in Laravel?
E.g.:
.env
DB_HOST = A
docker-compose.yml
environment:
- DB_HOST = B
in the application, is guarantee that DB_HOST is B?
At time of writing Laravel uses this dotenv environment. The key behaviour of this is determined by line:
static::$repository = $builder->immutable()->make();
Immutable, as described in the official dotenv repository, means that existing environment variables are not overwritten. Therefore the variables that docker-compose sets which are part of the container environment will not be overwritten by .env.
However since this is inferred by digging in the code and not explicitly documented (as far as I can tell), I think you need to treat it as undocumented behaviour and if you are relying on this then be vigilant before upgrading Laravel versions to make sure it has not changed.
Usually the variables that are defined in the .env are returned first. They are stored on config/ files as well. In your case it's stored on config/database.php file.
In my case env('DB_HOST', '127.0.0.1') it's this code.
What's it's saying basicly is that you get the value stored from the variable DB_HOST on .env, otherwise return the defaul value specified which is 127.0.0.1
Edit: As specified in the comments, you can always testing by using dd() or return env(DB_HOST); and you will get the result.
Related
I search a lot on the web, almost all links says define JVM custom variables in jvm.options also placed it on ${server.config.dir}/jvm.options.For example I added a variable called -DAPP_ENV=PROD. But this is getting as NULL after server startup.
Any idea?
It looks like you want to define an environment variable, so you have two options.
1. Use an Environment variable
In this case, you can define an environment variable (like $PATH) and load it in your app. Note this is not a JVM argument, and it will be set in the bin/server shell command used to start the server.
In the file:${server.config.dir}/server.env
Add the following line: APP_ENV=PROD
Access the value with:
System.getenv("APP_ENV"); -> PROD
2. Use a System property
This is what you are trying to do, so I am not sure why it doesn't work for you, but here's how:
In the file:${server.config.dir}/jvm.options
Add the following line: -DAPP_ENV=PROD
Access the value with:
System.getProperty("APP_ENV"); -> PROD
Note that in both cases these values are set at server start-up, and they are not changed dynamically (most Liberty configuration is dynamic). The JVM options and environment are sourced and set during the start script so a restart is required if you want to change either one.
My personal recommendation is go to the server.env route - its more generic and (to me) feels more appropriate since you are trying to influence the execution environment of the process, rather than defining behaviors or configuration of the JVM.
I have a Laravel 5 application that works perfectly on multiple servers. But on a specific Server, the values of my .env file are not readable via the \Config facade, or the config() function.
Let me give an example with the APP_DEBUG environment entry, the same goes for all other entries.
My .env file (the same on all servers) consists, amongst others, of the following line:
APP_DEBUG=false
through the use of $app->environmentFile() I know, that my .env file is used.
When I directly output the debug param via env('APP_DEBUG'), I get the correct value (false), but all approaches to read the value from the config (\Config::get('app.debug'), config('app.debug'), app('config')->get('app.debug')) only returned NULL.
I also tried to clear the cache via artisan cache:clear, because I thought, there could be some caching issue, but that didn't change a thing.
I also tried set the permissions of the .env file to 777.
When I output my whole config via \Config::all(), all values that are correctly set on my other servers, are NULL on this specific server.
Any suggestions?
Edit for clarification:
The project is set up twice on the same server on two different Virtual hosts, one to serve the dev.domain.tld (for development), and one to serve the www.domain.tld (for production). Both folders use the same webserver, the same PHP version and the same user
I've got a strange situation today. I called one of my variables in a playbook environment. If I dump variables using debug instruction, it is shown ok
"environment": "development",
But if I try to access it from a script using {{ environment }} it is always assigned a value of {}. I renamed it and it worked ok. Why is that? Is environment a reserved name in Ansible? I checked variable dump - there is no clashes with defined vars.
I found a statement regarding environment in the Google group:
Yes, environment is a restricted keyword. Initially specific within
playbooks, but it gets injected in the runner:
inject['environment'] = self.environment
so it will erase whatever value was set by inventory of vars.
There is a yet unaddressed feature request to warn if reserved variables are used.
Interestingly enough, Environment (proper-case) is usable, but environment (lower-case) is not as you found out.
I came across this one day when I accidentally used my existing Environment variable specified in lower-case and had a fun time trying to diagnose the issue.
I'd stick to using a different name as well (although I still use Environment on purpose just to remind myself about case sensitivity in variable names).
I've set a few custom config variables. I can see them in my application's settings->config variables. I can also see the values with the heroku config command. But when I start my application the environment variables are not there. I use (System/getenv "MY_VARIABLE_NAME") in Clojure to fetch them.
Is it because I try to retrieve them at boot time? Are they only available later? Or is there some twitch which I can get rid of by doing some trick? I've used config variables in Heroku before and they've worked, I don't know what's the problem here...
I was trying to retrieve client ID and secret for oauth authentication with Google from a config variable with System/getenv. I use a library called Friend to do this. Problem is, the set up for oauth parameters in that library is done via macros. And macro expansion happens compile-time. Heroku config variables are not available as environment variables during compilation (for good reasons). They are, however available via filesystem which was my solution to the problem. So instead of:
(System/getenv "MY_APP_GOOGLE_CLIENT_ID")
I'm using this:
(slurp (str (System/getenv "ENV_DIR") "/" "MY_APP_GOOGLE_CLIENT_ID"))
And it works!
I'm currently writing a tutorial on setting up Wordpress on Heroku. Right now I'm using the ClearDB add-on which sets a CLEARDB_DATABASE_URL ENV variable automatically. Is it possible to alias the ENV variable through Heroku as DATABASE_URL?
It's not possible to alias an config var or refer to one from another. I asked a similar question and this is what they said:
I'm afraid that Config Variables can't refer to each other in this
way, as they are simple a collection of Names and Values, with no
interpolation or calculation available to the values.
You might like try a
profile
file...
I've had a similar issue - where I'm trying to use an app in a pipeline connected to 2 different heroku DB's - in order to keep all he environments consistent in code, I did the following:
Heroku Configs:
DATABASE_URL=XXXXXXXX - this was the first DB that heroku attached
HEROKU_POSTGRESQL_JADE_URL=XXXX - this was the second DB that heroku attached (the key name changes in each environment)
SECOND_DB_KEY_NAME=HEROKU_POSTGRESQL_JADE_URL
(ie. after each environment was set up - I added a reference to the new key)
This second DB key name, does not change if the DB credentials refresh.
In code, I then did the following at start up:
const databaseUrlKey = process.env.SECOND_DB_KEY_NAME
process.env['SECOND_DATABASE_URL'] = process.env[databaseUrlKey]
Maybe I'll just say something stupid, but why not just do this:
heroku config:set DATABASE_URL=CLEARDB_DATABASE_URL
In code:
ENV[ENV['DATABASE_URL']]
I'm not sure this information will be helpful for anyone but just in case:
This question involves an eroneous assertion. The ClearDB add-on does not set a CLEARDB_DATABASE_URL ENV variable. The ClearDB add-on creates a CLEARDB_DATABASE_URL config var. When the app is started an ENV variable is created from the config var. These two variables are different and could even have different values if you changed the ENV variable in your code base.
Of course, within your code base, you can do whatever you want with the ENV variables.
As to whether config vars can reference other config vars, or other ENV variables, or vica versa - I don't know. But surely this would be something pretty hacky, and contrary to intended use, and proper coding practice, and socially responsible behavior.