Quels sont tous les hooks dont je peux me servir dans app.yml

Bonjour, j’essaie de configurer un hook pour me connecter automatiquement à mon réseau docker lorsque discourse redémarre ou démarre après une construction. Ceci afin de pouvoir utiliser l’updater web admin lorsque je le peux, mais j’essaie de trouver la meilleure façon de procéder. Les docs ne disent pas vraiment tous les types de hooks que je peux utiliser et la recherche de hooks tels que after_post_boot et after_restart ne donne rien. Ces hooks ne fonctionnent-ils plus et si oui, pourquoi ? Voici mon code de hooks.

hooks:

début du hook de réseau personnalisé

after_restart:

  • exec:
    cmd:
  • bash
  • “-c”
  • |

Connecter Discourse au réseau Docker s’il n’est pas déjà connecté

NETWORK_NAME=“proxy”
CONTAINER_NAME=$(hostname)

        # Créer le réseau s'il n'existe pas
        if ! docker network inspect "$NETWORK_NAME" >/dev/null 2>&1; then
          echo "Création du réseau Docker : $NETWORK_NAME"
          docker network create "$NETWORK_NAME"
        fi

        # Connecter le conteneur au réseau (ignorer s'il est déjà connecté)
        echo "Connexion de $CONTAINER_NAME à $NETWORK_NAME..."
        docker network connect "$NETWORK_NAME" "$CONTAINER_NAME" 2>/dev/null || true

        echo "Connexion réseau terminée."

fin du hook de réseau personnalisé

Il n’existe en fait pas de liste globale fixe de types de hooks dans app.yml.
Les hooks sont fournis dynamiquement par Pups, et vous ne pouvez vous attacher qu’à ceux qui existent dans les modèles que vous incluez.


:magnifying_glass_tilted_left: Comment ça marche

Lorsque vous voyez quelque chose comme :

hooks:
  after_code:
    - exec:
        cd: $home/plugins
        cmd:
          - git clone https://github.com/discourse/docker_manager.git

cela fonctionne parce que les modèles contiennent une étape comme :

- hook: code
  run:
    - exec: ...

Pups vous permet d’attacher des commandes avant ou après n’importe lequel de ces points de hook définis.
Donc, si un modèle définit hook: code, vous pouvez utiliser before_code: ou after_code:.
S’il définit hook: assets_precompile, vous pouvez utiliser before_assets_precompile: ou after_assets_precompile: — et ainsi de suite.

S’il n’y a pas de hook: restart (par exemple), alors after_restart: ne se déclenchera tout simplement pas.


:white_check_mark: Hooks connus pour exister dans les modèles par défaut

À partir des templates/*.yml par défaut fournis avec Discourse Docker :

Nom du hook Usage courant Fonctionne avec
code Phase de configuration principale pour le clonage de plugins, les modifications de fichiers personnalisés, etc. before_code: / after_code:
assets_precompile Après la compilation des ressources Rails (par exemple, téléversement vers S3, nettoyage) after_assets_precompile:
web Pour les ajustements de dernière minute avant le démarrage du processus web before_web:

Vous verrez souvent after_code: et before_code: utilisés dans les exemples d’installation de plugins — ce sont les seuls nécessaires dans la plupart des configurations.


:cross_mark: Hooks qui n’existent pas par défaut

Des noms comme after_restart ou after_post_boot ne correspondent à aucun hook: dans les modèles standard, donc Pups ne sait pas où les attacher.
Ils ne se déclencheront pas à moins que vous n’ajoutiez une étape hook: restart correspondante dans un modèle personnalisé.


:toolbox: Comment trouver tous les hooks disponibles sur votre système

Depuis votre dossier /var/discourse, exécutez :

grep -R "hook:" -n templates/ samples/

Cela listera chaque nom de hook pris en charge par les modèles que vous incluez actuellement.
Tout ce que vous y trouverez peut être utilisé comme before_<nom>: ou after_<nom>: dans votre bloc hooks:.


:blue_book: Référence

Ce comportement est brièvement expliqué dans le README de Pups (l’outil de gestion de configuration utilisé par la configuration Docker de Discourse) :

“Les hooks sont des points dans les modèles qui permettent d’injecter des commandes avant ou après une étape marquée avec hook:.”


:puzzle_piece: En pratique

  • Utilisez after_code: pour la plupart des commandes shell personnalisées (comme les installations de plugins).
  • Pour les choses qui devraient se produire au démarrage ou au redémarrage du conteneur, utilisez un petit script de démarrage ou une tâche supervisord au lieu d’inventer de nouveaux noms de hooks.
  • Pour ajouter votre propre type de hook, créez un nouveau modèle avec une entrée hook: quelque chose, puis ciblez-le depuis app.yml.

TL;DR :
Seuls les noms de hooks qui apparaissent réellement comme entrées hook: dans vos modèles existent.
Dans le Discourse Docker standard, il s’agit essentiellement de code, assets_precompile et web.

2 « J'aime »

Pour référence, je pense que le dépôt pups se trouve ici :

@Ethsim2 Je ne vois rien à propos de

Peut-être devriez-vous examiner la réponse de l’IA avant de la publier :slightly_smiling_face:.

D’après le README :

Exécutez des commandes avant et après une commande spécifique en définissant un hook.

1 « J'aime »

Qu’en est-il ?

Les hooks vous permettent d’exécuter des commandes personnalisées avant ou après une étape de build spécifique, en définissant before_<nom>: ou after_<nom>: correspondant à une étiquette hook: <nom> dans un modèle.

1 « J'aime »

Je ne pense pas que les hooks vous aideront. Dites-vous que lorsque vous exécutez le web-updater, votre conteneur se déconnecte du réseau docker ?

Je suis à peu près sûr que le web-updater ne redémarre pas le conteneur – c’est ainsi qu’il peut s’exécuter sans arrêter Discourse.

1 « J'aime »

C’est exact.

Il faut également noter que les hooks sont exécutés à l’intérieur du conteneur, pour construire l’image de discourse. Rien n’y est exécuté sur l’hôte, et il n’y a aucun moyen via les fonctions du lanceur de recréer ou de détruire les réseaux docker.

Peut-être serait-il préférable d’expliquer le problème que vous rencontrez dans votre hébergement afin que nous ayons une meilleure compréhension de ce que vous essayez de résoudre.

1 « J'aime »

Mis à jour uniquement via la CLI, ce qui déconnecte du réseau Docker, mais ce n’est que parce que le conteneur redémarre à partir de ce point. J’essaierai le mise à jour web car je ne l’ai pas encore essayée avec cette configuration. Je pensais que le même comportement se produirait ici aussi, mais si la mise à jour web n’arrête pas les conteneurs, il n’y a vraiment rien à craindre. La raison pour laquelle j’ai dit tout cela, c’est parce que j’ai vu des gens avoir des problèmes lors de l’exécution de la mise à jour web à ce moment-là. Mais j’essaierai le mise à jour et je verrai comment cela se passe.

Jonnyboy ! Les iPhones, c’est génial !