問題タブ [12factor]

私はインターンで e2e テスト サービスをセットアップしており、npm dotenv ライブラリを使用して .env ファイルに秘密 (ソース ラボ キーなど) を保持したいと考えています。それをするために、私はrequireどこかにそれをする必要があります。私がそれを行うことができる最も早い場所はどこですか？私のインターン構成はすべて基本構成から継承しているので、今のところそれを使用する予定ですが、以前のどこかにありますか?

記録のために、これは自己完結型のテスト サービスであり、別のフレームワークの一部ではありません。私はこのライブラリを使用しています: https://github.com/motdotla/dotenv

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 ファクター アプリの開発に切り替えました。これに伴い、新しいツールや技術を採用するよう奨励されています。動的フロントエンド用のビュー エンジンを選択しようとしています。ReactJS を考えています。ただし、私はかなり環境に優しいので、ReactJS 状態を使用すると 12 要素アプリのステートレス要件が破られるのではないかと心配しています。

Twelve-Factor アプリに関する論文を書いていますが、ここで助けていただけないでしょうか。

12 要素アプリの 3 番目の要素は、次のように述べています。環境に構成を保存します。( https://12factor.net/config )。ページによると、デプロイ間で異なる可能性があるすべての構成は、環境変数に抽出する必要があります。

Rails アプリなどを作成する際に、開発中にどのように適用するのか疑問に思っています。現在、私の意見では、どちらも完璧ではない 2 つの方法があります。

• 環境変数を.bashrcや.zshrcなどのファイルに保存します。どちらも同じ環境変数を使用して特定の構成を必要とするため、このアプローチを使用してテスト環境と開発環境を管理する方法についてはよくわかりません。また、複数のプロジェクトに取り組んでいる場合、これによりシェルが変数で乱雑になりますが、12 要素アプリの方法論に準拠しているようです。
• https://github.com/bkeepers/dotenvのようなツールを使用します。これは、プロジェクトの一部であるファイルを使用して構成を保存するため、Rails フレームワークが既に提供している secrets.yml や database.yml とそれほど違いはありません。そして、これは 12 要素アプリのアイデアに完全には準拠していません (コードベースに誤ってチェックインされる可能性があり、ほとんど言語に依存しません)。

私の見解は正しいですか？この問題に取り組むためのベストプラクティスがあるかどうか疑問に思っています。

ありがとう！

Maven スナップショットを 12-factor-app でリリースするためのベスト プラクティスは何ですか。

ビルドを一度達成し、同じバイナリ ファイルを昇格させ、同じバイナリ ファイルをデプロイしたい。

ここではmavenとartifactoryを使用しています。

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

Twelve Factor App's Config - Section IIIについて読み、NodeJS でそれを行う方法を検索しました。ほとんどの人は、環境変数に設定を保存するためにdotenvを推奨しているようです。

ただし、次のように dotenv は Twelve-Factor App と矛盾しているようです。

構成へのもう 1 つのアプローチは、Rails の config/database.yml など、リビジョン管理にチェックインされていない構成ファイルを使用することです。これは、コード リポジトリにチェックインされる定数を使用する場合よりも大幅に改善されますが、まだ弱点があります。設定ファイルを誤ってリポジトリにチェックインするのは簡単です。構成ファイルはさまざまな場所やさまざまな形式に散在する傾向があり、すべての構成を 1 か所で確認して管理することは困難です。さらに、これらの形式は言語またはフレームワークに固有である傾向があります。

Twelve-Factor アプリは、構成を環境変数 (多くの場合、env vars または env に短縮されます) に保存します。環境変数は、コードを変更することなく、デプロイ間で簡単に変更できます。構成ファイルとは異なり、誤ってコード リポジトリにチェックインされる可能性はほとんどありません。また、カスタム構成ファイルや Java システム プロパティなどの他の構成メカニズムとは異なり、言語や OS に依存しない標準です。

このステートメントを理解すると、dotenv を使用して構成ファイル.envを作成し、それらを環境変数としてエクスポートするようです。

.envファイルが誤ってコード リポジトリにチェックインされる可能性があるため、これは Twelve-Factor App に違反しませんか?