So I have quite a large Meteor.Settings file, and when I tried to load all the json in an AWS EBS, it does not allow the length to exceed 256 characters (and mine is a lot more). I read in https://blog.sunsama.com/meteor-docker-opsworks/ that they used NPM.require to load the settings.json file into the METEOR_SETTINGS Environment variable. Can someone guide me as to how to do this?
process.env.METEOR_SETTINGS = readSettingsFile()
.
Can you elaborate on this?
I tried this very approach with sikka and iron-router-ga and neither could pick up the settings.
Also, should it work for both run and build?
you probably want this code to be executed before any code of packages. getting this done would require various hacks to the compiled files.
But the original question was about using process.env
object, as far as I can tell.
Ah yes! This needs to go before packages and it is not possible without a hack.
Hm, do you think it would be possible with a build plugin?
I’m thinking, register a build plugin that looks for a filename.settings file, take the content, validate the json and pass it on to process.env object?
Would that work both for meteor build and meteor run?
If it is something that would work, I guess @arjunrajjain can benefit from it as well.
It is just that I’m kind of hung up on and bummed out about meteor_settings nowadays.
@serkandurusoy I completely agree with you. Its definitely a pain when it comes to deployment and a package to dynamically load the settings.json file before other packages are executed would be a lot easier. I’m curious as to how/when @jkatzen loads the json file in Sunsama.
I have my settings stored in a JSON file that is on my host machine. From there, I have an environment variable that specifies the path to my JSON file, which I call METEOR_SETTINGS_PRODUCTION.
Once my file and environment variable are setup, I load the settings into by having a Meteor.startup
function within my server/lib/config.js
file. Here’s an example of how that file looks:
Meteor.startup(function() {
// This will setup meteor settings from a file on the server
Meteor.settings = Npm.require(process.env.METEOR_SETTINGS_PRODUCTION);
// If you have public settings that need to be exposed to the client,
// you can set them like this
if (Meteor.settings && Meteor.settings.public) {
__meteor_runtime_config__.PUBLIC_SETTINGS = Meteor.settings.public;
}
});
Awesome! When you deploy your app using docker + opswork, how do you know the path of the settings.json file?
In your dockerfile, you can use the COPY
or ADD
directive.
is there a specific filepath that I should be using for the container’s settings.json…or can i simply do the following :
COPY ./settings.json ./settings.json
and have the METEOR_SETTINGS_PRODUCTION Environment Variable set to “./settings.json”
Does this also get picked up by packages that require settings?
EDIT:
Nope, it does not!
@arjunrajjain - You can use whatever filepath you want. For my setup, I opted to put it into a folder I knew and which didn’t have a long pathname and have set that env variable to the full path.
@serkandurusoy - You’re right - most packages will have environment variables or some way to initiate them with some js startup code. After loading in my settings, I initialize such packages this way either with their documented code or by looking at how the packages load themselves. For dev, you can do something as simply as meteor --settings=$METEOR_SETTINGS_ENV_VARIABLE
.
…for those confused as to why the length of an environment variable would matter to your EBS-backed ec2 instances; it doesn’t. OP is talking about Elastic Beanstalk, Amazon’s free deployment and configuration service (which apparently has a 200-character limit on environment variables). Not ec2’s Elastic Block Store.