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.
Related
I need to create environment-dependent parameterization, into the newrelic.yml file.
I want to use an Heroku env var that can assume different values depending on the environment.
How can I make it?
Do I need to create files like newrelic.development, newrelic.staging, ecc. ?
Or what?
I think it depends on the language you're trying to use. I know in PHP for example you can use ${ENV_VAR_NAME} in the config files and it will use such a value.
I don't know if that's true of all the agent languages but let me know what language you're using and perhaps I can nudge in the right direction
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.
I'm using the Golang google-cloud-sdk to get informations on resources (specifically here compute instances, but it doesn't really matter).
The gcloud cli allows to do something like this:
gcloud config set compute/zone ZONE
Which under the hood will write in ~/.config/gcloud/configurations/config_default those value as something that looks like an ini file.
Can the (go) sdk read config those config file ?
The cli also read the environment variable CLOUDSDK_COMPUTE_ZONE if not defined in the config file.
Can the sdk also read this variables ?
To sum up the question , how can I use the same config mechanism the gcloud cli uses with the Go sdk ?
To sum up the question , how can I use the same config mechanism the gcloud cli uses with the Go sdk ?
As far as I know, you can't. You need to specify the zone to all your operations.
Long time ago, someone asked about CLOUDSDK_CONFIG and the last response is cristal clear:
Resolved: we decided not to honor CLOUDSDK_CONFIG, in the interest of maintaining simplicity for the ADC spec.
https://github.com/googleapis/google-cloud-go/issues/288
And I think it's true for all the CLOUDSDK_* env.
I would like a variable to be shared among the various modules that I use for my cloud code.
For example, I was hoping I would be able to do the following:
In main.js, I would have the following:
Env = 'prod';
var Foo = require('cloud/foo.js').Foo;
Then in foo.js, I'd want to be able to access the value of Env
console.log("environment is: " + Env);
This does not work when deployed on Parse, but it does work if I run this in node.js.
Essentially, what I am looking for is a poor man's way to do dependency injection to allow me to easily test my cloud code in a local environment using node.js.
In the case above, Env would store the information that differs whether the cloud code executes in production (as a cloud function in Parse) or in a test (in node.js run locally).
[In the simple example above, I set Env to prod in main.js, and I'd set it to 'test' in my test script.]
Thanks for any insight.
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!