グローバルエンタープライズプロパティはどこに保存しますか？
Javaアプリケーションの群集に直面しています。これらのアプリケーションには、操作にさまざまなグローバルなエンタープライズ全体のプロパティが必要です。たとえば、セントラルRDBMSのホスト名、セントラルセルフサービスポータルのホスト名と場所、中央LDAPのホストの場所、中央メールサーバーのホストの場所など.
正式には、このすべてのプロパティが定義されているプロパティファイルを使用して、各アプリケーションを構築します。しかし、メールサーバーのホスト名が変更された場合、各アプリケーションのプロパティファイルを変更してすべてのアプリケーションを再度デプロイする必要があるため、これは非常に悪いソリューションです。
私たちのアイデアは、このプロパティを一元化して、各アプリケーションが実行時に各プロパティを要求できるようにすることです。次に例を示します。
アイデア：プロパティファイルを簡単にアクセスできるファイル共有に配置します。したがって、プロパティを変更する必要がある場合、各アプリケーションは新しいプロパティを使用します。
アイデア：プロパティをデータベースに入れます。主な欠点：各アプリケーションのデータベースクライアントライブラリへの依存関係が必要です。
アイデア：アプリケーションごとにシステムプロパティを提供する1つの大きなアプリケーションサーバーにすべてのアプリケーションを配置します。主な欠点：各アプリケーションを1つのアプリケーションサーバーに展開する必要があります。しかし、それは現実的なシナリオではありません。
アイデア：グローバルな企業全体のプロパティを提供するWebサービス。主な欠点：一部のプロパティはパスワードまたはユーザー資格情報であるため、あまり安全ではありません。
他にどのような代替案が推奨されますか？最先端技術とは何ですか？
主に3つの異なるアプローチがあります。
- アプリケーションに毎回構成をプルさせる。
- 構成が変更されたときにアプリケーションに構成をプッシュするツールがあります。
- 設定が変更されないことを確認してください。
昇順の優先順。そう
3.構成が変更されていないことを確認します。
これは推奨オプションです。変更する必要のないすべてのものに適切なエイリアスを作成します。
メールサーバーのドメイン名は変更しないでください。ホストはできますが、mail.company.comまたはmail.inranetをリダイレクトするだけです1 新しいホストに。他のすべてのネットワークロケーションにも同じことが当てはまります。それらに適したDNS名を作成するだけです。同じことがdatabase.company.com、ldap.company.com、self-service.company.comなどにも当てはまります。各WebサービスとWebアプリケーションにも独自のvhostが必要なので、依存するアプリケーションを変更せずにそれぞれを個別に移動できます。
ホスト名が変更される唯一のケースは、たとえばデータベースサーバーを2つの別々のデータベースに分割したときに、異なるアプリケーションを異なるように構成する必要がある場合です。そのため、中央構成はいずれにしても役に立ちません。
同様に、各アプリケーションは、アプリケーションとして名前が付けられ、アプリケーションが必要とする操作のみに制限された、データベースへの個別のアカウントを持つ必要があります。これは、一部のアプリケーションが侵害された場合の損害を最小限に抑えるためのセキュリティ上の理由によるものです。副作用として、頻繁に変更する必要のない独自のユーザー名とパスワードを各アプリケーションに提供するため、中央構成の理由がなくなります。全く反対。各パスワードのある場所の数を制限して、誰かがクラックしたときに他のアプリケーションとそのアカウントが侵害されないようにする必要があります。
ある意味では、これは共有構成ですが、DNSサーバーに格納されています。 DNSには他にもさまざまな情報を保存できることを忘れないでください。サービスが実行されるポートを記録するためのSRVレコード、さまざまな種類の暗号化キーを格納するためのレコードなどがあります。
2.構成をアプリケーションにプッシュするツールを用意する
さまざまな 構成管理ソフトウェア があります。これらは、ソフトウェアのインストールとネットワーク全体の構成の展開を行うツールです。重要なネットワークでは、ネットワークを使用して、セキュリティ更新プログラムを確実にインストールする必要があります。
ある場合は、適切なルールを追加して、アプリケーションを実行するすべてのサーバーにプロパティファイルをデプロイします。そうでない場合は、1つ選択してください2 同じことを行い、セキュリティ更新を処理するように構成します。
これらのツールは、新しい構成をデプロイするときや、構成をリロードする必要があることをアプリケーションに通知するときに、アプリケーションサーバーの再起動も処理できることに注意してください。
したがって、これは良いオプションです。このようなツールは、ネットワークの管理に非常に役立つためです。
3.アプリケーションに構成をプルさせる。
これには、事前に各アプリケーションを変更する必要があります。とにかく、鶏と卵の問題に悩まされているため、問題は完全には解決しません。残りの構成をプルする場所を構成する必要があります。
ファイル共有は、各アプリケーションへの変更のサイズに関して明らかに最も簡単です。アプリケーションも再起動するか、構成が変更されたときにアプリケーションに通知するメカニズムを実装する必要があることを覚えておいてください。これもソリューションの有用性を低下させます。
だから私は間違いなくお勧めしませんこのアプローチの元のオプションはすべてバリエーションです。
1内部ネットワークで存在しない任意のトップレベルドメインを使用でき、会社名が変更された場合でも変更する必要がないという利点があります。 mDNS用に予約されている.localは使用しないでください。
2または、システム管理者に依頼してください。彼らはそれと最も相互作用する人です。
最後のアプローチに関連して、Webサービスを使用します。 Apache Zookeeper を確認することをお勧めします。そのドキュメントから：
ZooKeeperは、構成情報の維持、命名、分散同期の提供、およびグループサービスの提供のための集中型サービスです。
このアプローチのセキュリティへの影響を恐れるのは正しいことです。 ZookeeperはHadoopエコシステムに由来するため、その本来の目的は、Hadoopクラスター、およびHadoopと対話する他のサービス（Hive、HBaseなど）の構成の同期を提供することでした。
IMHO、Hadoopは、これらのサービスすべてが信頼できる環境で機能することを期待していたため、セキュリティを意識したことはありませんでしたが、その点で改善されており、ZKを検討するオプションになる可能性があります。シークレットをすべて公開する前に authentication and authorization を実行するようにZKを設定できますが、これらのオプションはデフォルトで無効になっているようです。