searchmysite.net
v1.4.16
Dieses Repository enthält die vollständige Codebasis für https://searchmysite.net/, die unabhängige Open-Source-Suchmaschine und Suche als Dienst für persönliche und unabhängige Websites (weitere Einzelheiten zu searchmysite.net finden Sie unter Über searchmysite.net).
Sie können dieses Repository verwenden, um:
Die Anwendung ist in 5 Komponenten aufgeteilt, die jeweils in einem eigenen Docker-Container bereitgestellt werden:
Die Projektverzeichnisstruktur ist wie folgt:
.
├── 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
Es gibt 3 Docker-Compose-Dateien, die weitgehend identisch sind, außer:
Stellen Sie sicher, dass Docker installiert ist.
Holen Sie sich den Quellcode mit z.B
cd ~/projects/
git clone https://github.com/searchmysite/searchmysite.net.git
Erstellen Sie die Datenverzeichnisse für die Datenbank und den Suchindex:
cd ~/projects/searchmysite.net/
mkdir -p data/solrdata
mkdir -p data/sqldata
sudo chown 8983:8983 data/solrdata
Erstellen Sie eine ~/projects/searchmysite.net/src/.env-Datei für docker-compose.yml, die mindestens Folgendes enthält:
POSTGRES_PASSWORD=<password>
SECRET_KEY=<secretkey>
POSTGRES_PASSWORD und SECRET_KEY können beliebige Werte sein, die Sie für die lokale Entwicklung auswählen. Beachten Sie, dass dies zwar die einzigen Werte sind, die für das Funktionieren der Basisanwendung erforderlich sind, es aber auch andere Werte gibt, die für zusätzliche Funktionen eingerichtet werden müssen – siehe Abschnitt „Zusätzliche Umgebungsvariablen“ weiter unten.
Und schließlich erstellen Sie die Docker-Images:
cd ~/projects/searchmysite.net/src
docker compose build
Beachten Sie, dass der erste Build 20 bis 30 Minuten dauern kann und der Modellcontainer eine 3-GB-Modelldatei herunterlädt.
Wenn die Voraussetzungen erfüllt sind, können Sie Ihre Entwicklungsumgebung starten mit:
cd ~/projects/searchmysite.net/src
docker compose up -d
Die Website wird unter http://localhost:8080/ und die Apache Solr-Administratorschnittstelle unter http://localhost:8983/solr/#/ verfügbar sein.
Wenn Sie Websites, die als Basiseintrag hinzugefügt wurden, genehmigen oder ablehnen möchten, müssen Sie einen oder mehrere Admin-Benutzer einrichten. Nur verifizierte Websitebesitzer, also solche mit einem vollständigen Eintrag und der Möglichkeit, sich anzumelden, können als Admin-Benutzer berechtigt werden. Sie können über die Weboberfläche Ihre eigene Website über „Website hinzufügen“ als vollständige Auflistung hinzufügen oder Details direkt in die Datenbank einfügen.
Sobald Sie einen oder mehrere verifizierte Websitebesitzer haben, können Sie diese als Administratoren in der Datenbank zulassen, z. B.:
INSERT INTO tblPermissions (domain, role)
VALUES ('michael-lewis.com', 'admin');
Mit „Site hinzufügen“ können Sie über die Weboberfläche eine oder mehrere Sites als Basiseintrag hinzufügen. Sie müssen sich als Admin-Benutzer anmelden, auf „Überprüfen“ klicken und „Genehmigen“ auswählen, damit sie zur Indizierung in die Warteschlange gestellt werden.
Es gibt auch Massenimportskripte in src/db/bulkimport. checkdomains.py nimmt eine Liste von Domains oder Homepages als Eingabe, überprüft, ob es sich um gültige Websites handelt und ob sie nicht bereits in der Liste oder der Datenbank vorhanden sind, und generiert eine Datei zum Einfügen durch insertdomains.py.
Siehe auch die Diskussion unter #91.
Wenn Sie Funktionen zum Versenden von E-Mails nutzen möchten (z. B. das Kontaktformular), müssen Sie die folgenden Werte festlegen:
SMTP_SERVER=
SMTP_PORT=
SMTP_FROM_EMAIL=
SMTP_FROM_PASSWORD=
SMTP_TO_EMAIL=
Wenn Sie es nur testen, können Sie ein webbasiertes E-Mail-Konto erstellen und dafür die SMTP-Details verwenden.
Wenn Sie den Zahlungsmechanismus für verifizierte Einreichungen aktivieren möchten, müssen Sie Folgendes festlegen:
ENABLE_PAYMENT=True
STRIPE_SECRET_KEY=
STRIPE_PUBLISHABLE_KEY=
STRIPE_PRODUCT_ID=
STRIPE_ENDPOINT_SECRET=
Wenn Sie nur testen, können Sie bei Stripe ein Testkonto erhalten.
Die docker-compose.yml für Entwickler konfiguriert den Webserver so, dass er aus der Quelle liest, sodass Änderungen in der Quelle vorgenommen und neu geladen werden können. Der Webserver muss normalerweise neu gestartet werden, um Änderungen anzuzeigen:
docker exec -it web_dev apachectl restart
Bei häufigen Änderungen ist es besser, eine Flask-Entwicklungsumgebung außerhalb von Docker zu verwenden.
Dazu müssen Sie zunächst lokale Hosteinträge für „db“, „models“ und „search“ einrichten, also in /etc/hosts (vorausgesetzt, der „web“-Container kommuniziert mit den db-, models- und search-Containern). über die Hostnamen „db“, „models“ und „search“):
127.0.0.1 search
127.0.0.1 db
127.0.0.1 models
Zweitens installieren Sie Flask und Abhängigkeiten lokal (beachten Sie, dass Apache2-dev für mod-wsgi und libpq-dev für psycopg2 erforderlich ist) und installieren Sie das searchmysite-Paket im bearbeitbaren Modus (diese Schritte müssen nur einmal ausgeführt werden):
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 .
Laden Sie schließlich zu Beginn jeder Entwicklungssitzung Umgebungsvariablen und starten Sie Flask im Entwicklungsmodus über:
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
Ihre lokale Flask-Website ist beispielsweise unter http://localhost:5000/search/ verfügbar (beachten Sie, dass die Homepage, z. B. http://localhost:5000/, nicht dynamisch bereitgestellt wird und daher nicht über Flask verfügbar ist). . Änderungen am Code werden ohne Serverneustart übernommen, Sie sehen Debug-Protokollmeldungen und vollständige Stack-Traces sind bei Fehlern besser sichtbar.
Wie der Webcontainer ist auch der Indexierungscontainer auf dev so konfiguriert, dass er direkt von der Quelle liest, sodass Änderungen nur gespeichert werden müssen.
Normalerweise lösen Sie eine Neuindizierung aus, indem Sie SQL wie folgt ausführen:
UPDATE tblDomains
SET full_indexing_status = 'PENDING'
WHERE domain = 'michael-lewis.com';
und auf den nächsten src/indexing/indexer/run.sh warten (bis zu 1 Minute auf dev) oder ihn manuell auslösen:
docker exec -it src-indexing-1 python /usr/src/app/search_my_site_scheduler.py
Es sollte keine Probleme geben, wenn mehrere Planer gleichzeitig ausgeführt werden, wenn Sie sie manuell auslösen und der geplante Job dann ausgeführt wird.
Sie können die Indizierungsprotokolle überwachen über:
docker logs -f src-indexing-1
und kann LOG_LEVEL in src/indexing/indexer/settings.py in DEBUG ändern.
Der Dev-Solr-Docker-Container kopiert die Konfiguration beim Build, sodass für jede Konfigurationsänderung ein docker compose build erforderlich ist.
Beachten Sie, dass der solr-precreate content /opt/solr/server/solr/configsets/content die neue Konfiguration nach einem docker compose build nicht tatsächlich lädt. Daher sind die folgenden Schritte erforderlich, um Solr-Konfigurationsänderungen anzuwenden:
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
Abhängig von den Änderungen müssen Sie möglicherweise auch einige oder alle Daten im Index löschen, z
curl http://localhost:8983/solr/content/update?commit=true -H "Content-Type: text/xml" --data-binary '<delete><query>domain:michael-lewis.com</query></delete>'
und eine Neuindizierung wie oben beschrieben auslösen. Verwenden Sie <query>*:*</query> um alle Daten im Index zu löschen.
Sie können auch das Verzeichnis data/solrdata löschen und neu erstellen und es dann für einen Neuanfang neu erstellen.
Sie können eine Verbindung zur Datenbank herstellen über:
"host": "127.0.0.1",
"user": "postgres",
"port": 5432,
"ssl": false,
"database": "searchmysitedb",
"password": <password-from-dotenv-file>
Schemaänderungen sollten auf die Dateien src/db/sql/init* angewendet werden. Wenn Sie also das Verzeichnis data/sqldata löschen und neu erstellen, wird das neueste Schema angewendet.
Für grundlegende Experimente mit der Relevanzoptimierung können Sie manuell einige Websites hinzufügen und mit diesen experimentieren. Denken Sie daran, sicherzustellen, dass zwischen diesen Websites Links vorhanden sind, da indexed_inlink_domains_count ein wichtiger Faktor bei der Bewertung ist. Denken Sie auch daran, dass indexed_inlink*-Werte möglicherweise eine zweimalige Indizierung von Websites erfordern, um korrekt festgelegt zu werden. Der Indexierungsprozess setzt indexed_inlink*-Werte aus den indexed_outlink*-Werten und erfordert daher einen ersten Durchgang, um sicherzustellen, dass für alle Websites indexed_outlink*-Werte festgelegt sind.
Für eine ernsthafte Relevanzoptimierung ist es jedoch besser, eine Wiederherstellung der Produktions-Solr-Sammlung zu verwenden. Wenn Sie daran interessiert sind, lassen Sie es mich wissen und ich werde Ihnen ein aktuelles Exemplar zur Verfügung stellen.
Beachten Sie, dass es beim Hinzufügen neuer Felder zum Solr-Schema, die in der Relevanzbewertung verwendet werden sollen, besser ist, zu warten, bis alle Sites diese Felder hinzugefügt haben, bevor Sie die neuen Änderungen an der Relevanzbewertung bereitstellen. Dafür gibt es zwei Möglichkeiten: Erzwingen Sie eine Neuindizierung aller Websites oder warten Sie, bis alle Websites auf natürliche Weise neu indiziert werden. Es ist einfacher und sicherer, auf die natürliche Neuindizierung zu warten. Die erzwungene Neuindizierung aller Elemente wird wahrscheinlich über 24 Stunden dauern, da die Neuindizierung in 20er-Batches erfolgt und einige Websites mehr als eine Stunde für die Neuindizierung benötigen, während eine natürliche Neuindizierung 3,5 Tage dauert, um sicherzustellen, dass alle verifizierten Websites neu indiziert werden (28 Tage für nicht verifizierte Seiten).
Die Tests werden mit Pytest auf einer lokalen Flask-Instanz ausgeführt. Sie müssen daher Pytest installieren und eine lokale Flask-Instanz einrichten, wie im Abschnitt „Änderungen am lokalen Entwickler vornehmen“ / „Webänderungen“ oben beschrieben. Wenn Sie ENABLE_PAYMENT=True haben, müssen Sie auch Selenium und WebDriver einrichten, da die Stripe-Integration Schaltflächen umfasst, die JavaScript ausführen, z. B.:
pip3 install selenium
pip3 install chromedriver-py
Es gibt zwei Testskripte:
clean_test_env.sh – fährt alle Entwicklungs-Docker-Instanzen herunter, erstellt sie neu und startet die sauberen Test-Docker-Instanzen.run_tests.sh – richtet die Umgebungsvariablen ein, führt die Pytest-Skripte und die Indizierung aus.Die Pytest-Skripte:
Ausführen:
cd ~/projects/searchmysite.net/tests
./clean_test_env.sh
./run_tests.sh
Der Indexierungsschritt dauert ein bis zwei Minuten, vorausgesetzt, es handelt sich um die Indizierung realer Websites. Wenn ENABLE_PAYMENT=True ist, wird ein Browser-Popup angezeigt, dessen Öffnen und Schließen einige Sekunden dauert.
Wenn die Tests erfolgreich sind, verbleibt die Umgebung im gleichen Zustand wie zu Beginn, d. h. sie bereinigt sich selbst, sodass Sie clean_test_env.sh nicht erneut vor run_tests.sh ausführen müssen. Wenn die Tests jedoch fehlschlagen, müssen Sie clean_test_env.sh erneut ausführen. Aus dem gleichen Grund gilt: Wenn Sie run_tests.sh versehentlich für den Entwickler und nicht für die Testumgebung ausführen, z. B. weil Sie nicht zuerst clean_test_env.sh ausgeführt haben, ist die Umgebung in Ordnung, wenn die Tests erfolgreich sind. Es ist jedoch besser, die Test-Docker-Umgebung zu verwenden, da diese einen bekanntermaßen sauberen Ausgangspunkt bietet und sicherstellt, dass die geplante Neuindizierung die Indizierung im Test nicht beeinträchtigt.
