helm-chart/Chart.yaml

51 lines
1.6 KiB
YAML
Raw Normal View History

apiVersion: v2
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 17:56:55 +00:00
name: gitea
description: Gitea Helm chart for Kubernetes
type: application
version: 0.0.0
2023-07-22 10:50:27 +02:00
appVersion: 1.20.1
icon: https://docs.gitea.io/images/gitea.png
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 17:56:55 +00:00
keywords:
- git
- issue tracker
- code review
- wiki
- gitea
- gogs
sources:
- https://gitea.com/gitea/helm-chart
- https://github.com/go-gitea/gitea
- https://hub.docker.com/r/gitea/gitea/
maintainers:
- name: Charlie Drage
email: charlie@charliedrage.com
- name: Gitea Authors
email: maintainers@gitea.io
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 17:56:55 +00:00
- name: Konrad Lother
email: konrad.lother@novum-rgi.de
- name: Lucas Hahn
email: lucas.hahn@novum-rgi.de
- name: Steven Kriegler
email: sk.bunsenbrenner@gmail.com
- name: Patrick Schratz
email: patrick.schratz@gmail.com
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 17:56:55 +00:00
# Bitnami charts are served from GitHub CDN - See https://github.com/bitnami/charts/issues/10539 for details
Integrate NOVUM-RGI chart into the official helm chart. (#7) Fix ssh port settings Remove blank line from LICENSE file add check for admin user set PROTOCOL default to http Add Konrad Lother as Maintainer Update readme with generic values make app.ini generic - app.ini is now configurable via dictionary in values.yaml - database and server configuration is autogenerated if not defined - http and ssh services now use gitea config settings for targetPort - add default security value INSTALL_LOCK = true - clean up builtin cache settings bump gitea version Add values and Remove vscode TOC comments - values enablePushCreateOrg and enablePushCreateUser have been added to repository settings fix naming order of license and maintainers Multiple improvements for the chart: - add terminationGracePeriodSeconds to shutdown the statefulset gracefully on error - add guard for loadbalancer settings in ssh service - use mysql from bitnami, since they update the version much more frequent (old mysql only uses mysql ~6) - init container now also provisions mysql and external database correctly Fix PVC mounting issues for longhorn storageClass Add examples to readme Fix port setting for ssh Fix and operator for newer helm versions update values to support most configuration gitea offers Replace Readme update license file Update helpers with dependencies, update NOTES.txt update Chart.yaml with dependencies Requirements.yaml removed, since this is deprecated and moved to Chart.yaml Remove now unused dependencies and deployments - init is no longer used since databases are initialized on original charts and managed with dependency - ingress.yaml moved to templates/gitea - deployment.yaml no longer used and replaced with templates/gitea/statefulset.yaml - memcached also handled with helm dependency and initialized in original chart Add initial test for gitea helm chart Rework templates for helm chart. - app.ini configurable via config - admin user and ldap settings configurable via config - using statefulset to handle pvc - update helpers for new dependencies remove helm build artifacts since they are not needed in this repository Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Co-authored-by: Konrad Lother <konrad.lother@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/7 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-08-23 17:56:55 +00:00
dependencies:
2023-07-17 21:26:45 +02:00
# Chart release date: 2023-07 (https://github.com/bitnami/charts/blob/main/bitnami/postgresql/Chart.yaml)
- name: postgresql
repository: oci://registry-1.docker.io/bitnamicharts
2023-07-17 21:26:45 +02:00
version: 12.6.6
condition: postgresql.enabled
2023-07-17 21:26:45 +02:00
# Chart release date: 2023-07 (https://github.com/bitnami/charts/blob/main/bitnami/postgresql-ha/Chart.yaml)
[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 19:09:42 +00:00
- name: postgresql-ha
repository: oci://registry-1.docker.io/bitnamicharts
2023-07-17 21:26:45 +02:00
version: 11.7.9
[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 19:09:42 +00:00
condition: postgresql-ha.enabled
2023-07-17 21:26:45 +02:00
# Chart release date: 2023-07 (https://github.com/bitnami/charts/blob/main/bitnami/redis-cluster/Chart.yaml)
[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 19:09:42 +00:00
- name: redis-cluster
repository: oci://registry-1.docker.io/bitnamicharts
2023-07-17 21:26:45 +02:00
version: 8.6.9
[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 19:09:42 +00:00
condition: redis-cluster.enabled