Fonctionnalités de site : Horizon, Reverb, Pulse, WordPress

Les fonctionnalités de site sont des configurations toutes prêtes pour les outils qu'utilise votre framework, comme Laravel Horizon, Reverb ou le cron de WordPress. Vous les activez depuis le menu du framework dans l'en-tête du site, et Vimonto Deploy configure sur le serveur tout ce dont l'outil a besoin : processus Supervisor, tâches cron, directives Nginx et valeurs du .env. Le menu, et le bouton Ouvrir à côté, apparaissent une fois la première installation du site terminée et sa première version en ligne.

La fenêtre de chaque fonctionnalité montre exactement ce qu'elle va configurer avant que vous ne l'activiez, et les fonctionnalités sont redémarrées après chaque déploiement si nécessaire.

Ouvrir le menu des fonctionnalités#

Le menu se trouve dans l'en-tête du site et porte le nom du framework du site, par exemple Laravel ou WordPress. Il s'ouvre sur les fonctionnalités du framework, comme Fonctionnalités Laravel, avec un point vert pour celles qui sont activées et un compteur comme 2 sur 7 activées.

Vimonto Deploy lit les paquets de votre composer.json et de votre package.json à chaque déploiement. Les fonctionnalités dont votre application utilise le paquet sont marquées Dans votre code et listées en premier, avec les fonctionnalités déjà activées ; les autres se trouvent derrière Tout afficher (… de plus, absentes de votre code). Jusqu'au premier déploiement, toutes les fonctionnalités sont listées.

Activer ou désactiver une fonctionnalité#

1. Cliquez sur la fonctionnalité dans le menu pour ouvrir sa fenêtre.
2. Renseignez ses réglages, s'il y en a.
3. Vérifiez Ce que nous configurons et Nous définissons dans votre .env. Les clés dont la valeur change sont marquées change.
4. Cliquez sur Activer.

L'activation s'exécute sous forme de tâche en arrière-plan que vous pouvez suivre dans l'en-tête du site. En cas d'échec, la fonctionnalité affiche Échoué dans le menu et vous recevez une notification ; ouvrez-la et cliquez sur Enregistrer pour réessayer, ou sur Réessayer pour une fonctionnalité sans réglages, comme le Planificateur ou Pulse. Les deux appliquent à nouveau les mêmes réglages. Pour modifier les réglages d'une fonctionnalité activée, ouvrez-la, modifiez-les et cliquez sur Enregistrer. Pour la désactiver, ouvrez-la et cliquez sur Désactiver : ses processus, ses tâches cron et ses directives Nginx sont supprimés. Les valeurs qu'elle a définies dans le .env restent.

Les fonctionnalités nécessitent un site configuré et, pour la plupart, déployé : leurs commandes s'exécutent dans la release en ligne. Les fonctionnalités avec des directives Nginx nécessitent la configuration Nginx générée du site, ou une configuration personnalisée qui conserve la ligne d'include des directives supplémentaires.

Quelles fonctionnalités existe-t-il ?#

Les processus tournent sous Supervisor avec l'utilisateur du site et apparaissent sur la page files d'attente et planificateur avec un badge Via …. Les tâches cron s'exécutent sous l'utilisateur du site.

Fonctionnalités Laravel#

Planificateur#

Exécute vos commandes planifiées : une entrée cron exécute php artisan schedule:run chaque minute dans la release en ligne. C'est le même interrupteur que Activer sur la page files d'attente et planificateur.

Horizon#

Fait tourner vos files Redis avec Laravel Horizon : un programme Supervisor exécute php artisan horizon, qui démarre chaque worker décrit dans votre config/horizon.php.

• Réglage : Tâche la plus longue (secondes), 3600 par défaut. Lors d'un déploiement, les jobs en cours disposent de ce délai pour se terminer avant l'arrêt du processus.
• Après chaque déploiement : php artisan horizon:terminate, pour qu'Horizon termine ses jobs et que Supervisor le relance sur le nouveau code.
• .env : QUEUE_CONNECTION=redis.
• Lien : le Tableau de bord Horizon sur /horizon.

La fenêtre vous avertit quand le site a aussi ses propres queue workers (supprimez-les, pour que les jobs ne soient pas traités deux fois), et quand le serveur n'a pas Redis (faites pointer REDIS_HOST vers un serveur de cache).

Reverb#

