Journal Activer Elasticsearch pour son instance Mastodon

Posté par  . Licence CC By‑SA.
Étiquettes :
9
27
août
2023

Cet article est la suite de l'article pour héberger une instance Mastodon.

Mastodon (<3) évolue encore avec une belle nouveautée dans sa version stable de rentrée, comme l'indique par un toot d'Eric F. :

La #recherche plein texte (contenu des toots) est disponible sur la toute dernière version du logiciel #mastodon (en version bêta, déploiement dans la branche stable prévue en septembre selon @renchap)

Encore faut-il avoir un Elasticsearch (ou son fork à licence bien plus permissive, Opensearch) d'actif à disposition. Et comme le rappelle Renaud C., Mastodon core team member (et MERCI à toute votre équipe !) :

"(…) la fonctionnalité requiert ElasticSearch (comme les fonctionnalités de recherche hors hashtag des versions précédentes).
On va clarifier la doc et indiquer plus clairement que ElasticSearch n'est plus vraiment considéré comme optionnel, vu que pas mal de fonctionnalités vont dépendre dessus."

Car, peut-être comme moi, vous vous êtes dits qu'Elasticsearch est (1) consommateur (pour mon NUC) ; (2) parfois un peu "subtil" (pénible) à administrer, pour assez peu d’intérêts lorsque vous êtes sur de très petites instances comme la mienne (mono-usager). Vous auriez volontairement zappé ce point…

Hélas il faut désormais se mettre à la page !

Voici les modifications à apporter afin de préparer l'environnement de cette nouvelle version. D'abord avec l'ajout du service concerné dans docker-compose.yml :


