Preparation upgrade elasticsearch 7.10 bsds

[elishowk]

Préparer le passage à Elasticsearch 7.10 pour l'index bsds sur notre hébergement

• Elasticsearch 7.10 est la dernière version avec licence OSS, celle de Scalingo
• le pkg npm v7.14 casse la compatibilité avec la dernière version OSS d'elasticsearch aka v7.10, elastic ayant arrêté son support cf Is it still suppose to support OSS? breaking since new productCheck (7.14.0) elastic/elasticsearch-js#1530 et autre. Il nous faut donc rester à 7.13
• pour mettre à jour son env local: npm i et docker-compose down && docker-compose --build up

Procédures

• À faire en recette, puis staging & production (les 2 en même temps car le code sur master ne sera compatible qu'avedc une version d'ES)
• Tout sauvegarder avant de démarrer, et afficher les bandeaux d'avertissement aux utilisateurs front
• Après chaque mise )à jour d'un cluster d'un environnement, faire des tests des dashboards
• Deux modalités de mise à jour sur Scalingo : soit on met à jour via Scalingo le cluster ES existant (A), soit on crée un nouveau cluster vierge (B), et on bascule l'application backend sur le nouveau cluster, un fois la réindexation terminée, via la variable d'env ELASTIC_SEARCH_URL

Mode A (une indexation complète, mais downtime ES à craindre)

• Tout sauvegarder avant de démarrer
• Mettre en place le bandeau d'avertissement
• Désactiver l'allocation des shards. Cela empêche le cluster de créer des répliques pendant la mise à jour.

PUT _cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "none"
    }
}

• Arrêter les worker d'indexation et laisser la job queue se vider des indexation actives
• Lancer la màj via Scalingo du cluster existant, en même temps que la release du code correspondant.
• Une fois terminée, il ne devrait pas y avoir de trous dans la raquette de l'index bsds mais les erreurs 500 du back-end pourront avoir déclenché des alertes si ES n'est plus disponible à un moment
• Réactiver l'allocation des shards

PUT _cluster/settings
{
    "persistent": {
        "cluster.routing.allocation.enable": "all"
    }
}

• redémarrer les worker d'indexation

Mode B (double indexation complète, mais pas de downtime ES à craindre)

• Tout sauvegarder avant de démarrer
• Mettre en place le bandeau d'avertissement sur le front
• Créer le nouveau cluster ES sur staging & production
• Lancer un container sur dev et changer la variable d'env ELASTIC_SEARCH_URL avant de lancer une réindexation complète, tout en passant à 4 container 2XL les worker d'indexation
• Mettre la nouvelle ELASTIC_SEARCH_URL dans l'env des api staging et production
• Release du code correspondant sur master
• Relancer une seconde fois la réindexation complète (prévue sans downtime) car il se peut qu'il y ait des trous dans l'indexation, mais il n'y aura pas eu de pics d'erreurs dû à une indisponibilité ES.
• Vérifier les settings du nouveau cluster : replicas, refresh interval.

Changements dans le code

• Pour permettre de lancer une indexation sur différents serveurs, permettre à la variable d'env ELASTIC_SEARCH_URL d'être transmise à la job queue pour pourvoir avoir des process de job queue qui recoivent dans les job data l'url cible voule
• supprimer "type" _doc disparu avec la v7 https://www.elastic.co/guide/en/elasticsearch/reference/7.17/removal-of-types.html

Extra : allègement des réponses bulkIndex

• Déjà présent sur l'indexation Sirene : https://github.com/MTES-MCT/trackdechets-sirene-search/blob/main/src/indexation/elasticSearch.helpers.ts#L199

• Évite les réponses très volumineuses entre ES et node

• Mettre à jour la documentation

• Mettre à jour le change log

• Documenter les manipulations à faire lors de la mise en production (sur le ticket Favro de release)

• S'assurer que la numérotation des nouvelles migrations est bien cohérente

• Informer le data engineer de tout changement de schéma DB

---

• Ticket Favro

[Riron]

Il faut coordonner la montée de version de l'ES de prod ? Comment ca se passe ?

[sonarqubecloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
0.5% Duplication