my question is simple. I want to set the play framework 'id' in my heroku deployed copy, different than the one I have locally.
To do so, I followed this reference page by running 'heroku run play id' from my local computer. However, that didn't work, as if I executed again the same command, it would tell me that the id was still empty.
So, I researched in StackOverflow a bit, and got to this page in which I understand, according to an answer, that I can do so by modifying the PLAY_OPTS variable, but I dont really get it... So if someone could explain it to me clearly, I would really appreciate it!
Thanks a lot in advance,
Pepillo
You can see the PLAY_OPTS environment variable with:
heroku config
Which should include:
PLAY_OPTS => --%prod -Dprecompiled=true
You can change that with something like:
heroku config:add PLAY_OPTS="--%foo -Dprecompiled=true"
But you will have to make sure that you also tell the Play app not to try and listen on the jpda port or it will fail to start on Heroku.
Edit your Heroku config (heroku config) and add PLAY_OPTS to your liking.
heroku config:add PLAY_OPTS="--%prod -Dprecompiled=true"
After, just change your Procfile to something like :
web: play run --http.port=$PORT $PLAY_OPTS
Related
I'm having real trouble making new relic work on my grails app in Heroku, This are the things I've tried without success:
Downloaded the java agent
Uzip it on the root folder of my app, it creates a folder called new relic
Added to the JAVA_OPTS "-javaagent:newrelic/newrelic.jar"
Then heroku can't start, I get "Process exited with status 1" and "State changed from starting to crashed"
Configured the buildConfig.groovy file, set dependencies to: provided 'com.newrelic.agent.java:newrelic-agent:3.7.0'
Set the NEWRELIC_HOME = 'newrelic' folder
Set JAVA_OPTS='-Xmx384m -Xss512k -XX:+UseCompressedOops -javaagent:target/dependency/newrelic-agent.jar' NEW_RELIC_APP_NAME="YOUR APP NAME GOES HERE"
Heroku can't start either I get: "Unrecognized VM option 'UseCompressedOops -javaagent:target/dependency/newrelic-agent.jar''"
Tried all this but instead of JAVA_OPTS used GRAILS_OPTS
Nothing really happened
The one I supposed should had worked is the second one but in the heroku site there is a part for the maven configuration I don't know how to setup that says: "Customize the build section so it always names the newrelic-agent.jar consistently." maybe there's something there that I'm missing but I wouldn't know what.
So, do you know how to make it work?
Thanks
I made it work, the answer was in option one but to change the JAVA_OPTS I needed to use the console.
This sentence worked:
heroku config:add JAVA_OPTS='-Xmx384m -Xss512k -XX:+UseCompressedOops -javaagent:newrelic/newrelic.jar'
Hope it helps!
I'm trying to set up new relic again (I tried some time ago with no success). I'm using heroku, and a Play 2.x application. I uploaded the newrelic agent, the yml file, everything properly configured.
Then I tried to add -javaagent:newrelic/newrelic.jar to JAVA_OPTS variable (as stated in Heroku docs), which did nothing. So I looked at the logs and found out that heroku is actually using JAVA_TOOL_OPTIONS (I think).
So I added the javaagent to that variable:
$ heroku config:set JAVA_TOOL_OPTIONS="-Djava.rmi.server.useCodebaseOnly=true -javaagent:newrelic/newrelic.jar"
After restarting the app, it looks like it actually did something because the app wouldn't start, showing this error:
"The java installation you have is not up to date requires at least version 1.6+, you have version 1.7.0_45."
I tried both with Java 6 and 7, with no success.
What am I doing wrong?
Instead of using JAVA_OPTS try to set the variable as java_opts. I know it seems strange but this should actually resolve the issue and get Heroku, Play and New Relic to be nice to one another.
You also want to modify your Procfile adding the following:
web: target/universal/stage/bin/YOUR_APP_NAME -Dhttp.port=${PORT} -J-javaagent:/app/newrelic/newrelic.jar -J-Dnewrelic.config.file=conf/newrelic.yml
Cheers
Adrienne
(TSE at New Relic. Inc)
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 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.
I came across this behavior and was wondering if anyone else had seen it. I have a workaround so it's not a show-stopper.
I created a new app on Heroku with a Cedar stack. When demonstrating multiple environments I added the following config var:
heroku config:add RACK_ENV=staging --app appname
I visually verified that the environment var was set, then put the following route in my simple Sinatra example:
get '/?' do
ENV['RACK_ENV']
end
When I tested locally on my laptop, I received the expected development.
When I pushed to Heroku and hit the same route on herokuapp.com I got development instead of staging.
I switched the web server from Thin to Unicorn through the Procfile and pushed the changes back up to Heroku.
Now when I hit the route, I get the expected staging.
Has anyone else seen this? My workaround on another project where I was running Thin was to key the environment off of the New Relic app name. (I didn't switch to Unicorn because I need New Relic to work and currently Cedar and New Relic and Unicorn work together).
I had the same problem with sinatra and thin on the cedar stack using heroku's example sinatra app. The RACK_ENV refuses to be set to anything but development. (Heroku seems to think that it's RACK_ENV is set, since running 'heroku config' displays the environment you set, however in the app it's always development).
The same app on the bamboo stack had no problems.
EDIT: I submitted a ticket to heroku about this and got a really quick response which fixed the bug for me:
QUOTE:
It looks like there's a small bug in our default Procfile if you're using thin. Can you create a Procfile with the following in it?
web: bundle exec thin start -R config.ru -e $RACK_ENV -p $PORT
You can also set both your RACK_ENV and RAILS_ENV to staging using the Heroku gem ... then it works as expected. I think it may be a problem with Heroku.