starred/lldap-lldap

Fork 0

mirror of https://github.com/lldap/lldap.git synced 2026-04-25 16:25:55 +03:00

[GH-ISSUE #881] [FEATURE REQUEST] Helm chart implementation details #318

New issue

Closed

opened 2026-02-27 08:16:37 +03:00 by kerem · 6 comments

kerem commented

2026-02-27 08:16:37 +03:00

Owner

Originally created by @djjudas21 on GitHub (Mar 27, 2024).
Original GitHub issue: https://github.com/lldap/lldap/issues/881

Motivation

Hi there, I am a new lldap user and I want to run it on Kubernetes via a Helm chart. I have already written a Helm chart for lldap which is mostly functional (supports sqlite, mariadb and postgres plus virtually all of the other settings).

My aim is that when mariadb or postgresql is configured, Kubernetes should not need to create a volume for /data, i.e. the deployment will be completely stateless. It's fine for lldap to write stuff into /data if it wants, provided it's also happy for that temporarily volume to be destroyed when the container is restarted.

Like all good Kubernetes deployments, my chart configures lldap exclusively via environment variables and I note that lldap creates a default /data/lldap_config.toml which I assume effectively does nothing, as all the settings are being overriden by env vars?

When not using sqlite, my helm chart supports running multiple replicas, and the additional replicas seem to work fine, i.e. they connect to the external database. However I noticed that /data/private_key differs between my two replicas. Is this a problem, and do I need to generate and distribute this key as part of the Helm chart to ensure that all replicas have the same?

Thanks for your help... once I've cleared up these last few issues about statelessness, I can publish a final version of the chart.

Originally created by @djjudas21 on GitHub (Mar 27, 2024). Original GitHub issue: https://github.com/lldap/lldap/issues/881 **Motivation** Hi there, I am a new lldap user and I want to run it on Kubernetes via a Helm chart. I have already written a [Helm chart for lldap](https://artifacthub.io/packages/helm/djjudas21/lldap) which is mostly functional (supports sqlite, mariadb and postgres plus virtually all of the other settings). My aim is that when mariadb or postgresql is configured, Kubernetes should *not* need to create a volume for `/data`, i.e. the deployment will be completely stateless. It's fine for lldap to write stuff into `/data` if it wants, provided it's also happy for that temporarily volume to be destroyed when the container is restarted. Like all good Kubernetes deployments, my chart configures lldap exclusively via environment variables and I note that lldap creates a default `/data/lldap_config.toml` which I assume effectively does nothing, as all the settings are being overriden by env vars? When *not* using sqlite, my helm chart supports running multiple replicas, and the additional replicas seem to work fine, i.e. they connect to the external database. However I noticed that `/data/private_key` differs between my two replicas. Is this a problem, and do I need to generate and distribute this key as part of the Helm chart to ensure that all replicas have the same? Thanks for your help... once I've cleared up these last few issues about statelessness, I can publish a final version of the chart.

kerem

2026-02-27 08:16:37 +03:00

closed this issue
added the
enhancement
label

kerem commented

2026-02-27 08:16:38 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 27, 2024):

I could swear someone had already made an lldap helm chart...

Anyway, I can solve your private_key problems! Just set the LLDAP_KEY_SEED to a random value (shared between the instances) and you won't need to share anything.

@nitnelave commented on GitHub (Mar 27, 2024): I could swear someone had already made an lldap helm chart... Anyway, I can solve your `private_key` problems! Just set the `LLDAP_KEY_SEED` to a random value (shared between the instances) and you won't need to share anything.

kerem commented

2026-02-27 08:16:38 +03:00

Author

Owner

@djjudas21 commented on GitHub (Mar 27, 2024):

TrueCharts have a Helm chart for lldap designed for TrueNAS appliances, supposed to be compatible with generic Kubernetes, but I've had various problems with their charts and I don't rate them for general use 🙂

Thanks for the tip on LLDAP_KEY_SEED. I'll fix that, and I'll implement support for bootstrap.sh so this chart will be a complete solution.

Do you have any interest in adopting this chart into the lldap namespace? I'm still happy to maintain it. Otherwise I'll leave it in my own djjudas21 namespace.

@djjudas21 commented on GitHub (Mar 27, 2024): TrueCharts have a Helm chart for lldap designed for TrueNAS appliances, supposed to be compatible with generic Kubernetes, but I've had various problems with their charts and I don't rate them for general use :slightly_smiling_face: Thanks for the tip on `LLDAP_KEY_SEED`. I'll fix that, and I'll implement support for `bootstrap.sh` so this chart will be a complete solution. Do you have any interest in adopting this chart into the lldap namespace? I'm still happy to maintain it. Otherwise I'll leave it in my own `djjudas21` namespace.

