B2C-exploit

B2C-exploit.md

Exploitation

Relancer les flux b2c

Comportement attendu

La tâche job se lance toutes les minutes, interroge la table referential.job (champs status et date) et lance les tâches en attente en commençant par la plus ancienne. 1 = en attente, 2 = ko ou 4 = ok.

En BDD, la base referential est celle remplie par Resadec, la table magento, par Magento.

Exception faite de referential.job qui est en dehors du processus. C'est la commande data:magento:product:erp-import-from-referential qui fait le lien entre les deux bases. Dans cette table, chaque entrée est un job qui contient les champs suivants :

• id
• code : la commande Symfony à exécuter (ex. data:referential:integrate-flux)
• parameters : les paramètres de la commande Symfony
• status : le statut de la commande, à savoir 1 (en attente), 2 (ko) ou 4 (ok)
• created_at : timestamp de l'ajout de la commande à la file d'attente
• started_at : début de traitement de la commande
• finished_at : fin de traitement de la commande (NULL si ko ou en cours)
• nb_try

Toutes les heures, de 8h30 à 18h30, des flux partiels (le flag -partial est ajouté à la fin du nom de ces archives) sont ajoutés à la file d'attente. La nuit, un flux complet (ou full) reprend tous les flux horaires de la journée.

La table est alimentée lors de l'update du FTP par Resadec, qui envoie ses données. À la réception des données, l'archive est créée et la commande associée est ajoutée à la table job (cf. tâche data:referential:download-flux).

Côté délai, l'intégration d'un catalogue partiel prend environ 1h.

La tâche plante

On reçoit un mail type : mail : Cron deployer@decdec-pw01-web cd $CLI_ROOT && bin/cli job:run >> $REFERENTIAL_LOG/cli_job_run.log (failed)

Ce mail indique notamment que le lock a plus de 4h, indice fort d'un plantage des flux. Le lock est un fichier qui s'assure de l'unicité de l'exécution des tâches et évite les tâches en concurrence. Il est "touch" à chaque consultation, ce qui met à jour son timestamp.

Depuis l'intégration de Datadog sur pw01, la tâche plante.

Relancer les flux

1. Kill les process fantômes

   • Se connecter au serveur de prod pw01 :

     ssh decitre-preprod-2023
     sudo -iu deployer
     ssh decdec-pw01-web

   • Identifier les process job:run fantômes :

     ps aux | grep job

     Hors plantage, ce process devrait toujours être unique.
   • Kill tous les php bin/cli job:run car ils sont tous obsolètes.
     Les logs associés sont des tâches enfants qui seront kill en même temps que leur parent.
     Commande :

     kill <id_du_process>

     Faire des copier-coller pour éviter les fautes de frappe lors du kill des process à partir de leurs IDs (seconde colonne du grep).
     Chaque process est kill un par un. Des mails de Cron confirmant que les process ont failed sont reçus.

2. Annuler les tâches obsolètes

   • Avant de relancer, passer les -partial des jours complets en ok (4) dans la BDD, puisqu'un full est également dans la liste. Éditer la table directement.

3. Relancer le flux

   • Vérifier le lock :

     ll /tmp/*lock

     Retourne quelque chose comme :

     -rw-rw-r-- deployer deployer <timestamp> /tmp/lock_job_run_b2c
     

   • Supprimer le lock :

     rm /tmp/lock_job_run_b2c

     Il est théoriquement supprimé automatiquement après chaque job, permettant à un autre de se lancer.

La suppression du lock indique au job qu'il peut passer à la commande suivante, les flux sont relancés. Il ne reste plus qu'à informer le métier et l'équipe dev (room IT X Ecom) de la date du plantage en précisant que la reprise est en cours.