2024-02-09 Sys Ops & Management SIG Agenda and Meeting notes

Deployment with Helm charts has become a standard way to deploy FOLIO on a Kubernetes cluster.

The group at LRZ is actively developing an improved alternative to the standard FOLIO Helm chart deployment ( https://github.com/folio-org/folio-helm-v2 ) which uses Helm charts on a public insititutional repo.

These Helm charts will be shared and developed further and maintained collaboratively by the community.

Prerequisites:

• Basic understanding of Kubernetes and Helm.

Topics:

• The decisions made at LRZ regarding FOLIO deployment
• The structure of the LRZ Helm charts

Could be followed by some kind of workshop or discussion. 

Florian Kr.: The discussed public helm repository for FOLIO installation at LRZ. This is the repo we plan on using internally and keep up to date in the future.

https://gitlab.bib-bvb.de/folio-public/folio-helm

Meeting Notes:

Florian & Florian at LRZ
A proper Helm repository which is public
A public repo. Also the source is located there: https://gitlab.bib-bvb.de/folio-public/folio-helm
The package repository of gitlab as a Helm repository. It can be parametreised.
Package registry will be automatically upgraded.
Look at README.md of the repo.
Kubernetes installed with kubespray.
DNS - manually set wildcard addresses.
S3 Storage or minio might be integrated in the helm charts later.
Zalando postgres operator vs. external DB
prerquisite: same namespace for all / prevent unwanted cross-namespace communication / using Calico network overlay. An alternitve network overlay: Silium. A&M uses Rancher K8s Flanel. A straight Flanel has issues, though.
wrong tenant id gets rejected by the ingress level
Another discussion: Kubrnetes setup decisions.
Could bring secrets in a new namespace.
Currently still using a global values file. Why a gloabl value file ? First thing is to build a postgres cluster. The value file is used to gerenrate the postgres configuration. Okapi needs access to the same credentials.
Jason: Helm charts with multiple pieces are also Helm charts. ... I think the gloabl Helm chart makes sense.
Florian Kr: doesn't make sense to have multiple elasticsearch services
How is helm used to install Okapi ? Quite a few values are parametrised. At this point, there is no ingress to Okapi.
Different Okapis use different Hazelcast services. Namespace + release name is used for cluster name of Hazelcast. The sevice name is "Okapi".
Using templating fpr hazelcast configmap. So you don't have to do any adjustments, once it is running. Skipping to demo the rest of the templates here.
Florian Gl.: We ususally install two Helm releaes, one for the auth module, and one for the other modules.
Each Helm charts feeds a range of backend modules. Every module has quite a bit of configurations. This can get quite complicated, but they all have the same kind of structure.
Next step is the tenant registration. The modules get regsitred for the tenant.
There is a servcice for every module and a service for Oakpi.
2 ingresses for every tenant. There is only one url per library. They can add /okapi to it.
The x-okapi-tenant header cannont be faked because it is being generated in the ingress controller.
There is a public Stripes build. There are specifics in the entry point. One Stripes config per release. Template variables for branding.
VuFInd integration. A second postgres cluster for this. The VuFind tenant also looks for the secret for FOLIO. Configures VuFind to connect to FOLIO.
Solr cloud deployment.
---
Infrastructure: The biggest Nodes have 192 Gb of RAM. Each node should at least have 32 GB of RAM. Control Pane nodes have 8 GB of RAM. We use thre Nodes exclusively as Control Pane nodes.
Jason: Database only runs on large Nodes. Nodes are being tagged.