searchmysite.net

検索マイサイト.net

このリポジトリには、https://searchmysite.net/ の完全なコードベースが含まれています。これは、独立したオープン ソースの検索エンジンであり、個人および独立した Web サイト向けのサービスとしての検索です (searchmysite.net の詳細については、「searchmysite.net について」を参照してください)。

このリポジトリを使用して次のことができます。

• searchmysite.net がどのように機能するかを正確に確認します。たとえば、インデックス作成、関連性の調整、検索クエリなどのコードを検査します。
• たとえば、問題を報告したり、改善を提案したり、修正や機能拡張を実装したりして、searchmysite.net サービスの改善に協力してください。 「貢献」を参照してください。
• 独自のインスタンスをセットアップして、インターネットの別の部分に対して完全にオープンで独立した検索を提供します。

ディレクトリ構造と docker-compose ファイル

アプリケーションは 5 つのコンポーネントに分割されており、それぞれが独自の Docker コンテナーにデプロイされます。

• db - Postgres データベース (サイトとインデックス構成の管理用)
• インデックス作成 - Scrapy Web クローラーと一括インポート スクリプト (サイトのインデックス作成用)
• モデル - 大規模言語モデル (LLM) を備えた TorchServe コンテナー
• search - Apache Solr 検索サーバー (実際の検索インデックス用)
• web - mod_wsgi Web サーバーを備えた Apache httpd、静的アセット (ホームページを含む)、および動的ページ (API を含む)

プロジェクトのディレクトリ構造は次のとおりです。

 .
├── data                    # Data for Docker data volumes (not in git - to be set up locally)
│   ├── solrdata            # Mounted to /var/solr/solrdata in Solr Docker
│   ├── sqldata             # Mounted to /var/lib/postgresql/data in Postgres Docker
├── src                     # Source files
│   ├── db                  # Database scripts
│   │   ├── bulkimport      # Scripts to load sites into the database for the indexer to index
│   ├── indexing            # Indexing code
│   │   ├── bulkimport      # Scripts to load content directly into the search engine
│   │   ├── common          # Indexing code shared between bulk import and spider
│   │   ├── indexer         # Spidering code
│   ├── models              # Language models
│   ├── search              # Search engine configuration
│   ├── web                 # Files for deployment to web / app server
│   │   ├── config          # Web server configuration
│   │   ├── content/dynamic # Dynamic pages and API, for deployment to app server
│   │   ├── content/static  # Static assets, for deployment to static web server
├── tests                   # Test scripts
└── README.md               # This file

3 つの docker-compose ファイルがあり、次の点を除いてほとんど同じです。

• docker-compose.yml (ローカル開発用) は、ソースから読み取るように Web サーバーとインデックス付けを構成するため、コードを変更しても再構築は必要ありません。
• docker-compose.test.yml (テスト スクリプトの実行用) はデータベースと検索を永続化せず、スケジュールされたインデックス作成も実行しないため、各テスト サイクルはクリーンで予測可能な環境で開始できます。
• docker-compose.prod.yml (運用環境用) はデータベースと検索を永続化し、Web サーバーとインデックス コードをコピーします。

開発環境のセットアップ

前提条件

Docker がインストールされていることを確認します。

たとえば、ソースコードを取得します

 cd ~/projects/
git clone https://github.com/searchmysite/searchmysite.net.git

データベースと検索インデックスのデータ ディレクトリを作成します。

 cd ~/projects/searchmysite.net/
mkdir -p data/solrdata
mkdir -p data/sqldata
sudo chown 8983:8983 data/solrdata

少なくとも以下を含む docker-compose.yml の ~/projects/searchmysite.net/src/.env ファイルを作成します。

 POSTGRES_PASSWORD=<password>
SECRET_KEY=<secretkey>

POSTGRES_PASSWORD と SECRET_KEY には、ローカル開発用に選択した任意の値を指定できます。基本的なアプリケーションが動作するために必要な値はこれらのみですが、追加機能のために設定する必要がある他の値があることに注意してください。以下の「追加の環境変数」セクションを参照してください。

最後に、Docker イメージをビルドします。

 cd ~/projects/searchmysite.net/src
docker compose build

最初のビルドには 20 ～ 30 分かかる場合があり、モデル コンテナーは 3 GB のモデル ファイルをダウンロードすることに注意してください。

開発環境を開始する

前提条件が整ったら、次の方法で開発環境を開始できます。

 cd ~/projects/searchmysite.net/src
docker compose up -d

Web サイトは http://localhost:8080/ で、Apache Solr 管理インターフェイスは http://localhost:8983/solr/#/ で利用できます。

管理者ログインの設定

基本リストとして追加されたサイトを承認または拒否できるようにするには、1 人以上の管理者ユーザーを設定する必要があります。認証済みのサイト所有者、つまり完全なリストがあり、ログインできるサイト所有者のみが、管理者ユーザーとして許可されます。 Web インターフェイスを使用して、[サイトの追加] で独自のサイトを完全なリストとして追加したり、詳細をデータベースに直接挿入したりできます。

