Clever Geek Handbook

HOCON-柔軟に構成可能





テキストコンフィグにプログラムパラメータを保存することは、かなり頻繁で一見些細な作業です。 多くはすぐに不平を言う：問題は何ですか？ プロパティ、XML、JSON、YAMLなど、多くの形式（およびそれらを操作するためのライブラリ）があります。 あなたが望むものは何でも-それだけです。 ビジネス何か。



ただし、スケールにより、異なる見方が必要になります。 特に、長年Javaでゲームサーバーを開発してきた後、私は徐々に構成の管理はそれほど一般的ではないという結論に達しました。 この記事では、HOCON形式について説明します-HOCON形式が提供する機会と、前回のプロジェクトでHOCON形式を使用し始めた理由について説明します。 具体的には、Javaで記述されたオープンソースライブラリであるTypesafe Configを使用します。



HOCONはJSONベースの構成ファイル形式です。 JSONと比較して、この形式はそれほど厳密ではなく、追加機能があります。 



{ //    "a" : 42 //       b: hello //    }


ただし、HOCONの中心的な価値は、変数の値とJSONオブジェクト全体をコピーすることです。 



 { a: 42 b: ${a} //   b   a c : { m1 : 1 m2 : 2 } d : ${c} { //   d   c m3 : 3 //   d  m3 = 3 } }


もちろん、これはクールです、読者はここで言うでしょうが、なぜ私はそれを必要としますか？ 単純なJSONまたはXMLで構成を保存するのではなく、なぜこの庭全体に煩わされるのですか？ この合理的な質問に答えるために、私たちの実務からの2つの例を共有します。



例1.管理者の生活から



ゲームサーバーを開発しています。 また、ゲームサーバーは、要件に応じて、異なるハードウェアセットおよび異なるレイアウトで実行できるサービスの動物園です。 例として、過去のプロジェクトの1つからホストごとにサービスのレイアウトの図を示します。







そしてもちろん、これらすべてのサービスについては、パラメーター全体を構成する必要があります。あらゆる種類のネットワークアドレス、データベース名、ユーザー、アクセスがあり、神は他に何を知っていますか。 これらのパラメーターは約100500です。



たとえば、3つのサービスs1、s2、s3があり、IPアドレスを構成する必要があるとします。 



 { s1 : { ip: “192.168.10.1” } s2 : { ip: “192.168.10.1” } s3 : { ip: “192.168.10.1” } }


多くの場合、これらのサービスは同じホストで実行され、同じIPアドレスを持っています。 そして、IPアドレスを変更するとき、設定をあちこちに移動して、どこでも変更したくありません（3つではなく、100,500であることに注意してください）。 どうする？ 設定を通常のJSONに保存する場合、一般的なhost_ipパラメーターを作成して、次のように記述できます。 



 ip = config.getValue(“s1.ip”); if ( ip == null ) { ip = config.getValue(“host_ip”); }


ただし、このソリューションには重大な欠点があります。



  1. サービス開発者は、この特定のケースについてそれを予見しないかもしれません。
  2. このロジックは、構成を構成する管理者には隠されています。 s1.ipパラメーターが指定されていない場合、host_ipパラメーターから取得されることを彼はどのように知っていますか？ 多数のパラメーターがあり、それらがしばしば同様のトリックを実行する場合、管理者で心臓発作が発生する可能性があります（そして彼の影は夜に開発者に現れます）。


HOCONでは、ソリューションは完全に透過的です。 



 { host_ip: “192.168.10.1” s1 : { ip: ${host_ip} } s2 : { ip: ${host_ip} } s3 : { ip: ${host_ip} } }


例2.開発者の生活から



開発中、新しいサーバーを最初からデプロイするタスクはそれほど珍しいことではありません。 新しいブランチを作成しました。 新しいプログラマーを雇った。 古いハードドライブが飛行し、すべてを再インストールする必要があります。 ローカルサーバーもすべてのサービス（一度に1つ）を備えた本格的な動物園なので、もちろん、毎回ゼロから構成を構成するのは望ましくありません。 これにより、コードとともにバージョン管理システムに共通の構成を保存するオプションが必要になり、ローカルサーバーを展開する場合は、その中のホストIPのみを変更します。 さて、前の例のソリューションを使用しましょう。 



 { host_ip: “192.168.10.1” s1 : { ip: ${host_ip} } s2 : { ip: ${host_ip} } s3 : { ip: ${host_ip} } }


しかし、ここに問題があります：一般的な設定はバージョン管理システムの下にあります！ host_ipを変更すると、多くの不便が生じます。diffは常にハングしているため、他の人が行った変更をマージする必要があります。 誤ってhost_ipを一般バージョンにコミットすることは禁じられています。 一般的な設定を別の場所に保存して、適切な場所に置くこともできます。 しかし、他の開発者によってバージョンに加えられた変更は、どのようにしてそこに到達しますか？



そして、ここでincludeディレクティブが助けになります： 



 { host_ip: “127.0.0.1” //      s1 : { ip: ${host_ip} } s2 : { ip: ${host_ip} } s3 : { ip: ${host_ip} } include “local_config.conf” //     local_config.conf }


そして、メインの設定ファイルの隣に、次の内容のlocal_config.confファイルを追加します。 



 { host_ip: “192.168.10.1” //  IP    }


local_config.confファイルはバージョン管理システムによって無視され、競合は発生しません。



おわりに



考慮されるユースケースは、実際の開発から取得されます。 そしてもちろん、HOCONの可能性はそれらに限定されません。 実際、HOCONは単なるテキスト形式ではなく、構成用の高度に特化したスクリプトであり、管理者と開発者の生活を大幅に簡素化できます。



ここでは、詳細な説明は特にしませんでした。すべてが公式ガイドに完全に記載されています 。 このライブラリを使用する独自の注目すべきケースがある場合は、コメントで共有してください！


More articles:


All Articles