S3

Conservez les fichiers et l’historique des projets dans un stockage compatible S3 sur un déploiement Kubernetes.

Les fichiers des projets et leur historique sont stockés par le service history-v1, les fichiers des modèles par le service filestore, tous deux dans chaque pod Ayakaleaf Pro. Par défaut, ils écrivent sur le volume de données ; avec S3, ils écrivent dans des buckets. Les buckets et autorisations nécessaires sont décrits dans S3.

Services	history-v1 (fichiers et historique des projets), filestore (fichiers des modèles), dans chaque pod Ayakaleaf Pro
Pod → S3	le point de terminaison S3, pour chaque fichier lu ou écrit
Obligatoire	pour plusieurs répliques : leurs volumes de données ne sont pas partagés, les buckets le sont
Tâches périodiques	aucune

Choisissez S3 avant que les utilisateurs ne créent des projets. Une instance qui conserve déjà des fichiers sur son volume doit d’abord effectuer la migration vers S3.

​

Configuration

1. Buckets et clés

   Créez les trois buckets overleaf-template-files, overleaf-project-blobs et overleaf-chunks ainsi que les deux utilisateurs restreints avec votre service S3, comme décrit dans Configuration de S3, ou exécutez Garage dans le cluster comme indiqué ci-dessous. Placez les quatre clés dans un Secret :

   kubectl -n overleaf create secret generic overleaf-s3 \
     --from-literal=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID=<filestore key> \
     --from-literal=OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY=<filestore secret> \
     --from-literal=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID=<history key> \
     --from-literal=OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY=<history secret>
   
2. ConfigMap

   30-config.yaml (additions)

     OVERLEAF_FILESTORE_BACKEND: s3
     OVERLEAF_FILESTORE_TEMPLATE_FILES_BUCKET_NAME: overleaf-template-files
     OVERLEAF_FILESTORE_S3_REGION: eu-west-1
     OVERLEAF_HISTORY_BACKEND: s3
     OVERLEAF_HISTORY_PROJECT_BLOBS_BUCKET: overleaf-project-blobs
     OVERLEAF_HISTORY_CHUNKS_BUCKET: overleaf-chunks
     OVERLEAF_HISTORY_S3_REGION: eu-west-1
     # a self-hosted S3 service also needs its endpoint and path-style addressing
     # OVERLEAF_FILESTORE_S3_ENDPOINT: http://garage:3900
     # OVERLEAF_FILESTORE_S3_PATH_STYLE: "true"
     # OVERLEAF_HISTORY_S3_ENDPOINT: http://garage:3900
     # OVERLEAF_HISTORY_S3_PATH_STYLE: "true"
   
3. Ajouter le Secret au pod et redémarrer

   Dans le Deployment (ou le StatefulSet), ajoutez le Secret à côté des autres :

             envFrom:
               - configMapRef: {name: overleaf-env}
               - secretRef: {name: overleaf-secrets}
               - secretRef: {name: overleaf-s3}
   

   kubectl apply -f 30-config.yaml -f 40-overleaf.yaml
   kubectl -n overleaf rollout restart deployment/overleaf     # or statefulset/overleaf
   

​

Garage dans le cluster

En l’absence de service S3, Garage est un petit serveur S3 qui s’exécute dans le cluster. La configuration de Mise à l’échelle horizontale a été testée avec lui. Les commandes ci-dessous génèrent elles-mêmes les clés et créent le Secret overleaf-s3 ; utilisez-les donc à la place de la commande de création du Secret de l’étape 1.

MinIO, utilisé dans l’exemple d’Overleaf, ne publie plus d’images de conteneur : minio/minio a disparu de Docker Hub et de quay.io.

50-garage.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: garage-config
  namespace: overleaf
data:
  garage.toml: |
    metadata_dir = "/var/lib/garage/meta"
    data_dir = "/var/lib/garage/data"
    db_engine = "lmdb"
    replication_factor = 1
    rpc_bind_addr = "[::]:3901"
    rpc_public_addr = "127.0.0.1:3901"
    # rpc_secret and admin_token come from GARAGE_RPC_SECRET / GARAGE_ADMIN_TOKEN
    [s3_api]
    s3_region = "garage"          # Overleaf's OVERLEAF_*_S3_REGION must match
    api_bind_addr = "[::]:3900"
    [admin]
    api_bind_addr = "[::]:3903"
---
apiVersion: v1
kind: Service
metadata:
  name: garage
  namespace: overleaf
spec:
  selector:
    app: garage
  ports:
    - name: s3
      port: 3900
