le-phare / ansible-deploy Goto Github PK

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

1. Documenter les limites de l'intégration actuelle ou les cas d'usages prévus.
2. 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

I can't use recent changes on main branch because "Build Ansible docker" workflow is scheduled.

The docker image lephare/ansible-deploy should on merge event.

Cela pourrait être intéressant d'avoir les commit associés à la release pour laisser Sentry deviner le commit qui a introduit une issue.

Doc: https://docs.sentry.io/workflow/releases/?platform=javascript#link-a-repository

Par default, pour ansible, c'est ~/.composer hors, dans la version 2 de composer, la home est soit dans XDG_CONFIG_HOME soit ~/.config/composer

Ce qui pose soucis lors de l'authentification (via le auth.json) packagist.

PostgresQL 16 has been released in September.

The image incudes pg_restore for PostgreSQL 15.4.

So, we can't restore a dump created by newer pg_dump version, like 16.0.

For project using cachetool 3.X , the URL results in 404:
https://github.com/gordalina/cachetool/releases/download/3.2.2/cachetool.phar"

Olds versions aren't accessible by releases path but tag path, see https://github.com/gordalina/cachetool#installation---old-versions

Expect behavior:
https://gordalina.github.io/cachetool/downloads/cachetool-3.2.2.phar

Permet d'utiliser lfs dans les actions GitHub

Add a github action to prepare new releases.

Aujourd'hui les .bashrc sur les machines ne satisfont personne, du coup chacun écrit son .bashrc à la main.
Le deploy pourrait envoyer un ou plusieurs .bashrc dans un dossier ~/.bashrc.d:
----~/
--------.bashrc.d/
------------.bashrc (commun à tout projet utilisant lephare/ansible-deploy)
------------.projetrc (optionnel, spécifique au projet)
Où le ~/.bashrc source tout fichier se trouvant dans le répertoire ~/.bashrc.d

Il faudrait se mettre d'accord sur un .bashrc commun. A partir de ceux que nous avons l'habitude d'utiliser on a de quoi faire cc @Athalyan @jacbac

Extrait d'une discussion avec @erichard

Description du problème

Après installation d'un nouveau projet utilisant le-phare/ansible-deploy ainsi que les recipes Flex le-phare/flex-recipes, certaines tâches de déploiement en preprod s'effectuent avec un environnement Symfony prod.

Hypothèse

cbrunnkvist/ansistrano-symfony-deploy utilise la variable symfony_env afin de déterminer quel env Symfony utiliser pour certaines commandes (via les variables d'env SYMFONY_ENV et APP_ENV).

Nous faisons également appel à cette variable Ansible dans ce projet : exemple, mais nous n'avons pas de valeur par défaut pour cette variable.
La valeur par défaut de ansistrano-symfony-deploy est alors choisie, qui est prod.

La recette le-phare/flex-recipes deploy-pack utilise également cette variable Ansible : voir code, mais ne définit pas non plus de valeur par défaut.

Ce projet déclare une variable nommée application_environment que je trouve conceptuellement proche de symfony_env.

Proposition de modification

"Unifier" les variables Ansible application_environment et symfony_env comme ceci :

symfony_env: "{{ application_environment }}"

dans defaults/main.yaml ou dans le fichier ansible/_variables.yml de la recette deploy-pack de le-phare/flex-recipes (lien).