问题标签 [12factor]

我正在与实习生一起设置我们的 e2e 测试服务，并希望使用 npm dotenv 库将我的秘密（酱实验室密钥等）保存在 .env 文件中。为了做到这一点，我需要在require某个地方。我最早可以在哪里做到这一点？我的实习生配置都继承自基本配置，所以我打算暂时使用它——但有没有更早的地方？

作为记录，这是一个独立的测试服务，不是另一个框架的一部分，我正在使用这个库：https ://github.com/motdotla/dotenv

12 factor app manifesto 建议将所有日志输出写入 stdout。如果您的服务/应用程序在 docker 容器中运行，这非常容易实现。然后，您可以使用 docker log 驱动程序将日志发送到像 fluentd 这样的日志传送器，然后它可以将它们发送到 elasticsearch 进行分析或类似 HDFS 的东西进行长期存储。

虽然很清楚如何处理日志，但似乎没有任何关于如何处理指标的指导。例如，我们可能想要跟踪每个请求所花费的时间、错误率和我们服务的其他内容。

可以让服务直接发送指标，但这似乎违反了 12 因素应用程序原则。此外，如果指标服务器出现故障或服务出现故障，我们将需要处理将指标写入磁盘和其他类似预写日志的功能，这会增加复杂性。

一种可能的解决方案是将指标写入stdout并使用 fluentd 过滤它们。但是在这种情况下，我们将日志和指标混合在一起，我们需要为日志和指标的外观设置一套格式来区分它们，这对于不是我们编写的服务可能不是一个选项。

在 12 因素应用程序中，应如何将来自应用程序/服务的指标发送到指标服务器？

We deploy services as docker containers using Marathon. The containers include a base config file, Marathon pulls an environment config file (which has a subset of the base keys) at deployment time so when the app starts it has;

• environment.toml
• config.toml

when reading the config we need to conflate the values in both files to a single set, effectively masking/shadowing the values present in both files with those in the environment file.

I didn't find this functionality in the Viper docs. Unless I have missed something it seems my options are;

• Write a package that uses Viper to read both files and perform the conflation.
• Extend Viper

Before I start writing code, is there already a mechanism for doing this?

您将如何编写一个 12 要素的 webpack/expressjs 应用程序？特别是，我希望 expressjs 服务器上的环境变量在运行时提供一些应用程序配置。

目前，我在<script>标签中创建了一个全局 Config 对象，并通过渲染模板并传入值来填充它，但我想使用 webpack 外部并将其包装为适当的模块。有没有人尝试过这样做，或者有类似的解决方案？

我的工作场所最近转而开发 12 要素应用程序。与此同时，我们被鼓励采用新的工具和技术。我正在尝试为动态前端选择视图引擎。我正在考虑 ReactJS。但是，由于我还很年轻，我担心使用 ReactJS 状态会打破 12 因子应用程序的无状态要求？

我正在写一篇关于十二因素应用程序的论文，我想知道你是否可以在这里帮助我。

十二因素应用程序的第三个因素状态：在环境中存储配置。（https://12factor.net/config）。根据页面，部署之间可能会有所不同的所有配置都应提取到环境变量中。

我想知道在创建例如 Rails 应用程序时如何在开发过程中应用。目前，我看到两种在我看来都不完美的方法。

• 将环境变量存储在.bashrc或.zshrc等文件中。我不知道如何使用这种方法管理测试和开发环境，因为两者都需要使用相同环境变量的特定配置。此外，在处理多个项目时，这会使 shell 充满变量，但它似乎符合十二因素应用程序方法。
• 使用像https://github.com/bkeepers/dotenv这样的工具，它使用作为项目一部分的文件来存储配置，因此与 Rails 框架已经提供的 secrets.yml 或 database.yml 没有太大区别并且不完全符合十二因素应用程序的想法（仍然可以不小心检查到代码库中，并且大部分与语言无关）

我的观点正确吗？我想知道是否有任何最佳实践来解决这个问题。

谢谢！

促进 Maven 快照在 12-factor-app 中发布的最佳实践是什么？

