我一直在开发一些Node应用程序,我一直在寻找一种存储部署相关设置的良好模式。在Django世界(我来自那里),常见的做法是有一个settings.py文件包含标准设置(时区等),然后有一个local_settings.py用于部署特定的设置,即。要与什么数据库通信、什么memcache套接字、管理员的电子邮件地址等等。

我一直在为Node寻找类似的模式。只要一个配置文件就好了,这样它就不必与app.js中的其他所有东西挤在一起,但我发现有一种方法在源代码控制之外的文件中拥有特定于服务器的配置很重要。同一款应用可以部署在不同设置的服务器上,必须处理合并冲突,这不是我的乐趣所在。

那么是否存在某种框架/工具,或者每个人都只是自己拼凑一些东西?


当前回答

您可以从Node v0.5开始要求JSON文件。X(引用这个答案)

json:

{
    "username" : "root",
    "password" : "foot"
}

app.js:

var config = require('./config.json');
log_in(config.username, config.password);

其他回答

现在,在使用数据库时,最简单的方法是完全不处理配置文件,因为部署环境更容易设置,只需使用单个环境变量(例如,将其称为DB_CONNECTION),并根据需要向其传递任何额外的配置数据。

配置数据举例:

const config = {
    userIds: [1, 2, 3],
    serviceLimit: 100,
    // etc., configuration data of any complexity    
};
// or you can read it from a config file

创建一个连接字符串,包含数据库驱动程序不关心的额外参数:

import {ConnectionString} from 'connection-string';

const cs = new ConnectionString('postgres://localhost@dbname', {
    user: 'user-name',
    password: 'my-password',
    params: {
        config
    }  ​
});

然后我们可以生成结果字符串存储在环境中:

cs.toString();
//=>postgres://localhost:my-password@dbname?config=%7B%22userIds%22%3A%5B1%2C2%2C3%5D%2C%22serviceLimit%22%3A100%7D

所以你把它存储在你的环境中,比如说DB_CONNECTION,在客户端进程中你可以通过process.env.DB_CONNECTION读取它:

const cs = new ConnectionString(process.env.DB_CONNECTION);

const config = JSON.parse(cs.params?.config); // parse extra configuration
//=> { userIds: [ 1, 2, 3 ], serviceLimit: 100 }

通过这种方式,您将在单个环境变量中同时拥有连接和所需的所有额外配置,而不需要打乱配置文件。

尝试使用properties-gen https://www.npmjs.com/package/properties-gen

node-config与node-config非常相似,后者加载配置基础文件,并根据所设置的环境使用ext文件对其进行扩展,但这是一个按需运行且完全可配置的cli。

npx properties-gen init

要创建cli配置,然后将其安装到项目中

npm install properties-gen --save-dev

定义您的配置文件(基本和扩展),并在构建过程之前或在项目中启动开发服务器之前运行generate命令。

{
  "name": "myApp",
  "scripts": {
    "config": "properties-gen generate",
    "dev": "npm run config && next dev",
    "build": "npm run config && next build",
    "start": "next start"
  }
}

一件很酷的事情是,您可以定义多个配置组,以防您需要生成多个输出,例如特定于客户端和服务器的文件。

在这里,我将全身心地投入其中,因为这些答案中没有一个解决了几乎任何系统都需要的所有关键组件。注意事项:

公共配置(可以从前端看到)vs私有配置(guy mograbi说对了)。并确保它们是分开的。 钥匙一样的秘密 默认值vs特定于环境的覆盖 前端包

以下是我如何进行配置:

config.default.private.js - In version control, these are default configuration options that can only be seen by your backend. config.default.public.js - In version control, these are default configuration options that can be seen by backend and frontend config.dev.private.js - If you need different private defaults for dev. config.dev.public.js - If you need different public defaults for dev. config.private.js - Not in version control, these are environment specific options that override config.default.private.js config.public.js - Not in version control, these are environment specific options that override config.default.public.js keys/ - A folder where each file stores a different secret of some kind. This is also not under version control (keys should never be under version control).

I use plain-old javascript files for configuration so I have the full power of the javascript langauge (including comments and the ability to do things like load the default config file in the environment-specific file so they can then be overridden). If you want to use environment variables, you can load them inside those config files (tho I recommend against using env vars for the same reason I don't recommend using json files - you don't have the power of a programming language to construct your config).

每个键在一个单独的文件中的原因是为了安装程序的使用。这允许您有一个安装程序,在机器上创建密钥并将它们存储在密钥文件夹中。如果不这样做,当你加载无法访问密钥的配置文件时,安装程序可能会失败。通过这种方式,您可以遍历目录并加载该文件夹中的任何关键文件,而不必担心在任何给定版本的代码中哪些存在哪些不存在。

由于您可能在私有配置中加载了密钥,因此您绝对不希望在任何前端代码中加载私有配置。虽然严格来说,将前端代码库与后端代码库完全分离可能更理想,但很多时候,PITA是一个足够大的障碍,阻止人们这样做,从而导致私有配置与公共配置。但是我做了两件事来防止在前端加载私有配置:

我有一个单元测试,确保我的前端包不包含我在私有配置中的一个密钥。 我将前端代码放在与后端代码不同的文件夹中,并且我有两个名为“config.js”的不同文件-一端一个。对于后端,config.js加载私有配置,对于前端,它加载公共配置。然后你总是只需要('config'),而不用担心它来自哪里。

最后一件事:您的配置应该通过一个完全独立于任何其他前端代码的文件加载到浏览器中。如果捆绑前端代码,公共配置应该作为一个完全独立的包构建。否则,你的配置就不再是真正的配置了——它只是你代码的一部分。配置需要能够在不同的机器上有所不同。

我的解决办法相当简单:

在./config/index.js中加载环境配置

var env = process.env.NODE_ENV || 'development'
  , cfg = require('./config.'+env);

module.exports = cfg;

在./config/config.global.js中定义一些默认值

var config = module.exports = {};

config.env = 'development';
config.hostname = 'dev.example.com';

//mongo database
config.mongo = {};
config.mongo.uri = process.env.MONGO_URI || 'localhost';
config.mongo.db = 'example_dev';

重写。/config/config.test.js中的默认值

var config = require('./config.global');

config.env = 'test';
config.hostname = 'test.example';
config.mongo.db = 'example_test';

module.exports = config;

在./models/user.js中使用:

var mongoose = require('mongoose')
, cfg = require('../config')
, db = mongoose.createConnection(cfg.mongo.uri, cfg.mongo.db);

在测试环境中运行应用程序:

NODE_ENV=test node ./app.js

你也可以看看dotenv,它遵循了十二要素应用程序的原则。

我曾经使用节点配置,但出于这个原因创建了dotenv。它的灵感完全来自ruby的dotenv库。

用法很简单:

var dotenv = require('dotenv');
dotenv.load();

然后你只需要创建一个。env文件,把你的设置放在那里,就像这样:

S3_BUCKET=YOURS3BUCKET
SECRET_KEY=YOURSECRETKEYGOESHERE
OTHER_SECRET_STUFF=my_cats_middle_name

这是nodejs的dotenv。