S3

Projektdateien und Verlauf in einem Kubernetes-Deployment in S3-kompatiblem Speicher ablegen.

Projektdateien und ihr Verlauf werden vom Dienst history-v1 gespeichert, Vorlagendateien vom Dienst filestore, beide in jedem Ayakaleaf Pro-Pod. Standardmäßig schreiben sie auf das Daten-Volume; mit S3 schreiben sie in Buckets. Welche Buckets und Berechtigungen benötigt werden, ist unter S3 beschrieben.

Dienste	history-v1 (Projektdateien und Verlauf), filestore (Vorlagendateien), in jedem Ayakaleaf Pro-Pod
Pod → S3	der S3-Endpunkt, für jede gelesene oder geschriebene Datei
Erforderlich	für mehrere Replikate: Ihre Daten-Volumes werden nicht geteilt, die Buckets schon
Periodische Jobs	keine

Entscheiden Sie sich für S3, bevor Benutzer Projekte anlegen. Eine Instanz, die bereits Dateien auf ihrem Volume speichert, benötigt zuerst die S3-Migration.

​

Konfiguration

1. Buckets und Schlüssel

   Erstellen Sie bei Ihrem S3-Dienst die drei Buckets overleaf-template-files, overleaf-project-blobs und overleaf-chunks sowie die beiden eingeschränkten Benutzer wie unter S3 einrichten beschrieben, oder betreiben Sie Garage im Cluster wie unten gezeigt. Legen Sie die vier Schlüssel in einem Secret ab:

   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. Das Secret zum Pod hinzufügen und neu starten

   Fügen Sie das Secret im Deployment (oder StatefulSet) neben den anderen hinzu:

             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 im Cluster

Ohne einen S3-Dienst ist Garage ein kleiner S3-Server, der im Cluster läuft. Das Setup für die Horizontale Skalierung wurde damit getestet. Die folgenden Befehle erzeugen die Schlüssel und legen das Secret overleaf-s3 selbst an; verwenden Sie sie daher anstelle des Secret-Befehls aus Schritt 1.

MinIO, das im Beispiel von Overleaf verwendet wird, veröffentlicht keine Container-Images mehr: minio/minio ist von Docker Hub und quay.io verschwunden.

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

Erzeugen Sie die Secrets, starten Sie Garage und legen Sie dann das Layout, die Buckets und die beiden eingeschränkten Schlüssel an. Garage-Schlüssel-IDs bestehen aus GK plus 24 Hexadezimalzeichen, Secrets aus 64 Hexadezimalzeichen:

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

Die Berechtigungen entsprechen den Richtlinien unter S3. Garage prüft die Region: Sie lautet hier garage, und OVERLEAF_*_S3_REGION muss identisch sein.

Setzen Sie mit Garage in der ConfigMap für beide Dienste den Endpunkt, PATH_STYLE: "true" und die Region garage, wie in 60-config.yaml unter Horizontale Skalierung.

​

Mehrere Replikate

Alle Replikate müssen dieselben Buckets und Schlüssel verwenden. Sichern Sie die Buckets mit den Werkzeugen Ihres S3-Anbieters; die eigenen Festplatten der Replikate enthalten dann keine Daten, die gesichert werden müssen.

​

Auf Kubernetes getestet

Auf Kubernetes 1.37 mit drei Replikaten und Garage wie oben bestand jeder End-to-End-Test dieser Seiten, der Projekte anlegt, Dateien hochlädt, den Verlauf nutzt oder Vorlagen veröffentlicht, und anschließend enthielten die Buckets overleaf-project-blobs, overleaf-chunks und overleaf-template-files die Objekte, während das eigene /var/lib/overleaf/data/history der Replikate leer blieb.