node转JAVA环境变量_小谈Node环境变量

看了一篇外文，讲如何使用node环境变量的。这期我也结合自己的一些经验写写读后感吧。

概述

说来话长，我最早接触环境变量还是在学Java的时候。特地找了张比较复古的图片，记得当时照着书本配环境变量都折腾好了几天。我后来还写到了百度知道里，现在都能搜到。

Environment Variables

无论何种语言，在开发和生产中，我们都会碰到各种各样的环境变量，直接写到系统环境里显然不合适。不过，也有例外。我刚进厂的时候，我们的产品还真的就是给客户环境加无数的系统变量，当时都震惊了。(汗)

Node开发

在Node开发中我们又是怎样使用环境变量的呢？

命令行

每次运行前先set各种变量，这个自然很蠢，就不往下说了。

set PROT=8080

node main.js

cross-env是npm script里最常用的一种添加环境变量的方式：用法很简洁，先在本地安装cross-env包，接着往package.json的script里一路列变量就行了。

yarn add -D cross-env

// package.json

{

"scripts": {

"main": "cross-env NODE_ENV=production SCOPE=onion node main.js"

},

"dependencies": {

"cross-env": "^5.1.4"

}

}

如上，调用的时候在控制台运行yarn main或是npm run main，环境变量就起效果了。具体体现如下，就是把代码里的proces.env.*给替换成npm script里对应的值。

// main.js

console.log(proces.env.NODE_ENV); // production

console.log(proces.env.SCOPE); // onion

cross-env很简洁，但也过于简单——它只能适应仅有少数环境变量的程序。假如有成百上千个变量值呢，我总不可能把这些都列在package.json里吧？

OK，你可以把这成百上千的变量放到文件里，比如给这个文件起个名字叫.env。

# .env

NODE_ENV=production

SCOPE=onion

PORT=8080

DB_CONN="balabala"

...

事实上就是有一个叫dotenv的npm包这么做的。安装还是一样简单：

yarn add -D dotenv

接着在main.js的开头加一句require("dotenv").config()，它就会在运行时自动读取根目录里.env文件的配置了。

// main.js

require('dotenv').config();

console.log(proces.env.NODE_ENV); // production

console.log(proces.env.SCOPE); // onion

当然，你不想在代码里四处添加require('dotenv')，也可以选择预加载——加个-r参数就行了。有的人还喜欢把这个这些配置加到vscode的launch.json里，道理是一样的。

node -r .env main.js

Webpack

Webpack一般用于前端模块的构建和打包，但事实上对node后端项目打包也很方便。我在部署lambda function的时候就用到了webpack，它能把一个庞大的项目压缩至几兆，是解决aws lambda依赖大小限制的重要手段。

OK，webpack处理环境变量与上述种种略有不同，并非运行时调取proces.env对象；而是在build时用字符串替换掉所有proces.env.*。

// main.js

console.log(proces.env.NODE_ENV);

console.log(proces.env.SCOPE);

上述代码事实上在打包后等价于：

console.log('production');

console.log('onion');

有个很经典的webpack插件叫DefinePlugin，就可以处理这些变量，他用于定义全局常量。你可以这么使用：

// webpack.config.js

module.exports = {

...

plugins: [

new webpack.DefinePlugin({

'process.env.NODE_ENV': 'production',

'process.env.SCOPE': 'onion'

})

]

...

};

后来，我又发现了一个专门处理环境变量的插件叫EnvironmentPlugin, 它与DefinePlugin最后等价。

// webpack.config.js

module.exports = {

...

plugins: [

new webpack.EnvironmentPlugin({

NODE_ENV: 'production'

SCOPE: 'onion'

})

]

...

};

有了EnvironmentPlugin就可以把所有变量都放到webpack.config.js。当然，假如你坚持需要专门的.env文件里，强大如webpack社区也早已为你考虑到了——dotenv-webpack。同dotenv一样，你把所有环境变量列到.env里，然后在webpack.config.js添加新插件即可。

// webpack.config.js

const Dotenv = require('dotenv-webpack');

module.exports = {

...

plugins: [

new Dotenv()

]

...

};

VS Code

VS Code是目前最主流的Node开发工具，假如开发组团队全部使用VS Code，大家也可以把环境变量配到.vscode/launch.json里。

// launch.json

{

"configurations": [

{

"env": {

"NODE_ENV": 'production'

"SCOPE": 'onion'

}

}

]

}

VS Code也可以和.env文件打通：

// launch.json

{

"configurations": [

{

"envFile": "${workspaceFolder}/.env"

}

]

}

生产环境

上面提到的都是本地开发环境里如何使用环境变量，但是在生产环境里必须要有更多安全的考量；环境变量很可能包含敏感信息，比如数据库密码、access key、credentials等等。因此这些变量不适合直接提交到较开放的代码仓库里。一般的解决方法有这么几种：

私有部署

将配置文件上传到私有Git上，并在build或是运行时，依靠构件工具自动拉取这些配置。

持久化配置服务

云服务商都会打包持久化配置服务，主要就是存储环境变量。比如aws的Systems manger，我经常用它里面的SSM:parameter store来处理lambda的环境配置。这些配置可以直接通过云服务自带的SDK获取：既可以运行前预加载，也可以在运行时异步加载。这个服务与role相关，因此确保了第三方服务器即便拿到了Token也无法访问。

加密服务

在某些安全级别特别高的服务器里，内部私有Git都不被允许，还不信任敌国势力股权下的云服务商，那就只能使用加密服务了。一般来说就是将所有环境变量加密存储，并利用SDK解密后放入运行环境中。

小结

环境管理是开发中经常碰到的问题。我记得以前开发团队内部会手手相传某个巨大的配置文件；谁也不知道它们各自的作用，且经常被人更改，每次更改后如果不到某个环节还不知道特定效果。因此每天都会有人喊，“咋又打不开了？”，“可能是一个月前改的某个变量吧，我的配置发给你试试。”

想起来还是回味无穷的。现在开发中除了极少数配置，我已经把绝大多数环境变量放到AWS的Systems manager里了，开发时也是动态读取。Systems manager价格也很便宜，一个月几毛钱吧。许多问题开阔一下眼界就迎刃而解了。