I'm developing an application with my team with Firebase, and I want to deploy my app both in development and production environments.
To achieve this, I have done several things. (Details are below)
But NODE_ENV keeps set as 'development' when I deploy it to firebase functions app.
How can I deploy it as 'development' to firebase?
Those are what I have done to achieve my goal.
Make another firebase project and function for 'production' (Use current firebase project as 'development')
firebase console
Edit .firebaserc file and set aliases for my projects (to use firebase --use command)
.firebaserc
Separate RDS Instance and Slack Monitoring app
Separate .env files with .env.dev and .env.prod and use secrets based on NODE_ENV
set .env files
Add 'dev' script to package.json to deploy as 'NODE_ENV = development'
package.json scripts
This is the code I wrote to find out is which environment my server is running
node_env console.log
And this is from my github actions log and firebase console log
github actions and firebase console log
When I run my app in local with 'serve' command, console.log prints 'development' as I expected.
I guess 'firebase deploy' command automatically changes my NODE_ENV to production when it is deployed.
Or did I make some mistakes to do this?
The recommended way to have a development and production environment is to have two separate Firebase projects, which you are already making use of. For the sake of an example, let's assume you have hyositive-app as your production project and hyositive-dev as your development project.
Defining Deployed Environment Variables
Use of environment variables with Cloud Functions for Firebase are based on .env files compatible with the dotenv package. By default, the following files are supported (ignoring others!):
Name
Purpose
.env
Environment variables common to all environments
.env.<projectID>
Environment variables used when deployed to the named project (e.g. .env.hyositive-app)
.env.<alias>
Environment variables used when deployed to the aliased project (e.g. .env.dev).Note: default is the only alias configured out of the box. dev/prod/etc. are not defined.
.env.local
Environment variables used when using emulating functions on your system using the Cloud Functions emulator.
To use .env.dev and .env.prod, you will need to define them as project aliases in your .firebaserc file (or you can continue using development and production aliases and just update the filenames to match):
{
"projects": {
"default": "hyositive-dev",
"dev": "hyositive-dev",
"prod": "hyositive-app"
}
}
This then allows you to use .env.dev and .env.prod instead of .env.hyositive-dev and .env.hyositive-app respectively.
Using Environment Variables
The Cloud Functions runtime (the process that runs your deployed code) defines a number of built-in environment variables that have various purposes (such as allowing you to use initializeApp() with no arguments).
In addition to these variables, a handful of language-specific variables are also defined by the runtime to aid in painless deployment of code. However, the Cloud Functions documentation states to not rely on their values unless you set the values yourself.
The Node.js Cloud Functions runtime is built using the Cloud Functions Framework (however, it is not guaranteed to perfectly match this open source version). Because this runtime executes using Node.js and makes use of other packages such as express, it sets NODE_ENV to production, to minimise unexpected behaviour that depends on its value. But as mentioned above, this behaviour should not be relied on even though it is unlikely to change.
To override NODE_ENV to development, you would add it into .env.dev, .env.hyositive-dev and/or .env.local (as appropriate). Similarly, you should also define NODE_ENV as production in .env.prod or .env.hyositive-app (as appropriate).
Rather than rely on NODE_ENV, I would recommend defining behaviour around another variable that you have complete control over (such as HYOSITIVE_ENV) or compare against the executing project ID to determine whether it is running in the production project or not.
const PROD_PROJECT_ID = "hyositive-app",
// DEV_PROJECT_ID = "hyositive-dev",
PROJECT_ID = JSON.parse(process.env.FIREBASE_CONFIG).projectId,
isProduction = PROJECT_ID === PROD_PROJECT_ID;
Note: This other thread may have some useful background information.
Related
In our Node.JS application, we have been specifying application environments (dev, qa, stage, prod, etc.) in package.json as below:
"start-prod": "NODE_ENV=prod node ./bin/www",
"start-qa": "NODE_ENV=qa node ./bin/www"
etc.
However, we have realized recently that using NODE_ENV in this manner to specify app environments is not a good practice. So, I am trying to use the npm package node-config
for this purpose as well as for loading environment-specific configuration which is currently coming from AWS Parameter Store since there seem multiple advantages of using overriding config files over repeated configuration in AWS Parameter Store.
Therefore, I have created different config.json files, e.g., dev.config.json, qa.config.json, etc. But I am not sure how to specify/read the environment (qa, dev, stage, prod, etc.) and load configuration from the corresponding config.json file.
It may be a very stupid question but I am not able to find a good implementation example for node-config. Any help will be highly appreciated.
As documented on the node-config wiki, you can create:
default.js
prod.js
dev.js
qa.js
I am building a web application that utilises environment variables locally, and I want to put this on production (online). I am trying to find out how to set environment variables on AWS.
This is a node.js application and I am using elastic beanstalk on AWS for deployment. I have looked through https://docs.aws.amazon.com/cloud9/latest/user-guide/env-vars.html#env-vars-env-list , but I'm unsure of which option applies to me.
The .env file I have locally contains lines like
PASSWORD=MYPASSWORD
and I am using the dotenv package, with require('dotenv').config(); in the appropriate files. I am accessing environment variables in my code through things like process.env.PASSWORD (using the aforementioned example of a line in the .env file).
I've tried searching several places and am presented with various options, but I'm not sure which one applies to my environment variables.
The link you are following may help you in ec2 machine that is mangages by you, but if you are working Elasticbeanstalk I will recommend using Environment variable configuration provided by elasticbeanstalk.
I am not in favour of .env in case of Elasticbeanstalk, ECS and many other services where AWS provide easy and out of the box feature to set environment variable in the configuration and .env write environment to file which is less secure then system environment variable.
The interesting part of Elasticbeanstalk ENV is, the system environment variable has higher periphery then .env environment variable but better to not place dotenv on elasticbeanstalk.
Environment Properties and Other Software Settings
You can use environment properties to pass secrets, endpoints, debug
settings, and other information to your application. Environment
properties help you run your application in multiple environments for
different purposes, such as development, testing, staging, and
production.
elasticbeanstalk-deploy_nodejs
Example .ebextensions/options.config
option_settings:
aws:elasticbeanstalk:application:environment:
API_ENDPOINT: www.example.com/api
Now all you need
var endpoint = process.env.API_ENDPOINT
Environment Properties
The Environment Properties section lets you specify environment
configuration settings on the Amazon EC2 instances that are running
your application. These settings are passed in as key-value pairs to
the application.
Inside the Node.js environment running in AWS Elastic Beanstalk, you
can access the environment variables using process.env.ENV_VARIABLE
similar to the following example.
var endpoint = process.env.API_ENDPOINT
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 would like to use different credentials in my Netlify functions depending on my NODE_ENV variable. I have a Gatsby project and when I run netlify dev Gatsby sets NODE_ENV === development and gatsby develop command sets it to production.
Please have a look at Auth.js file https://github.com/iamskok/gatsby-dev-blog-starter/tree/feature/github-comments/.netlify/functions
Netlify functions have to use the same ENV variables as Gatsby does.
NODE_ENV is a tricky one to use because so many web tools use it toggle on/off production optimizations - its meaning has become somewhat overloaded. Take for example deploying to Netlify you always want to see an optimised prod build, even when deploying to a non-prod develop env, so NODE_ENV should always be "production" there.
So perhaps the answer is to setup a new env var APP_ENV (or whatever) that you can freely change in Netlify/Gatsby to properly indicate the current env (dev vs. staging vs. prod) and leave NODE_ENV for the tools to manage themselves.
They talk about it a bit in the Gatsby docs here:
https://www.gatsbyjs.org/docs/environment-variables/#additional-environments-staging-test-etc
I'm a newbie with Google Cloud App Engine and I want to deploy my simple Node.js application. I need to configure it for "production" environment. For example, I want to provide some credentials for email box, which my application is going to query for new emails.
I like to use nconf npm package, it gives me powerful and flexible configuration via command-line arguments or environment variables. I don't need to hard-code possibly secure values in source code.
Is there a way to configure environment variables or command-line arguments for an application in Google Developer Console?
P. S.
I found from documentation, that one can inline environment variables in app.yml config file:
env_variables:
FOO: 'myapp.bar'
But this is still not suitable for me, since app.yml is staged in git.