我想实现一次构建并推广相同的二进制文件，部署相同的二进制文件。

我在这里使用 maven 和 artifactory。

https://content.pivotal.io/ebooks/beyond-the-12-factor-app

我正在运行一个 jelastic 设置来托管多个 Rails 应用程序。

在 Rails 中，将配置存储在环境中是很常见的。尤其是机密数据，例如密码或访问密钥。

我应该将它们放在 Ruby/Rails jelastic 设置的什么位置？

我目前有 nginx 和乘客；因为这是默认设置。如果 Puma 或 Unicorn 让这变得更容易或更强大，我很想听听。

/etc/nginx/nginx.conf我目前在using nginx env指令中声明了我的环境变量。但这意味着我将秘密存储在 nginx.conf 文件中。呸。

1. 您如何在任何 jelastic 设置中管理您的秘密？
2. 您如何在 Rails jelastic 设置中管理您的秘密？
3. 您在哪里存储环境变量以供正在运行的应用程序获取？

编辑：我对将秘密远​​离“机器上的其他用户/进程”不感兴趣。我不想将我的秘密存储在我的应用程序 git-repo 中。这是非常非常糟糕的做法。因此，我希望我的 Rails 应用程序能够读取ENV['AWS_SECRET_KEY']，而不是将该密钥存储在我的代码库中的某个位置。

Developing and testing applications inside of Docker containers and finally running them in the same manner in production is a great approach to reduce the used to work on my machine but is magically failing in production risk.

This is also reflected in factor no. 10 of the well-known 12 factor manifesto which I try to follow wherever it makes sense for the given use case: Keep development, staging, and production as similar as possible.

On our production server, we have a reverse-proxy in place which is taking incoming requests on port 80 and forwards them to the correct container depending on the Host header used when accessing the host via virtual domains - e.g. requests to app1.domain.name go to the app1 container while requests to app2.domain.name go to the app2 container etc. We use traefik for that but it could also be jwilder/nginx-proxy or any other reverse-proxy or load balancer. No other container ports are publicly exposed for the application containers.

My question now is, what would be the most efficient way to simulate this setup during development? I could think of the following ones:

1. Ignore the reverse-proxy during development and expose a public port for each service under which one can reach it during development. In production, however, do not publicly expose any ports. While this is easy to do, it does not give exact parity between the development and production setup.
2. Run a similar reverse-proxy locally during development. While this gives much better parity between development and production environment, this requirement needs to be documented somewhere and places some burden on new developers to get the prerequisites right before actually diving into the application itself - something that the Docker approach actually tries to avoid.
3. Automate setting up a development environment which mimics the production one (including the reverse-proxy) by putting everything into a virtual machine (e.g. with Vagrant). While this would be convenient from a developer's point of view, it takes some further time to setup initially and consumes more resources.

Did I miss here some other approach which is superior to the ones described?

我已阅读有关十二因素应用程序的配置 - 第 III 节的信息，并在 NodeJS 中搜索了一种方法。似乎大多数人建议使用dotenv将配置存储在环境变量中。

然而，dotenv 似乎与十二因素应用程序相矛盾，如下所述：

另一种配置方法是使用未检入修订控制的配置文件，例如 Rails 中的 config/database.yml。与使用检入代码仓库的常量相比，这是一个巨大的改进，但仍然存在弱点：很容易错误地将配置文件检入到代码仓库；配置文件倾向于分散在不同的地方和不同的格式，使得在一个地方查看和管理所有配置变得困难。此外，这些格式往往是特定于语言或框架的。

十二因素应用程序将配置存储在环境变量中（通常缩写为 env vars 或 env）。环境变量很容易在部署之间更改，而无需更改任何代码；与配置文件不同，它们被意外签入代码仓库的可能性很小；与自定义配置文件或其他配置机制（如 Java 系统属性）不同，它们是与语言和操作系统无关的标准。

理解这个声明，似乎使用 dotenv，您将创建一个配置文件.env，然后将它们导出为环境变量。

这不会违反十二因素应用程序，因为.env文件可能会意外签入代码仓库吗？