search

etalab / sirene_as_api_ansible

Ansible to install your own sirene_as_api server
5 stars 4 forks source link

Problèmes lors du déploiement et du peuplement #8

Open mpo-deltacode opened 5 years ago

mpo-deltacode commented 5 years ago

Bonjour, je viens vers vous pour vous demander des conseils sur différents problèmes que je rencontre lors du déploiement de Sirene

En environnement de production, après la commande mina deploy to=production, je ne vois pas apparaitre SOLR avec la commande ps aux | grep solr, alors que je n'ai eu aucune erreur dans le déploiement. Ce problème a l'air d'apparaitre seulement en production, car la commande bundle exec rake sunspot:solr:start RAILS_ENV=monEnvironnement fonctionne avec l'environnement de test et de développement

Donc j'ai essayé de déployer en environnement de développement, je vois bien le processus SOLR apparaitre, j'arrive à peupler ma base de données, mais lors de la mise à jour des patchs, une erreur apparait make sure solr server is launched on the right environment and accessible., alors que SOLR est bien chargé dans le bon environnement. Et quand l'update demande de supprimer la base pour la recréer, après l'avoir supprimer, j'obtiens une erreur de ce type

no implicit conversion of nil into String

Merci d'avance pour votre lectures et vos réponses

Cordialement

Samuelfaure commented 5 years ago

Bonjour,

Solr est très capricieux. Je vous conseille de mettre RAILS_ENV=production avant bundle exec. Verifiez bien que les fichiers data ont été copiés correctement, suivez bien la partie troubleshooting à la fin du README du repo sirene_as_api. Vous pouvez vous rendre sur http://localhost:8982/solr/ (ou autre port definit dans config/sunspot.yml) pour interagir avec le serveur solr dans votre navigateur, cela peut aider au debug. Si malgrès tout cela vous n'y arrivez pas, je compte dockeriser l'API dans les mois qui viennent.

mpo-deltacode commented 5 years ago

Bonjour, Tout d'abord merci de votre réponse Pour l'instant, j'ai déployer l'API en development. Le problème, c'est qu'en production Solr n'apparait jamais dans ma liste de processus. Après le déploiement de Mina, malgré que, dans l'historique de deploy.rb il me dise que solr à bien été redémarré, je ne vois pas apparaître ce dernier.

Et même en essayant de le démarrer à la main, j'ai un retour me disant qu'il à bien démarrer, mais encore une fois, je ne le vois pas apparaître dans les processus.

Est ce que ça pourrait être du à une erreur dans un fichier ? Ou peut-être que je dois remplacer une valeur dans un certain fichier ?

Cordialement

Samuelfaure commented 5 years ago

Sunspot (la librairie ruby pour Solr) a la facheuse habitude de vous dire que solr a démarré même en cas d'échec. Executez bundle exec rake sunspot:solr:run au lieu de start et le processus se lancera dans le shell, ce sera plus facile de vérifier quelle erreur intervient.

J'insiste pour que vous jetiez un oeil, si pas encore fait, au troubleshooting dans le README de l'autre repo sirene_as_api :) cela vous aidera beaucoup à affronter les problèmes de Solr.

mpo-deltacode commented 5 years ago

Pardonner moi de la réponse tardive.

Merci beaucoup, je vous tiendrais informé de l'evolution

Et une dernière question : Y a t-il une commande pour lancer la tache CRON qui permet de mettre automatiquement à jour la base de données de l'application ?

Cordialement

Samuelfaure commented 5 years ago

Depuis la dernière réponse nous avons dockerisé l'app ;) les changements n'ont pas encore été mergés, mais vous pouvez cloner la branche dockerize. Tout retour d'utilisateur nous serait précieux.

cron est le logiciel disponible sur les plateforms unix, macOs, ect. qui execute tout ce qui se trouve dans le fichier crontab. Normalement, un deploiement par notre script execute la gem whenever qui met à jour la crontab pour y ajouter nos taches rake qui updatent l'API. Les taches cron sont disponibles/modifiables par la commande suivante sur le systeme d'installation : crontab -e

Pour consulter les taches rake disponibles : (ajouter RAILS_ENV=production en environnement de production) :

bundle exec rake -T

De mémoire, il me semble que la tache à lancer est :

bundle exec rake sirene_as_api:update_database

En esperant vous avoir aidé

mpo-deltacode commented 5 years ago

Bonjour, je reviens vers vous après quelques tests

Premièrement, je n'ai pas encore vraiment pu tester votre version dockerize de Siren, je la testerai prochainement et je vous ferai un retour