Fait tourner Laravel Reverb, le serveur WebSocket pour le broadcasting, sur sa propre adresse WebSocket.

• Adresse WebSocket : ws. suivi du domaine du site par défaut, comme ws.shop.example.com.
• Port local : le port sur lequel Reverb écoute, uniquement sur le serveur lui-même, à partir de 8080. Chaque application du serveur a besoin du sien.

Quand vous l'activez, Vimonto Deploy :

• exécute php artisan reverb:start --host=127.0.0.1 --port=… sous Supervisor ;
• ajoute l'adresse WebSocket aux noms du site, ainsi que des règles Nginx qui transmettent /app/ (connexions WebSocket) et /apps/ (l'API HTTP de Reverb) à Reverb ;
• crée l'enregistrement DNS quand l'adresse est sur on-deploy.link, ou quand le domaine du site est géré par une intégration DNS connectée ; un enregistrement qui y pointe ailleurs et que Vimonto Deploy n'a pas créé est laissé tel quel, et la tâche le signale. Sinon, la fenêtre liste l'enregistrement A à créer, pointant vers l'adresse IP du serveur ;
• demande un nouveau certificat Let's Encrypt incluant l'adresse WebSocket quand le site en a déjà un et que le nom pointe vers le serveur. Sinon, demandez un nouveau certificat dans domaines et SSL une fois l'enregistrement DNS en place ;
• exécute php artisan reverb:restart après chaque déploiement.

Elle définit ces clés dans le .env, en réutilisant l'ID, la clé et le secret d'application Reverb si votre .env les contient déjà, et en les générant sinon :

BROADCAST_CONNECTION=reverb
REVERB_APP_ID=…
REVERB_APP_KEY=…
REVERB_APP_SECRET=…
REVERB_HOST=ws.shop.example.com
REVERB_PORT=443
REVERB_SCHEME=https
REVERB_SERVER_HOST=127.0.0.1
REVERB_SERVER_PORT=8080
VITE_REVERB_APP_KEY="${REVERB_APP_KEY}"
VITE_REVERB_HOST="${REVERB_HOST}"
VITE_REVERB_PORT="${REVERB_PORT}"
VITE_REVERB_SCHEME="${REVERB_SCHEME}"

Sans HTTPS sur le site, REVERB_PORT vaut 80 et REVERB_SCHEME vaut http. Redéployez ensuite, pour que votre build frontend prenne en compte les valeurs VITE_. Une fois Reverb activé, la fenêtre affiche l'Adresse WebSocket complète à laquelle vos clients se connectent.

Pulse#

Maintient php artisan pulse:check en marche, pour que le tableau de bord Laravel Pulse affiche le CPU, la mémoire et le disque du serveur. Elle exécute pulse:restart après chaque déploiement et renvoie au Tableau de bord Pulse sur /pulse.

Inertia SSR#

Génère le rendu des pages Inertia côté serveur, pour des premiers chargements plus rapides et de meilleurs résultats dans les moteurs de recherche. Elle exécute php artisan inertia:start-ssr sous Supervisor et inertia:stop-ssr après chaque déploiement, pour que le serveur de rendu redémarre sur le nouveau bundle.

• Construisez aussi le bundle SSR dans votre script de déploiement, par exemple npm run build && npx vite build --ssr. La fenêtre vous avertit si elle n'y trouve pas --ssr.
• Le serveur a besoin de Node.js (les serveurs d'application et web l'ont).
• Le serveur SSR écoute sur le port d'Inertia, 13714 : un seul site par serveur peut donc l'utiliser.

Nightwatch#

Maintient l'agent Laravel Nightwatch en marche (php artisan nightwatch:agent), pour que votre application envoie ses données à Nightwatch.

• Réglage : Jeton Nightwatch, issu de votre application sur nightwatch.laravel.com. Laissez-le vide par la suite pour garder le token actuel.
• .env : NIGHTWATCH_TOKEN, affiché masqué dans la fenêtre.

Fonctionnalités Symfony#

Workers Messenger#

Exécute bin/console messenger:consume pour vos transports Symfony Messenger, avec --time-limit=3600 --env=prod.

• Transports : séparés par des espaces, par ordre de priorité, comme async scheduler_default. Par défaut : async.
• Processus : le nombre de workers qui tournent côte à côte (de 1 à 20).
• Après chaque déploiement : messenger:stop-workers, pour que Supervisor les relance sur le nouveau code.

