- Do not commit directly to
main. Always use a feature branch:
git checkout -b feat/my-feature- Before opening a PR, rebase or squash your commits to keep history clean:
git rebase origin/main- Use clear and concise commit messages. We recommend following Conventional Commits:
git commit -m "docs: add CONTRIBUTING.md"- Ensure your branch is up to date with
mainbefore creating a PR:
git fetch origin
git rebase origin/main- All PRs must be reviewed by at least one maintainer before merging.
This Helm chart should ideally work on any Kubernetes cluster. For local development and iterative testing, we recommend using MicroK8s. This setup enables a rapid development workflow without the need to manage complex infrastructure.
[ -d $HOME/.kube ] && mv $HOME/.kube $HOME/.kube.oldmicrok8s install --cpu 8 --mem 24 --disk 200 --channel latest/stablemkdir $HOME/.kube && microk8s config -o yaml > $HOME/.kube/config
chmod 400 $HOME/.kube/configEnable DNS and local storage addons
microk8s enable dns
microk8s enable hostpath-storageYou will need a valid IP address range on your network that MetalLB can use for LoadBalancer services.
Depending on your OS, you might be running MicroK8s directly on Linux or inside a virtual machine on macOS. Below are example commands for each setup:
Get CIDR on Linux using the eth0 interface
CIDR=$(ip -4 -o addr show scope global | grep 'eth0' | awk '{print $4}' | sed 's|[0-9]\+/|0/|')Get CIDR on macOS using the MicroK8s VM address
CIDR=$(multipass info microk8s-vm --format json | jq -r '.info["microk8s-vm"].ipv4[0] + "/32"')You can verify that the CIDR was captured correctly with:
echo $CIDROnce you have your CIDR, you can enable metallb
microk8s enable metallb:$CIDRImportant
If you are running MicroK8s on macOS, you will need to increase the memory map areas per VM process
# only if running microk8s on macOS
multipass exec microk8s-vm -- sudo sysctl -w vm.max_map_count=262144# check template rendering
helm template graylog . --debug | less
# do a dry run with a small configuration
helm install graylog . --dry-run --debug --create-namespace -n graylog --set size="xs"
# do a dry run with the default configuration
helm install graylog . --dry-run --debug --create-namespace -n graylog
helm install graylog . -n graylog --create-namespace -n graylog --set size="xs" --set graylog.custom.service.type="LoadBalancer"Note
Values can be passed into the chart from multiple sources, including
- The
values.yamlfile in the chart, with all default values - A values file passed with the
--valuesor-fflag (e.g.helm upgrade graylog . -f mynewvals.yaml) - Individual parameters passed with
--set(e.g.helm upgrade graylog . --set foo=bar)
The default values in values.yaml can be overridden by a parent chart's values.yaml (in the event this chart is used as a subchart), which can in turn be overridden by a user-supplied values file with -f, which can in turn be overridden by --set parameters.
Note
The reset-values and reuse-values flags can be used to control how values are handled during an upgrade:
--reset-values: Discards the previously set values and uses only the values provided in the current upgrade command (via--valuesor--set).--reuse-values: Reuses the values from the last release and merges them with any new values provided in the upgrade command.
These two flags are mutually exclusive.
In addition, if no -f (or --values), or --set (or --set-string, or --set-file) flags are applied,
--reuse-values will be used by default. Otherwise, --reset-values will be used by default.
# keeps previously set values and overrides current "version"
helm upgrade graylog . -n graylog --reuse-values --set version="6.3"