kerem commented

2026-02-27 08:16:38 +03:00

Author

Owner

@nitnelave commented on GitHub (Mar 27, 2024):

I don't know what it means to adopt a chart. Or do you just mean have the chart be in a repo under the lldap organization? Yeah, we could do that (and I'd give you full author permissions, naturally).

I know next to nothing about charts. It's essentially a config file / startup script to get a kubernetes or similar cluster set up for running an instance or more of a service, right?

@nitnelave commented on GitHub (Mar 27, 2024): I don't know what it means to adopt a chart. Or do you just mean have the chart be in a repo under the lldap organization? Yeah, we could do that (and I'd give you full author permissions, naturally). I know next to nothing about charts. It's essentially a config file / startup script to get a kubernetes or similar cluster set up for running an instance or more of a service, right?

kerem commented

2026-02-27 08:16:38 +03:00

Author

Owner

@djjudas21 commented on GitHub (Mar 27, 2024):

Yes, I mean to store it in a repo in the lldap org and to publish it under the name lldap/lldap rather than djjudas21/lldap, which includes having it indexed on ArtifactHub which is sort of an app store for Helm charts.

Helm charts are effectively a templating system that generate the yaml manifests that describe a Kubernetes deployment. I based my chart off the Kubernetes example you link to in your README, with a few extras included.

Let me continue developing my chart for the time being and I'll contribute it after it's tested 🙂

@djjudas21 commented on GitHub (Mar 27, 2024): Yes, I mean to store it in a repo in the lldap org and to publish it under the name `lldap/lldap` rather than `djjudas21/lldap`, which includes having it indexed on ArtifactHub which is sort of an app store for Helm charts. Helm charts are effectively a templating system that generate the yaml manifests that describe a Kubernetes deployment. I based my chart off the Kubernetes example you link to in your README, with a few extras included. Let me continue developing my chart for the time being and I'll contribute it after it's tested :slightly_smiling_face:

kerem commented

2026-02-27 08:16:38 +03:00

Author

Owner

@djjudas21 commented on GitHub (Apr 2, 2024):

The chart is now fully working 👌 including support for bootstrapping users & groups. When you've got a moment, could you create a repo called charts in the lldap organisation, and I'll push my chart.

I'll need access to GitHub Actions and GitHub Pages so I can use chart-releaser to test, build & publish the charts in their own helm chart repo.

I'm aiming for the same setup as my own repo, where:

https://github.com/djjudas21/charts contains the chart(s)
https://djjudas21.github.io/charts/ is created by chart-releaser and hosts the charts for consumption by Helm users and ArtifactHub
https://artifacthub.io/packages/search?repo=djjudas21&sort=relevance&page=1 indexes charts in arbitrary Helm repos to make them more discoverable for Helm users

@djjudas21 commented on GitHub (Apr 2, 2024): The chart is now fully working :ok_hand: including support for bootstrapping users & groups. When you've got a moment, could you create a repo called `charts` in the `lldap` organisation, and I'll push my chart. I'll need access to GitHub Actions and GitHub Pages so I can use [chart-releaser](https://github.com/helm/chart-releaser) to test, build & publish the charts in their own helm chart repo. I'm aiming for the same setup as my own repo, where: * https://github.com/djjudas21/charts contains the chart(s) * https://djjudas21.github.io/charts/ is created by chart-releaser and hosts the charts for consumption by Helm users and ArtifactHub * https://artifacthub.io/packages/search?repo=djjudas21&sort=relevance&page=1 indexes charts in arbitrary Helm repos to make them more discoverable for Helm users

kerem commented

2026-02-27 08:16:38 +03:00

Author

Owner

@nitnelave commented on GitHub (Apr 3, 2024):

Alright, I setup lldap/charts, you should have write access to the repo. Tell me if anything is missing in terms of permissions. I'm closing this issue since we can talk about the details either on discord or on the new repo.

@nitnelave commented on GitHub (Apr 3, 2024): Alright, I setup lldap/charts, you should have write access to the repo. Tell me if anything is missing in terms of permissions. I'm closing this issue since we can talk about the details either on discord or on the new repo.

kerem referenced this issue

2026-02-27 08:18:25 +03:00

[PR #318] [MERGED] Bump version to 0.4.2-alpha #675