1 人以上の確認済みサイト所有者がいる場合は、データベース内で管理者として許可できます。例:

 INSERT INTO tblPermissions (domain, role)
  VALUES ('michael-lewis.com', 'admin');

他の Web サイトを追加する

「サイトの追加」を使用すると、Web インターフェース経由で 1 つまたは複数のサイトを基本リストとして追加できます。管理者ユーザーとしてログインし、[レビュー] をクリックして、インデックス作成のキューに追加されるように [承認] を選択する必要があります。

src/db/bulkimport には一括インポート スクリプトもあります。 checkdomains.py は、ドメインまたはホームページのリストを入力として受け取り、それらが有効なサイトであること、およびリストまたはデータベースにまだ存在していないことを確認し、insertdomains.py が挿入するファイルを生成します。

#91 の議論も参照してください。

追加の環境変数

電子メールを送信する機能 (連絡先フォームなど) を使用したい場合は、次の値を設定する必要があります。

 SMTP_SERVER=
SMTP_PORT=
SMTP_FROM_EMAIL=
SMTP_FROM_PASSWORD=
SMTP_TO_EMAIL=

テストするだけの場合は、Web ベースの電子メール アカウントを作成し、それに SMTP の詳細を使用できます。

検証済みの送信に対して支払いメカニズムを有効にする場合は、次のように設定する必要があります。

 ENABLE_PAYMENT=True
STRIPE_SECRET_KEY=
STRIPE_PUBLISHABLE_KEY=
STRIPE_PRODUCT_ID=
STRIPE_ENDPOINT_SECRET=

テストのみの場合は、Stripe からテスト アカウントを取得できます。

ローカル開発者に変更を加える

ウェブの変更

開発用の docker-compose.yml は、ソースから読み取るように Web サーバーを構成するため、ソースに変更を加えてリロードできます。通常、変更を表示するには Web サーバーを再起動する必要があります。

 docker exec -it web_dev apachectl restart

頻繁に変更を行う場合は、Docker の外部の Flask 開発環境を使用することをお勧めします。

これを行うには、まず、「db」、「models」、および「search」のローカル ホスト エントリを、つまり /etc/hosts に設定する必要があります (「web」コンテナが db、models、および search コンテナと通信する場合) 「db」、「models」、および「search」ホスト名経由）:

 127.0.0.1 search
127.0.0.1 db
127.0.0.1 models

次に、Flask と依存関係をローカルにインストールし (mod-wsgi には apache2-dev が、psycopg2 には libpq-dev が必要であることに注意してください)、searchmysite パッケージを編集可能モードでインストールします (これらの手順は 1 回だけ実行する必要があります)。

 sudo apt install apache2-dev libpq-dev
cd ~/projects/searchmysite.net/src/web/
pip3 install -r requirements.txt
cd ~/projects/searchmysite.net/src/web/content/dynamic/
pip3 install -e .

最後に、すべての開発セッションの開始時に、環境変数をロードし、次のようにして開発モードで Flask を起動します。

 set -a; source ~/projects/searchmysite.net/src/.env; set +a
export FLASK_ENV=development
export FLASK_APP=~/projects/searchmysite.net/src/web/content/dynamic/searchmysite
flask run --debug

ローカルの Flask Web サイトは、たとえば http://localhost:5000/search/ で利用できます (ホームページ、つまり http://localhost:5000/ は動的に提供されないため、Flask 経由では利用できないことに注意してください) 。コードへの変更はサーバーを再起動しなくても反映され、デバッグ ログ メッセージが表示され、エラーが発生した場合には完全なスタック トレースがより見やすくなります。

インデックスの変更

Web コンテナーと同様、開発上のインデックス作成コンテナーはソースから直接読み取るように構成されているため、変更を保存するだけで済みます。

通常は、次のような SQL を実行してインデックスの再作成をトリガーします。

 UPDATE tblDomains 
  SET  full_indexing_status = 'PENDING'
  WHERE domain = 'michael-lewis.com';	

次の src/indexing/indexer/run.sh を待つか (開発時は最大 1 分)、または手動でトリガーします。

 docker exec -it src-indexing-1 python /usr/src/app/search_my_site_scheduler.py 

手動でトリガーしてスケジュールされたジョブが実行される場合、複数のスケジューラーを同時に実行しても問題はありません。

次の方法でインデックス作成ログを監視できます。

 docker logs -f src-indexing-1

src/indexing/indexer/settings.py で LOG_LEVEL を DEBUG に変更できます。

検索（Solr）の変更点

dev Solr docker コンテナはビルド時に構成をコピーするため、構成を変更するたびにdocker compose buildが必要です。

solr-precreate content /opt/solr/server/solr/configsets/content docker compose build後に実際には新しい構成をロードしないことに注意してください。そのため、Solr 構成の変更を適用するには、次の手順が必要です。

 docker compose build
