13

「Twelve-FactorApp」（http://www.12factor.net/）と呼ばれる優れたドキュメントがあり、作成者は最新のアプリを設計、構築、および展開するための完璧な方法を定義しようとしています。サービス。

このドキュメントは非常に一般的であり、多くの場合、説明されているプラ​​クティスは最適ではなく、簡単に実行できないか、Microsoftのベストプラクティスに違反しています。例：ドキュメントでは、構成ファイルの使用を推奨していませんが、構成に環境変数を使用することを推奨しています。これは、XML構成ファイルを使用するのが一般的な（ベスト？）プラクティスである.NETでは正しくないように思われます。

理想的な世界（つまり、予算/技術/スキルの制約を忘れる）で、Microsoftプラットフォームがすべての展開で選択されるプラットフォームとして選択され、.NET / TFSが選択される開発環境/ツールである場合、ガイダンスに従う方法12ファクターアプリで？

そのようなアプリケーションの良い例はありますか（おそらく、優れた参照アーキテクチャを備えたオープンソースのアプリケーション）？

4

4 に答える 4

12

構成に関する部分を読みましたが、作成者は.NETでの構成ファイルの使用を明確に理解していません。彼らが表現する問題は、私たちが.iniファイルで抱えていた問題です。これらの問題は、次の理由で.NETには存在しません。

  1. 「デスクトップ」アプリケーションには、デプロイメントごとに1つの構成ファイルがあります。「app.config」は、アプリケーションと同じフォルダーにデプロイされたprogram.exe.configとして存在します。
  2. Webアプリケーションでは、web.configファイルの階層が、明確に定義された場所に、明確に定義された名前で存在します。
  3. Visual Studio 2010のweb.config変換機能を使用すると、各ビルド構成（環境）のメインファイルを自動的に編集する方法を指定する変換ファイルとともに、メイン構成ファイルをソース管理にチェックインできます。これらのファイルはすべて、ソース管理に保存できます。
  4. クレデンシャルがそのようなファイルに保存される（したがってソース管理にチェックインされる）のはデフォルトですが、これは必要ありません。
  5. 少なくともWebアプリケーションの場合、IISのMSDEPLOY機能とVisual Studio 2010のWeb公開パイプラインにより、展開をパラメーター化できます。デフォルトでは、これには、資格情報が発生する可能性が高い主要な領域の1つである接続文字列のパラメーター化が含まれます。これを拡張して、すべての資格情報またはその他の機密データのパラメーター化を含めることができるため、開発者はこの情報にアクセスできません。パラメータは、展開プロセスの一部として入力できます。
于 2012-06-22T22:05:01.983 に答える
7

12 Factorには、構成に関する3つの「要件」があります。

  1. 構成をコードに保存しないでください
  2. 構成をソース管理（または最終的にソース管理になる可能性のある形式）に入れないでください。彼らは「単一のコードベース」を望んでいます。
  3. 構成を、任意のテクノロジースタック（.NET / Java / Ruby /など）にアクセスできる形式で配置します。

.NET構成ファイルはこれらの半分に準拠していると思います。

  1. 構成ファイルがコードに含まれていません（パス）。
  2. 構成ファイルはソース管理下にある必要はありませんが、多くの場合、そこに到達します（失敗します）。
  3. XML形式であり、他のテクノロジにアクセスできるにもかかわらず、.NET構成ファイルには多くの.NETismがあります。configsectionsのスキーマは.NETタイプによって提供されるため、Javaアプリはスキーマを検証できませんでした。（ハーフクレジット）。

私は彼らの要件の意図に同意することができますが、環境変数の彼らの提案は悪い提案だと思います。彼らは環境変数を最小公分母と見なし、すべてのプラットフォームで利用できるため、環境変数を選択しましたが、実際にはすべてのプラットフォームで利用できるとは限りません。部分信頼Webアプリ（共有ホスティングプラットフォームで一般的）で実行している場合は、環境変数を取得/設定するためのアクセス権がない可能性があります。

環境変数はマシンごとに設定されます。実稼働環境の構成を変更する必要がある場合は、すべてのサーバーに対して1か所で一度変更したいと思います。環境変数ではそれができません。

すべての開発者がアクセスできるシークレットをバージョン管理に保存したくないという彼らの指摘はわかりますが。構成をバージョン管理することには間違いなく利点があります。構成の変更により実稼働環境がダウンした場合、「何が変更されたのか」を簡単に尋ねることができます。誰かが本番マシンにSSHで接続し、環境変数を設定するだけで残された監査証跡は、追跡するのがそれほど簡単ではない場合があります。そうは言っても、バージョン管理の残りの部分と同じ部分に構成ファイルを保存しないことがよくあります。必要な人だけがアクセスできるように、セキュリティが制限されているフォルダに入れました。おそらくそれをさらに一歩進めて、別のプロジェクトに入れることができます。

私は、彼らがファイルに構成を入れないという彼ら自身の規則に違反していることに賭けたいと思います。例えば。彼らのホームページの最初の箇条書きは、「プロジェクトに参加する新しい開発者の時間とコストを最小限に抑えるために、セットアップの自動化に宣言型フォーマットを使用する」です。どこのファイルにもあるはずのないすべての構成設定は、シェフのレシピに含まれているに違いありません。自動化の目標を達成するには、それらをどこかのファイルに永続化する必要があります。そして、シェフのレシピを正しく取得するために多くの時間を費やした誰かが、それをバージョン管理のどこかに保存しなかったとしたら、私は驚きます。