---
apiVersion: apps/v1
kind: StatefulSet
metadata:
  name: garage
  namespace: overleaf
spec:
  serviceName: garage
  replicas: 1
  selector:
    matchLabels:
      app: garage
  template:
    metadata:
      labels:
        app: garage
    spec:
      containers:
        - name: garage
          image: dxflrs/garage:v2.5.0
          env:
            - name: GARAGE_RPC_SECRET
              valueFrom: {secretKeyRef: {name: garage-secrets, key: rpc_secret}}
            - name: GARAGE_ADMIN_TOKEN
              valueFrom: {secretKeyRef: {name: garage-secrets, key: admin_token}}
          ports:
            - containerPort: 3900
          readinessProbe:
            tcpSocket:
              port: 3900
          resources:
            requests: {cpu: 50m, memory: 64Mi}
            limits: {memory: 512Mi}
          volumeMounts:
            - {name: config, mountPath: /etc/garage.toml, subPath: garage.toml}
            - {name: data, mountPath: /var/lib/garage}
      volumes:
        - name: config
          configMap:
            name: garage-config
  volumeClaimTemplates:
    - metadata:
        name: data
      spec:
        accessModes: [ReadWriteOnce]
        resources:
          requests:
            storage: 10Gi

Générez les secrets, démarrez Garage, puis créez la disposition (layout), les buckets et les deux clés restreintes. Les identifiants de clé Garage se composent de GK suivi de 24 caractères hexadécimaux, les secrets de 64 caractères hexadécimaux :

kubectl -n overleaf create secret generic garage-secrets \
  --from-literal=rpc_secret="$(openssl rand -hex 32)" \
  --from-literal=admin_token="$(openssl rand -base64 32)"
kubectl -n overleaf create secret generic overleaf-s3 \
  --from-literal=OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID="GK$(openssl rand -hex 12)" \
  --from-literal=OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY="$(openssl rand -hex 32)" \
  --from-literal=OVERLEAF_HISTORY_S3_ACCESS_KEY_ID="GK$(openssl rand -hex 12)" \
  --from-literal=OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY="$(openssl rand -hex 32)"
kubectl apply -f 50-garage.yaml
kubectl -n overleaf rollout status statefulset/garage

g() { kubectl -n overleaf exec garage-0 -- /garage "$@"; }
s() { kubectl -n overleaf get secret overleaf-s3 -o jsonpath="{.data.$1}" | base64 -d; }
g layout assign -z dc1 -c 8G "$(g status 2>/dev/null | awk '/^[0-9a-f]{16}/{print $1; exit}')"
g layout apply --version 1
for b in overleaf-template-files overleaf-project-blobs overleaf-chunks; do g bucket create "$b"; done
g key import --yes -n overleaf-filestore "$(s OVERLEAF_FILESTORE_S3_ACCESS_KEY_ID)" "$(s OVERLEAF_FILESTORE_S3_SECRET_ACCESS_KEY)"
g key import --yes -n overleaf-history "$(s OVERLEAF_HISTORY_S3_ACCESS_KEY_ID)" "$(s OVERLEAF_HISTORY_S3_SECRET_ACCESS_KEY)"
g bucket allow --read --write overleaf-template-files --key overleaf-filestore
g bucket allow --read overleaf-project-blobs --key overleaf-filestore
g bucket allow --read --write overleaf-project-blobs --key overleaf-history
g bucket allow --read --write overleaf-chunks --key overleaf-history

Les autorisations correspondent aux politiques décrites dans S3. Garage vérifie la région : elle vaut ici garage, et OVERLEAF_*_S3_REGION doit avoir la même valeur.

Avec Garage, définissez dans le ConfigMap le point de terminaison, PATH_STYLE: "true" et la région garage pour les deux services, comme dans le fichier 60-config.yaml de Mise à l’échelle horizontale.

​

Plusieurs répliques

Toutes les répliques doivent utiliser les mêmes buckets et les mêmes clés. Sauvegardez les buckets avec les outils de votre fournisseur S3 ; les disques propres aux répliques ne contiennent alors aucune donnée à sauvegarder.

​

Testé sur Kubernetes

Sur Kubernetes 1.37 avec trois répliques et Garage comme ci-dessus, tous les tests de bout en bout de ces pages qui créent des projets, téléversent des fichiers, utilisent l’historique ou publient des modèles ont réussi ; ensuite, les buckets overleaf-project-blobs, overleaf-chunks et overleaf-template-files contenaient les objets, tandis que le répertoire /var/lib/overleaf/data/history propre à chaque réplique restait vide.