I have a Play! application which is on Heroku.
My config file is different between my local application and the same on Heroku. Especially for the URL of my MongoDB base.
On localhost my base address is 127.0.0.1 and on heroku it's on MongoHQ. So when I push my application to Heroku I modify my config file.
But some times, like this morning Heroku change the config file. I pushed my application correctly configured on Heroku this morning and everything worked until now.
When I watch the logs I see that Heroku changed my config and try to connect to my local MongoDB base.
Is someone knowing what ? I hope I'm clear :)
Thanks everybody !
If there are differences in your application in different environments (e.g. local vs production), you should be using assigning the values with environment variables. For Play apps, you can use environment variables in your application.conf file, like this:
`mongo.url=${MONGO_URL}`
Then, on Heroku you can set the environment variables with config vars, like this (note, this may already be assigned for you by the add-on provider):
$ heroku config:add MONGO_URL=...
Locally, you can use Foreman to run your application with the environment variables stored in an .env file in your project root.
Related
How do I get HEROKU specific ENV variables? (Such as $HEROKU_API_KEY_ENC)
I'm writing a buildpack to perform some operations on app deploys (not dyno restart, just deploy) but I need to know which variables are available at that point.
I know I have access to my own environment variables and HEROKU runtime dyno metadata but I'd like to see what else is there, such as which git user is making the deploy, or whether there's a variable to determine it is a deploy or a restart etc.
I appreciate your help.
P.S I already tried deployhooks and it doesn't solve my problem.
The linux printenv command will display every available environment variable.
How about this
heroku config --app your_app_id | grep "your_variable"
Here is a question about the Heroku CLI.
When I run this command inside my local folder for a given app already on the server:
heroku config
I get a list of my environment variables settings.
But if I run the same command from another folder with the same name it does not work anymore.
This shows that the name of the local folder is not enough for heroku config to know which app I am thinking about.
How does heroku config know which app to query on the server?
By default, Heroku infers the app from your Git remotes:
App commands are typically executed from within an app’s local git clone. The app name is automatically detected by scanning the git remotes for the current working copy, so you don’t have to specify which app to operate on explicitly.
You can also explicitly tell it what app to use:
If you have multiple heroku remotes or want to execute an app command outside of a local working copy, you can specify the remote name or an explicit app name as follows:
heroku apps:info --app example
heroku apps:info --remote production
Or via environment variable:
Alternatively, the app name can be specified by setting the HEROKU_APP environment variable.
In Play, you can use multiple config files (application.conf, prod.conf...). Usually you would have a default conf file, i.e. application.conf, and let the other files import it and overload specific values.
One case is for example when you have a production database and wand to overwrite access configuration values set by developers and use credentials only known to the production personnel.
Here is a manual on this topic that say that the wanted config is to be specified as a parameter when running the application
I am deploying my application onto Heroku, which takes care of running the application. The only peace missing here and I can't find is how to tell Heroku which config file to load?
I solved this by using a Procfile with the contents:
web: target/universal/stage/bin/my_app -Dhttp.port=$PORT -Dconfig.resource=my-special.conf
You can define environment variables for your Heroku app, e.g. using the heroku config CLI command:
heroku config:set PLAY_CONFIG_FILE=application.conf
See Heroku config vars.
Our team is using foreman for development and .env files to preassign development ports to each piece of a service oriented application. It dramatically simplifies things for this file to just live with the repository as we are not doing any specific per-machine local configurations even though multiple docs seem to think this is a bad idea.
Does anybody know if Heroku will ignore these .env files automatically? What if they were added to .slugignore?
I setup a test app to try this out including a PORT=5005 in the .env file and then committing/deploying to Heroku. Heroku didn't seem to notice it was even there and no new config vars appeared when I checked heroku config.
You answered your own question, but just for confirmation: .env is entirely a Foreman construct, while Foreman and Heroku will make use of Procfile.
We actually wanted to be able to ensure consistent environments between local and Heroku deployments, so I wrote a python script to export .env up to Heroku.
In case others want to export .env to Heroku:
https://github.com/FinalsClub/karmaworld/blob/68f0f0340d7b6420e263cab648ff7de1ea851a0e/export_env_to_heroku.py
I'm trying to migrate my app to Heroku - I have a config file that varies with development/staging/production environments as it contains uniquely assigned keys (from Facebook, S3, etc.), so I keep it out of the repository and keep the configs local.
As such I'm trying to find a solution for Heroku to have that config file since Heroku deploys from the repository. I noticed Heroku deploys from the master branch - can it deploy from another branch? Because then I could commit the Heroku configs there, and have it not overwrite the other environments' configs every time it pulls.
Thanks!
I believe Heroku always launches the master branch of the Gt repo, but they support config vars to address exactly this issue.
You can use foreman and heroku-config for this.
Check out the article at heroku dev center:
http://devcenter.heroku.com/articles/config-vars
I love this because you can keep the .env file in .gitignore and shield your production variables from ending up in the repository.