docspell icon indicating copy to clipboard operation
docspell copied to clipboard

[Kubernetes] Wrong PostgreSQL mount path and other Kubernetes manifest issues

Open TheAnachronism opened this issue 1 year ago • 4 comments

I'm currently in the process of generally reworking my entire docspell setup, and decided to switch to a Kubernetes-based deployment. I was pleased to find that there were already kustomize ready manifests available, but I've found some issues with them.

1. The volume mount for the postgres stateful set doesn't quite work.

Due to how volume mounting works, it can happen that there is a lost+found directory created within the specified /var/lib/postgresql/data path. This causes Postgres to fail on startup, due to the not-empty directory.

To fix this, a simple subPath statement can be added:

volumeMounts:
  - name: postgres-data
    mountPath: /var/lib/postgresql/data
    subPath: pgdata

2. Wrong permissions for Apache Solr in /var/solr

Sadly, the volume mounts causes solr to have issues with file permissions in the /var/solr directory. To make sure, that the file permissions are always correct, an initContainer should be added:

template:
  metadata:
    labels:
      app: solr
  spec:
    initContainers:
      - name: fix-permissions
        image: busybox
        command:
          - "sh"
          - "-c"
          - "chown -R 8983:8983 /var/solr"
        volumeMounts:
          - name: solr-data
            mountPath: /var/solr

3. Whatever the ingress is supposed to be?

I'm really unsure what the original intent of the ingress.yaml was for the Kubernetes deployment, but it doesn't work together with either the used service names, or the actual paths. A simple path to the restserver service on port 7880 is already enough to make docspell available from outside.

4. With the new languages added in v0.41.0, an additional module has to be added so that the index can properly be created.

Without the -Dsolr.modules=analysis-extras module, joex cannot create the proper full search index inside solr. This can be solved with the SOLR_OPTS environment variable, that can be passed to the container:

env:
  - name: SOLR_OPTS
    value: "-Dsolr.modules=analysis-extras"

TheAnachronism avatar Feb 15 '24 14:02 TheAnachronism

Hi @TheAnachronism I need to say, that my k8s knowledge is very limited. Another user did this nice contribution in https://github.com/eikek/docspell/pull/2034 . I would always merge any changes made to the setup, unless other people intervene :) (ping @waldher)

eikek avatar Feb 18 '24 14:02 eikek

Hey there, Like I mentioned, it's very nice that this existing deployment exists, I just noticed the listed issues with it, when trying to install the newest version of Docspell with it. I hope this can help to make the entire thing more available ^^

TheAnachronism avatar Feb 18 '24 14:02 TheAnachronism

@TheAnachronism Could you tell me what specifically the error related to permissions is? I haven't encountered it yet, and when I look at the container without your changes, the /var/solr/data and /var/solr/logs directories are owned by the solr user, while the /var/solr directory is owned by root. With your changes, /var/solr is owned by solr. Does this prevent solr from creating some additional subdirectories that it needs?

waldher avatar Feb 19 '24 01:02 waldher

Yes, that's the case, solr cannot create the directories. I'm unsure, and I'll have to test this out, but I think with certain storage classes, mounting volumes can result in a lost+found directory being created. This and the missing permissions to create the directory resulted in the permission error.

TheAnachronism avatar Feb 19 '24 08:02 TheAnachronism