タグ付けされた質問 「configuration-files」

構成ファイルを使用せずにプログラムでWCFサービスを公開する方法の良い例を誰かが知っていますか？WCFを使用すると、サービスオブジェクトモデルが大幅に機能強化されたので、それが可能であることを知っています。その方法の例を見たことがありません。逆に、構成ファイルなしでの消費もどのように行われるかを確認したいと思います。 誰かが尋ねる前に、私はこれを設定ファイルなしで行う非常に特別な必要があります。私は通常、そのような方法はお勧めしませんが、前述したように、この場合は非常に具体的なニーズがあります。

90 wcf  configuration  configuration-files 

私はしばらくの間、構成ファイルとコードとの関係について検討してきましたが、日によって、風の方向によっては、私の意見が変わったようです。Lispの学習中に最初に得た気づきにどんどん戻っていきますが、データとコードにはほとんど違いがありません。これは、構成ファイルについても二重に当てはまるようです。右から見ると、Perlスクリプトはperlの構成ファイルにすぎません。これは、QAや、構成ファイルの変更を担当する必要がある人のような分業などのタスクにかなり重い結果をもたらす傾向があります。 設定ファイルから本格的な言語へのクリープは一般に遅く、一般的なシステムを作りたいという欲求によって引き起こされているようです。ほとんどのプロジェクトは、ログを書き込む場所、データを検索する場所、ユーザー名とパスワードなどのいくつかの構成項目を備えた小さなものから始まります。しかし、その後、プロジェクトは成長し始めます。機能をオンまたはオフにできるようになります動作のタイミングと順序が制御され始め、必然的に誰かがそれにロジックを追加し始めたいとします（たとえば、マシンがXの場合は10、マシンがYの場合は15を使用します）。ある時点で、設定ファイルはドメイン固有の言語になり、その部分では不十分に記述された言語になります。 準備ができたので、次は私の質問です。 設定ファイルの真の目的は何ですか？ 設定ファイルをシンプルに保つように試みるべきですか？ それらに変更を加える責任は誰にあるべきですか（開発者、ユーザー、管理者など）？ それらはソース管理されるべきですか（質問3を参照）？ 前に言ったように、これらの質問に対する私の答えは常に変化しますが、今は考えています： プログラマーでない人が大きな動作のチャンクを素早く変更できるようにするため はい、ざらざらしていないものはすべてコードに含める必要があります ユーザーは構成ファイルを担当し、プログラマーは構成ファイルとコードの間の構成層を担当して、アプリケーションをより細かく制御する必要があります。 いいえ、しかしより細かい中間層は

90 configuration  programming-languages  configuration-files  config 

PythonのConfigParserモジュールを使用して設定を保存しようとしました。私のアプリでは、セクション内の各名前の大文字と小文字を区別することが重要です。ドキュメントには、str（）をConfigParser.optionxform（）に渡すとこれが達成されると記載されていますが、私には機能しません。名前はすべて小文字です。私は何かが足りないのですか？ <~/.myrc contents> [rules] Monkey = foo Ferret = baz 私が得たもののPython擬似コード： import ConfigParser,os def get_config(): config = ConfigParser.ConfigParser() config.optionxform(str()) try: config.read(os.path.expanduser('~/.myrc')) return config except Exception, e: log.error(e) c = get_config() print c.options('rules') [('monkey', 'foo'), ('ferret', 'baz')]

90 python  configuration-files  python-2.x  configparser 

かなりの数（〜30）の構成パラメーターを必要とするPythonアプリケーションがあります。これまで、OptionParserクラスを使用してアプリ自体のデフォルト値を定義し、アプリケーションを呼び出すときにコマンドラインで個々のパラメーターを変更する可能性がありました。 ここで、たとえばConfigParserクラスの「適切な」構成ファイルを使用したいと思います。同時に、ユーザーはコマンドラインで個々のパラメーターを変更できる必要があります。 2つのステップを組み合わせる方法があるかどうか疑問に思いました。たとえば、optparse（または新しいargparse）を使用してコマンドラインオプションを処理しますが、ConfigParse構文で構成ファイルからデフォルト値を読み取ります。 これを簡単な方法で行う方法はありますか？ConfigParseを手動で呼び出してから、すべてのオプションのすべてのデフォルトを適切な値に手動で設定するのはあまり好きではありません...

89 python  command-line  configuration-files 

VS Ultimate 2015Previewを使用してASP.NET5WebAPIプロジェクトを開発しています。私はこのようにアプリを構成しようとしています（行番号は単なるガイドです）： 1 using Microsoft.Framework.ConfigurationModel; 2 3 public IConfiguration Configuration { get; private set; } 4 5 public Startup() 6 { 7 Configuration = new Configuration() 8 .AddJsonFile("config.json") 9 .AddEnvironmentVariables(); 10 } 8行目でエラーが発生します：「構成」に「AddJsonFile」の定義が含まれていません... なにが問題ですか？

88 c#  configuration  configuration-files  asp.net-core  config.json 

ConfigParserスクリプトのランタイム構成を読み取るために使用しています。 セクション名を指定しない柔軟性が必要です（十分に単純なスクリプトがあります。「セクション」は必要ありません）。例外ConfigParserをスローしNoSectionError、ファイルを受け入れません。 ConfigParserに(key, value)セクション名のない構成ファイルのタプルを単純に取得させるにはどうすればよいですか？ 例えば： key1=val1 key2:val2 設定ファイルには書きたくありません。

87 python  parsing  configuration-files 

バックグラウンド： 現在、サービスにDockerとDockerComposeを使用しています。さまざまな環境の構成を、アプリケーションによって読み取られる環境変数を定義するファイルに外部化しました。たとえば、prod.envファイル： ENV_VAR_ONE=Something Prod ENV_VAR_TWO=Something else Prod およびtest.envファイル： ENV_VAR_ONE=Something Test ENV_VAR_TWO=Something else Test したがって、コンテナを起動するときにprod.envortest.envファイルを使用するだけです。 docker run --env-file prod.env <image> 次に、アプリケーションはで定義された環境変数に基づいて構成を取得しますprod.env。 質問： 次のようにハードコーディングする代わりに、Kubernetesのファイルから環境変数を提供する方法はありますか（ポッドを定義する場合など）。 apiVersion：v1 種類：ポッド メタデータ： ラベル： コンテキスト：docker-k8s-lab 名前：mysql-pod 名前：mysql-pod スペック： コンテナ： - env： - 名前：MYSQL_USER 値：mysql - 名前：MYSQL_PASSWORD 値：mysql - 名前：MYSQL_DATABASE 値：サンプル - 名前：MYSQL_ROOT_PASSWORD 値：超秘密 画像：「mysql：latest」 名前：mysql ポート： - containerPort：3306 …

84 configuration  docker  environment-variables  configuration-files  kubernetes 

大規模で複雑なソフトウェア製品では、構成可能な設定を管理することが大きな問題になります。この問題に対して私が見た2つのアプローチは次のとおりです。 システム内の各コンポーネントに、構成ファイルまたはレジストリ設定から独自の構成をロードさせます。 構成可能なすべてのシステム設定をロードする設定ローダークラスがあり、各コンポーネントに設定ローダーに設定を照会させます。 これらのアプローチはどちらも私には間違っていると感じています。 問題を単純化するために使用できるデザインパターンはありますか？依存性注入手法を利用するものかもしれません。

83 design-patterns  configuration  configuration-files  application-settings 

私は相当を探していますsource .bashrcのための魚。

81 shell  configuration-files  fish