Ensuite, je rencontre un petit problème. J'ai mis à jour la base de données samedi, j'ai réindexé les données hier, mais lorsque je compare mon Siren au Siren officiel, je constate des différences dans les resultats (souvent, mon Siren contient plus d'objets que le Siren officiel), est ce que c'est normal ?

Et petite question pour le lancement de la tache Cron de whenever : j'ai beau modifier le fichier schedule.rb pour y remplacer l'environnement "sandbox" par mon environnement "development" et passer la variable NODE_ENV=development devant ma commande whenever --update-crontab, la tache cron se lance en environnement production J'ai aussi essayer la commande whenever -s environment=development, lorsque je met à jour le cron, mais ça ne change rien Auriez vous une idée ?

Merci d'avance

Cordialement

Samuelfaure commented 5 years ago

Bonjour,

Ensuite, je rencontre un petit problème. J'ai mis à jour la base de données samedi, j'ai réindexé les données hier, mais lorsque je compare mon Siren au Siren officiel, je constate des différences dans les resultats (souvent, mon Siren contient plus d'objets que le Siren officiel), est ce que c'est normal ?

Tristement, nos données ne sont pas à jour actuellement. L'INSEE a récemment changé les formats de fichiers (de V2 vers V3), ce qui implique des changements longs et couteux de notre coté. L'ancien format n'est plus delivré depuis fin 2018. Le nouveau format consiste en de multiples fichiers avec un fonctionnement tout à fait différent.

Nous avons temporairement utilisé un script pour convertir les fichiers V3 en fichiers V2. Cette solution était temporaire et imparfaite. Les données actuelles sont les données V3 de février, au format V2.

Ce passage à la V3 est cependant notre priorité la plus urgente, et une release sera probablement disponible dans 1 ou 2 mois. Il y aura un certain nombre de breaking changes avec cette release, car nous réecrivons quasiment toute l'API. Cela vient quand même avec de bonnes nouvelles : les données sur les établissements fermés seront disponibles. Davantage de possibilités pour les requêtes.

Tout cela sera expliqué dans la prochaine newsletter que nous adresserons à nos utilisateurs.

Si vous vous interrogez sur les données geographiques des établissements, c'est un service gracieusement fournis par Étalab et par certains passionnés d'open source / open data. Nous géolocalisons les établissements pour permettre les recherches géographiques.

J'ai aussi essayer la commande whenever -s environment=development, lorsque je met à jour le cron, mais ça ne change rien

A priori nous avons configuré whenever (lancé automatiquement par le script de déploiement mina, dans deploy.rb) pour modifier automatiquement la crontab du serveur en environnement de production. Garder une base à jour en environnement de développement n'est pas une pratique courante.

Le plus simple à faire est surement de modifier votre crontab à la main : crontab -e sur environnement ubuntu / debian / probablement iOS aussi mais je n'ai pas testé. Cela devrait vous permettre de modifier la crontab à la main. Voici un exemple de ce que vous pouvez y mettre :

30 3 * * * /bin/bash -l -c 'cd /path/vers/mon/dossier/rails && RAILS_ENV=development bundle exec rake sirene_as_api:automatic_update_database --silent'

Ceci lancera la commande bundle exec rake sirene_as_api:automatic_update_database dans votre dossier rails sirene_as_api tous les jours à 3h30 du matin.

mpo-deltacode commented 5 years ago

Très bien, pas de soucis pour les données, c'est juste que j'étais étonné de ne pas retrouver les mêmes, mais je comprend mieux maintenant. Très bien, j'attend donc votre newsletter avec impatience ahah

Je vois, très bien, j'avais déja modifié manuellement la crontab, je vais voir si ma commande est donc exacte

Merci pour votre aide

mpo-deltacode commented 5 years ago

Bonjour, Je reviens vers vous après avoir installé la version de docker de l'INSEE sur mon serveur Tout se déroule très bien, juste deux ou trois petits points et questions :

Merci d'avance

Cordialement

Samuelfaure commented 5 years ago

Bonjour,

1/ Merci pour ce point important ! je le rajouterais dans la documentation.

2/ A priori le reindexage est toujours automatique après import oui

3/ Bien sur. A priori pas besoin de changer la config de rails, une modification sur le fichier docker-compose devrait suffire. Ligne 19, changer :

- "3000:3000" Pour : - "80:3000"

N'oubliez pas de rebuild le docker-compose ! A priori c'est l'ordre correct pour mapper le port 3000 du conteneur vers votre localhost:80, si ça ne marche pas essayez 3000:80

mpo-deltacode commented 5 years ago

Je viens de finir le reindexage des données, mais seul le /siren et /siret me retournent un résultat, les points /near_etablissement, /fulltext et /near_point me retournent une réponse "not found"

Et pour le port 80, je ne souhaiterai pas toucher au docker-compose, car lorsqu'il y aura une modif à cloner (par exemple la nouvelle version des fichiers), je devrais rechanger le port. J'aimerai pouvoir mettre un conteneur nginx qui permettrait de mapper le port 3000 en 80 sur le serveur, pensez vous que c'est possible ?

Merci

Samuelfaure commented 5 years ago

Pour le reindexage : avez vous interrogé /full_text juste après reindex ou avez vous fermé / rebuild le conteneur entre temps ? Il est possible que les indexs n'aient pas étés persistés correctement dans un volume fixe et que les données soient perdus à la fermeture du conteneur.

Si vous avez effectivement testé après fermeture ou rebuild, testez sans. Si cela fonctionne prévenez moi et je lancerais un fix la semaine prochaine.

Si cela ne fonctionne toujours pas (tandis que /siren fonctionne) , il faudrait verifier si le serveur solr est bien lancé et accessible au sein du conteneur. Par exemple en pinguant le tableau de bord Solr avec cette commande : docker-compose run sirene curl -Is http://localhost:8982/solr/\#/

Concernant le mapping des ports, j'imagine que nginx doit faire l'affaire.

mpo-deltacode commented 5 years ago

J'avais interrogé directement après le reindex, je n'avais pas rebuild le conteneur. Pour l'instant j'ai supprimer la version docker, je la remettrai sur une VPS spécifique pour Docker, je vous tiendrai au courant de l'evolution

mpo-deltacode commented 5 years ago

Je reviens vers vous. Je suis entrain de tester l'API en production. J'arrive a remplir la base de données, le début se passe très bien. Mais a la fin de la population de la BDD les patchs ne s'installent pas et j'obtiens l'erreur ✖ Error: could not update etablissement attributes: rsolr::error::http | Time: 00:00:00 ETA: ??:??:?? make sure solr server is launched on the right environment and accessible.

Et pour le reindexage, la console me retourne une erreur Error using progress bar: FATAL: password authentication failed for user "sirene_as_api_production" FATAL: password authentication failed for user "sirene_as_api_production" Pourtant j'ai bien modifié le database.yml avant de lancer le ansible. Jessai de démarrer le solr dans /var/www/sirene_api_production/release/1, ou dans /var/www/sirene_api_production/current, mais toujours la même erreur ou bien la commande ne lance rien

Auriez vous une idée de pourquoi solr ne fonctionne pas ?

Merci d'avance

Cordialement

Samuelfaure commented 5 years ago

Il semble y avoir deux problèmes distincts :

1/ Accès à la base de donnée Postgres : le mot de passe est-il le bon dans la partie production du fichier database.yml ?

2/ Lancement de Solr : regardez bien la partie troubleshooting à la fin du README du repo sirene_as_api : il est mentionné qu'il peut y avoir un problème de copie des fichiers solr, ce qui peut empecher Solr de se lancer. Avez vous essayé la solution proposée ?

mpo-deltacode commented 5 years ago

Bonjour, je pense avoir trouvé d'où vient le problème, mais je n'ai pas encore tester (je pense que, vu que dans le fichier database.yml, je ne passe le mot de passe que de l'environnement production, et que les autres environnements les récupèrent de "default", il doit y avoir un problème lors du passage du mot de passe, du coup je vais tester en faisant en sorte que chaque environnement ai son mot de passe directement écrit, et non récupérer )

Mais ce matin je me confronte à un nouveau problème. J'ai réussi a peupler la base vendredi dernier sans soucis, mais aujourd'hui, je réessaye et je tombe sur l'erreur Error : http://data.cquest.org/geo_sirene/2019-07/geo_sirene.csv.gz could not be reached. et effectivement il n'y a pas le dossier geo_sirene du mois de Juillet. Est ce parce que vous faites une mise à jour de l'API ? Ou une erreur?

Cordialement

Samuelfaure commented 5 years ago

C'est du à la mise à jour en effet. A priori il faudra attendre la nouvelle release (chantier en cours) pour avoir des données à jour

mpo-deltacode commented 5 years ago

Une autre question, j'ai installé INSEE sur un deuxième serveur, mais au lieu d'indiquer l'adresse IP du serveur, j'ai indiqué le nom de domaine que j'ai associé à ce serveur.

J'ai donc, dans le fichier sirene_as_api.yml, dans la clé client_server_name, le nom de domaine de mon serveur. Puis dans le fichier deploy.rb Le déploiement s'est passé sans soucis, mais lorsque j'ai tenter de faire une requête comme celle ci example.mondomaine.fr/v1/siren/852832260 l'API me retourne 'result not found'

Y a t-il un autre fichier où je dois indiquer le nom de domaine ?

Cordialement

Samuelfaure commented 5 years ago

A priori ces soucis tiennent davantage d'un problème personnel que du code, les issues github sont donc peu adaptées pour ça. Je vais fermer ici. Envoyez moi un message à l'occasion, si j'ai du temps libre je regarderais.

mpo-deltacode commented 5 years ago

Je comprend, pas de soucis, je vais regarder de plus pres

Merci a vous