[adguard-home] Introduce config as code and add ability to run as non-root

[mkilchhofer]

Special notes for your reviewer:

Here I have another update for [adguard-home]. :-) Normally you configure "adguard-home" by clicking through the web UI. Then the app stores a YAML inside a PVC. I added the ability to put the yaml config inside a ConfigMap and configure it inside the values.yaml. This helps me to configure this piece of software like my other apps inside my cluster: via config as code (CAC), versioned in Git.

Additionally I do not like containers that run as root, and therefore I added code to run this app as an unprivileged user inside the container.

Checklist

[Place an '[x]' (no spaces) in all applicable fields. Please remove unrelated fields.]

• [x] Chart Version bumped
• [x] Variables are documented in the README.md
• [x] Title of the PR starts with chart name (e.g. [radarr])

[mkilchhofer]

Maybe we should discuss, if we provide a default config or leave it commented out.

[dcplaya]

If no default is provided, won't Adguard create one? But this means that you MUST know to enter the correct bind port based on your values.yaml file.

I think supplying a default config is better because of the above. It was my original plan when I set out to create the helm chart actually too.

[mkilchhofer]

Yes, this bind port(s) is a problem.

My implementation is like this: Before the app starts, an initConainer overwrites the real config with the one provided in the values.yaml and/or with your injected ones. But you need to opt-in by setting configAsCode.enabled: true. I implemented it with an initContainer because the real config file need to be writable, otherwise the app throws an error and exits. Then at runtime, when you change settings in the app, these settings will be reverted the next time the pod gets restarted.

[dcplaya]

Seems like a good idea to me. Someone can still use a PV for the config they want as well.