I've set up NewRelic for a rails application on Heroku.
I notice NewRelic is determining the application name from the rails environment definition. This is mediated through the app_name variable in the newrelic.yml configuration file. However, I run the same rails environment on disparate Heroku applications, each being used for different development testing or staging purposes. So we entirely do not want all those applications (although using the same rails environment) to report back to the same NewRelic 'application'. That would provide no value at all in NewRelic - rather, each Heroku application should be its own 'application' in NewRelic, otherwise we just get one useless aggregate for all those applications each running a different source version of our application with different load or test simulations.
What should be the most straightforward and solid way to configure that separation?
Thanks!
P.S. of course for our production environment we do want to have all dynos report back as one NewRelic application. Just not for disparate staging/test environments.
You could make a new environment variable for each of the disparate staging and test environments, and then pull that environment variable into your app_name in your newrelic.yml staging and testing environments.
For example, you could create an environment variable called SPECIFIC_APP and set it to "staging_one" for one of your apps and "staging_two" for another app, by running these commands in the respective apps:
heroku config:set SPECIFIC_APP=staging_one
heroku config:set SPECIFIC_APP=staging_two
Then, you could modify the New Relic app_name for each of those SPECIFIC_APP environments, like so:
staging:
<<: *default_settings
monitor_mode: true
app_name: <%= ENV["NEW_RELIC_APP_NAME"] %> <%= ENV["SPECIFIC_APP"] %>
You could do the same thing for each of your testing apps, appending an additional app-specific environment variable to the "testing" environment at the end of your newrelic.yml.
This way, each application in the staging and testing RAILS_ENV's would be unique according to what the SPECIFIC_APP environment variable for each application is set to.
Related
I was just checking on how pipelines work in Heroku. I want the staging and production apps to be the same except that they should access different API endpoints.
How could I achieve that?
Heroku encourages getting configuration from the environment:
A single app always runs in multiple environments, including at least on your development machine and in production on Heroku. An open-source app might be deployed to hundreds of different environments.
Although these environments might all run the same code, they usually have environment-specific configurations. For example, an app’s staging and production environments might use different Amazon S3 buckets, meaning they also need different credentials for those buckets.
An app’s environment-specific configuration should be stored in environment variables (not in the app’s source code). This lets you modify each environment’s configuration in isolation, and prevents secure credentials from being stored in version control. Learn more about storing config in the environment.
On a traditional host or when working locally, you often set environment variables in your .bashrc file. On Heroku, you use config vars.
In this instance you might use an environment variable called API_BASE that gets set to the base URL of your staging API on your staging instance and to the base URL of your production API in production.
Exactly how you read those values depends on the technology you're using, but if you look for "environment variables" in your language's documentation you should be able to get started.
I've been having this issue many times. When I promote my staging app to production its config vars are not loaded properly. Right now my production app is using my staging's config vars. How can I fix this?
From the docs:
Pipelines only manage the application slug. The Git repo, config vars,
add-ons and other environmental dependencies are not considered part
of a pipeline and must be managed independently.
So if your "build artifact" (i.e. your slug) contains config vars from your staging app, it will get promoted to prod. All pipelines really do is allow you to skip the slug compilation by simply using the exact same slug from the previous environment. If you cannot remove config vars from the slug compilation for your code base in the staging environment, I would avoid pipelines.
Note: this is true as of the time this answer was submitted, who knows if Heroku will be able to change this in the future.
In Heroku, how do I change what database my Sinatra app accesses depending on its environment?
That is: If main.rb is on my local machine, how do I get it to access localhost, but when I git push it to any branch on my Heroku repo, get it to access a live database?
Same for JS and CSS. If I'm working on my local machine, how would I set my app so that it accesses JS in dev/js/script.js, but when live it would access live/js/script.js?
Firstly, you shouldn't usually have separate assets based on the environment you are running on. That can give you a small nightmare when you need update things.
How this usually works in Ruby land is that the server (Heroku etc) sets global environment variables when it runs your app. These variables & values are available in your app so you can check if you are running in production, testing etc.
Heroku automatically sets the DATABASE_URL environment variable and you can access it like so:
configure do
ActiveRecord::Base.establish_connection(ENV['DATABASE_URL'])
end
On each server the DATABASE_URL variable will be set accordingly.
Normally you should not have separate folder for different environments for js and css, and they should be put under assets folder:
If you have a good reason to do so, you can use the following code:
set :root, File.expand_path(File.dirname(__FILE__))
configure :development do
set :public_folder, Proc.new { "#{root}/dev/assets" }
end
configure :production do
set :public_folder, Proc.new { "#{root}/live/assets" }
end
Then in the view, if you put javascripts under assets/javascript, you can link to them with the path javascripts/filename.js
I'm trying to create two different environments on Heroku with my RoR application, i will try to explain myself easily:
my machine -> development environment (A)
a free plan Heroku instance -> test environment (B)
subscripted Heroku instance -> production environment (C)
But I can't push to (B), telling to Heroku "hey, load the "test" environment".
Surfing the net i find this: https://devcenter.heroku.com/articles/multiple-environments but I don't understand why in that guide they talked about "staging" environment. I would be happy to use the 3 default ruby on rails environment: development/test/production
Do you have some suggestions?
Thanks and sorry, but I'm new about Ruby on Rails and Heroku :)
Have a nice day.
Because test is a special environment in the Ruby on Rails world, I'd strongly recommend avoiding using test as an environment name.
I've seen QA used (per another SO question about this topic)... But it's still outside of the convention. So, opposed to test, Heroku's standard is staging, but you could use anything you want (like QA) - I'd just avoid test.
How can I host concurrent environments of a single application of on AppHarbor?
We are currently in development so a single environment of DEBUG is sufficient, with builds triggered from the develop branch.
Soon we will need a PROD environment, triggered by changes to the master branch (or perhaps manually).
How can I configure AppHarbor such that both the DEBUG & PROD environments are accessible at any given time for a single application?
With hostnames such as:
http://debug-myapp.apphb.com
http://prod-myapp.apphb.com
For now you will have to create two applications, one for your debug environment and one for your production environment. You can also set up the tracking branch for each application. Here is a link where we describe how to manage environments.