3. Déployer MongoDB et Redis

Exécutez MongoDB en replica set et Redis avec persistance, ou utilisez les vôtres.

Ayakaleaf Pro a besoin de :

• MongoDB 8 en replica set (il utilise des transactions). Trois membres répartis sur trois nœuds survivent à la perte d’un nœud ; un seul membre fonctionne également.
• Redis 7, un seul serveur avec persistance AOF. Redis contient les modifications qui ne sont pas encore écrites dans MongoDB, les sessions et les messages échangés entre les services Overleaf. Overleaf se connecte à un seul serveur Redis : Sentinel et Redis Cluster ne sont pas pris en charge.

Vous pouvez utiliser des services managés à la place, comme MongoDB Atlas ou le Redis de votre cloud. Ignorez cette page et faites pointer OVERLEAF_MONGO_URL et OVERLEAF_REDIS_HOST vers eux à l’étape 4.

1. MongoDB

   10-mongo.yaml

   apiVersion: v1
   kind: Service
   metadata:
     name: mongo
     namespace: overleaf
   spec:
     clusterIP: None                 # headless: gives mongo-0.mongo, mongo-1.mongo, ...
     publishNotReadyAddresses: true  # members must resolve each other before the set is initiated
     selector:
       app: mongo
     ports:
       - name: mongo
         port: 27017
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: mongo
     namespace: overleaf
   spec:
     serviceName: mongo
     replicas: 3
     selector:
       matchLabels:
         app: mongo
     template:
       metadata:
         labels:
           app: mongo
       spec:
         affinity:
           podAntiAffinity:
             requiredDuringSchedulingIgnoredDuringExecution:
               - labelSelector:
                   matchLabels:
                     app: mongo
                 topologyKey: kubernetes.io/hostname
         containers:
           - name: mongo
             image: mongo:8.0
             args:
               - --replSet=overleaf
               - --bind_ip_all
               - --wiredTigerCacheSizeGB=0.25   # default is 50% of (RAM - 1 GB); size it for your nodes
             # env:
             #   - name: GLIBC_TUNABLES        # only on kernel 6.19+ (SERVER-121912)
             #     value: glibc.pthread.rseq=1
             ports:
               - containerPort: 27017
             readinessProbe:
               tcpSocket:
                 port: 27017
             resources:
               requests:
                 cpu: 100m
                 memory: 384Mi
               limits:
                 memory: 768Mi
             volumeMounts:
               - name: data
                 mountPath: /data/db
     volumeClaimTemplates:
       - metadata:
           name: data
         spec:
           accessModes: [ReadWriteOnce]
           resources:
             requests:
               storage: 5Gi
   ---
   # Initiates the replica set once. Safe to re-run: it does nothing when the set exists.
   apiVersion: batch/v1
   kind: Job
   metadata:
     name: mongo-init-replica-set
     namespace: overleaf
   spec:
     backoffLimit: 20
     template:
       spec:
         restartPolicy: OnFailure
         containers:
           - name: init
             image: mongo:8.0
             command:
               - mongosh
               - --quiet
               - --host=mongo-0.mongo
               - --eval
               - |
                 try {
                   rs.status()
                   print('replica set already initiated')
                 } catch (e) {
                   rs.initiate({
                     _id: 'overleaf',
                     members: [
                       { _id: 0, host: 'mongo-0.mongo.overleaf.svc.cluster.local:27017' },
                       { _id: 1, host: 'mongo-1.mongo.overleaf.svc.cluster.local:27017' },
                       { _id: 2, host: 'mongo-2.mongo.overleaf.svc.cluster.local:27017' },
                     ],
                   })
                 }
   

   kubectl apply -f 10-mongo.yaml
   kubectl -n overleaf rollout status statefulset/mongo
   kubectl -n overleaf wait --for=condition=complete job/mongo-init-replica-set --timeout=5m
   kubectl -n overleaf exec mongo-0 -- mongosh --quiet --eval 'rs.status().members.map(m => m.name + " " + m.stateStr)'
   

   Au bout de quelques secondes, un membre doit être PRIMARY et les autres SECONDARY. Le Job réessaie jusqu’à ce que tous les membres répondent ; quelques pods de Job en échec sont donc normaux.

   • Le Service headless a besoin de publishNotReadyAddresses: true : les membres doivent se trouver mutuellement par leur nom avant que le replica set n’existe.
   • Les membres sont ajoutés avec leurs noms stables (mongo-0.mongo.overleaf.svc.cluster.local), jamais avec les IP des pods, qui changent à chaque redémarrage.
   • Pour un seul membre, définissez replicas: 1 et ne conservez que mongo-0 dans le Job.
2. Redis

   20-redis.yaml

   apiVersion: v1
   kind: Service
   metadata:
     name: redis
     namespace: overleaf
   spec:
     selector:
       app: redis
     ports:
       - name: redis
         port: 6379
   ---
   apiVersion: apps/v1
   kind: StatefulSet
   metadata:
     name: redis
     namespace: overleaf
   spec:
     serviceName: redis
     replicas: 1
     selector:
       matchLabels:
         app: redis
     template:
       metadata:
         labels:
           app: redis
       spec:
         containers:
           - name: redis
             image: redis:7.4
             args: [--appendonly, "yes"]
             ports:
               - containerPort: 6379
             readinessProbe:
               tcpSocket:
                 port: 6379
             resources:
               requests:
                 cpu: 50m
                 memory: 128Mi
               limits:
                 memory: 512Mi
             volumeMounts:
               - name: data
                 mountPath: /data
     volumeClaimTemplates:
       - metadata:
           name: data
         spec:
           accessModes: [ReadWriteOnce]
           resources:
             requests:
               storage: 2Gi
   

   kubectl apply -f 20-redis.yaml
   kubectl -n overleaf rollout status statefulset/redis
   

​

Q&A

MongoDB 8 plante au démarrage sur un noyau récent. Pourquoi ?

Réponse : MongoDB 8 échoue sur les noyaux Linux 6.19 et ultérieurs (SERVER-121912). Décommentez la variable d’environnement GLIBC_TUNABLES dans 10-mongo.yaml.

De combien de mémoire MongoDB a-t-il besoin ?

Réponse : Par défaut, MongoDB utilise pour son cache la moitié de la mémoire du nœud moins 1 Go, et il voit la mémoire du nœud, pas la limite du pod. Ajustez --wiredTigerCacheSizeGB à vos nœuds ; 0.25 a maintenu chaque membre à environ 200 à 260 Mio sur nos nœuds de test de 4 Go.