2019-12-12 12:38:31 -06:00
|
|
|
{{/* vim: set filetype=mustache: */}}
|
|
|
|
{{/*
|
|
|
|
Expand the name of the chart.
|
|
|
|
*/}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
|
|
|
|
{{- /* multiple replicas assertions */ -}}
|
|
|
|
{{- if gt .Values.replicaCount 1.0 -}}
|
|
|
|
{{- fail "When using multiple replicas, a RWX file system is required" -}}
|
|
|
|
{{- if eq (get (.Values.persistence.accessModes 0) "ReadWriteOnce") -}}
|
|
|
|
{{- fail "When using multiple replicas, a RWX file system is required" -}}
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
|
{{- if eq (get .Values.gitea.config.indexer "ISSUE_INDEXER_TYPE") "bleve" -}}
|
|
|
|
{{- fail "When using multiple replicas, the repo indexer must be set to 'meilisearch' or 'elasticsearch'" -}}
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
|
{{- if and (eq .Values.gitea.config.indexer.REPO_INDEXER_TYPE "bleve") (eq .Values.gitea.config.indexer.REPO_INDEXER_ENABLED "true") -}}
|
|
|
|
{{- fail "When using multiple replicas, the repo indexer must be set to 'meilisearch' or 'elasticsearch'" -}}
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
|
{{- if eq .Values.gitea.config.indexer.ISSUE_INDEXER_TYPE "bleve" -}}
|
|
|
|
{{- (printf "DEBUG: When using multiple replicas, the repo indexer must be set to 'meilisearch' or 'elasticsearch'") | fail -}}
|
|
|
|
{{- end }}
|
|
|
|
{{- end }}
|
|
|
|
|
2020-08-23 12:56:55 -05:00
|
|
|
{{- define "gitea.name" -}}
|
2019-12-12 12:38:31 -06:00
|
|
|
{{- default .Chart.Name .Values.nameOverride | trunc 63 | trimSuffix "-" -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{/*
|
|
|
|
Create a default fully qualified app name.
|
2020-08-23 12:56:55 -05:00
|
|
|
We truncate at 63 chars because some Kubernetes name fields are limited to this (by the DNS naming spec).
|
|
|
|
If release name contains chart name it will be used as a full name.
|
2019-12-12 12:38:31 -06:00
|
|
|
*/}}
|
2020-08-23 12:56:55 -05:00
|
|
|
{{- define "gitea.fullname" -}}
|
|
|
|
{{- if .Values.fullnameOverride -}}
|
|
|
|
{{- .Values.fullnameOverride | trunc 63 | trimSuffix "-" -}}
|
|
|
|
{{- else -}}
|
2019-12-12 12:38:31 -06:00
|
|
|
{{- $name := default .Chart.Name .Values.nameOverride -}}
|
2020-08-23 12:56:55 -05:00
|
|
|
{{- if contains $name .Release.Name -}}
|
|
|
|
{{- .Release.Name | trunc 63 | trimSuffix "-" -}}
|
|
|
|
{{- else -}}
|
|
|
|
{{- printf "%s-%s" .Release.Name $name | trunc 63 | trimSuffix "-" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{/*
|
|
|
|
Create chart name and version as used by the chart label.
|
|
|
|
*/}}
|
|
|
|
{{- define "gitea.chart" -}}
|
|
|
|
{{- printf "%s-%s" .Chart.Name .Chart.Version | replace "+" "_" | trunc 63 | trimSuffix "-" -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
2021-04-29 04:12:48 -05:00
|
|
|
{{/*
|
|
|
|
Create image name and tag used by the deployment.
|
|
|
|
*/}}
|
|
|
|
{{- define "gitea.image" -}}
|
2022-06-09 05:55:08 -05:00
|
|
|
{{- $registry := .Values.global.imageRegistry | default .Values.image.registry -}}
|
2021-04-29 04:12:48 -05:00
|
|
|
{{- $name := .Values.image.repository -}}
|
2022-03-01 08:55:44 -06:00
|
|
|
{{- $tag := .Values.image.tag | default .Chart.AppVersion -}}
|
2021-04-29 04:12:48 -05:00
|
|
|
{{- $rootless := ternary "-rootless" "" (.Values.image.rootless) -}}
|
2022-06-09 05:55:08 -05:00
|
|
|
{{- if $registry -}}
|
|
|
|
{{- printf "%s/%s:%s%s" $registry $name $tag $rootless -}}
|
|
|
|
{{- else -}}
|
|
|
|
{{- printf "%s:%s%s" $name $tag $rootless -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{/*
|
|
|
|
Docker Image Registry Secret Names evaluating values as templates
|
|
|
|
*/}}
|
|
|
|
{{- define "gitea.images.pullSecrets" -}}
|
|
|
|
{{- $pullSecrets := .Values.imagePullSecrets -}}
|
|
|
|
{{- range .Values.global.imagePullSecrets -}}
|
|
|
|
{{- $pullSecrets = append $pullSecrets (dict "name" .) -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if (not (empty $pullSecrets)) }}
|
|
|
|
imagePullSecrets:
|
|
|
|
{{ toYaml $pullSecrets }}
|
|
|
|
{{- end }}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
|
|
|
|
{{/*
|
|
|
|
Storage Class
|
|
|
|
*/}}
|
|
|
|
{{- define "gitea.persistence.storageClass" -}}
|
|
|
|
{{- $storageClass := .Values.global.storageClass | default .Values.persistence.storageClass }}
|
|
|
|
{{- if $storageClass }}
|
|
|
|
storageClassName: {{ $storageClass | quote }}
|
|
|
|
{{- end }}
|
2021-04-29 04:12:48 -05:00
|
|
|
{{- end -}}
|
|
|
|
|
2020-08-23 12:56:55 -05:00
|
|
|
{{/*
|
|
|
|
Common labels
|
|
|
|
*/}}
|
|
|
|
{{- define "gitea.labels" -}}
|
|
|
|
helm.sh/chart: {{ include "gitea.chart" . }}
|
2021-03-01 06:20:55 -06:00
|
|
|
app: {{ include "gitea.name" . }}
|
2020-08-23 12:56:55 -05:00
|
|
|
{{ include "gitea.selectorLabels" . }}
|
2022-03-01 08:55:44 -06:00
|
|
|
app.kubernetes.io/version: {{ .Values.image.tag | default .Chart.AppVersion | quote }}
|
|
|
|
version: {{ .Values.image.tag | default .Chart.AppVersion | quote }}
|
2020-08-23 12:56:55 -05:00
|
|
|
app.kubernetes.io/managed-by: {{ .Release.Service }}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{/*
|
|
|
|
Selector labels
|
|
|
|
*/}}
|
|
|
|
{{- define "gitea.selectorLabels" -}}
|
|
|
|
app.kubernetes.io/name: {{ include "gitea.name" . }}
|
|
|
|
app.kubernetes.io/instance: {{ .Release.Name }}
|
|
|
|
{{- end -}}
|
|
|
|
|
2023-07-22 06:46:44 -05:00
|
|
|
{{- define "postgresql-ha.dns" -}}
|
|
|
|
{{- if (index .Values "postgresql-ha").enabled -}}
|
2023-07-18 12:07:33 -05:00
|
|
|
{{- printf "%s-postgresql-ha-postgresql.%s.svc.%s:%g" .Release.Name .Release.Namespace .Values.clusterDomain (index .Values "postgresql-ha" "service" "ports" "postgresql") -}}
|
2020-09-28 18:26:06 -05:00
|
|
|
{{- end -}}
|
2023-07-22 06:46:44 -05:00
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "postgresql.dns" -}}
|
|
|
|
{{- if (index .Values "postgresql").enabled -}}
|
|
|
|
{{- printf "%s-postgresql.%s.svc.%s:%g" .Release.Name .Release.Namespace .Values.clusterDomain .Values.postgresql.global.postgresql.service.ports.postgresql -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
2020-09-28 18:26:06 -05:00
|
|
|
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- define "redis.dns" -}}
|
|
|
|
{{- if (index .Values "redis-cluster").enabled -}}
|
|
|
|
{{- printf "redis+cluster://:%s@%s-redis-cluster-headless.%s.svc.%s:%g/0?pool_size=100&idle_timeout=180s&" (index .Values "redis-cluster").global.redis.password .Release.Name .Release.Namespace .Values.clusterDomain (index .Values "redis-cluster").service.ports.redis -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "redis.port" -}}
|
|
|
|
{{- if (index .Values "redis-cluster").enabled -}}
|
|
|
|
{{ (index .Values "redis-cluster").service.ports.redis }}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "redis.servicename" -}}
|
|
|
|
{{- if (index .Values "redis-cluster").enabled -}}
|
|
|
|
{{- printf "%s-redis-cluster-headless.%s.svc.%s" .Release.Name .Release.Namespace .Values.clusterDomain -}}
|
|
|
|
{{- end -}}
|
2019-12-12 12:38:31 -06:00
|
|
|
{{- end -}}
|
|
|
|
|
2020-08-23 12:56:55 -05:00
|
|
|
{{- define "gitea.default_domain" -}}
|
2020-10-29 12:08:58 -05:00
|
|
|
{{- printf "%s-gitea.%s.svc.%s" (include "gitea.fullname" .) .Release.Namespace .Values.clusterDomain | trunc 63 | trimSuffix "-" -}}
|
2019-12-12 12:38:31 -06:00
|
|
|
{{- end -}}
|
|
|
|
|
2020-12-16 06:37:47 -06:00
|
|
|
{{- define "gitea.ldap_settings" -}}
|
2021-10-08 07:16:24 -05:00
|
|
|
{{- $idx := index . 0 }}
|
|
|
|
{{- $values := index . 1 }}
|
|
|
|
|
|
|
|
{{- if not (hasKey $values "bindDn") -}}
|
|
|
|
{{- $_ := set $values "bindDn" "" -}}
|
2021-06-10 06:13:33 -05:00
|
|
|
{{- end -}}
|
|
|
|
|
2021-10-08 07:16:24 -05:00
|
|
|
{{- if not (hasKey $values "bindPassword") -}}
|
|
|
|
{{- $_ := set $values "bindPassword" "" -}}
|
2021-06-10 06:13:33 -05:00
|
|
|
{{- end -}}
|
|
|
|
|
2021-07-06 00:28:13 -05:00
|
|
|
{{- $flags := list "notActive" "skipTlsVerify" "allowDeactivateAll" "synchronizeUsers" "attributesInBind" -}}
|
2021-10-08 07:16:24 -05:00
|
|
|
{{- range $key, $val := $values -}}
|
2021-06-10 06:13:33 -05:00
|
|
|
{{- if and (ne $key "enabled") (ne $key "existingSecret") -}}
|
2021-07-06 00:28:13 -05:00
|
|
|
{{- if eq $key "bindDn" -}}
|
2021-10-08 07:16:24 -05:00
|
|
|
{{- printf "--%s \"${GITEA_LDAP_BIND_DN_%d}\" " ($key | kebabcase) ($idx) -}}
|
2021-07-06 00:28:13 -05:00
|
|
|
{{- else if eq $key "bindPassword" -}}
|
2021-10-08 07:16:24 -05:00
|
|
|
{{- printf "--%s \"${GITEA_LDAP_PASSWORD_%d}\" " ($key | kebabcase) ($idx) -}}
|
2021-06-10 06:13:33 -05:00
|
|
|
{{- else if eq $key "port" -}}
|
2021-07-06 00:28:13 -05:00
|
|
|
{{- printf "--%s %d " $key ($val | int) -}}
|
|
|
|
{{- else if has $key $flags -}}
|
2021-06-29 15:09:16 -05:00
|
|
|
{{- printf "--%s " ($key | kebabcase) -}}
|
2020-12-16 06:37:47 -06:00
|
|
|
{{- else -}}
|
2021-06-29 15:09:16 -05:00
|
|
|
{{- printf "--%s %s " ($key | kebabcase) ($val | squote) -}}
|
2020-12-16 06:37:47 -06:00
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
2021-03-01 06:24:11 -06:00
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "gitea.oauth_settings" -}}
|
2021-12-20 08:43:55 -06:00
|
|
|
{{- $idx := index . 0 }}
|
|
|
|
{{- $values := index . 1 }}
|
|
|
|
|
|
|
|
{{- if not (hasKey $values "key") -}}
|
|
|
|
{{- $_ := set $values "key" (printf "${GITEA_OAUTH_KEY_%d}" $idx) -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- if not (hasKey $values "secret") -}}
|
|
|
|
{{- $_ := set $values "secret" (printf "${GITEA_OAUTH_SECRET_%d}" $idx) -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- range $key, $val := $values -}}
|
2021-12-21 04:59:18 -06:00
|
|
|
{{- if ne $key "existingSecret" -}}
|
2021-12-20 08:43:55 -06:00
|
|
|
{{- printf "--%s %s " ($key | kebabcase) ($val | quote) -}}
|
2021-03-01 06:24:11 -06:00
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
2021-04-29 04:12:48 -05:00
|
|
|
{{- end -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
|
2022-07-28 03:29:33 -05:00
|
|
|
{{- define "gitea.public_protocol" -}}
|
|
|
|
{{- if and .Values.ingress.enabled (gt (len .Values.ingress.tls) 0) -}}
|
|
|
|
https
|
|
|
|
{{- else -}}
|
|
|
|
{{ .Values.gitea.config.server.PROTOCOL }}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- define "gitea.inline_configuration" -}}
|
|
|
|
{{- include "gitea.inline_configuration.init" . -}}
|
|
|
|
{{- include "gitea.inline_configuration.defaults" . -}}
|
|
|
|
|
|
|
|
{{- $generals := list -}}
|
|
|
|
{{- $inlines := dict -}}
|
|
|
|
|
|
|
|
{{- range $key, $value := .Values.gitea.config }}
|
|
|
|
{{- if kindIs "map" $value }}
|
|
|
|
{{- if gt (len $value) 0 }}
|
|
|
|
{{- $section := default list (get $inlines $key) -}}
|
|
|
|
{{- range $n_key, $n_value := $value }}
|
|
|
|
{{- $section = append $section (printf "%s=%v" $n_key $n_value) -}}
|
|
|
|
{{- end }}
|
|
|
|
{{- $_ := set $inlines $key (join "\n" $section) -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- else }}
|
|
|
|
{{- if or (eq $key "APP_NAME") (eq $key "RUN_USER") (eq $key "RUN_MODE") -}}
|
|
|
|
{{- $generals = append $generals (printf "%s=%s" $key $value) -}}
|
|
|
|
{{- else -}}
|
|
|
|
{{- (printf "Key %s cannot be on top level of configuration" $key) | fail -}}
|
|
|
|
{{- end -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end }}
|
|
|
|
{{- end }}
|
|
|
|
|
|
|
|
{{- $_ := set $inlines "_generals_" (join "\n" $generals) -}}
|
|
|
|
{{- toYaml $inlines -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "gitea.inline_configuration.init" -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "cache") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "cache" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "server") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "server" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "metrics") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "metrics" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "database") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "database" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "security") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "security" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not .Values.gitea.config.repository -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "repository" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "oauth2") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "oauth2" dict -}}
|
|
|
|
{{- end -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- if not (hasKey .Values.gitea.config "session") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "session" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "queue") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "queue" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "queue.issue_indexer") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "queue.issue_indexer" dict -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config "indexer") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config "indexer" dict -}}
|
|
|
|
{{- end -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "gitea.inline_configuration.defaults" -}}
|
|
|
|
{{- include "gitea.inline_configuration.defaults.server" . -}}
|
|
|
|
{{- include "gitea.inline_configuration.defaults.database" . -}}
|
|
|
|
|
|
|
|
{{- if not .Values.gitea.config.repository.ROOT -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.repository "ROOT" "/data/git/gitea-repositories" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not .Values.gitea.config.security.INSTALL_LOCK -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.security "INSTALL_LOCK" "true" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config.metrics "ENABLED") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.metrics "ENABLED" .Values.gitea.metrics.enabled -}}
|
|
|
|
{{- end -}}
|
2023-07-18 11:10:38 -05:00
|
|
|
{{- if (index .Values "redis-cluster").enabled -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- $_ := set .Values.gitea.config.cache "ENABLED" "true" -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.cache "ADAPTER" "redis" -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- if not (.Values.gitea.config.cache.HOST) -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.cache "HOST" (include "redis.dns" .) -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- /* redis queue */ -}}
|
|
|
|
{{- if (index .Values "redis-cluster").enabled -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.queue "TYPE" "redis" -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.queue "CONN_STR" (include "redis.dns" .) -}}
|
|
|
|
{{- end -}}
|
2023-07-18 12:22:51 -05:00
|
|
|
{{- if not (get .Values.gitea.config.session "PROVIDER") -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.session "PROVIDER" "redis" -}}
|
2023-07-18 12:22:51 -05:00
|
|
|
{{- end -}}
|
|
|
|
{{- if not (get .Values.gitea.config.session "PROVIDER_CONFIG") -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.session "PROVIDER_CONFIG" (include "redis.dns" .) -}}
|
2023-07-18 12:22:51 -05:00
|
|
|
{{- end -}}
|
[Breaking] Add HA-support; switch to `Deployment` (#437)
# Changes
A big shoutout to @luhahn for all his work in #205 which served as the base for this PR.
## Documentation
- [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long).
Most of the information below should go into it with more details and explanations behind all of the individual components.
## Chart deps
~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~
~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~
- Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2.
- Removes `memcached` instead of `redis-cluster`
- Add `postgresql-ha` as default DB dep in favor of `postgres`
## Adds smart HA chart logic
The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1.
- If `replicaCount` > 1,
- `gitea.config.session.PROVIDER` is automatically set to `redis-cluster`
- `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch`
- `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not
Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc.
## Deployment vs Statefulset
Given all the discussions about this lately (#428), I think we could use both.
In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets.
On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment.
Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption.
Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case.
This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet.
The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way?
## Chart PVC Creation
I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation.
In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial.
A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse...
- New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim`
- New `persistence.create`: whether to create a new PVC
## Testing
As this PR does a lot of things, we need proper testing.
The helm chart can be installed from the Git branch via `helm-git` as follows:
```
helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment
helm install gitea --version 0.0.0
```
It is **highly recommended** to test the chart in a dedicated namespace.
I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine.
I just did some basic operations though and we should do more niche testing before merging.
Examplary `values.yml` for testing (only needs a valid RWX storage class):
<details>
<summary>values.yaml</summary>
```yml
image:
tag: "dev"
PullPolicy: "Always"
rootless: true
replicaCount: 2
persistence:
enabled: true
accessModes:
- ReadWriteMany
storageClass: FIXME
redis-cluster:
enabled: false
global:
redis:
password: gitea
gitea:
config:
indexer:
ISSUE_INDEXER_ENABLED: true
REPO_INDEXER_ENABLED: false
```
</details>
## Preferred setup
The preferred HA setup with respect to performance and stability might currently be as follows:
- Repos: RWX (e.g. EFS or Azurefiles NFS)
- Issue indexer: Meilisearch (HA)
- Session and cache: Redis Cluster (HA)
- Attachments/Avatars: Minio (HA)
This will result in a ~ 10-pod HA setup overall.
All pods have very low resource requests.
fix #98
Co-authored-by: pat-s <pat-s@noreply.gitea.io>
Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437
Co-authored-by: pat-s <patrick.schratz@gmail.com>
Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-17 14:09:42 -05:00
|
|
|
{{- if not .Values.gitea.config.indexer.ISSUE_INDEXER_TYPE -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.indexer "ISSUE_INDEXER_TYPE" "db" -}}
|
|
|
|
{{- end -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "gitea.inline_configuration.defaults.server" -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config.server "HTTP_PORT") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "HTTP_PORT" .Values.service.http.port -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not .Values.gitea.config.server.PROTOCOL -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "PROTOCOL" "http" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (.Values.gitea.config.server.DOMAIN) -}}
|
|
|
|
{{- if gt (len .Values.ingress.hosts) 0 -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "DOMAIN" (index .Values.ingress.hosts 0).host -}}
|
|
|
|
{{- else -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "DOMAIN" (include "gitea.default_domain" .) -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not .Values.gitea.config.server.ROOT_URL -}}
|
2022-07-28 03:29:33 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.server "ROOT_URL" (printf "%s://%s" (include "gitea.public_protocol" .) .Values.gitea.config.server.DOMAIN) -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end -}}
|
|
|
|
{{- if not .Values.gitea.config.server.SSH_DOMAIN -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "SSH_DOMAIN" .Values.gitea.config.server.DOMAIN -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not .Values.gitea.config.server.SSH_PORT -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "SSH_PORT" .Values.service.ssh.port -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config.server "SSH_LISTEN_PORT") -}}
|
|
|
|
{{- if not .Values.image.rootless -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "SSH_LISTEN_PORT" .Values.gitea.config.server.SSH_PORT -}}
|
|
|
|
{{- else -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "SSH_LISTEN_PORT" "2222" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config.server "START_SSH_SERVER") -}}
|
|
|
|
{{- if .Values.image.rootless -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "START_SSH_SERVER" "true" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config.server "APP_DATA_PATH") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "APP_DATA_PATH" "/data" -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- if not (hasKey .Values.gitea.config.server "ENABLE_PPROF") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.server "ENABLE_PPROF" false -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "gitea.inline_configuration.defaults.database" -}}
|
2023-07-18 11:34:56 -05:00
|
|
|
{{- if (index .Values "postgresql-ha" "enabled") -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- $_ := set .Values.gitea.config.database "DB_TYPE" "postgres" -}}
|
|
|
|
{{- if not (.Values.gitea.config.database.HOST) -}}
|
2023-07-22 06:46:44 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.database "HOST" (include "postgresql-ha.dns" .) -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end -}}
|
2023-07-18 12:16:33 -05:00
|
|
|
{{- $_ := set .Values.gitea.config.database "NAME" (index .Values "postgresql-ha" "global" "postgresql" "database") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "USER" (index .Values "postgresql-ha" "global" "postgresql" "username") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "PASSWD" (index .Values "postgresql-ha" "global" "postgresql" "password") -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end -}}
|
2023-07-22 06:46:44 -05:00
|
|
|
{{- if (index .Values "postgresql" "enabled") -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "DB_TYPE" "postgres" -}}
|
|
|
|
{{- if not (.Values.gitea.config.database.HOST) -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "HOST" (include "postgresql.dns" .) -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "NAME" .Values.postgresql.global.postgresql.auth.database -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "USER" .Values.postgresql.global.postgresql.auth.username -}}
|
|
|
|
{{- $_ := set .Values.gitea.config.database "PASSWD" .Values.postgresql.global.postgresql.auth.password -}}
|
|
|
|
{{- end -}}
|
2021-12-22 04:44:04 -06:00
|
|
|
{{- end -}}
|
2022-08-07 14:32:19 -05:00
|
|
|
|
|
|
|
{{- define "gitea.init-additional-mounts" -}}
|
|
|
|
{{- /* Honor the deprecated extraVolumeMounts variable when defined */ -}}
|
|
|
|
{{- if gt (len .Values.extraInitVolumeMounts) 0 -}}
|
|
|
|
{{- toYaml .Values.extraInitVolumeMounts -}}
|
|
|
|
{{- else if gt (len .Values.extraVolumeMounts) 0 -}}
|
|
|
|
{{- toYaml .Values.extraVolumeMounts -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
|
|
|
|
|
|
|
{{- define "gitea.container-additional-mounts" -}}
|
|
|
|
{{- /* Honor the deprecated extraVolumeMounts variable when defined */ -}}
|
|
|
|
{{- if gt (len .Values.extraContainerVolumeMounts) 0 -}}
|
|
|
|
{{- toYaml .Values.extraContainerVolumeMounts -}}
|
|
|
|
{{- else if gt (len .Values.extraVolumeMounts) 0 -}}
|
|
|
|
{{- toYaml .Values.extraVolumeMounts -}}
|
|
|
|
{{- end -}}
|
|
|
|
{{- end -}}
|
2023-01-17 10:58:10 -06:00
|
|
|
|
|
|
|
{{- define "gitea.gpg-key-secret-name" -}}
|
|
|
|
{{ default (printf "%s-gpg-key" (include "gitea.fullname" .)) .Values.signing.existingSecret }}
|
|
|
|
{{- end -}}
|
2023-05-31 03:47:58 -05:00
|
|
|
|
|
|
|
{{- define "gitea.serviceAccountName" -}}
|
|
|
|
{{ .Values.serviceAccount.name | default (include "gitea.fullname" .) }}
|
|
|
|
{{- end -}}
|