彼らは構成ページを別の方法で記述し、構成をコードから分離しておくと言っただけかもしれないと思います。別のファイルに保存し（コードに埋め込まないでください）、別の場所に保存します（同じリポジトリに配置しないでください）。デプロイメントプロセスでは、これらを1つのデプロイ可能なパッケージ（コードと構成）に戻しますが、それまでは別々にする必要があります。

構成についての私の提案は、構成を「接続されたリソース」として扱い、それをバッキングストア（データベース）に保存することです。これにより、アプリの階層がさらにステートレスになります。これは、もう1つの目標です。

于 2012-06-28T18:23:38.787 に答える
5

私が少しナイーブだと思うデザインには多くの問題があります。

たとえば、Backing Services セクションでは、コードの変更に関係なくデータストアを交換できるはずだと述べています。

問題は、特定のデータ ストアのパフォーマンスと機能の利点を活用するために、最初に使用したスト​​アの特定の機能を利用することに自然と引き寄せられることです。

さらに、すべてのデータストアが、あるデータストアから別のデータストアに簡単に移動できるような共通のコマンド セットをサポートしているわけではありません。MySql または CouchDB を使用した彼らの特定の例は興味深いものです。なぜなら、これら 2 つの DB システムは概念的に非常に異なっているからです。1 つは従来の RDBMS に近く、もう 1 つはドキュメント ベースです。テーブル構造を取得して CouchDB に直接適用し、SQL コマンドをスローすることを期待することはできません。

つまり、Web サービスとして公開された一連のコマンドで特定のデータストアを本質的にラップするために、フロント エンドを配置する必要があります。

現在、同様のサーバー (ローカルの mysql) をリモートのサーバー (Amazon RDS) に交換することに制限している場合、URL を介してデータストア リソースにアクセスするという要件は重要ではありません。さらに、別のサーバーで正確な DB を実行することをサポートするためだけにコードを変更する必要がないため、その移動に対してコードを変更しないという要件は不要です。

上記は、私が正直に見た最初の領域です。John Saunders が言ったように、config 1 は .Net のような技術の理解が完全に欠如していることも示しています。率直に言って、全体はしばらくの間 Ruby の世界にいて、他に何があるかを見ていない誰かによって書かれたように見えます。

于 2012-06-29T01:55:10.930 に答える
0

Microsoft Windows プラットフォームで彼らのガイダンスに従うには、プラットフォームを深く理解している必要があると思います。

3 番目の要素である構成を環境に保存するという提案についてのご意見に従い、Windows プラットフォームの環境変数とは正確には何なのかを自問する必要があります。答えは Windows レジストリです。現在、私は Windows レジストリを利用するサーバー アプリケーションの開発に本業で取り組んでおり、自分の役割 (継続的インテグレーション、ビルド、およびインストーラーに関心があります) を考えると、私たちがしなければならない復讐心で本当に嫌いです。 Windows レジストリを使用しますが、これは Windows プラットフォームで行うことです。

Windows レジストリは、言語や OS に依存しない標準では明らかに機能しませんが、Windows プラットフォームでは、Windows レジストリ キーに実装されているプレーンなバニラ環境変数を使用する場合でも失敗します。

私は時々、資格情報を SCM (ちなみに、近年は主に TFS) に保存するという罪を犯しますが、アプリケーション自体、主にビルド​​ インフラストラクチャ (つまり、決してデプロイされないもの) に対しては決して行いません。アプリケーション コードから完全に分離されている)。

app/web.config を使用して資格情報を保存することもできます (暗号化機能もあります) が、一般的にはお勧めできません。

また、データベースをバックエンド (リレーショナル、非リレーショナル、実際にはあらゆる種類のデータベース) として使用する場合、一部の構成はそこに保存される可能性があり、一部の構成はそこに格納するのにさらに適している場合があります (つまり、マルチテナント アプリケーション)。 、テナント関連の構成を分離したいと本当に思っており、多くの場合、共有された構成はテナント 0 の特別なストアにまとめられてしまいます)。そこのあなた。

2 番目の質問については、12factor マニフェストには不慣れなため (ただし、基本的な概念ではなく、これまで読んだことから)、現時点で .Net の参照アーキテクチャについて提案することはできません。

2番目の質問に関する更新

また、もう 1 つの質問については、2 番目の要因である依存関係が、文字通り厳密なアプローチを取ると、Microsoft プラットフォームで適切なリファレンス実装を見つけるのを妨げる可能性があると言えます。

Windows インストーラーや高レベルのインストール オーサリング ツール (Wix、InstallShield など) のようなものは、RubyGems や CPAN に匹敵するものではなく、NuGet はまだ普及していません。

作成者が 12factor を知らなかったとしても、マニフェストがかなり賢明なことを要求している場合でも、NuGet フィードを参照して参照実装を探すことができます。優れた開発者はほとんどそれらまたはかなり類似した概念に従っています。

このアプローチの例として、AyendeのRavenDBを参照することをお勧めします。NuGetを介して取得することができます。すべてではないにしても、ほとんどの 12factor ガイ ボックス ( intro、features、およびsourceコード）。

于 2012-06-29T09:47:37.677 に答える