こんにちは、

既存のSolrインスタンスをKubernetesに移行する必要があります。

Dockerfileを作成して

1. コアを作成
2. データをロード
3. Solrを実行
   することを試みています。

既存の設定からコアを作成し、以下のコマンドで実行することはできました。
"docker run -v myconf:/myservice solr:6.6 -c myservice -d /myservice"

しかし、そのコンテナを新しいイメージに保存し、それをKubernetesで再利用するのは避けたいです。

これは一般的なユースケースだと思いますが、以下のリンクでは何も見つかりませんでした。
https://github.com/docker-solr/docker-solr

何か助けになる情報があれば感謝します！

Bjørn Larsen

こんにちは！

スタンドアロンSolrからKubernetes上のSolrCloudセットアップに移行を検討しているとのことですね。Kubernetes環境でConfigSetsやコレクションの管理方法について質問されていますが、確かに一つの解決策として、管理プロセスを導入する方法が考えられます。例えば、bashスクリプトを使用して、ZooKeeperサービスに対してConfigSetsをアップロードし、Solrサービスを経由してコレクションをリロードまたは作成するというアプローチです。このプロセスは、すべてのSolrポッド（およびZooKeeper）が起動して準備が整った後に実行されるべきでしょう。

このようなアプローチで十分機能しますが、他の方法を使用しているかもしれないユーザーもいますので、他の手法についても共有してもらえると参考になるかもしれません。

よろしくお願いします、
Dmitrii Fitisov

みなさん、

現在、私たちはアプリケーションでSolr Cloud（Solrバージョン8.6.3）を使用しています。マスター・スレーブのSolrアプローチを使用していないため、私たちのSolrノードのいずれにもレプリケーションハンドラを設定していません。
以下の脆弱性が私たちにも適用可能かどうかを誰か確認していただけますか？

CVE-2021-27905 Apache Solr ReplicationHandler/SSRF vulnerability
説明：Apache Solrの8.8.1までのバージョンで重大な脆弱性が見つかりました（CVSS 9.8）。この脆弱性の影響を受けるのは、/replicationファイル内の未知のコードブロックです。masterUrl/leaderUrlの引数を不明な入力で操作すると、特権昇格の脆弱性が発生する可能性があります。 *注：CVE-2021-27905（Apache Solr <= 8.8.1 SSRF）、CVE-2017-12629（SSRF経由のリモートコード実行）、およびCVE-2019-0193（DataImportHandler）を対象としたPOCが今後も登場する予定です。また、Apache Solr Velocity RCE用のMetasploitモジュールと、2つのApache OFBizの脆弱性もあります。脆弱性の数、深刻さ、およびPOCの利用可能性を考慮すると、脆弱なシステムはできるだけ早くパッチを適用することが強くお勧めされます。

ありがとうございます
Anchal Sharma

こんにちは皆さん、

私たちはSolr 8.8.2のクラウドセットアップを使用しており、zkアンサンブル3.6.3（3つのzkサーバー）を使用しています。
私たちのHAモニタリングシステムは、solrのURLやシャードの可用性を確認するために5分ごとにpingします。もし問題が発生した場合（solrサーバーがダウンしている場合）、検索をDB検索に切り替えるフラグを立てます。

現在、私たちの問題は、zkホストを渡してsolrに接続しているところです。もし2つのZooKeeperがダウンしていて、solrping.process(client)を呼び出した場合、全てのZooKeeperがダウンしているために処理が長時間実行され、スレッドがスタックしてWebLogicアプリケーションサーバーが遅くなっています。

次のようなメソッドがあります：

private int pingRepo(zkHostList, corename) {
    SolrClient client = SolrConnectionUtil.getSolrClient(zkHostList, “ping”);
    ((CloudSolrClient) client).setDefaultCollection(corename);
    SolrPing ping = new SolrPing();
    SolrPingResponse resp;
    try {
        resp = ping.process(client);
        return resp.getQTime();
    } catch (Exception e) {
        // Exception handling
    }
    return -1;
}

この問題をどのように解決すれば良いか、ご提案いただけますでしょうか？ZooKeeperがダウンしている場合の対処方法について、ご意見をお待ちしております。ありがとうございます。

敬具
Reej

/api/cores や /solr/admin/cores は、それらが呼び出されたSolrインスタンスのすべてのコアの現在の状態に関する非常に有用な情報を返します。

ただし、Solrインスタンスが再起動したばかりの場合、これらの呼び出しは以下のように空の応答を返すか、または現時点でロードされているコアのみを含んだ応答を返します。すべてのコアがロードされるまで待機させる方法はありますか？

空の応答:

{
  "responseHeader": {
    "status": 0,
    "QTime": 150
  },
  "initFailures": {},
  "status": {}
}

部分的な応答:

{
  "responseHeader": {
    "status": 0,
    "QTime": 35
  },
  "initFailures": {},
  "status": {
    "books": {
      "name": "books",
      "instanceDir": "/var/lib/solr/books",
      "dataDir": "/var/lib/solr/books/data/",
      "config": "solrconfig.xml",
      "schema": "schema.xml",
      "startTime": "2022-11-14T20:55:36.571Z",
      "uptime": 4286,
      "index": {
        "numDocs": 0,
        "maxDoc": 0,
        "deletedDocs": 0,
        "indexHeapUsageBytes": 0,
        "version": 4748,
        "segmentCount": 0,
        "current": true,
        "hasDeletions": false,
        "directory": "org.apache.lucene.store.NRTCachingDirectory:NRTCachingDirectory(MMapDirectory@/var/lib/solr/books/data/index lockFactory=org.apache.lucene.store.NativeFSLockFactory@7bae9d87; maxCacheMB=48.0 maxMergeSizeMB=4.0)",
        "segmentsFile": "segments_c1",
        "segmentsFileSizeInBytes": 119,
        "userData": {
          "commitCommandVer": "0",
          "commitTimeMSec": "1658435977333"
        },
        "lastModified": "2022-07-21T20:39:37.333Z",
        "sizeInBytes": 119,
        "size": "119 bytes"
      }
    }
  }
}

上記の例では、booksコアが空で非常にシンプルなため、他のデータが多いコアよりも比較的速くロードされます。

すべてのコアがロードされた最終的な応答には、私の場合は19個のこのようなコアが含まれます。