Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
TheAnachronism opened this issue Feb 15, 2024 · 4 comments

Comments

@TheAnachronism
Copy link
Contributor

TheAnachronism commented Feb 15, 2024

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 added a commit to TheAnachronism/docspell that referenced this issue Feb 15, 2024
TheAnachronism added a commit to TheAnachronism/docspell that referenced this issue Feb 15, 2024
…ulset to make sure no conflicts happen on startup.
TheAnachronism added a commit to TheAnachronism/docspell that referenced this issue Feb 15, 2024
TheAnachronism added a commit to TheAnachronism/docspell that referenced this issue Feb 15, 2024
TheAnachronism added a commit to TheAnachronism/docspell that referenced this issue Feb 15, 2024
…to properly set the JDBC connection for Joex.
@eikek
Copy link
Owner

eikek commented Feb 18, 2024

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

@TheAnachronism
Copy link
Contributor Author

TheAnachronism commented Feb 18, 2024

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 ^^

@waldher
Copy link
Contributor

waldher commented Feb 19, 2024

@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?

@TheAnachronism
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants