問題タブ [12factor]

12-Factor アプリでは、環境変数を使用してアプリケーションを構成することをお勧めします。ここまでは順調ですね。接続文字列を設定する必要がある場合、これが良い方法であることは容易に想像できます。

しかし、非常に多くの値を含むより複雑な構成がある場合はどうなるでしょうか? 私は確かに 50 以上の環境変数を持ちたくありませんよね?

どうすればこれを解決でき、それでも 12-Factor Apps の考え方に準拠できますか?

angularjs アプリを構成 ( http://12factor.net/config ) に関して 12 ファクターに準拠させようとしています。

環境に依存する必要があり、コードに 、 、 などの単語が表示されないdevelopmentはずtestですproduction。

envたとえば、変数はbashに保存できます。それらをWebサーバーに渡すことができました。

.erb テンプレート ファイルをerb config.js.erb > config.js.

私はすでにこの記事を見つけましたhttp://mindthecode.com/how-to-use-environment-variables-in-your-angular-application/

しかし、これは大きな嘘であり、Grunt.js がこれを行うのは本当に... とにかく。

12factor の哲学がフロントエンド アプリケーション用に作成されたものではないことは知っていますが、角度のあるアプリケーションは多くの環境のさまざまなサーバーにデプロイでき、適切に処理しようとしても害はありません :)。

ありがとう ！

編集：

使用したい設定パラメータは、次のようなものです。

その他の編集:

この男はちょっと答えに行きました：http://bahmutov.calepin.co/inject-valid-constants-into-angular.html私はちょっと醜く、完全にangularjsにバインドされていると思います。しかし、それは動作します!

環境変数を使用して Docker の動作を制御するネイティブまたは一般的に受け入れられている方法、つまり 12factor の方法はまだありますか?

私が見た唯一の言語に依存しない方法は、docker run コマンドを -e 変数で汚染することです。私が見た中で最も保守しやすいソリューションは、cat と sed の組み合わせを使用して、.env ファイルを使用して CLI パラメーターを生成することです: https://twitter.com/DataKyle/status/422843345120296960

現在、開発には Vagrant を使用し、テストとデプロイには CI/CD ホステッド プロバイダーを使用し、AWS Elastic Beanstalk をステージングおよび本番 PAAS として使用しています。私たちのアプリには 100 を超える構成可能なパラメーターがあり、そのほとんどは既定値に設定されていますが、各環境ではそれらの約 10 ～ 20 をカスタマイズする必要があります。そのようなコマンドライン変数の膨大なリストを使って docker を実行するのは、ハックすぎるように思えます。

さらに、さらにハッキングせずに、docker ホストから変数 (CI プロバイダーのプレインストールされた Redis または Postgres 資格情報など) を取得することはできません。

私が見つけていないこれに対する解決策はありますか？それとも、これは Docker にとって欠落している部分ですか? それとも、これはどういうわけか哲学的に Docker の哲学に反しているのでしょうか?

12 ファクター アプリのマニフェストhttp://12factor.net/を読んでいました。マニフェストでは、アプリケーションの構成データを環境変数に保存することを推奨しています。これは、DB ユーザー名/パスワード、リソース URL などのプロパティを、プロパティ ファイルとしてではなく、Java Env 変数の一部として保存する必要があることを意味しますか? これは情報を安全に保存する方法ですか? 私には、これは情報を保存するかなり扱いにくい方法のように思えます。これに関して共有できるベスト プラクティスや経験はありますか?

私が考えることができる 1 つのオプションは、別の構成サービスをランドスケープで実行し、Env プロパティを使用して構成サービスに接続し、さらに詳細な構成データについて構成サービスを照会することです。

ポート バインディング http://12factor.net/port-bindingに関する 12 ファクターの記事では、すべてのアプリが自己完結型であり、Tomcat などのランタイムが注入されていないという要件があります。これが推奨される理由は何ですか...マイクロサービス用の自己完結型アプリの利点は何ですか?

12factor は、プロセスをデーモン化しないことを推奨しています。そうすることの欠点は何ですか？

私はここで見つけることができるTwelve-Factorアプリ「マニフェスト」に言及しています: http://12factor.net

8番目の要因で、著者は次のように書いています。

12 要素アプリ プロセスは、PID ファイルをデーモン化または書き込みしないでください。代わりに、オペレーティング システムのプロセス マネージャー (Upstart、クラウド プラットフォーム上の分散プロセス マネージャー、開発中の Foreman のようなツールなど) に依存して、出力ストリームを管理し、クラッシュしたプロセスに対応し、ユーザーが開始した再起動とシャットダウンを処理します。

ここで「プロセスは決してデーモン化しないでください」が何を意味するのかわかりません。

特にJavaプロセスのコンテキストで、プロセスをデーモン化することの長所と短所を誰かが説明してもらえますか? また、デーモン化されたプロセスをプロセス マネージャーで管理することはできませんか?