RFC: messenger integration

TLDR;

L'intégration de symfony/messenger dans le role lephare/ansible-deploy me semble liée au transport Doctrine alors qu'on devrait tenir compte d'autre type de Transport (RabbitMQ par exemple).

Aujourd'hui crontab est utilisé pour lancer les workers. Je comprends que ce soit "good enough" pour la plupart des cas , mais nous devrions avoir des alternatives possibles, notamment ne pas utiliser crontab/Doctrine et préférer avoir la situation suivante:

utiliser Systemd en process manager pour s'assurer que nos workers tournent
utiliser --memory-limit=128M ou --time-limit=3600 en option du messenger:consume afin d'éviter les problèmes de mémoire. Systemd se charge de créer un nouveau process dans ce cas.
lancer la commande messenger:stop-workers au déploiement et pas forcément au before_doctrine

Aussi, je trouve dommage d'utiliser crontab car

on impose un delta de temps d'office au traitement asynchrone d'une tâche. Par exemple, si je configure un worker pour être lancé toutes les 7 minutes et que le worker plante au bout d'une minute, je devrais attendre le nextRun.
on se limite à 1 worker par symfony_messenger_queues alors que Systemd peut lancer plusieurs workers.

Comment ça marche ajd ?

https://github.com/le-phare/ansible-deploy/blob/master/config/steps/symfony/messenger/after_symlink.yml

- name: LEPHARE | MESSENGER | setup transports
  shell: chdir={{ ansistrano_release_path.stdout }}
    APP_ENV={{symfony_env}} {{symfony_php_path}} {{symfony_console_path}} messenger:setup --no-interaction

- name: LEPHARE | MESSENGER | schedule workers
  ansible.builtin.cron:
    name: "Messenger worker schedule for {{ item.name }} #{{ ansible_loop.index }}"
    minute: "*/{{ item.time_limit }}"
    job: cd {{ ansistrano_release_path.stdout }}; APP_ENV={{ symfony_env }} {{ symfony_php_path }} {{ symfony_console_path }} messenger:consume {{ item.name }} --no-interaction --time-limit={{ item.time_limit * 60 }} --quiet
  loop: "{{ symfony_messenger_queues | list }}"
  loop_control:
    extended: true

- name: LEPHARE | MESSENGER | restart workers
  raw: cd {{ ansistrano_release_path.stdout }}; nohup APP_ENV={{ symfony_env }} {{ symfony_php_path }} {{ symfony_console_path }} messenger:consume {{ item.name }} --no-interaction --time-limit={{ item.time_limit * 60 }} --quiet </dev/null >/dev/null 2>&1 &
  loop: "{{ symfony_messenger_queues | list }}"

Cette tâche est exécutée lors que la variable symfony_messenger_enabled est true.

https://github.com/le-phare/ansible-deploy/blob/master/config/steps/symfony/messenger/before_doctrine.yml

- name: LEPHARE | MESSENGER | stop workers
  shell: chdir={{ ansistrano_release_path.stdout }}
    APP_ENV={{symfony_env}} {{symfony_php_path}} {{symfony_console_path}} messenger:stop-workers --no-interaction

Suggestions

Documenter les limites de l'intégration actuelle ou les cas d'usages prévus.
Découpler l'intégration du Transport. Par exemple la variable symfony_messenger_enable n'a a priori rien à voir avec la tâche symfony_messenger_enable

Références:

https://symfony.com/doc/current/messenger.html#deploying-to-production

Salut @pierreboissinot !

L'intégration de symfony/messenger dans le role lephare/ansible-deploy me semble liée au transport Doctrine alors qu'on devrait tenir compte d'autre type de Transport (RabbitMQ par exemple).

J'imagine que tu fait reference au setup-transport, effectivement doctrine nécessite cette étape mais d'autres transports peuvent l'implementer un jour (et probablement RabbitMQ pourrait faire partie de ceux là). Si tu utilises RabbitMQ ça fonctionne bien également.

Aujourd'hui crontab est utilisé pour lancer les workers. Je comprends que ce soit "good enough" pour la plupart des cas , mais nous devrions avoir des alternatives possibles, notamment ne pas utiliser crontab/Doctrine [...]

Crontab faisait partie des pré-requis et les hébergeurs nous fournissent généralement une implémentation satisfaisante. Nos experiences avec "supervisord", "systemd" et "pm2" n'étaient pas aussi fiable.

Aussi, je trouve dommage d'utiliser crontab car

on impose un delta de temps d'office au traitement asynchrone d'une tâche. Par exemple, si je configure un worker pour être lancé toutes les 7 minutes et que le worker plante au bout d'une minute, je devrais attendre le nextRun.

Il s'agissait d'un tradeoff acceptable, un traitement asynchrone par définition n'est pas prioritaire. si ce traitement nécessite plus d'attention, tu peux mettre en place un healthcheck qui t'alertes qu'il tombe et / ou simplement réduire la durée d'execution en contre partie des performances.

on se limite à 1 worker par symfony_messenger_queues alors que Systemd peut lancer plusieurs workers.

Non ce n'est pas le cas tu peux regarder la documentation que j'ai écrite ici https://github.com/le-phare/ansible-deploy/blob/master/docs/symfony/messenger.md

Pour résumé, a mon avis, cette tâche remplie tout ce qu'on lui demande sans avoir besoin d'intervention de l’hébergeur. Si l’hébergeur propose une autre solution je pense qu'il est préférable de créer une tache custom dans ton projet et de désactiver celle-ci.

le-phare / ansible-deploy