Usually, I am deploying my apps via mup. But I now got the request to deploy an app the “manual way”, using meteor build. How can I provide a link to the production version of the settings.json file in this case? I can only see an option “–mobile-settings”.
Hi,
In my case, on the production server, i define the METEOR_SETTINGS variable
1 Like
Hi,
here is a basic start script :
export METEOR_SETTINGS=$(cat my_settings.json )
meteor node mybundle/main.js >> bundle.log 2>>bundle.log
By the way, that solution @victor brought up ( I think from meteor-base having the same issue? ) … has bloomed over here.
Once you find yourself pre-processing JSON in a bash script, which does not sound exciting, it becomes a whole new possible world in multi-entrypoint environments.
One is then free to go full-
as follows:
If you pair jq with that solution, you can then load multiple configuration files over each other. Or remove certain portions of what would previously be one big glob shared everywhere. One can only give what the code needs, to each application if you have more than just client and server applications in one environment.
What really “bakes your noodle later on” is how to get jq to deep-merge objects. And also: why were we not doing this before? Why not force JSON in through an environment variable? Why did I take this long to not hate that convention so deeply? I remember hating with a passion not to be able to pull JSON within the process versus have a layer which decides and assembles the configuration which itself might change agent behavior and summon the right one!
Remember, this is all still in a bash script before your deployment boots up in a container 
Only change needed then: if using an alpine build you need apk to pull in jq and if using a debian / ubuntu build like most node images, then you need apt-get to include jq … but does not hurt image size very much.
Of course it is possible to just render settings from multiple scripts into one and still pass one, but maintaining a settings “build” while also maintaining everything else feels more insane. And being able to swap configurations on-the-run without intervention seems awesome to have the freedom open to do still.
This “annoying problem” of being forced into using environment variables and passing in JSON became something very helpful actually, and pretty cool.
jq seems pretty well setup team-wise … might even get a deep-merge command from their ninjas 
The deep-merge scenario was answered:
jq --slurp 'reduce .[] as $item ({}; . * $item)'
Then that either has JSON chunks piped into it, or any number of files passed as arguments.
In my case mentioned above:
#de Adjust if inside container, vs. on bare metal in development environment:
prefix=''
if [[ `pwd` =~ '<special environment identifier in pwd>' ]]; then
prefix='<special prefixed path>'
fi
base='settings' #de Root directory of JSON files
#de Explode comma-separated list of JSON files;
#de each without .json suffix and /settings/ prepended
json_files=()
while IFS=',' read -ra JSON; do
for i in "${JSON[@]}"; do
#de Debug; dump each to console if unsure at first:
#de echo "Merging JSON: $prefix/$base/$i.json"
json_files+=("$prefix/$base/$i.json")
done
done <<< "$METEOR_SETTINGS_PATH"
#de Space-delimit since these are command-line arguments now, once preprocessed:
jq_input=$(IFS=' ' ; echo "${json_files[*]}")
export METEOR_SETTINGS=$(jq --slurp 'reduce .[] as $item ({}; . * $item)' $jq_input)
#de Debug; dump entire JSON object to inspect:
echo $METEOR_SETTINGS | json_pp
That requires jq and json_pp ( if inspecting )
Special thanks to jq ninja jrib on StackOverflow
Ok, thanks. So this is the only way, there is no command line option? I am wondering how mup does it. I guess with the same approach.
Is the meteor in front of meteor node ... actually needed? I thought an exported Meteor app was just another Node app?
I can not speak for mup, I do not use it and as far as I know it is the only way.
1 Like
I use it to ensure the same exact version of Node is used for building and running the app : the node used is the one that comes with Meteor.
Also, I pinpoint the meteor executable to the version I am looking for into .meteor/packages/meteor-tool
You could use node directly if you ensure the version is consistent
1 Like
Ok, but this also means you have to install meteor on the machine.
Meteor Up and all of the other deployment tools and services do it the same way by putting the content of settings.json into the environment variable. It seems to be missing from the custom deployment guide, and from the readme in the app bundle. I’ve opened an issue to add it in those places.
The documentation for it is in the env variable and Meteor.settings sections.
For getting the correct node version, you can also find the version in the bundle in the .node_version.txt or star.json files.
3 Likes