Kubernetes SolrCloudクラスタをGitOps方式で構成/再構成する
コピーリンク
(The bot translated the original post https://lists.apache.org/thread/1mn4xh00p87gg3mbm1ybp62vt4o1xv3v into Japanese and reposted it under Apache License 2.0. The copyright of posted content is held by the original poster.)
こんにちは！
スタンドアロンSolrからKubernetes上のSolrCloudセットアップに移行を検討しているとのことですね。Kubernetes環境でConfigSetsやコレクションの管理方法について質問されていますが、確かに一つの解決策として、管理プロセスを導入する方法が考えられます。例えば、bashスクリプトを使用して、ZooKeeperサービスに対してConfigSetsをアップロードし、Solrサービスを経由してコレクションをリロードまたは作成するというアプローチです。このプロセスは、すべてのSolrポッド（およびZooKeeper）が起動して準備が整った後に実行されるべきでしょう。
このようなアプローチで十分機能しますが、他の方法を使用しているかもしれないユーザーもいますので、他の手法についても共有してもらえると参考になるかもしれません。
よろしくお願いします、
Dmitrii Fitisov
こんにちは！
Kubernetes上でSolrを管理するための公式プロジェクト「Solr Operator」がありますので、自分で実装する代わりに、それをチェックしてみてもよいかもしれません。
また、以前はSolrのイメージをベースにカスタムDockerイメージを作成し、ConfigSetsをその中に配置して、Solrの起動時にスクリプトを使ってアップロードしていました。このスクリプトはdocker-entrypoint-initdb.dフォルダに置いていました。この方法を使うことで、イメージとConfigSetsをバージョン管理に組み込むことができました。
--ufuk yilmaz
ありがとうございます！Solr Operatorを確認しましたが、良い方法のようですね。
イメージ内のスクリプトからのアップロードについてですが、何かロック機構を実装しましたか、それとも1つのインスタンスにその作業を「割り当てる」ようにしましたか？
よろしくお願いします、
Dmitrii Fitisov
こんにちは！イメージ内からスクリプトをアップロードする際には、ロック機構を実装したり、特定のインスタンスに割り当てたりはしませんでした 🤔。最初に実行された際にconfigsetがすでにアップロードされている場合、それ以降の実行では「configsetはすでに存在します」というエラーメッセージが記録され、そのままプロセスが進みます。ただ、最初の実行時に2つのSolrポッドが完全に同時に起動して競合する可能性があるかどうかはわかりません。私の推測では、Zookeeper自体がその状況を処理してくれると思います。
--ufuk yilmaz
トピックへ返信するには、ログインが必要です。