I am trying to deploy an application prototype to openshift. It works locally with mongodb at 127.0.0.1. I am trying to get it to respect process.env.OPENSHIFT_MONGODB_DB_URL when in the openshift environment but that variable is not accessible to my nodejs cartridge at runtime.
I can see that it is being set in my application's shell environment. When I do rhc ssh and then export I see OPENSHIFT_MONGODB_DB_URL=[full_url_with_password] and it all looks good.
But when, in my node.js application, I call process.env.OPENSHIFT_MONGODB_DB_URL it returns undefined.
To double check, I did a console.log(util.inspect(process.env)) from within my node.js app, and what I saw was different from what I see within my appication's secure shell. No OPENSHIFT_MONGODB_* variables were in the environment that is exposed to my node.js app.
How can I access variables across different cartridges? Or is this a configuration error?
It sounds like a configuration error. I have a similar application and
console.log(util.inspect(process.env))
gives me a clear picture of the mongodb environment variables.
The developers page indicates that:
Database environment variables pertain to a database, if one exists, and are used to connect an application to a database. Note that these connections are only available to an application internally; you cannot connect from an external source.
This suggests, to me, that the nodejs is external to the mongodb installation. I have an idea that it can be verified with the command:
rhc app show OPENSHIFT_APP_NAME
It might lead to the source of the problem. A correctly configured app would have nodejs and mongodb in this list.
Related
I am trying to access a Linux environment variable in angular 2 but I am not sure how to do it. For example if I export a variable in terminal i can access it in node but I don't know how to access this variable in angular 2.
$ export HOST_IP="192.168.1.1"
I can access this environment variable in node like: process.env.HOST_IP. Could anyone please tell me how to access it in angular 2.
Thanks
NodeJS applications are run in a Server. So a NodeJS app can access the attributes of the server (Ex : Environmental variables).
But an Angular application runs on the browser. Thus it cannot access to the details of the machine that it is run on (there are some exceptions of course, but I'll not discuss them here).
Said that, if your true requirement is to change certain variables depending on the build of the Angular app (ex : test build, debug build, production deployment build), You can use the environment files. There are plenty of guidelines on the internet on how to do that. Few of them are,
https://alligator.io/angular/environment-variables/
https://medium.com/beautiful-angular/angular-2-and-environment-variables-59c57ba643be
https://medium.com/#natchiketa/angular-cli-and-os-environment-variables-4cfa3b849659
I'm currently making an app using express, mongodb and mongoose, and I'm running it locally on my machine. My problem is that if I'm not connected to the internet the app won't run at all due to the app not being able to connect to mongodb server.
I thought that if I ran the mongodb server locally on my computer along with the app then I wouldn't need an internet connection, or is my understanding wrong?
Any help would be much appreciated.
The answer is: yes.
If you install MongoDB locally then you won't need internet connection to access it.
Make sure that your connection string contains "localhost".
Also, make sure that you don't need anything else on the internet, and that you run npm install while you are connected to the internet, or otherwise your dependencies (like mongoose) won't get installed. After they are installed they can work without the internet connection just fine - if your database is on localhost.
Also, make sure that your local MongoDB server is running. You can run:
mongo test
in the command line to see if you can connect to a local database.
You're in the right path !
Here's the thing, you need to get yourself a copy of MongoDB, you can download and install the suitable version to your system from here.
Now you need to configure MongoDB in your in your path so you can launch it when you is or simply add it a process that will launch when your system starts.
In order to configure please choose the suitable conf to your system :
Windows.
Linux.
macOS.
Then, before running your application, make sure MongoDB is running in the background ad service or daemon and then simply launch your application.
When you learn front-end development, the creed is to never store passwords on the client--only on the server/db. So now I'm building API's and using third-parties like Twitter and I'm realizing that since I'm using Github, and later pushing to Heroku, I have no place on the server to store my tokens/secrets (since Heroku pulls from Github I can't add to a .gitignore).
I've come to two solutions:
1) Store in a db. That option seems trivial for smaller apps but scalability.
2) Encrypt the info on the server and upload that way.
What are the best practices when you have sensitive info, and are pushing to Heroku from Github?
The answer here is this (for anyone who finds this thread): use Heroku environment variables.
Heroku encourages you to store any application specific sensitive information in environment variables. You can set these variables via the Heroku command line tool, or the Heroku dashboard.
If you'd like to set Heroku environment variables on the command line, you can do so like this:
$ heroku config:set MY_VARIABLE=my_value
That will store the environment variable.
Since you're using Node.js, you can then read the value of these variables in your Heroku code by doing something like this:
console.log(process.env.MY_VARIABLE);
In Node, you can access environment variables via process.env as an object =)
It seems that my workflow would be improved if I had some way to automatically manage my environment variables so I can have different sets load automatically depending on if the server is running locally or running on Heroku.
What are my choices? Heroku must be using something on their end, because there are variable like local.env.PORT. What are they using? I was thinking that maybe if I use the same thing it would be easier.
I believe you can use the Foreman ruby gem with Heroku even if you are deploying apps using Node.js.
Foreman allows you to specify different application configurations on your local and remote application servers. I use it to control and manage my workers, web instances on Heroku for my rails apps.
Here's a link to a Heroku page showing how to manage environment variables using foreman:
https://devcenter.heroku.com/articles/config-vars
You're looking for something like figaro which is quite useful. There is a node-figaro project inspired by figaro, but the docs are unclear on how to actually use the project to initialize environment variables.
I am building a Node.js application and need to store database credentials (and other runtime properties) in such a way that they can be read when deployed on Heroku. My source is available in a public GitHub repository.
I am currently using environment variables, configured using heroku config:add, but am looking to understand if there are any alternatives. I would potentially like to use Cloud9 IDE, but it does not currently support environment variables.
Another option is to store the parameters in a config. file, but I believe the file would need to be checked in to Git (and as such, be publicly available) in order to be pushed to Heroku.
Thanks for your help.
ENV vars are generally considered the way to go, and the way Heroku do it themselves for database_urls and the like.
As you and your app are the only people with access to the env vars, you're generally OK security wise.
Putting credentials in Git or similar is a bad idea as it's another place that needs to be secured.
The one way I know of to solve the problem for development using command-line arguments. These can be specified in your run/debug configuration. You can then access the parameters in process.argv. Of course this means that they will be stored in your Cloud9IDE dev environment. You could then use the ENV variables in a retail production. This will at least prevent the credentials from being visible in source or config files.