es01:
container_name: es01
image: elasticsearch:8.9.1
volumes:
- ./elasticsearch8:/usr/share/elasticsearch/data
environment:
- "node.name=es01"
- "discovery.type=single-node"
- "ES_JAVA_OPTS=-Xms512m -Xmx512m" # à adapter
- "ELASTIC_PASSWORD=mon_super_mot_de_passe" # à changer
`

N'hésitez pas à ajouter un healthcheck si vous le souhaitez. Attention pour le point de montage du dossier dans le conteneur, Elasticsearch écrit en root par défaut.

Puis on charge la modification : 

docker compose up -d

Ce qui lancera la récupération de l'image et son instanciation. Si vous avez plusieurs réseaux Docker voire plusieurs stacks, il est possible que vous ayez des redémarrages plus larges à prévoir.

Alors on regardera que l'instance va bien : 

capp@nothusserv1:~/mastodon$ docker compose ps 
NAME                   IMAGE                       COMMAND                  SERVICE             CREATED             STATUS                    PORTS
db                     postgres:14.6               "docker-entrypoint.s…"   db                  8 months ago        Up 27 minutes (healthy)   
es01                   elasticsearch:8.9.1         "/bin/tini -- /usr/l…"   es01                24 minutes ago      Up 24 minutes             
mastodon-sidekiq-1     tootsuite/mastodon:v4.1.4   "/usr/bin/tini -- bu…"   sidekiq             23 minutes ago      Up 23 minutes (healthy)   3000/tcp, 4000/tcp
mastodon-streaming-1   tootsuite/mastodon:v4.1.4   "/usr/bin/tini -- no…"   streaming           23 minutes ago      Up 23 minutes (healthy)   3000/tcp, 127.0.0.1:4000->4000/tcp
mastodon-web-1         tootsuite/mastodon:v4.1.4   "/usr/bin/tini -- ba…"   web                 23 minutes ago      Up 23 minutes (healthy)   3000/tcp, 4000/tcp
redis                  redis:7-alpine              "docker-entrypoint.s…"   redis               58 minutes ago      Up 27 minutes (healthy)

Je vous conseille aussi de surveiller les journaux d'Elasticsearch (attention les yeux) : 

docker compose logs es01

Vous pouvez également vérifier que l'instance ES tourne correctement en demandant le statut (comme pour un healthcheck), directement dans le conteneur visé : 

julien@julien-Vostro-7580:~/Developpement/mastodon/article$ docker compose exec -it -u root es01 bash
root@a0276a607959:/usr/share/elasticsearch# curl -u elastic:mon_super_mot_de_passe http://es01:9200
{
  "name" : "es01",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "***-***",
  "version" : {
    "number" : "8.9.1",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "***",
    "build_date" : "***",
    "build_snapshot" : false,
    "lucene_version" : "9.7.0",
    "minimum_wire_compatibility_version" : "7.17.0",
    "minimum_index_compatibility_version" : "7.0.0"
  },
  "tagline" : "You Know, for Search"
}

Parfait !

On modifiera alors le fichier .env.production pour que l'instance la prenne en compte, en prenant garde à ce que le nom résolvable de votre conteneur soit bien déclaré dans ES_HOST (ici c'est "es01") : 

# Elasticsearch (optional)
# ------------------------
ES_ENABLED=true
ES_HOST=es01
ES_PORT=9200
# Authentication for ES (optional)
ES_USER=elastic
ES_PASS=mon_super_mot_de_passe

Ce qui va nous obligé à redémarrer (pas la peine de recréer) le conteneur Mastodon, ici s'appelant "web" : 

docker compose restart web

Enfin vous pouvez rentrer dedans pour demander la création de l'index. Cela prend un peu de temps, soyez patient : 

julien@julien-Vostro-7580:~/Developpement/mastodon/article$ docker compose exec -it -u root web bash
root@21a0039cfad6:/opt/mastodon# RAILS_ENV=production bin/tootctl search deploy
Done! 100529/100529 |=========================================================================================================================================================================================| Time: 00:00:17 (5913 docs/s)
Indexed 74684 records, de-indexed 0

Voilà, votre instance a sa propre indexation, comme une grande. Dans mon cas, les index nouvellement créés représentent 17 Mo au démarrage sur le disque, 4% de mon CPU et près d'1 Go de RAM - mais garder à l'esprit que mon instance est mono-utilisateur : cela peut être considérablement plus ! Laissez toujours Elasticsearch "souffler" et avoir du rab', il peut vite être erratique en cas de stress de ressources.

Évidemment on n'expose jamais son instance Elasticsearch au reste du monde, particulièrement avec aussi peu de sécurité que je viens de le décrire. Si vous avez un doute, n'hésitez jamais à demander dans un forum : mieux vaut s’embêter une heure avant, que tout perdre après !

Vivement la rentrée…

  • # Compliqué ?

    Posté par  (site web personnel) . Évalué à 7.

    Je vois que Mastodon utilise Postgresql. Pourquoi ne pas avoir utilisé la fonctionnalité de recherche intégrée à cette base ?

    Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Compliqué ?

      Posté par  (site web personnel) . Évalué à 5.

      Car solr et elastic search permettent d'ordonner précisément les résultats, peuvent fonctionner très simplement sur des clusters (pas de relations), de faire de la recherche approximative (par exemple sans accents, avec des fautes), permet d'optimiser la recherche lorsqu'il y a plusieurs termes, et encore beaucoup, beaucoup, beaucoup d'autres choses.

      • [^] # Re: Compliqué ?

        Posté par  (site web personnel) . Évalué à 4.

        Dans les beaucoup, il y a le faceting aussi.. à lui seul, ça justifie l'usage de solr.

      • [^] # Re: Compliqué ?

        Posté par  . Évalué à 6.

        par exemple sans accents, avec des fautes

        Ce que permet PostgreSQL : https://www.postgresql.org/docs/current/unaccent.html

        permet d'optimiser la recherche lorsqu'il y a plusieurs termes

        Idem : https://www.postgresql.org/docs/current/textsearch.html

        En tout cas, je trouve intéressant de déjà tester avec PostgreSQL avant d'ajouter une brique supplémentaire à maintenir dans sa stack :)

        • [^] # Re: Compliqué ?

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 30 août 2023 à 04:25.

          Solr permet de contrôler la manière dont est créé l'index, et de traiter la requête de la même façon. On peut le faire en Postgres, il n'est pas nécessaire d'utiliser unaccent, il suffit d'ajouter une colonne et de mettre une copie sans accents, c'est d'ailleurs ce qui est pratiqué avec Solr. Pour cet usage précis, Solr permet de créer automatiquement les copies (tu pourrais aussi le faire avec une procédure stockée à Postgres… Bref, c'est juste pas pratique).

          Finalement, on pourrait aussi tout faire en C (ou en C++ ou en Rust.. mais pas en Python, pitié, ni en JS/TypeScript…) … Avec des indexes aux petits oignons, en fonction du type de chaîne de caractères (référence produit, argot, adresse postale, adresse mail), c'est juste que Solr a pensé a tous les cas d'usage, et que c'est pas trop long a maîtriser, comme l’auto-complétion et le faceting.

          Un exemple de configuration pour comprendre la manière dont sont traitées les chaînes de caractères avec Solr pour les textes anglais :

            <fieldType name="text_en" class="solr.TextField" positionIncrementGap="100">
    <analyzer type="index">
      <tokenizer class="solr.StandardTokenizerFactory"/>
      <filter class="solr.StopFilterFactory" words="lang/stopwords_en.txt" ignoreCase="true"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EnglishPossessiveFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
    </analyzer>
    <analyzer type="query">
      <tokenizer class="solr.StandardTokenizerFactory"/>
      <filter class="solr.SynonymGraphFilterFactory" expand="true" ignoreCase="true" synonyms="synonyms.txt"/>
      <filter class="solr.StopFilterFactory" words="lang/stopwords_en.txt" ignoreCase="true"/>
      <filter class="solr.LowerCaseFilterFactory"/>
      <filter class="solr.EnglishPossessiveFilterFactory"/>
      <filter class="solr.KeywordMarkerFilterFactory" protected="protwords.txt"/>
      <filter class="solr.PorterStemFilterFactory"/>
    </analyzer>
  </fieldType>

          On voit la partie index et query, ça fait bien plus que unaccent, juste pour ce cas simple.

          P.S.: J'ai lu plus bas qu'ElasticSearch n'était pas OpenSource, je n'utilise que Solr sur nos instances (voir le site de taack.org et taper JDBC par exemple dans le moteur de recherche..).

    • [^] # Re: Compliqué ?

      Posté par  . Évalué à 3. Dernière modification le 27 août 2023 à 17:36.

      Pourquoi ne pas avoir utilisé la fonctionnalité de recherche intégrée à cette base ?

      Cette recherche intégrée est déjà disponible pour mastodon.social and mastodon.online

    • [^] # Re: Compliqué ?

      Posté par  . Évalué à 2.

      C'est demandé https://github.com/mastodon/mastodon/issues/26645

      https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll

  • # Pas "moins permissive"

    Posté par  (site web personnel) . Évalué à 9. Dernière modification le 27 août 2023 à 18:30.

    Encore faut-il avoir un Elasticsearch (ou son fork à licence bien plus permissive, Opensearch) d'actif à disposition.

    Correction : Encore faut-il avoir un Elasticsearch (ou son fork à licence libre, Opensearch) d'actif à disposition.

    Ta phrase sous-entend que Elasticsearch serait libre, le fork n'étant que du libre plus permissif, alors que le soucis avec Elasticsearch est qu'il n'est plus libre.

    Du coup :

    On va clarifier la doc et indiquer plus clairement que ElasticSearch n'est plus vraiment considéré comme optionnel, vu que pas mal de fonctionnalités vont dépendre dessus."

    Ai-je bien compris qu'un "core dev" de Mastodon parle de considérer obligatoire un logiciel non libre? Même si il y a une version libre du logiciel, la façon d'afficher sous-entend qu'ils n'ont rien à faire du libre…

    Après, libre à eux de n'avoir rien à faire du libre, mais du coup je me demande combien de temps tiendra la licence (AGPL) de Mastodon avant un changement "pour de bonnes raisons", un petit avertissement pour les libristes pensant que Mastodon c'est une alternative libre à long terme.

    Question : as-tu essayé une solution libre ou que du non libre avant de dire que l'alternative libre est utilisable? (le fork libre d'Elsasticsearch n'a pas toutes les fonctionnalités car Elsasticsearch a ajouté des trucs depuis, du coup OpenSearch ne peut marcher que si il n'y a pas de spécificités Elsasticsearch utilisées)

    • [^] # Re: Pas "moins permissive"

      Posté par  (site web personnel) . Évalué à 10. Dernière modification le 27 août 2023 à 19:03.

      Pour préciser:

      • OpenSearch est sous licence Apache 2.0 sans CLA ;
      • il propose des fonctionnalités que n'avait pas la version libre Elasticsearch (sur l'authentification et la gestion des droits par exemple) ;
      • ils sont en train de travailler la gestion des métriques et des traces pour chatouiller la suite Grafana sur son terrain.

      Bref OpenSearch, c'est bon, mangez-en.

      Le post ci-dessus est une grosse connerie, ne le lisez pas sérieusement.

    • [^] # Re: Pas "moins permissive"

      Posté par  . Évalué à 1. Dernière modification le 29 août 2023 à 19:30.

      Sur Opensearch mea culpa, en effet ma phrase est mal formulée. Tu as raison sue le fond, Opensearch est libre et Elasticsearch non.

      Non je n'ai pas testé une alternative - voir l'échange Mastodon que je cite en intro, qui indique des instances qui utilisent Opensearch.

      Pour l'usage au sein de Mastodon, voici un commit de la documentation du projet :
      https://github.com/mastodon/documentation/commit/18defebf2f5eba82c403a6ef8be4ae336d6611f4

      Elasticsearch est cité à plusieurs reprises. En partie parce que c'est une bibliothèque de l'éditeur qui est utilisée en interne, cf. :
      https://oisaur.com/@renchap/110961332489669407

      Pour le fond, je te laisse contacter l'auteur pour avoir plus de détails, je n'en sais pas plus…

  • # pour les petites instances

    Posté par  . Évalué à 8.

    Il y a des serveurs qui ne sont pas optimisés pour tourner en cluster et ne mettent pas d'usine à gaz dans leurs dépendances.

    Bref: Pleroma, ça marche plutôt bien, et il y en a d'autres.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.