小谈Node环境变量

看了一篇外文，讲如何使用node环境变量的。这期我也结合自己的一些经验写写读后感吧。 概述 说来话长，我最早接触环境变量还是在学Java的时候。特地找了张比较复古的图片，记得当时照着书本配环境变量都折腾好了几天。我后来还写到了百度知道里，现在都能搜到。 Environment Variables 无论何种语言，在开发和生产中，我们都会碰到各种各样的环境变量，直接写到系统环境里显然不合适。不过，也有例外。我刚进厂的时候，我们的产品还真的就是给客户环境加无数的系统变量，当时都震惊了。（汗） Node开发 在Node开发中我们又是怎样使用环境变量的呢？ 命令行 每次运行前先set各种变量，这个自然很蠢，就不往下说了。 set PROT=8080 node main.js cross-env 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 dotenv 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价格也很便宜，一个月几毛钱吧。许多问题开阔一下眼界就迎刃而解了。

本文章由javascript技术分享原创和收集