十二要素应用程序:与配置指南保持一致的方法 [英] Twelve-Factor Apps: ways to stay align with the config guideline

查看:47
本文介绍了十二要素应用程序:与配置指南保持一致的方法的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在写一篇有关十二因子应用程序的论文,我想知道您是否能在这里为我提供帮助.

I'm writing a thesis about twelve-factor apps and I wonder if you can help me out here.

十二个因素应用程序的第三个因素指出:将配置存储在环境中.( https://12factor.net/config ).根据该页面,应将部署之间可能有所不同的所有配置提取到环境变量中.

The third factor of twelve-factor apps states: Store config in the environment. (https://12factor.net/config). According to the page all configuration which might vary between deploys should be extracted to environment variables.

我想知道在创建例如Rails应用程序.目前,我认为两种方法都不是完美的.

I am wondering how to apply during development when creating e.g. a Rails app. Currently I see two ways which are both not perfect in my opinion.

  • 将环境变量存储在 .bashrc .zshrc 之类的文件中.对于如何使用这种方法来管理测试和开发环境,我没有一个好主意,因为两者都需要使用相同的环境变量进行特定的配置.同样,当在多个项目上工作时,这会使shell变得杂乱无章,但似乎与十二要素应用程序方法兼容.
  • 使用类似 https://github.com/bkeepers/dotenv 之类的工具,该工具使用文件它是项目的一部分,用于存储配置,因此与Rails框架已经提供的secrets.yml或database.yml并没有太大区别,并且与十二因子应用程序的想法并不完全兼容(仍然可以不经意地检查进入代码库,并且与语言无关)
  • Store environment variables in a file like .bashrc or .zshrc. I don't have a good idea on how to manage a test and development environment using this approach since both need a specific configuration using the same environment variables. Also when working on multiple projects this will clutter the shell with variables but it seems to be compliant with the twelve-factor app methodology.
  • use a tool like https://github.com/bkeepers/dotenv which uses a file which is part of the project to store the configuration and is thereby not so much different from secrets.yml or database.yml which the Rails framework already offers and which is not perfectly compliant to the twelve-factor app idea (can still be accidentally checked into the codebase and is mostly language-agnostic)

我的观点正确吗?我想知道是否有解决此问题的最佳实践.

Is my view correct? I wonder if there are any best practices to tackle this problem.

谢谢!

推荐答案

基本上,可以根据您的上下文访问环境变量.运行流程,系统,应用程序的用户都可以修改可以在应用程序中的任何给定时间/位置访问的变量集.因此,放置它们的位置取决于应用程序的需求-是否需要在同一服务器上隔离不同的应用程序?您需要有效管理数十个应用程序吗?您是否需要供应和填充新的服务器环境?等等.

Basically, Environment Variables are accessible based on your context. The user running the process, the system, the application, all can modify the set of variables you can access at any given time/place in your app. So, where you put them depends on the needs of your app - do you need to isolate different apps on the same server? Do you need to effectively manage dozens of apps? Do you need to provision and populate new server Environments? Etc.

至于选项,这就是我所经历的:

As for options here is what I have experienced:

.* rc 文件适用于这种配置,即使您可能不喜欢它的 flavor .这使它们对环境运行文件的用户可用,因此,如果您的登录用户是 ubuntu ,但是您的服务与其他用户一样运行,例如 www-data httpd .

The .*rc files are fine for this kind of config, even though you may not like the flavor of it. These make them available to the user whose Environment runs the files, so it might not work for you if your login user is ubuntu but your services run as other users, like www-data or httpd.

Dotenv也很好,因为它在运行时会将变量注入到实际的ENV中.虽然不是完美的,但是仍然可以接受,恕我直言(假设您从不将这些变量提交给vc,正如您所指出的那样).这使得使用Dotenv的单个应用程序可以使用它们.

Dotenv is also fine, because it injects the variables into the actual ENV when it runs. Not perfect, but still acceptable imho (assuming you never commit those variables to vc, as you point out). This makes them available to the single application using Dotenv.

(对于Web应用程序)其他方式是将其置于Apache或Nginx(或其他Web服务器)配置中.它们可以放在virtualhost定义层或服务/守护程序配置层的环境中(尽管我认为Nginx不支持vhost环境).这使变量可用于由这些服务启动的任何应用程序.这对于网站或网络应用程序很常见.

Other ways are (for web apps) to put them in the Apache or Nginx (or other web server) configuration. They can be put into the Environment at the virtualhost definition layer, or at the service/daemon configuration layer (though Nginx I think doesn't support vhost Environments). This makes the variables available to any apps started by these services. This is common for a website or web app.

您还可以在服务器范围内设置环境:/etc/profile /etc/environment .这使它们可用于整个系统上的任何服务.

You can also set the Environment server-wide: /etc/profile or /etc/environment. This makes them available to any service on the entire system.

除此之外(多服务器应用程序,复杂托管等)更多是Ops的问题-管理多个配置集仍然与12因子应用程序相关,但没有简单的答案:)

Beyond this (multi-server apps, complex hosting, etc) is more a question of Ops - managing multiple configuration sets is still relevant to the 12-Factor App, but won't have a simple answer :)

您不必立即决定!使用环境变量是一种非常灵活的方法!您可以在开发Macbook上使用DotEnv,将它们放在Staging环境中的Apache中,对测试/集成服务器使用 .bashrc ,然后将它们放入/etc/environment 在您定制的Lighttpd Production服务器上.让您的应用程序期望您的配置包含在ENV中意味着您的应用程序不必在乎它的实现方式 !!!

You don't have to decide right away! Using Environment Variables is a very flexible approach! You can use DotEnv on your Development Macbook, put them in Apache on your Staging environment, use .bashrc for your Test/Integration server, and put them in /etc/environment on your custom-built Lighttpd Production server. Having your app expect your config to be in ENV means your app doesn't have to care about how it got there!!!

这篇关于十二要素应用程序:与配置指南保持一致的方法的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