Setting an environment variable on the localhost is done using export.
e.g. export PORT=80
My Question is how to set an environment var for the remote meteor server.
I am using Meteor's free hosting service and deploy using meteor deploy appname, and therefore have no ssh access to the remote command line.
I'd like to set DISABLE_WEBSOCKETS to true.
I've looked at the list of possible meteor commands and haven't found one which relates to setting env vars.
You do it the same way when you run your server e.g, you don't have to use export you can just put the environment variables in the line you use to start meteor.
PORT=80 node main.js
or if you use forever
PORT=80 forever start main.js
or even with meteor
DISABLE_WEBSOCKETS=TRUE meteor
I'm a bit confused about your setup, by remote meteor server you mean a production environment? You shouldn't use the meteor command in production as it is not optimized this way and performance would be very significantly affected.
Meteor gets the environment variables using process so whatever you use to start the process you can pass the environment variables to it using the typical terminal/bash/shell/ssh that you used to start the process up.
Related
Standard procedure to start with
meteor app -p 3000&
This works, except when I close the ssh connection, application is no more running? I have no clue why this is happening.
Awakening Edit:
I use PM2 for traditional node apps, but if I have to setup process monitors, logs, database all by myself. I could just go back to reactjs and socketio and rock it with node.
Consider use mup package from Arunoda to easily deploy and run your app in production.
You could launch meteor with nohup (no hang-up) which serves this purpose.
nohup meteor --production &
But it's not a good idea to run a site in production with meteor anyway.
What should I do to run meteor forever ?
You can use forever, a Node.js tool designed to run node apps as services.
I also want to point that forever is getting old and I've heard of better recent alternatives but it seems to still be a pretty common tool. You could also use systemd which integrates better with the UNIX service ecosystem but that's anoter story.
But first, you'll have to "demeteorize" your meteor application like this :
cd my-project-meteor
meteor bundle --directory ../my-project-node
this is going to take some time
cd ../my-project-node/programs/server
npm install
this is going to take some time too
So now you have a plain node app, that you can run with node main.js
Let me mention that it might be a good idea to use the node version used by meteor which is 0.10.29 as of meteor 0.9.1 You can install it traditionally or you could use the node version that is shipped with the meteor tool.
sudo ln -s ~/.meteor/packages/meteor-tool/1.0.27/meteor-tool-os.linux.x86_64/dev_bundle/bin/node /usr/bin/node
sudo ln -s ~/.meteor/packages/meteor-tool/1.0.27/meteor-tool-os.linux.x86_64/dev_bundle/bin/npm /usr/bin/npm
Note that this way of "installing" node + npm on your system is problematic because :
it assumes you're doing only meteor related stuff.
it is dependant on the release process of the meteor tool (you'll need to rerun these commends if the meteor tool is updated).
You can install the forever tool using npm :
-g means globally : give access to forever to all users on the system
sudo npm install -g forever
To launch your node app as a service, you can use the following command, which sets correctly some environment variables and run the app using forever :
sudo export PORT=80 MONGO_URL=mongodb://localhost/my-project-mongodb ROOT_URL=http://localhost forever start my-project-node/main.js
You can monitor it using forever stop my-project-node/main.js
Also, what's the point of using 3rd party database service like https://mongolab.com/?
When using the meteor tool, it launches a mongod process automatically for you, and the underlying node process executed by meteor representing your app connects to this mongo instance.
When we want to launch our meteor app as a node app, we have to handle the mongo stuff ourself, which kinda answer the question : why not using another service to handle it for us, they know better, right ?
Doesn't it slow down the website, because now application has to connect to their database instead of local database ?
Of course, relying on a 3rd party database service has its inconvenients, and this is one of them. Network communications will always be slower than interprocess communications taking place on localhost (this is especially true on these SSD backed cheap VPS you can find nowadays).
And how exactly do I connect to mongolab for example ?
By setting an appropriate value to the environment variable MONGO_URL, the database service provider will give you an url that corresponds to your online mongodb, this is what you need to pass to the node process in command line if you want meteor to connect to your distant database and work as usual.
If you want to launch a dedicated local mongod instance to let your application connect to it, well this is another topic but you'll have to follow these steps :
first install mongodb correctly on your server, using the reference documentation for the OS version. By correctly I mean choose the same version as meteor is using currently (2.4.9) and let it run as a service so that it will actually restart when your server reboots.
test that mongod is running by launching a client with the mongo command.
pass the correct MONGO_URL when launching your app with forever (something like mongodb://localhost/my-project-mongodb)
Understand now why meteor deploy is amazing :D
Answer copy from here
I would like to know the best practice for setting environment variables in local machine to reflect the production environment.
I want to set the private API keys in the ENV variable, rather than directly committing them in Git. In Rails, I would use plugins like figaro to put every ENV variables in a single YML file, and they will be available.
What is the common practice in Meteor?
I think I could
run SECRET_KEY=some_key OTHER_SECRET_KEY=some_other_key meteor every time I run the local server. But that's too much to remember.
set environment variables locally but I don't want them to live in the global namespace in my machine.
Any alternatives?
Found this old post while having the same problem.
Looks like meteor is offering now to start with a config file.
meteor run --settings config.json
You would exclude that (or rather gitignore it) to keep it local. More here in the docs.
I develop Meteor application on my local computer, and deploy it to meteor.com. I want to have an opportunity to use remote production MongoDB database for local development.
So, I get url to my DB with meteor mongo --url myapp.meteor.com, then I add it to my MONGO_URL environment variable:
export MONGO_URL=mongodb://client-5345a08c:5f63edff-8cec-a818-7f35-c05021bb6d91#production-db-d1.meteor.io:27017/34377_ru
The inconvinience is that this url is invalid in one minute, so I need to generate another one and modify my MONGO_URL every time I want to start my application. I suspect some permanent url to my MongoDB is out there. I ran meteor mongo myapp.meteor.com and noticed greeting:
MongoDB shell version: 2.4.9
connecting to: production-db-d1.meteor.io:27017/34377_ru
I tried to use this url:
export MONGO_URL=mongodb://production-db-d1.meteor.io:27017/34377_ru
and even
export MONGO_URL=mongodb://myneteorcomusername:mymeteorcompassproduction-db-d1.meteor.io:27017/34377_ru
but I had no luck.
Are there ways to simplify my workflow and make meteor use my remote database by default?
I guess for scaling purposes, there is no dedicated mongo ever for each subdomain. I could be wrong so better ask this question over at the Meteor Talk Google group.
I am using Ubuntu 13.10 lokal and running my meteorJs app on it. My MongoDB is an external DB (modulus.io).
I set my mongoDb in my console like this:
sudo MONGO_URL='mongodb://login#db' meteor
Works fine.
But everytime when I restart my lokal meteorJs App this settings seems to be resetet! So everytime when I restart my App I have to set the enviroment variable again and again ...
Is there a way to set this variable permanent in my meteorJs App so I dont have to re set it again and again.
Fast solution:
Create startup.sh and insert:
export MONGO_URL='mongodb://login#db'
meteor
sh startup.sh
Another way to set environment variables that are accessed from within your app, is to put the following in your server code, i.e. for HTTP_FORWARDED_COUNT:
process.env.HTTP_FORWARDED_COUNT = 1
Doing it programmatically like this does not work for variables that need to be read during the app startup process, however - such as the MongoDB URL.
Application
I have an angularjs application that is built by grunt which uses grunt to inject environment variables (like API endpoints) into the angularjs code. However this problem is more specific to grunt applications being deployed in docker containers.
Motivation
I've just recently started trying to integrate docker into the deployment process (something similar to this) but realized I don't know how to best get the environment variables into the application anymore. I'll describe the sequence of events:
Make changes to my code
Build a complete docker image that accepts API endpoints as environment variables
Push the docker image to my server
Run a container based off this new image
As you can see, grunt build occurs in step 2, but the environment variables are not available until step 4.
Possible Solution
I could wrap the call to start the static server for my angular application in a small bash script which creates a javascript file containing the environment variable. I could then add a <script> tag in my index.html to import it and then start the server as usual, with everything working. However that feels like I'm sidestepping grunt inappropriately.
Does anyone know of a straightforward way to inject environment variables into client side code around the same time the connect:dist:keepalive task runs? To clarify, I'm already using the ng-constant grunt task but that can only access environment variables at build time, not server startup time.