We're running an EmberCLI application in our infrastructure, and I'm tasked to make it work better with the rest of our services. One thing that's a bit interesting about EmberCLI is that all it's configuration variables are baked into the build by default. (Specifically in the <meta> tag).
I had trouble finding a way to supply runtime configuration. We have an "API_URL" environment variable that's supplied to all our services so they can find the API. What is the recommended way to supply this url to EmberCLI at run-time, so I can avoid a rebuild and have fully-built docker containers with our frontend application.
If you want to use an environment variable for configuration ember-cli-dotenv will help. It allows you to access an environment variable in config/enviroment.js:
// config/environment.js
module.exports = function(environment){
return {
apiUrl: process.env.API_URL
}
};
You have to whitelist the environment variables used in ember-cli-build.js:
// ember-cli-build.js
module.exports = function(defaults) {
var app = new EmberApp(defaults, {
dotEnv: {
clientAllowedKeys: ['API_URL']
}
});
return app.toTree();
};
A short side note: Configuration variables are baked into the build by ember-cli cause ember-cli has done it's job after build. Files generated should be served by a normal webserver like nginx. The webserver which could be started with ember serve should not be used in production.
Related
I have this rails application which handles the backend for the app and I also have a Vue project in the root of the same directory acting as a front end. Now, the rails server runs on port:3000 and Vue runs on Port:8081 by default.
I need to make sure both communicate through a single port.
If you are using webpack or the Vue CLI you can easily define a reverse proxy in the configuration of your front-end project. Here is an example of such a webpack config:
devServer: {
proxy: {
'/api': 'http://localhost:3000'
}
}
When defining such a configuration, your front-end devserver will redirect each request from http://localhost:8081/api/* to http://localhost:3000/api/*. You can also define another pattern than /api depending on your needs.
In Vue CLI, you can use the same configuration and add it to the vue.config.js file. Make sure to add the webpackConfig into the section configureWebpack:
module.exports = {
configureWebpack: {
[...the config like above...]
}
};
Here are some documentation references:
Webpack Dev Server: Proxy
Vue CLI Webpack Config
The above described configuration works for the development environment. The productive environment must be handled differently, because there is no webpack devserver in production. You need to build the static HTML/JS/CSS content with webpack and then either put the generated code into the Rails application and serve it from there statically or you use two web servers (one for Rails and one for serving the static files) and put a reverse proxy in front of them.
I am using ember-cli-mirage to serve for requests. As I have my rails api to serve those request, how i shd remove or uninstall ember-cli-mirage from my ember ?
If am removing mirage folder, am getting build error !!
You should leave Mirage installed (and the folder on disk) but disable the server whenever you want to use your actual backend API. This will let you use Mirage in selective environments, for example in testing.
By default, Mirage is disabled in production, and also in development when using the -proxy option.
To disable Mirage explicitly, you can set the enabled config option to false. For example, to always disable in development:
// config/environment.js
...
if (environment === 'development') {
ENV['ember-cli-mirage'] = {
enabled: false
};
}
Leave mirage installed, if you want to use your backend api just launch ember with
ember s --proxy http://localhost:8000
if api's are running on your machine on port 8000.
More info on mirage official site: http://www.ember-cli-mirage.com/docs/v0.3.x/configuration/#enabled
I have a Rails app that I package as a war file for deploying to Tomcat using Warbler. And it works, but the problem is I don't know how to configure the runtime properties like secret_key_base. I use the standard setup of using secrets.yml, with production variables coming from environment variables. But I don't know how to set the variables while still keeping them out of source control.
Ideally I'd still like to be able to deploy the war file automatically, by just dropping it into the webapps/ directory, but I suppose I could edit the server config file? Or is there a better way of handling this?
either do it the same way as you would in a Rails server ... let it read from ENV (of course you will need to make sure Tomcat has the environment variable set).
alternatively you can set it in a web.xml if you're packaging and than do a $servlet_context.getAttribute('foo') in secrets.yml ... or read it from a file location that only the server's tomcat username can access etc.
sky is the limit here - you basically need to decide what fits your deployments the best.
I've enjoyed using Rails on Heroku, and like that I can adjust the configuration property of a Heroku app without having to commit a change to xyz.yml and redeploy.
It would be nice to completely do away with the Yaml config files in my Rails app, and rely as much as possible on storing configuration in ENV. This goes along with the 12-factor config principle.
However, there are some trade-offs in switching from a Yaml-based configuration management to a Heroku/12-factor-based one.
While it's true that a proliferation of deployments (qa, stage, prod, dev, demo, labs) can lead to a proliferation of Yaml files, it's very easy to copy-paste to create a new configuration profile. I don't see a way to 'copy' configuration profiles from one deployment to another in Heroku.
Storing configuration data in the repo means that, in the case of Heroku, deploying and configuring and application are accomplished in a single operation. If I were to move my configuration out of Yaml files and into ENV variables, I would have to configure my application in a separate step after deployment.
Would like to hear from people who have used 12-factor style configuration in their private applications, and how they have managed lots of configuration variables across lots of deployments.
How do you quickly configure a new deployment?
Where do you keep your authoritative source of configuration variables, if not the repo? How do you distribute it among developers?
Thanks!
What I typically use is Yaml using the ENV and provide defaults. For instance, YAML can be ERB'ed happily to include your ENV vars:
foo:
var: ENV["MY_CONFIG"] || "default_value"
You just need to make sure that you load the Yaml with ERB when you read it:
YAML.load(ERB.new(File.read("#{Rails.root}/config/app_config.yml")).result)
By doing this your code works fine in dev, but also allows you to set config vars in the environment as well.
You can accomplish this relatively easy with some simple shell scripts, iterate existing variables via heroku config or heroku release:info v99, and then set heroku config:set k=v --app
But if its a problem/pain/friction perhaps you have too much inside your env var configuration.
A bit of a late answer, but I believe this is what you are looking for.
I developed a gem called settei, allowing you to use YAML files to configure the app. However the gem will serialize the YAML file as one environment variable during deploy. This way one get the best of both worlds: YAML for ease of management/creating derivative environment, and ENV for 12-factor compliance.
I was wanting to run a custom environment called "local"...as in a local dev. I would use the config (eg DB connections) of this before a war would be deployed to the "shared" development server. But I noticed that it lacks the behavior of the standard Grails "development" Environment, such as Changes to a GSP were not available when you refresh the browser.
So this led me to wonder how do you change the behaviours of a custom environment? How can you copy all the settings for "development" to another environment?
You can enable reloading of modified gsp in a custom environment specifying the run-app flag:
-Dgrails.gsp.enable.reload=true
I don't think the automatic reloading is environment dependent. If you execute grails run-app, reloading will happen regardless of which environment you run under. In other words, automatic reloading will happen for all of
grails dev run-app
grails prod run-app
grails test run-app
On the other hand, reloading will not happen if you build a war using grails war, then deploy it. So reloading depends on how you run the app, not the environment. The easiest way to define a custom environment that is similar to dev, is to define a set of default configuration, then selectively override the settings for each environemnt, e.g.
//default config
myApp {
userRoleName = 'ROLE_USER'
adminRoleName = 'ROLE_ADMIN'
dateFormat = 'yyyy-MM-dd'
}
environments {
// config overrides for dev
development {
myApp.dateFormat = 'yyyy/MM/dd'
}
// config overrides for local
local {
myApp.dateFormat = 'MM/yy/dd'
}
}