Fonctionnalités WordPress#

Les fonctionnalités WordPress utilisent WP-CLI, que Vimonto Deploy installe sur le serveur (dans /usr/local/bin/wp) la première fois qu'une fonctionnalité en a besoin.

Vrai cron pour WordPress#

WordPress exécute normalement ses tâches planifiées quand quelqu'un visite une page, ce qui les fait sauter sur les sites peu fréquentés et ralentit les sites très fréquentés. Vrai cron définit DISABLE_WP_CRON dans wp-config.php et exécute à la place wp cron event run --due-now chaque minute via une vraie tâche cron. La désactiver retire à nouveau la constante.

Cache d'objets Redis pour WordPress#

Installe et active le plugin Redis Object Cache et active le cache, pour que WordPress cesse de poser les mêmes questions à la base de données à chaque requête. Elle nécessite Redis sur le serveur ; la fonctionnalité n'est pas disponible sur les serveurs qui en sont dépourvus. La désactiver désactive le cache et le plugin.

Durcissement pour WordPress#

Ferme les portes par lesquelles passent habituellement les attaques contre WordPress :

• Nginx refuse xmlrpc.php ;
• Nginx refuse d'exécuter des fichiers PHP dans wp-content/uploads ;
• DISALLOW_FILE_EDIT désactive l'éditeur de fichiers de thèmes et de plugins dans le tableau de bord.

Maintenance et accès#

Mode maintenance#

Affiche aux visiteurs une page de maintenance jusqu'à ce que vous le désactiviez. Tant qu'il est activé, l'en-tête du site affiche Mode maintenance ; cliquez dessus pour ouvrir la fenêtre.

• Laravel et Statamic : exécute php artisan down avec un secret et --retry=60. La fenêtre affiche un Lien de contournement (dépose un cookie) qui vous permet de voir le site normalement. À chaque activation, le secret change : un ancien lien cesse donc de fonctionner. L'état est conservé dans storage/, partagé entre les releases : il survit donc aux déploiements.
• WordPress : exécute wp maintenance-mode activate.

Protection par mot de passe#

Demande un nom d'utilisateur et un mot de passe (authentification HTTP basique) avant que quiconque ne voie le site : utile pour les sites de staging et les aperçus sur l'adresse on-deploy.link.

• Nom d'utilisateur : preview par défaut ; lettres, chiffres, ., _ et -.
• Mot de passe : au moins 8 caractères. Seul un hash bcrypt est stocké. Laissez-le vide par la suite pour garder le mot de passe actuel.

Let's Encrypt peut toujours atteindre le site pour délivrer et renouveler les certificats pendant qu'il est protégé. Sur un site à charge répartie, la protection par mot de passe est la seule fonctionnalité, et elle protège d'un coup tous les serveurs d'application placés derrière le load balancer.

Pour ne protéger qu'un chemin, comme /admin, ou donner à plusieurs personnes leur propre connexion, utilisez plutôt des règles de sécurité. Une règle de sécurité pour tout le site et la protection par mot de passe ne peuvent pas être actives en même temps.

Questions fréquentes#

Que signifie « Dans votre code » ?#

Le paquet de la fonctionnalité figure dans votre composer.json ou votre package.json lors du dernier déploiement, par exemple laravel/horizon pour Horizon. Vous pouvez tout de même activer les fonctionnalités non trouvées ; ouvrez Tout afficher pour les voir.

Désactiver une fonctionnalité supprime-t-il ses valeurs du .env ?#

Non. Les processus, les tâches cron et les directives Nginx sont supprimés, mais les valeurs définies par la fonctionnalité dans le .env restent. Modifiez-les sur la page environnement si vous n'en avez plus besoin.

Pourquoi une fonctionnalité n'est-elle pas disponible ?#

La fenêtre indique pourquoi, par exemple Il n'y a pas de Redis sur ce serveur., Ce serveur n'a pas Node.js., ou le fait que le site a sa propre configuration Nginx sans l'include des directives supplémentaires.

Puis-je modifier moi-même le processus d'une fonctionnalité ?#

Pas directement. Les processus et tâches cron créés par une fonctionnalité ne sont modifiés et supprimés que via la fonctionnalité, pour qu'ils correspondent toujours à ses réglages. Ajoutez vos propres queue workers ou processus serveur pour tout le reste.