docker compose up -d
docker exec -it search_dev cp -r /opt/solr/server/solr/configsets/content/conf /var/solr/data/content/
docker restart search_dev

変更によっては、インデックス内の一部またはすべてのデータを削除する必要がある場合もあります。

 curl http://localhost:8983/solr/content/update?commit=true -H "Content-Type: text/xml" --data-binary '<delete><query>domain:michael-lewis.com</query></delete>'

上記のようにインデックスの再作成をトリガーします。インデックス内のすべてのデータを削除するには、 <query>*:*</query>を使用します。

data/solrdata ディレクトリを削除して再作成し、再構築して新たに開始することもできます。

データベース (Postgres) の変更

次の方法でデータベースに接続できます。

  "host": "127.0.0.1",
  "user": "postgres",
  "port": 5432,
  "ssl": false,
  "database": "searchmysitedb",
  "password": <password-from-dotenv-file>

スキーマの変更は src/db/sql/init* ファイルに適用する必要があるため、data/sqldata ディレクトリを削除して再作成すると、最新のスキーマが適用されます。

関連性の調整

関連性チューニングの基本的な実験として、手動でいくつかのサイトを追加し、それらを試してみることができます。 Indexed_inlink_domains_count はスコアリングの重要な要素であるため、これらのサイト間にリンクがあることを必ず確認してください。また、indexed_inlink* 値を正しく設定するには、サイトのインデックスを 2 回作成する必要がある場合があることにも注意してください。インデックス作成プロセスでは、indexed_outlink* 値から Indexed_inlink* 値が設定されるため、すべてのサイトに Indexed_outlink* 値が設定されていることを確認するための最初のパスが必要です。

ただし、関連性を大幅に調整する場合は、運用環境の Solr コレクションの復元を使用することをお勧めします。これに興味がある場合は、お知らせください。最新のものを用意します。

関連性スコアリングで使用される新しいフィールドを Solr スキーマに追加する場合は、すべてのサイトにこれらのフィールドが追加されるまで待ってから、新しい関連性スコアリングの変更を展開することをお勧めします。これを行うには 2 つの方法があります。すべてのサイトのインデックスを強制的に再作成するか、すべてのサイトのインデックスが自然に再作成されるまで待つことです。インデックスが自然に再作成されるまで待つほうが簡単かつ安全です。再インデックスが 20 個のバッチで行われ、一部のサイトではインデックスの再作成に 1 時間以上かかることを考えると、強制的にすべてのインデックスを再作成するには 24 時間以上かかる可能性があります。一方、自然な再インデックスでは、検証済みのすべてのサイトのインデックスが確実に再作成されるまでに 3.5 日かかります (検証済みのサイトの場合は 28 日)。未検証のサイト）。

テスト

テストはローカルの Flask インスタンスで pytest を使用して実行されるため、上記の「ローカル開発での変更」/「Web の変更」セクションに従って、pytest をインストールし、ローカルの Flask インスタンスをセットアップする必要があります。 ENABLE_PAYMENT=True の場合、Stripe 統合には JavaScript を実行するボタンが含まれるため、Selenium と WebDriver もセットアップする必要があります。

 pip3 install selenium
pip3 install chromedriver-py

次の 2 つのテスト スクリプトがあります。

• clean_test_env.sh - すべての開発 Docker インスタンスをシャットダウンし、クリーン テスト Docker インスタンスを再構築して開始します。
• run_tests.sh - 環境変数を設定し、pytest スクリプトとインデックス作成を実行します。

pytest スクリプト:

• 基本リストを送信して承認する
• ENABLE_PAYMENT=True の場合、STRIPE_* 変数で指定された Stripe アカウントへのテスト支払いを含む、完全なリスティング サイトを送信します。
• 新しくインデックスされたサイトを検索する
• テストサイトを削除する

実行するには:

 cd ~/projects/searchmysite.net/tests
./clean_test_env.sh
./run_tests.sh

実際のサイトのインデックス作成を実行しているため、インデックス作成の手順には 1 ～ 2 分かかります。ENABLE_PAYMENT=True の場合、開いたり閉じたりするのに数秒かかるブラウザのポップアップが表示されます。

テストが成功すると、環境は開始時と同じ状態のままになります。つまり、テスト自体の後でクリーンアップされるため、 run_tests.shの前にclean_test_env.shを再度実行する必要はありません。ただし、テストが失敗した場合は、 clean_test_env.sh再実行する必要があります。同じ理由で、最初にclean_test_env.shを実行しなかったなどの理由で、誤ってテスト環境ではなく開発環境に対してrun_tests.sh実行した場合、テストが成功すれば環境は問題ありません。ただし、テスト Docker 環境を使用することをお勧めします。これにより、既知のクリーンな開始点が提供され、スケジュールされた再インデックス作成がテスト時のインデックス作成に干渉しないことが保証されます。