searchmysite.net
v1.4.16
Ce référentiel contient la base de code complète de https://searchmysite.net/, le moteur de recherche open source indépendant et la recherche en tant que service pour les sites Web personnels et indépendants (voir À propos de searchmysite.net pour plus de détails sur searchmysite.net).
Vous pouvez utiliser ce référentiel pour :
L'application est divisée en 5 composants, chacun déployé dans son propre conteneur Docker :
La structure du répertoire du projet est la suivante :
.
├── 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
Il existe 3 fichiers docker-compose, qui sont en grande partie identiques sauf :
Assurez-vous que Docker est installé.
Obtenez le code source avec par exemple
cd ~/projects/
git clone https://github.com/searchmysite/searchmysite.net.git
Créez les répertoires de données pour la base de données et l'index de recherche :
cd ~/projects/searchmysite.net/
mkdir -p data/solrdata
mkdir -p data/sqldata
sudo chown 8983:8983 data/solrdata
Créez un fichier ~/projects/searchmysite.net/src/.env pour docker-compose.yml contenant au moins les éléments suivants :
POSTGRES_PASSWORD=<password>
SECRET_KEY=<secretkey>
POSTGRES_PASSWORD et SECRET_KEY peuvent être n'importe quelle valeur que vous choisissez pour le développement local. Notez que même si ce sont les seules valeurs requises pour que l'application de base fonctionne, d'autres valeurs devront être configurées pour des fonctionnalités supplémentaires - voir la section « Variables d'environnement supplémentaires » ci-dessous.
Et enfin, créez les images Docker :
cd ~/projects/searchmysite.net/src
docker compose build
Notez que la première génération peut prendre 20 à 30 minutes et que le conteneur de modèles télécharge un fichier de modèle de 3 Go.
Une fois les prérequis en place, vous pouvez démarrer votre environnement de développement avec :
cd ~/projects/searchmysite.net/src
docker compose up -d
Le site Web sera disponible à l'adresse http://localhost:8080/ et l'interface d'administration Apache Solr à l'adresse http://localhost:8983/solr/#/.
Si vous souhaitez pouvoir approuver ou rejeter les sites ajoutés en tant que liste de base, vous devrez configurer un ou plusieurs utilisateurs administrateurs. Seuls les propriétaires de sites vérifiés, c'est-à-dire ceux disposant d'une liste complète et capables de se connecter, peuvent être autorisés en tant qu'utilisateurs administrateurs. Vous pouvez utiliser l'interface Web pour ajouter votre propre site en tant que liste complète via Ajouter un site ou insérer des détails directement dans la base de données.
Une fois que vous avez un ou plusieurs propriétaires de sites vérifiés, vous pouvez les autoriser en tant qu'administrateurs dans la base de données, par exemple :
INSERT INTO tblPermissions (domain, role)
VALUES ('michael-lewis.com', 'admin');
Vous pouvez utiliser Ajouter un site pour ajouter un ou plusieurs sites en tant que liste de base via l'interface Web. Vous devrez vous connecter en tant qu'utilisateur administrateur, cliquer sur Réviser et sélectionner Approuver pour qu'ils soient mis en file d'attente pour l'indexation.
Il existe également des scripts d'importation en masse dans src/db/bulkimport. checkdomains.py prend une liste de domaines ou de pages d'accueil en entrée, vérifie qu'il s'agit de sites valides et qu'ils ne figurent pas déjà dans la liste ou la base de données, et génère un fichier à insérer par insertdomains.py.
Voir aussi la discussion au #91.
Si vous souhaitez utiliser une fonctionnalité d'envoi d'e-mails (par exemple le formulaire de contact), vous devrez définir les valeurs suivantes :
SMTP_SERVER=
SMTP_PORT=
SMTP_FROM_EMAIL=
SMTP_FROM_PASSWORD=
SMTP_TO_EMAIL=
S'il s'agit simplement d'un test, vous pouvez créer un compte de messagerie Web et utiliser les détails SMTP pour cela.
Si vous souhaitez activer le mécanisme de paiement pour les soumissions vérifiées, vous devrez définir :
ENABLE_PAYMENT=True
STRIPE_SECRET_KEY=
STRIPE_PUBLISHABLE_KEY=
STRIPE_PRODUCT_ID=
STRIPE_ENDPOINT_SECRET=
S'il s'agit simplement de tests, vous pouvez obtenir un compte de test auprès de Stripe.
Le docker-compose.yml pour dev configure le serveur Web pour lire à partir de la source, afin que des modifications puissent être apportées à la source et rechargées. Le serveur Web devra généralement être redémarré pour afficher les modifications :
docker exec -it web_dev apachectl restart
Pour les changements fréquents, il est préférable d'utiliser un environnement de développement Flask en dehors de Docker.
Pour ce faire, vous devrez d'abord configurer les entrées d'hôte local pour "db", "models" et "search", c'est-à-dire dans /etc/hosts (étant donné que le conteneur "web" communique avec la base de données, les modèles et les conteneurs de recherche via les noms d'hôtes "db", "models" et "search") :
127.0.0.1 search
127.0.0.1 db
127.0.0.1 models
Deuxièmement, installez Flask et ses dépendances localement (en notant qu'apache2-dev est requis pour mod-wsgi et libpq-dev pour psycopg2), et installez le package searchmysite en mode modifiable (ces étapes ne doivent être effectuées qu'une seule fois) :
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 .
Enfin, au début de chaque session de développement, chargez les variables d'environnement et démarrez Flask en mode développement via :
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
Votre site Web Flask local sera disponible par exemple sur http://localhost:5000/search/ (notez que la page d'accueil, c'est-à-dire http://localhost:5000/, n'est pas servie dynamiquement et ne sera donc pas disponible via Flask) . Les modifications apportées au code seront reflétées sans redémarrage du serveur, vous verrez les messages du journal de débogage et les traces complètes de la pile seront plus visibles en cas d'erreurs.
Comme pour le conteneur Web, le conteneur d'indexation sur dev est configuré pour lire directement à partir de la source, les modifications doivent donc simplement être enregistrées.
Vous déclencheriez généralement une réindexation en exécutant SQL comme :
UPDATE tblDomains
SET full_indexing_status = 'PENDING'
WHERE domain = 'michael-lewis.com';
et attendre le prochain src/indexing/indexer/run.sh (jusqu'à 1 min en développement), ou le déclencher manuellement :
docker exec -it src-indexing-1 python /usr/src/app/search_my_site_scheduler.py
Il ne devrait y avoir aucun problème avec plusieurs planificateurs exécutés simultanément si vous le déclenchez manuellement et que le travail planifié s'exécute ensuite.
Vous pouvez surveiller les journaux d'indexation via :
docker logs -f src-indexing-1
et peut changer le LOG_LEVEL en DEBUG dans src/indexing/indexer/settings.py.
Le conteneur Docker dev Solr copie dans la configuration lors de la construction, donc une docker compose build est requise pour chaque changement de configuration.
Notez que le solr-precreate content /opt/solr/server/solr/configsets/content ne charge pas réellement la nouvelle configuration après un docker compose build , les étapes suivantes sont donc requises pour appliquer les modifications de configuration 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
En fonction des modifications, vous devrez peut-être également supprimer tout ou partie des données de l'index, par exemple
curl http://localhost:8983/solr/content/update?commit=true -H "Content-Type: text/xml" --data-binary '<delete><query>domain:michael-lewis.com</query></delete>'
et déclencher la réindexation comme ci-dessus. Utilisez <query>*:*</query> pour supprimer toutes les données de l'index.
Vous pouvez également supprimer et recréer le répertoire data/solrdata, puis le reconstruire pour un nouveau départ.
Vous pouvez vous connecter à la base de données via :
"host": "127.0.0.1",
"user": "postgres",
"port": 5432,
"ssl": false,
"database": "searchmysitedb",
"password": <password-from-dotenv-file>
Les modifications du schéma doivent être appliquées aux fichiers src/db/sql/init*. Ainsi, si vous supprimez et recréez le répertoire data/sqldata, le dernier schéma est appliqué.
Pour une expérimentation de base avec le réglage de la pertinence, vous pouvez ajouter manuellement quelques sites et les expérimenter. N'oubliez pas de vous assurer qu'il existe des liens entre ces sites, car indexed_inlink_domains_count est un facteur important dans la notation. N'oubliez pas également que les valeurs indexed_inlink* peuvent nécessiter que les sites soient indexés deux fois pour être correctement définis - le processus d'indexation définit les valeurs indexed_inlink* à partir des valeurs indexed_outlink*, il a donc besoin d'un premier passage pour garantir que tous les sites ont des valeurs indexed_outlink* définies.
Cependant, pour un réglage sérieux de la pertinence, il est préférable d'utiliser une restauration de la collection Solr de production. Si cela vous intéresse, faites-le-moi savoir et j'en mettrai une à jour à votre disposition.
Notez que si vous ajoutez de nouveaux champs au schéma Solr qui doivent être utilisés dans la notation de pertinence, il est préférable d'attendre que tous les sites aient ajouté ces champs avant de déployer les nouvelles modifications de notation de pertinence. Il existe deux manières de procéder : forcer une réindexation de tous les sites, ou attendre que tous les sites soient naturellement réindexés. Il est plus facile et plus sûr d'attendre la réindexation naturelle. La réindexation forcée de tout prendra probablement plus de 24 heures étant donné que la réindexation se produit par lots de 20 et que certains sites prennent plus d'une heure pour être réindexés, tandis qu'une réindexation naturelle prendra 3,5 jours pour garantir que tous les sites vérifiés sont réindexés (28 jours pour sites non vérifiés).
Les tests sont exécutés avec pytest sur une instance Flask locale, vous devrez donc installer pytest et configurer une instance Flask locale conformément à la section « Apporter des modifications sur le développement local » / « Modifications Web » ci-dessus. Si vous avez ENABLE_PAYMENT=True, vous devrez également configurer Selenium et WebDriver, car l'intégration Stripe implique des boutons qui exécutent du JavaScript, par exemple :
pip3 install selenium
pip3 install chromedriver-py
Il existe deux scripts de test :
clean_test_env.sh - arrête toutes les instances de docker de développement, reconstruit et démarre les instances de docker de test propres.run_tests.sh - configure les variables d'environnement, exécute les scripts pytest et l'indexation.Les scripts pytest :
Pour exécuter :
cd ~/projects/searchmysite.net/tests
./clean_test_env.sh
./run_tests.sh
L'étape d'indexation prendra une minute ou deux, étant donné qu'elle effectue l'indexation de sites réels, et si ENABLE_PAYMENT=True, vous verrez un navigateur apparaître qui prend quelques secondes pour s'ouvrir et se fermer.
Si les tests réussissent, il laissera l'environnement dans le même état qu'au début, c'est-à-dire qu'il nettoie après lui-même, vous n'avez donc pas besoin d'exécuter clean_test_env.sh avant run_tests.sh à nouveau. Si toutefois les tests échouent, vous devrez réexécuter clean_test_env.sh . Pour la même raison, si vous exécutez accidentellement run_tests.sh sur le développeur plutôt que sur l'environnement de test, par exemple parce que vous n'avez pas exécuté clean_test_env.sh en premier, alors si les tests réussissent, l'environnement ira bien. Il est cependant préférable d'utiliser l'environnement Test Docker, car cela fournit un point de départ propre et connu et garantit que la réindexation planifiée n'interfère pas avec l'indexation dans les tests.
