feat: add a Helm chart #512
Conversation
|
@dunglas sure, a specific chart is better in my opinion. I think using helm-docs is a good way to generate documentation from the values file, so I'd consider adding that. I'd also consider grouping application specific configuration under a Updating the ingress template is also worth doing: https://github.com/sagikazarmark/helm-charts/blob/master/charts/caddy/templates/ingress.yaml |
helm/mercure/templates/hpa.yaml
Outdated
| - type: Resource | ||
| resource: | ||
| name: cpu | ||
| targetAverageUtilization: {{ .Values.autoscaling.targetCPUUtilizationPercentage }} |
There was a problem hiding this comment.
FYI, I was facing this issue when using HPA with average cpu utilization (but with autoscaling/v2beta2)
kubernetes/kubernetes#56165
Co-authored-by: Quentin Barloy <quentin@les-tilleuls.coop>
* 'feat/helm' of github.com:dunglas/mercure: Update helm/mercure/templates/deployment.yaml
dunglas
force-pushed
the
feat/helm
branch
3 times, most recently
from
e689d3d
to
2c54fb8
Compare
| key: extra-directives | ||
| {{- if .Values.persistence.enabled }} | ||
| volumeMounts: | ||
| - mountPath: /data |
There was a problem hiding this comment.
I'm more conservative on these issues, so I'd vote for /var/mercure.
There was a problem hiding this comment.
Our Docker image and the official Caddy image already work like that.
charts/mercure/values.yaml
Outdated
| # -- enable the debug mode | ||
| debug: false | ||
| # -- enable the development mode, including the debug UI and the demo | ||
| dev: false | ||
| # -- the URL representation of the transport to use | ||
| transportUrl: bolt:///data/mercure.db | ||
| # -- extra Mercure directives to include in the Caddyfile | ||
| extraDirectives: "" | ||
|
|
||
| # -- the JWT key to use for publishers, a random key will be generated if empty | ||
| publisherJwtKey: "" | ||
| # -- the JWT algorithm to use for publishers | ||
| publisherJwtAlg: HS256 | ||
|
|
||
| # -- the JWT key to use for subscribers, a random key will be generated if empty | ||
| subscriberJwtKey: "" | ||
| # -- JWT algorithm to use for subscribers | ||
| subscriberJwtAlg: HS256 | ||
|
|
||
| # -- license key for [the High Availability version](https://mercure.rocks/docs/hub/cluster) (not necessary is you use the FOSS version): | ||
| license: "" |
There was a problem hiding this comment.
I still think these should be under a config key to better separate them from the rest of the chart values.
There was a problem hiding this comment.
Is it a common practice? AFAIK most charts don't do that (and it looks in contractions with Helm's best practices: https://helm.sh/docs/chart_best_practices/).
There was a problem hiding this comment.
I don't see a contradiction with the best practices. I don't think the claim about the mandatory check in case of nesting is true.
I honestly can't tell whether most charts do it or not. It certainly proved useful for me. Take it with a grain of salt.
Co-authored-by: Márk Sági-Kazár <sagikazarmark@users.noreply.github.com>
* 'feat/helm' of github.com:dunglas/mercure: Update charts/mercure/templates/ingress.yaml
Add a new Helm chart for the Caddy build. Fixes #357.
@sagikazarmark, I hesitated to use your Caddy chart, but as the hub has some specificities, I don't think that it's worth it, so I created a more specific one. However, I'll be glad to collaborate with you to share everything that can be shared.