Ajouter l'aide LaTeX pour les utilisateurs

Servir des pages d’aide LaTeX depuis un site MediaWiki sous /learn sur un déploiement Kubernetes.

Les pages /learn sont servies par le service web (le module learn) de chaque pod Ayakaleaf Pro, à partir d’un cache du wiki défini dans WIKI_URL. Le fonctionnement du module et les wikis compatibles sont décrits dans Ajouter l’aide LaTeX pour les utilisateurs.

Service	web (module learn), dans chaque pod Ayakaleaf Pro
Pod → extérieur	WIKI_URL (par défaut https://learnwiki.overleaf.com) : toutes les pages au premier démarrage, puis une page à nouveau lorsqu’un utilisateur l’ouvre après WIKI_MAX_CACHE_AGE
Navigateur → extérieur	les images des pages, directement depuis WIKI_URL
Données stockées	le cache des pages dans /var/lib/overleaf/data/learnPages sur le volume de données
Tâches périodiques	aucune : les pages sont actualisées lorsque les utilisateurs les ouvrent

​

Configuration

30-config.yaml (additions)

  OVERLEAF_PROXY_LEARN: "true"
  # optional: your own MediaWiki
  # WIKI_URL: https://wiki.example.com

kubectl apply -f 30-config.yaml
kubectl -n overleaf rollout restart deployment/overleaf     # or statefulset/overleaf
kubectl -n overleaf rollout status deployment/overleaf --timeout=30m

Lors de son premier démarrage avec le module activé, le service web télécharge l’intégralité du wiki avant d’accepter des requêtes, ce qui prend plusieurs minutes. Le pod reste non prêt jusque-là ; prévoyez-le donc dans rollout status --timeout et dans toute sonde de démarrage ou de vivacité (liveness) que vous ajoutez. Les démarrages suivants réutilisent le cache présent sur le volume de données.

Au premier démarrage, avant qu’un cache n’existe, les pods doivent pouvoir atteindre WIKI_URL : sans cela, le service web échoue au démarrage et est relancé encore et encore à l’intérieur du pod, si bien que le pod ne devient jamais prêt. Désactivez le module, ou autorisez les pods à sortir vers le wiki. Une fois le cache constitué, les pods démarrent et servent les pages en cache même lorsque le wiki est injoignable.

​

Plusieurs réplicas

Chaque réplica conserve son propre cache sur le disque de son nœud ; chacun télécharge donc le wiki à son premier démarrage. Avec podManagementPolicy: OrderedReady, ils le font l’un après l’autre. Un utilisateur peut voir une page dans une version légèrement différente sur un autre réplica jusqu’à ce qu’elle y soit actualisée.

​

Testé sur Kubernetes

Sur Kubernetes 1.37 avec trois réplicas derrière HAProxy, chacun téléchargeant https://learnwiki.overleaf.com dans le cache de son propre nœud à son premier démarrage, nos tests de bout en bout pour /learn réussissent (12 cas) : le lien Documentation dans l’en-tête, le message de bienvenue et le menu Aide de l’éditeur, la barre latérale du sommaire, les pages, liens et redirections au sein du wiki, les images chargées depuis le wiki, l’erreur 404 pour les pages inconnues, la connexion requise sans accès public, et une page obsolète servie depuis le cache après que WIKI_URL a été remplacée par une adresse injoignable. En démarrant avec un cache vide et WIKI_URL pointant vers une adresse qui refuse les connexions, le pod est resté non prêt sans redémarrer, tandis que le service web qu’il contient a démarré et échoué 77 fois en trois minutes.