Azure設定のベストプラクティス？

Question

Azureの移行を開始したときに、web.configの設定をAzureの設定.cscfgファイルに移行しました。

私はすぐに設定をハックすることができるので、これはうまくいくものの、テスト環境では便利ですが、これは生産上かなり危険です。設定をすばやくハックすることができます。

より正式には、Azure管理コンソールへのアクセス権を持つすべての人が、実稼働のAzureインスタンスに制御されない変更を加えることは容易であることを意味します。

これは私を非常に悪くします。

実際には、.cscfgファイルの背後にある任意のユーティリティが標準の診断文字列の設定を超えていますか？

Answer 1

我々はテストで.cscfgファイルの柔軟性が好きで、私たちテスト環境は、本番環境の正確なレプリカからいくつかの設定の差異を差し引いたものでなければならないと考えているため、テストとプロダクションのコードベースがわずかに異なることは望ましくありません。

同時に、間違った展開を間違って削除したり、間違った.cscfgファイル/値を変更したりする開発者がいます。この問題を解決するために、テスト用とプロダクション用の2つのサブスクリプションを作成しました。すべての開発者にテストサブスクリプションへのアクセス権を付与しますが、導入担当者のみがプロダクションサブスクリプションにアクセスできます。

デプロイメントエンジニアは、運用環境（インスタンスの再起動/再イメージ化、デプロイメントの削除など）でできることとできないことを正確に把握しています。プロダクションで触れる唯一の.cscfg値は "インスタンス数"プロパティです（ビルドサーバーは他のプロダクション.cscfg値をすべて設定します）。

これまでのところ、この設定は非常にうまく機能しています。

Answer 2

セキュリティ&コンプライアンスポリシーに応じて、あなたはおそらくAzureストレージまたはSQL Azureの中のすべてのアプリ-設定を収容するために、カスタムアプリ・設定・ソリューションを持っているしたい場合は...

余分なものは何もありません「推奨「私が最近http://www.paraleap.com/blog/post/Managing-environments-in-a-distributed-Azure-or-other-cloud-based-NET-solution.aspx

@公開したブログのエントリをチェックし、Visual Studioで環境間の切り替えを容易にするため...

アプリの設定は、/ Oの再配備ワットの変化のために利用できるように持っていることが非常に有用です

Answer 3

引き続きweb.configを使用できますAzureでは設定が不可能な設定をしたいと思っています。私たちは、2 ...

この場合はそれほど設定不可

を組み合わせて、あなたがそれらを変更するために再デプロイする必要がありますを意味します...

Answer 4

Azure Management Consoleへのアクセスを制限するだけで、すべての問題を本当に使用できます。配備が必要な人が複数いる場合は、Azure管理コンソールにアクセスする代わりに、使用する証明書を作成するだけで済みます。

実際に私たちのビルド環境では、本番環境にデプロイするときに構成ファイルを再構成しています。これにより基本的に管理UIに入る必要がなくなり、構成は常に同じになります。