I am trying to add environment variables in my App Engine Standard NodeJs app, and I have found multiple ways, out of which one is to add them in app.yaml using separate file(which we will not commit to repo), and second is to directly push .env file while deploying to App engine (Not ignoring it).
I was just thinking what are the cons of the second step which is to directly push my .env file(which I was also doing in App Engine Nodejs Flexible app)? Are there any major issues if I will do that.
Thanks.
No, there is no issue with it. You can consider it as your own server. No one will have access to your environments variables. So, it's safe.
Related
I develop an application with nodejs and react. I use dotenv for configuration in my different environment.
I use TFS 2017 for build and release my application.
What is the best practise for add my .env file of production environment?
Production configs can be difficult to maintain. You can use any module or even write your own custom module to load environment variable in to your application.
However, maintaining production .env files locally for each product (i.e. committing them or putting them inside your docker image is a bad idea. If you ever happen to change some of those configs, you will have to manually change in the code for each application, build docker image (if required) and redeploy. If there are just a couple of applications, it might be easy. But if the number of related applications grow in size (as usually happens in case of microservice based architecture) - all of them sharing credentials, ips for database connections etc. it becomes a hectic task to manually change code and redeploy all the applications.
Usually, developers tend to keep a central repository of all credentials and environment variables. For examples, AWS offers parameter store and MS Azure offers Azure Key vault. In such a case, all the parameters are fetched during start time, and all we have to do is restart the application.
So usually people set only one global varibale NODE_ENV (as prod or dev), dynamically fetch all environment variables based on NODE_ENV running something like env $(node read-env-variables.js) node app.js.
I've been told to implement Continuous Integration for an existing application (FrontEnd: Node.js - BackEnd: .Net API).
The API endpoints are currently hardcoded in the .js files, that get "uglyfied" after the build (webpack). I want to move them to a config file, that gets copied to the dist folder, so they can be changed at deployment time (just like a Web.config file in the API).
I have zero experience with Node. Is this possible? How?
Look into a dotenv file and use process.env.MY_ENV_VARIABLE in your code to access environment variables. Here's one library https://github.com/motdotla/dotenv but I'm sure there others (can't remember which one I used in the past).
Edit: If you're using Webpack to bundle your front end app you might need to configure it to pull in environment variables, you can use the define plugin: https://webpack.js.org/plugins/define-plugin/
I have an Angular4 web app, deployed on Azure. Now I want to deploy this app to other environments on Azure: one for testing, one for acceptance and one for production. Every environment has different API endpoints and may have other variables, like Application Insights. All those environments run Angular in production mode.
The way Angular advises you to do this, is by the Enviroment files (environment.test.ts, enviroment.acc.ts, environment.prod.ts). I could configure all the different API endpoints in those files, and run my build with --prod for production for example.
But that is not the way I want to do this. I want to use the exact same application package deployed to test for my acceptance environment, without rebuilding the project. In Visual Studio Online, this is also really simple to configure.
The point is: how can I make my API endpoints differ per environment in that way?
The way I want to do this, is by the App Settings in Azure. But Angular can't get to those environment variables because it's running on the client side. Node.js is running on serverside and could get those App Settings - but if that's the way I need to do it, how do I make Node.js (used in Angular4 CLI) to send those server variables to the client side? And what about performance impact for this solution?
How did you fix this problem for your Angular4 apps on Azure? Is it just impossible to fix this problem with the Azure App Settings?
For everyone with the same question: I didn't fix this problem the way I described above.
At the end, I did it the way Angular wants you to do it: so rebuild for dev, rebuild for acc and rebuild for prod.
In Visual Studio Online, at build time, it builds and tests our code and it saves the uncompiled/unminified code. At release time, it builds en tests it again and releases it to the right environment with the right environment variables (--prod for example).
I don't think there is another way to fix this.
The solution is pretty old school but it works! Although you can use branching or tag for this purpose instead of cloning the code to the package.
The best solution as you said is Azure app settings will be saved as environment variable so you should implement an API with node.js and share the variables you want.
Of course there is an impact because of additional http call, but it's just one time at application start which is about max 5ms and depends on each program policy whether is impact or not.
Another option could be move the variables to the JSON file in the asset folder, and change it at deploy runtime with release pipeline. that's easier implementation but the disadvantage is you will have to use release variables instead of app settings and if you have config changes you will have to update the variable value first and redeploy it, although that works most of the times but sometimes you want to change just like a connection string and you will have to redeploy.
I've come across people using both methods to do config management.
What are the pros and cons of each approach?
If I have a lot of variables that I store in my config object, will I have to set them all one by one in an upstart script before executing the node app?
You generally use envvar to keep an application stateless. The same codebase should work in dev, staging, test and production environment.
You will put var like MySQL config, API keys, if log is enabled or not, if debug is on or not ...
Config file are used for variables which are not dependent of the environment. For instance, name of the application, number of items per page ...
I guess you can use config.json file for storing big configs. ENV I've usually use for passing application port or something very important for normal application start. For example if you use some external lib, it's better to be able to pass custom path to lib executor in ENV.
P.S. You should never save config.json in SVN.
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.