forgejo-helm/values.yaml

793 lines
29 KiB
YAML
Raw Permalink Normal View History

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
# Default values for gitea.
# This is a YAML-formatted file.
# Declare variables to be passed into your templates.
## @section Global
#
## @param global.imageRegistry global image registry override
## @param global.imagePullSecrets global image pull secrets override; can be extended by `imagePullSecrets`
## @param global.storageClass global storage class override
## @param global.hostAliases global hostAliases which will be added to the pod's hosts files
global:
imageRegistry: ''
## E.g.
## imagePullSecrets:
## - myRegistryKeySecretName
##
imagePullSecrets: []
storageClass: ''
hostAliases: []
# - ip: 192.168.137.2
# hostnames:
# - example.com
## @param namespaceOverride String to fully override common.names.namespace
##
namespaceOverride: ''
[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
## @param replicaCount number of replicas for the deployment
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
replicaCount: 1
[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
## @section strategy
## @param strategy.type strategy type
## @param strategy.rollingUpdate.maxSurge maxSurge
## @param strategy.rollingUpdate.maxUnavailable maxUnavailable
strategy:
type: 'RollingUpdate'
[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
rollingUpdate:
maxSurge: '100%'
[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
maxUnavailable: 0
## @param clusterDomain cluster domain
clusterDomain: cluster.local
## @section Image
## @param image.registry image registry, e.g. gcr.io,docker.io
## @param image.repository Image to start for this pod
## @param image.tag Visit: [Image tag](https://code.forgejo.org/forgejo/-/packages/container/forgejo/versions). Defaults to `appVersion` within Chart.yaml.
## @param image.digest Image digest. Allows to pin the given image tag. Useful for having control over mutable tags like `latest`
## @param image.pullPolicy Image pull policy
## @param image.rootless Wether or not to pull the rootless version of Forgejo
## @param image.fullOverride Completely overrides the image registry, path/image, tag and digest. **Adjust `image.rootless` accordingly and review [Rootless defaults](#rootless-defaults).**
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
image:
registry: code.forgejo.org
2023-01-03 16:47:23 +00:00
repository: forgejo/forgejo
# Overrides the image tag whose default is the chart appVersion.
tag: ''
digest: ''
pullPolicy: IfNotPresent
rootless: true
fullOverride: ''
## @param imagePullSecrets Secret to use for pulling the image
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
imagePullSecrets: []
## @section Security
split the securityContext in two: pod and container securityContext (#259) Hello ! I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍 I would like to contribute the following enhancement. ## The problem I want to solve I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized. Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed. The current helm chart does not allow me to achieve this because: - the container security context is configurable only for the main container. The security context of init containers cannot be specified. - a fixed uid is hard coded - a fixed fs group is hard coded Also, the securityContext of a pod and the securityContext of a container do not accept the same options. - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core ## How I'm solving the problem I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions. The behavior for existing deployments is unchanged: - fsGroup 1000 is the default value for the podSecurityContext variable - the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext - the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not. This approach is well tested: it is used consistently on bitnami's Helm charts. ## How I tested I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7. **rootless variant on Kubernetes**: ```yaml podSecurityContext: fsGroup: 10001 containerSecurityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL add: - SYS_CHROOT privileged: false runAsGroup: 10001 runAsNonRoot: true runAsUser: 10001 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` **rootless variant on OpenShift**: ```yaml podSecurityContext: fsGroup: null containerSecurityContext: allowPrivilegeEscalation: false privileged: false runAsNonRoot: true runAsUser: 1000790000 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` Let me know if something is unclear. Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io> Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
2021-12-18 11:10:48 +00:00
# Security context is only usable with rootless image due to image design
## @param podSecurityContext.fsGroup Set the shared file system group for all containers in the pod.
split the securityContext in two: pod and container securityContext (#259) Hello ! I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍 I would like to contribute the following enhancement. ## The problem I want to solve I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized. Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed. The current helm chart does not allow me to achieve this because: - the container security context is configurable only for the main container. The security context of init containers cannot be specified. - a fixed uid is hard coded - a fixed fs group is hard coded Also, the securityContext of a pod and the securityContext of a container do not accept the same options. - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core ## How I'm solving the problem I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions. The behavior for existing deployments is unchanged: - fsGroup 1000 is the default value for the podSecurityContext variable - the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext - the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not. This approach is well tested: it is used consistently on bitnami's Helm charts. ## How I tested I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7. **rootless variant on Kubernetes**: ```yaml podSecurityContext: fsGroup: 10001 containerSecurityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL add: - SYS_CHROOT privileged: false runAsGroup: 10001 runAsNonRoot: true runAsUser: 10001 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` **rootless variant on OpenShift**: ```yaml podSecurityContext: fsGroup: null containerSecurityContext: allowPrivilegeEscalation: false privileged: false runAsNonRoot: true runAsUser: 1000790000 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` Let me know if something is unclear. Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io> Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
2021-12-18 11:10:48 +00:00
podSecurityContext:
fsGroup: 1000
## @param containerSecurityContext Security context
split the securityContext in two: pod and container securityContext (#259) Hello ! I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍 I would like to contribute the following enhancement. ## The problem I want to solve I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized. Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed. The current helm chart does not allow me to achieve this because: - the container security context is configurable only for the main container. The security context of init containers cannot be specified. - a fixed uid is hard coded - a fixed fs group is hard coded Also, the securityContext of a pod and the securityContext of a container do not accept the same options. - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core ## How I'm solving the problem I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions. The behavior for existing deployments is unchanged: - fsGroup 1000 is the default value for the podSecurityContext variable - the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext - the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not. This approach is well tested: it is used consistently on bitnami's Helm charts. ## How I tested I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7. **rootless variant on Kubernetes**: ```yaml podSecurityContext: fsGroup: 10001 containerSecurityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL add: - SYS_CHROOT privileged: false runAsGroup: 10001 runAsNonRoot: true runAsUser: 10001 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` **rootless variant on OpenShift**: ```yaml podSecurityContext: fsGroup: null containerSecurityContext: allowPrivilegeEscalation: false privileged: false runAsNonRoot: true runAsUser: 1000790000 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` Let me know if something is unclear. Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io> Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
2021-12-18 11:10:48 +00:00
containerSecurityContext: {}
# allowPrivilegeEscalation: false
# capabilities:
# drop:
# - ALL
# # Add the SYS_CHROOT capability for root and rootless images if you intend to
# # run pods on nodes that use the container runtime cri-o. Otherwise, you will
# # get an error message from the SSH server that it is not possible to read from
# # the repository.
# # https://gitea.com/gitea/helm-chart/issues/161
# add:
# - SYS_CHROOT
# privileged: false
# readOnlyRootFilesystem: true
# runAsGroup: 1000
# runAsNonRoot: true
# runAsUser: 1000
## @deprecated The securityContext variable has been split two:
## - containerSecurityContext
## - podSecurityContext.
2023-01-03 16:47:23 +00:00
## @param securityContext Run init and Forgejo containers as a specific securityContext
split the securityContext in two: pod and container securityContext (#259) Hello ! I'm using the new Helm chart (5.x) and I really like the new configuration mechanism. 👍 I would like to contribute the following enhancement. ## The problem I want to solve I'm trying to deploy Gitea in a Kubernetes shared platform and I need to make sure each instance is running as a different user so that in case of container escape, the risk of data leak is minimized. Additionally, on my platform (OpenShift), arbitrary users (such as uid 1000 for Gitea) are not allowed. The current helm chart does not allow me to achieve this because: - the container security context is configurable only for the main container. The security context of init containers cannot be specified. - a fixed uid is hard coded - a fixed fs group is hard coded Also, the securityContext of a pod and the securityContext of a container do not accept the same options. - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#podsecuritycontext-v1-core - https://kubernetes.io/docs/reference/generated/kubernetes-api/v1.19/#securitycontext-v1-core ## How I'm solving the problem I split the `securityContext` (values.yaml) in two: `containerSecurityContext` and `podSecurityContext`. The containerSecurityContext applies to all containers (init and main) in order to be consistent with file permissions. The behavior for existing deployments is unchanged: - fsGroup 1000 is the default value for the podSecurityContext variable - the "configure-gitea" init container uses the uid 1000 unless otherwise stated in the containerSecurityContext - the main container is using the existing securityContext variable when defined in order not to break existing deployments and uses the new containerSecurityContext variable if not. This approach is well tested: it is used consistently on bitnami's Helm charts. ## How I tested I tested both root and rootless variants on a Kubernetes 1.22, as well as rootless variant on OpenShift 4.7. **rootless variant on Kubernetes**: ```yaml podSecurityContext: fsGroup: 10001 containerSecurityContext: allowPrivilegeEscalation: false capabilities: drop: - ALL add: - SYS_CHROOT privileged: false runAsGroup: 10001 runAsNonRoot: true runAsUser: 10001 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` **rootless variant on OpenShift**: ```yaml podSecurityContext: fsGroup: null containerSecurityContext: allowPrivilegeEscalation: false privileged: false runAsNonRoot: true runAsUser: 1000790000 extraVolumes: - name: var-lib-gitea emptyDir: {} extraVolumeMounts: - name: var-lib-gitea readOnly: false mountPath: "/var/lib/gitea" ``` Let me know if something is unclear. Co-authored-by: Nicolas MASSE <nicolas.masse@itix.fr> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/259 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: nmasse-itix <nmasse-itix@noreply.gitea.io> Co-committed-by: nmasse-itix <nmasse-itix@noreply.gitea.io>
2021-12-18 11:10:48 +00:00
securityContext: {}
[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
## @param podDisruptionBudget Pod disruption budget
podDisruptionBudget: {}
# maxUnavailable: 1
# minAvailable: 1
## @section Service
service:
## @param service.http.type Kubernetes service type for web traffic
## @param service.http.port Port number for web traffic
## @param service.http.clusterIP ClusterIP setting for http autosetup for deployment
## @param service.http.loadBalancerIP LoadBalancer IP setting
## @param service.http.nodePort NodePort for http service
## @param service.http.externalTrafficPolicy If `service.http.type` is `NodePort` or `LoadBalancer`, set this to `Local` to enable source IP preservation
## @param service.http.externalIPs External IPs for service
## @param service.http.ipFamilyPolicy HTTP service dual-stack policy
## @param service.http.ipFamilies HTTP service dual-stack familiy selection,for dual-stack parameters see official kubernetes [dual-stack concept documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/).
## @param service.http.loadBalancerSourceRanges Source range filter for http loadbalancer
## @param service.http.annotations HTTP service annotations
## @param service.http.labels HTTP service additional labels
## @param service.http.loadBalancerClass Loadbalancer class
http:
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
type: ClusterIP
port: 3000
clusterIP:
loadBalancerIP:
nodePort:
externalTrafficPolicy:
externalIPs:
ipFamilyPolicy:
ipFamilies:
loadBalancerSourceRanges: []
annotations: {}
labels: {}
loadBalancerClass:
## @param service.ssh.type Kubernetes service type for ssh traffic
## @param service.ssh.port Port number for ssh traffic
## @param service.ssh.clusterIP ClusterIP setting for ssh autosetup for deployment
## @param service.ssh.loadBalancerIP LoadBalancer IP setting
## @param service.ssh.nodePort NodePort for ssh service
## @param service.ssh.externalTrafficPolicy If `service.ssh.type` is `NodePort` or `LoadBalancer`, set this to `Local` to enable source IP preservation
## @param service.ssh.externalIPs External IPs for service
## @param service.ssh.ipFamilyPolicy SSH service dual-stack policy
## @param service.ssh.ipFamilies SSH service dual-stack familiy selection,for dual-stack parameters see official kubernetes [dual-stack concept documentation](https://kubernetes.io/docs/concepts/services-networking/dual-stack/).
## @param service.ssh.hostPort HostPort for ssh service
## @param service.ssh.loadBalancerSourceRanges Source range filter for ssh loadbalancer
## @param service.ssh.annotations SSH service annotations
## @param service.ssh.labels SSH service additional labels
## @param service.ssh.loadBalancerClass Loadbalancer class
ssh:
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
type: ClusterIP
port: 22
clusterIP:
loadBalancerIP:
nodePort:
externalTrafficPolicy:
externalIPs:
ipFamilyPolicy:
ipFamilies:
hostPort:
loadBalancerSourceRanges: []
annotations: {}
labels: {}
loadBalancerClass:
## @section Ingress
## @param ingress.enabled Enable ingress
## @param ingress.className Ingress class name
## @param ingress.annotations Ingress annotations
## @param ingress.hosts[0].host Default Ingress host
## @param ingress.hosts[0].paths[0].path Default Ingress path
## @param ingress.hosts[0].paths[0].pathType Ingress path type
## @param ingress.tls Ingress tls settings
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
ingress:
enabled: false
# className: nginx
className:
annotations:
{}
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
# kubernetes.io/ingress.class: nginx
# kubernetes.io/tls-acme: "true"
hosts:
- host: git.example.com
paths:
- path: /
pathType: Prefix
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
tls: []
# - secretName: chart-example-tls
# hosts:
# - git.example.com
## @section Route
## @param route.enabled Enable route
## @param route.annotations Route annotations
## @param route.host Host to use for the route (will be assigned automatically by OKD / OpenShift is not defined)
## @param route.wildcardPolicy Wildcard policy if any for the route, currently only 'Subdomain' or 'None' is allowed.
## @param route.tls.termination termination type (see [OKD documentation](https://docs.okd.io/latest/rest_api/network_apis/route-route-openshift-io-v1.html#spec-tls))
## @param route.tls.insecureEdgeTerminationPolicy the desired behavior for insecure connections to a route (e.g. with http)
## @param route.tls.existingSecret the name of a predefined secret of type kubernetes.io/tls with both key (tls.crt and tls.key) set accordingly (if defined attributes 'certificate', 'caCertificate' and 'privateKey' are ignored)
## @param route.tls.certificate PEM encoded single certificate
## @param route.tls.privateKey PEM encoded private key
## @param route.tls.caCertificate PEM encoded CA certificate or chain that issued the certificate
## @param route.tls.destinationCACertificate PEM encoded CA certificate used to verify the authenticity of final end point when 'termination' is set to 'passthrough' (ignored otherwise)
route:
enabled: false
annotations: {}
host:
wildcardPolicy:
tls:
termination: edge
insecureEdgeTerminationPolicy: Redirect
existingSecret:
certificate:
# certificate: |-
# -----BEGIN CERTIFICATE-----
# ...
# -----END CERTIFICATE-----
privateKey:
# privateKey: |-
# -----BEGIN PRIVATE KEY-----
# ...
# -----END PRIVATE KEY-----
caCertificate:
# caCertificate: |-
# -----BEGIN CERTIFICATE-----
# ...
# -----END CERTIFICATE-----
destinationCACertificate:
# destinationCACertificate: |-
# -----BEGIN CERTIFICATE-----
# ...
# -----END CERTIFICATE-----
[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
## @section deployment
#
## @param resources Kubernetes resources
resources:
{}
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
# We usually recommend not to specify default resources and to leave this as a conscious
# choice for the user. This also increases chances charts run on environments with little
# resources, such as Minikube. If you do want to specify resources, uncomment the following
# lines, adjust them as necessary, and remove the curly braces after 'resources:'.
# limits:
# cpu: 100m
# memory: 128Mi
# requests:
# cpu: 100m
# memory: 128Mi
## Use an alternate scheduler, e.g. "stork".
## ref: https://kubernetes.io/docs/tasks/administer-cluster/configure-multiple-schedulers/
##
## @param schedulerName Use an alternate scheduler, e.g. "stork"
schedulerName: ''
[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
## @param nodeSelector NodeSelector for the deployment
nodeSelector: {}
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
[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
## @param tolerations Tolerations for the deployment
tolerations: []
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
[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
## @param affinity Affinity for the deployment
affinity: {}
[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
## @param topologySpreadConstraints TopologySpreadConstraints for the deployment
topologySpreadConstraints: []
## @param dnsConfig dnsConfig for the deployment
dnsConfig: {}
[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
## @param priorityClassName priorityClassName for the deployment
priorityClassName: ''
[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
## @param deployment.env Additional environment variables to pass to containers
## @param deployment.terminationGracePeriodSeconds How long to wait until forcefully kill the pod
## @param deployment.labels Labels for the deployment
## @param deployment.annotations Annotations for the Forgejo deployment to be created
[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
deployment:
env:
[]
# - name: VARIABLE
# value: my-value
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
terminationGracePeriodSeconds: 60
labels: {}
annotations: {}
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
## @section ServiceAccount
## @param serviceAccount.create Enable the creation of a ServiceAccount
## @param serviceAccount.name Name of the created ServiceAccount, defaults to release name. Can also link to an externally provided ServiceAccount that should be used.
## @param serviceAccount.automountServiceAccountToken Enable/disable auto mounting of the service account token
## @param serviceAccount.imagePullSecrets Image pull secrets, available to the ServiceAccount
## @param serviceAccount.annotations Custom annotations for the ServiceAccount
## @param serviceAccount.labels Custom labels for the ServiceAccount
serviceAccount:
create: false
name: ''
automountServiceAccountToken: false
imagePullSecrets: []
[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: private-registry-access
annotations: {}
labels: {}
## @section Persistence
#
## @param persistence.enabled Enable persistent storage
[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
## @param persistence.create Whether to create the persistentVolumeClaim for shared storage
## @param persistence.mount Whether the persistentVolumeClaim should be mounted (even if not created)
## @param persistence.claimName Use an existing claim to store repository information
## @param persistence.size Size for persistence to store repo information
## @param persistence.accessModes AccessMode for persistence
## @param persistence.labels Labels for the persistence volume claim to be created
## @param persistence.annotations.helm.sh/resource-policy Resource policy for the persistence volume claim
## @param persistence.storageClass Name of the storage class to use
## @param persistence.subPath Subdirectory of the volume to mount at
## @param persistence.volumeName Name of persistent volume in PVC
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
persistence:
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 19:09:42 +00:00
create: true
mount: true
claimName: gitea-shared-storage
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
size: 10Gi
accessModes:
- ReadWriteOnce
labels: {}
storageClass:
subPath:
volumeName: ''
annotations:
helm.sh/resource-policy: keep
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
## @param extraVolumes Additional volumes to mount to the Forgejo deployment
extraVolumes: []
enhancements to support postgres client-cert authentication (#47) This PR adds a few new chart features which adds to the flexibility of the chart. - allow extra volumes to be mounted (such as secrets): 2f862c5a48 - pass environment variables also to the init-container: 7044049478 - allow a preparation script to be "injected" into the init-container: 6125a69345 As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret: ``` apiVersion: v1 kind: Secret type: Opaque metadata: name: gitea-postgres-ssl data: postgresql.crt: <base64...> postgresql.key: <base64...> root.crt: <base64...> ``` and then mounting this as a volume in Gitea using: ``` extraVolumes: - name: postgres-ssl-vol secret: secretName: gitea-postgres-ssl extraVolumeMounts: - name: postgres-ssl-vol readOnly: true mountPath: "/pg-ssl" ``` To get the right permissions on the credentials, we'd use the `initPreScript`: ``` initPreScript: | # copy postgres client and CA cert from mount and # give proper permissions mkdir -p /data/git/.postgresql cp /pg-ssl/* /data/git/.postgresql/ chown -R git:git /data/git/.postgresql/ chmod 400 /data/git/.postgresql/postgresql.key ``` and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container): ``` statefulset: env: - name: "PGSSLCERT" value: "/data/git/.postgresql/postgresql.crt" - name: "PGSSLKEY" value: "/data/git/.postgresql/postgresql.key" - name: "PGSSLROOTCERT" value: "/data/git/.postgresql/root.crt" ``` Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io> Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
2021-01-20 11:28:39 +00:00
# - name: postgres-ssl-vol
# secret:
# secretName: gitea-postgres-ssl
2023-01-03 16:47:23 +00:00
## @param extraContainerVolumeMounts Mounts that are only mapped into the Forgejo runtime/main container, to e.g. override custom templates.
extraContainerVolumeMounts: []
enhancements to support postgres client-cert authentication (#47) This PR adds a few new chart features which adds to the flexibility of the chart. - allow extra volumes to be mounted (such as secrets): 2f862c5a48 - pass environment variables also to the init-container: 7044049478 - allow a preparation script to be "injected" into the init-container: 6125a69345 As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret: ``` apiVersion: v1 kind: Secret type: Opaque metadata: name: gitea-postgres-ssl data: postgresql.crt: <base64...> postgresql.key: <base64...> root.crt: <base64...> ``` and then mounting this as a volume in Gitea using: ``` extraVolumes: - name: postgres-ssl-vol secret: secretName: gitea-postgres-ssl extraVolumeMounts: - name: postgres-ssl-vol readOnly: true mountPath: "/pg-ssl" ``` To get the right permissions on the credentials, we'd use the `initPreScript`: ``` initPreScript: | # copy postgres client and CA cert from mount and # give proper permissions mkdir -p /data/git/.postgresql cp /pg-ssl/* /data/git/.postgresql/ chown -R git:git /data/git/.postgresql/ chmod 400 /data/git/.postgresql/postgresql.key ``` and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container): ``` statefulset: env: - name: "PGSSLCERT" value: "/data/git/.postgresql/postgresql.crt" - name: "PGSSLKEY" value: "/data/git/.postgresql/postgresql.key" - name: "PGSSLROOTCERT" value: "/data/git/.postgresql/root.crt" ``` Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io> Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
2021-01-20 11:28:39 +00:00
## @param extraInitVolumeMounts Mounts that are only mapped into the init-containers. Can be used for additional preconfiguration.
extraInitVolumeMounts: []
## @deprecated The extraVolumeMounts variable has been split two:
## - extraContainerVolumeMounts
## - extraInitVolumeMounts
## As an example, can be used to mount a client cert when connecting to an external Postgres server.
2023-01-03 16:47:23 +00:00
## @param extraVolumeMounts **DEPRECATED** Additional volume mounts for init containers and the Forgejo main container
extraVolumeMounts: []
enhancements to support postgres client-cert authentication (#47) This PR adds a few new chart features which adds to the flexibility of the chart. - allow extra volumes to be mounted (such as secrets): 2f862c5a48 - pass environment variables also to the init-container: 7044049478 - allow a preparation script to be "injected" into the init-container: 6125a69345 As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret: ``` apiVersion: v1 kind: Secret type: Opaque metadata: name: gitea-postgres-ssl data: postgresql.crt: <base64...> postgresql.key: <base64...> root.crt: <base64...> ``` and then mounting this as a volume in Gitea using: ``` extraVolumes: - name: postgres-ssl-vol secret: secretName: gitea-postgres-ssl extraVolumeMounts: - name: postgres-ssl-vol readOnly: true mountPath: "/pg-ssl" ``` To get the right permissions on the credentials, we'd use the `initPreScript`: ``` initPreScript: | # copy postgres client and CA cert from mount and # give proper permissions mkdir -p /data/git/.postgresql cp /pg-ssl/* /data/git/.postgresql/ chown -R git:git /data/git/.postgresql/ chmod 400 /data/git/.postgresql/postgresql.key ``` and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container): ``` statefulset: env: - name: "PGSSLCERT" value: "/data/git/.postgresql/postgresql.crt" - name: "PGSSLKEY" value: "/data/git/.postgresql/postgresql.key" - name: "PGSSLROOTCERT" value: "/data/git/.postgresql/root.crt" ``` Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io> Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
2021-01-20 11:28:39 +00:00
# - name: postgres-ssl-vol
# readOnly: true
# mountPath: "/pg-ssl"
## @section Init
## @param initPreScript Bash shell script copied verbatim to the start of the init-container.
initPreScript: ''
enhancements to support postgres client-cert authentication (#47) This PR adds a few new chart features which adds to the flexibility of the chart. - allow extra volumes to be mounted (such as secrets): 2f862c5a48 - pass environment variables also to the init-container: 7044049478 - allow a preparation script to be "injected" into the init-container: 6125a69345 As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret: ``` apiVersion: v1 kind: Secret type: Opaque metadata: name: gitea-postgres-ssl data: postgresql.crt: <base64...> postgresql.key: <base64...> root.crt: <base64...> ``` and then mounting this as a volume in Gitea using: ``` extraVolumes: - name: postgres-ssl-vol secret: secretName: gitea-postgres-ssl extraVolumeMounts: - name: postgres-ssl-vol readOnly: true mountPath: "/pg-ssl" ``` To get the right permissions on the credentials, we'd use the `initPreScript`: ``` initPreScript: | # copy postgres client and CA cert from mount and # give proper permissions mkdir -p /data/git/.postgresql cp /pg-ssl/* /data/git/.postgresql/ chown -R git:git /data/git/.postgresql/ chmod 400 /data/git/.postgresql/postgresql.key ``` and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container): ``` statefulset: env: - name: "PGSSLCERT" value: "/data/git/.postgresql/postgresql.crt" - name: "PGSSLKEY" value: "/data/git/.postgresql/postgresql.key" - name: "PGSSLROOTCERT" value: "/data/git/.postgresql/root.crt" ``` Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io> Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
2021-01-20 11:28:39 +00:00
#
# initPreScript: |
# mkdir -p /data/git/.postgresql
# cp /pg-ssl/* /data/git/.postgresql/
# chown -R git:git /data/git/.postgresql/
# chmod 400 /data/git/.postgresql/postgresql.key
## @param initContainers.resources.limits initContainers.limits Kubernetes resource limits for init containers
## @param initContainers.resources.requests.cpu initContainers.requests.cpu Kubernetes cpu resource limits for init containers
## @param initContainers.resources.requests.memory initContainers.requests.memory Kubernetes memory resource limits for init containers
initContainers:
resources:
limits: {}
requests:
cpu: 100m
memory: 128Mi
# Configure commit/action signing prerequisites
## @section Signing
#
## @param signing.enabled Enable commit/action signing
## @param signing.gpgHome GPG home directory
## @param signing.privateKey Inline private gpg key for signed internal Git activity
## @param signing.existingSecret Use an existing secret to store the value of `signing.privateKey`
signing:
enabled: false
gpgHome: /data/git/.gnupg
privateKey: ''
# privateKey: |-
# -----BEGIN PGP PRIVATE KEY BLOCK-----
# ...
# -----END PGP PRIVATE KEY BLOCK-----
existingSecret: ''
enhancements to support postgres client-cert authentication (#47) This PR adds a few new chart features which adds to the flexibility of the chart. - allow extra volumes to be mounted (such as secrets): 2f862c5a48 - pass environment variables also to the init-container: 7044049478 - allow a preparation script to be "injected" into the init-container: 6125a69345 As a concrete example of how this can be used, I use is to configure Gitea to use client certificate authentication against an external Postgres database. That could be accomplished by having a `gitea-postgres-ssl` secret: ``` apiVersion: v1 kind: Secret type: Opaque metadata: name: gitea-postgres-ssl data: postgresql.crt: <base64...> postgresql.key: <base64...> root.crt: <base64...> ``` and then mounting this as a volume in Gitea using: ``` extraVolumes: - name: postgres-ssl-vol secret: secretName: gitea-postgres-ssl extraVolumeMounts: - name: postgres-ssl-vol readOnly: true mountPath: "/pg-ssl" ``` To get the right permissions on the credentials, we'd use the `initPreScript`: ``` initPreScript: | # copy postgres client and CA cert from mount and # give proper permissions mkdir -p /data/git/.postgresql cp /pg-ssl/* /data/git/.postgresql/ chown -R git:git /data/git/.postgresql/ chmod 400 /data/git/.postgresql/postgresql.key ``` and to make sure that Gitea uses the certificate we need to pass the proper postgres environment variables (both to the init container and the "main" container): ``` statefulset: env: - name: "PGSSLCERT" value: "/data/git/.postgresql/postgresql.crt" - name: "PGSSLKEY" value: "/data/git/.postgresql/postgresql.key" - name: "PGSSLROOTCERT" value: "/data/git/.postgresql/root.crt" ``` Co-authored-by: Peter Gardfjäll <peter.gardfjall.work@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/47 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: petergardfjall <petergardfjall@noreply.gitea.io> Co-committed-by: petergardfjall <petergardfjall@noreply.gitea.io>
2021-01-20 11:28:39 +00:00
2023-01-03 16:52:18 +00:00
## @section Gitea
#
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
gitea:
2023-01-03 16:47:23 +00:00
## @param gitea.admin.username Username for the Forgejo admin user
## @param gitea.admin.existingSecret Use an existing secret to store admin user credentials
2023-01-03 16:47:23 +00:00
## @param gitea.admin.password Password for the Forgejo admin user
## @param gitea.admin.email Email for the Forgejo admin user
## @param gitea.admin.passwordMode Mode for how to set/update the admin user password. Options are: initialOnlyNoReset, initialOnlyRequireReset, and keepUpdated
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
admin:
# existingSecret: gitea-admin-secret
existingSecret:
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
username: gitea_admin
password: r8sA8CPHD9!bt6d
email: 'gitea@local.domain'
passwordMode: keepUpdated
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
2023-01-03 16:47:23 +00:00
## @param gitea.metrics.enabled Enable Forgejo metrics
## @param gitea.metrics.serviceMonitor.enabled Enable Forgejo metrics service monitor
## @param gitea.metrics.serviceMonitor.namespace Namespace in which Prometheus is running
metrics:
enabled: false
serviceMonitor:
enabled: false
namespace: ''
# additionalLabels:
# prometheus-release: prom1
## @param gitea.ldap LDAP configuration
ldap:
[]
# - name: "LDAP 1"
# existingSecret:
# securityProtocol:
# host:
# port:
# userSearchBase:
# userFilter:
# adminFilter:
# emailAttribute:
# bindDn:
# bindPassword:
# usernameAttribute:
# publicSSHKeyAttribute:
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
# Either specify inline `key` and `secret` or refer to them via `existingSecret`
## @param gitea.oauth OAuth configuration
oauth:
[]
# - name: 'OAuth 1'
# provider:
# key:
# secret:
# existingSecret:
# autoDiscoverUrl:
# useCustomUrls:
# customAuthUrl:
# customTokenUrl:
# customProfileUrl:
# customEmailUrl:
## @param gitea.additionalConfigSources Additional configuration from secret or configmap
additionalConfigSources: []
# - secret:
# secretName: gitea-app-ini-oauth
# - configMap:
# name: gitea-app-ini-plaintext
## @param gitea.additionalConfigFromEnvs Additional configuration sources from environment variables
additionalConfigFromEnvs: []
2023-01-03 16:47:23 +00:00
## @param gitea.podAnnotations Annotations for the Forgejo pod
podAnnotations: {}
2023-05-10 08:22:58 +00:00
## @param gitea.ssh.logLevel Configure OpenSSH's log level. Only available for root-based Forgejo image.
ssh:
logLevel: 'INFO'
## @section `app.ini` overrides
## @descriptionStart
## Every value described in the [Cheat
## Sheet](https://forgejo.org/docs/latest/admin/config-cheat-sheet/) can be
## set as a Helm value. Configuration sections map to (lowercased) YAML
## blocks, while the keys themselves remain in all caps.
## @descriptionEnd
config:
# values in the DEFAULT section
# (https://forgejo.org/docs/latest/admin/config-cheat-sheet/#overall-default)
# are un-namespaced
## @param gitea.config.APP_NAME Application name, used in the page title
APP_NAME: 'Forgejo: Beyond coding. We forge.'
## @param gitea.config.RUN_MODE Application run mode, affects performance and debugging: `dev` or `prod`
RUN_MODE: prod
## @param gitea.config.repository General repository settings
repository: {}
## @param gitea.config.cors Cross-origin resource sharing settings
cors: {}
## @param gitea.config.ui User interface settings
ui: {}
## @param gitea.config.markdown Markdown parser settings
markdown: {}
## @param gitea.config.server [object] General server settings
server:
SSH_PORT: 22 # rootful image
SSH_LISTEN_PORT: 2222 # rootless image
## @param gitea.config.database Database configuration (only necessary with an [externally managed DB](https://code.forgejo.org/forgejo-helm/forgejo-helm#external-database)).
database: {}
## @param gitea.config.indexer Settings for what content is indexed and how
indexer: {}
## @param gitea.config.queue Job queue configuration
queue: {}
## @param gitea.config.admin Admin user settings
admin: {}
## @param gitea.config.security Site security settings
security: {}
## @param gitea.config.camo Settings for the [camo](https://github.com/cactus/go-camo) media proxy server (disabled by default)
camo: {}
## @param gitea.config.openid Configuration for authentication with OpenID (disabled by default)
openid: {}
## @param gitea.config.oauth2_client OAuth2 client settings
oauth2_client: {}
## @param gitea.config.service Configuration for miscellaneous Forgejo services
service: {}
## @param gitea.config.ssh.minimum_key_sizes SSH minimum key sizes
ssh.minimum_key_sizes: {}
## @param gitea.config.webhook Webhook settings
webhook: {}
## @param gitea.config.mailer Mailer configuration (disabled by default)
mailer: {}
## @param gitea.config.email.incoming Configuration for handling incoming mail (disabled by default)
email.incoming: {}
## @param gitea.config.cache Cache configuration
cache: {}
## @param gitea.config.session Session/cookie handling
session: {}
## @param gitea.config.picture User avatar settings
picture: {}
## @param gitea.config.project Project board defaults
project: {}
## @param gitea.config.attachment Issue and PR attachment configuration
attachment: {}
## @param gitea.config.log Logging configuration
log: {}
## @param gitea.config.cron Cron job configuration
cron: {}
## @param gitea.config.git Global settings for Git
git: {}
## @param gitea.config.metrics Settings for the Prometheus endpoint (disabled by default)
metrics: {}
## @param gitea.config.api Settings for the Swagger API documentation endpoints
api: {}
## @param gitea.config.oauth2 Settings for the [OAuth2 provider](https://forgejo.org/docs/latest/admin/oauth2-provider/)
oauth2: {}
## @param gitea.config.i18n Internationalization settings
i18n: {}
## @param gitea.config.markup Configuration for advanced markup processors
markup: {}
## @param gitea.config.highlight.mapping File extension to language mapping overrides for syntax highlighting
highlight.mapping: {}
## @param gitea.config.time Locale settings
time: {}
## @param gitea.config.migrations Settings for Git repository migrations
migrations: {}
## @param gitea.config.federation Federation configuration
federation: {}
## @param gitea.config.packages Package registry settings
packages: {}
## @param gitea.config.mirror Configuration for repository mirroring
mirror: {}
## @param gitea.config.lfs Large File Storage configuration
lfs: {}
## @param gitea.config.repo-avatar Repository avatar storage configuration
repo-avatar: {}
## @param gitea.config.avatar User/org avatar storage configuration
avatar: {}
## @param gitea.config.storage General storage settings
storage: {}
## @param gitea.config.proxy Proxy configuration (disabled by default)
proxy: {}
## @param gitea.config.actions Configuration for [Forgejo Actions](https://forgejo.org/docs/latest/user/actions/)
actions: {}
## @param gitea.config.other Uncategorized configuration options
other: {}
## @section LivenessProbe
#
## @param gitea.livenessProbe.enabled Enable liveness probe
## @param gitea.livenessProbe.tcpSocket.port Port to probe for liveness
## @param gitea.livenessProbe.initialDelaySeconds Initial delay before liveness probe is initiated
## @param gitea.livenessProbe.timeoutSeconds Timeout for liveness probe
## @param gitea.livenessProbe.periodSeconds Period for liveness probe
## @param gitea.livenessProbe.successThreshold Success threshold for liveness probe
## @param gitea.livenessProbe.failureThreshold Failure threshold for liveness probe
# Modify the liveness probe for your needs or completely disable it by commenting out.
livenessProbe:
enabled: true
tcpSocket:
port: http
initialDelaySeconds: 200
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 10
## @section ReadinessProbe
#
## @param gitea.readinessProbe.enabled Enable readiness probe
## @param gitea.readinessProbe.httpGet.path Path to probe for readiness
## @param gitea.readinessProbe.httpGet.port Port to probe for readiness
## @param gitea.readinessProbe.initialDelaySeconds Initial delay before readiness probe is initiated
## @param gitea.readinessProbe.timeoutSeconds Timeout for readiness probe
## @param gitea.readinessProbe.periodSeconds Period for readiness probe
## @param gitea.readinessProbe.successThreshold Success threshold for readiness probe
## @param gitea.readinessProbe.failureThreshold Failure threshold for readiness probe
# Modify the readiness probe for your needs or completely disable it by commenting out.
readinessProbe:
enabled: true
httpGet:
path: /api/healthz
port: http
initialDelaySeconds: 5
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 3
# # Uncomment the startup probe to enable and modify it for your needs.
## @section StartupProbe
#
## @param gitea.startupProbe.enabled Enable startup probe
## @param gitea.startupProbe.tcpSocket.port Port to probe for startup
## @param gitea.startupProbe.initialDelaySeconds Initial delay before startup probe is initiated
## @param gitea.startupProbe.timeoutSeconds Timeout for startup probe
## @param gitea.startupProbe.periodSeconds Period for startup probe
## @param gitea.startupProbe.successThreshold Success threshold for startup probe
## @param gitea.startupProbe.failureThreshold Failure threshold for startup probe
startupProbe:
enabled: false
tcpSocket:
port: http
initialDelaySeconds: 60
timeoutSeconds: 1
periodSeconds: 10
successThreshold: 1
failureThreshold: 10
## @section Redis&reg; Cluster
## @descriptionStart
## Redis&reg; Cluster is loaded as a dependency from [Bitnami](https://github.com/bitnami/charts/tree/master/bitnami/redis-cluster) if enabled in the values.
## Complete Configuration can be taken from their website.
## Redis cluster and [Redis](#redis) cannot be enabled at the same time.
## @descriptionEnd
#
## @param redis-cluster.enabled Enable redis cluster
## @param redis-cluster.usePassword Whether to use password authentication
## @param redis-cluster.cluster.nodes Number of redis cluster master nodes
## @param redis-cluster.cluster.replicas Number of redis cluster master node replicas
[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
redis-cluster:
enabled: true
usePassword: false
cluster:
nodes: 3 # default: 6
replicas: 0 # default: 1
[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
## @section Redis&reg;
## @descriptionStart
## Redis&reg; is loaded as a dependency from [Bitnami](https://github.com/bitnami/charts/tree/master/bitnami/redis) if enabled in the values.
## Complete Configuration can be taken from their website.
## Redis and [Redis cluster](#redis-cluster) cannot be enabled at the same time.
## @descriptionEnd
#
## @param redis.enabled Enable redis standalone or replicated
## @param redis.architecture Whether to use standalone or replication
## @param redis.global.redis.password Required password
## @param redis.master.count Number of Redis master instances to deploy
redis:
enabled: false
architecture: standalone
global:
redis:
password: changeme
master:
count: 1
## @section PostgreSQL HA
## @descriptionStart
## PostgreSQL HA is loaded as a dependency from [Bitnami](https://github.com/bitnami/charts/tree/master/bitnami/postgresql-ha) if enabled in the values.
## Complete Configuration can be taken from their website.
## @descriptionEnd
#
## @param postgresql-ha.enabled Enable PostgreSQL HA chart
## @param postgresql-ha.postgresql.password Password for the `gitea` user (overrides `auth.password`)
## @param postgresql-ha.global.postgresql.database Name for a custom database to create (overrides `auth.database`)
## @param postgresql-ha.global.postgresql.username Name for a custom user to create (overrides `auth.username`)
## @param postgresql-ha.global.postgresql.password Name for a custom password to create (overrides `auth.password`)
## @param postgresql-ha.postgresql.repmgrPassword Repmgr Password
## @param postgresql-ha.postgresql.postgresPassword postgres Password
## @param postgresql-ha.pgpool.adminPassword pgpool adminPassword
## @param postgresql-ha.service.ports.postgresql PostgreSQL service port (overrides `service.ports.postgresql`)
## @param postgresql-ha.primary.persistence.size PVC Storage Request for PostgreSQL HA volume
[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
postgresql-ha:
global:
2023-07-18 16:31:58 +00:00
postgresql:
database: gitea
password: gitea
username: gitea
enabled: true
postgresql:
repmgrPassword: changeme2
postgresPassword: changeme1
password: changeme4
pgpool:
adminPassword: changeme3
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
service:
2023-01-03 21:37:40 +00:00
ports:
postgresql: 5432
[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
primary:
persistence:
size: 10Gi
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
## @section PostgreSQL
## @descriptionStart
## PostgreSQL is loaded as a dependency from [Bitnami](https://github.com/bitnami/charts/tree/master/bitnami/postgresql) if enabled in the values.
## Complete Configuration can be taken from their website.
## @descriptionEnd
#
## @param postgresql.enabled Enable PostgreSQL
## @param postgresql.global.postgresql.auth.password Password for the `gitea` user (overrides `auth.password`)
## @param postgresql.global.postgresql.auth.database Name for a custom database to create (overrides `auth.database`)
## @param postgresql.global.postgresql.auth.username Name for a custom user to create (overrides `auth.username`)
## @param postgresql.global.postgresql.service.ports.postgresql PostgreSQL service port (overrides `service.ports.postgresql`)
2023-01-03 21:34:25 +00:00
## @param postgresql.primary.persistence.size PVC Storage Request for PostgreSQL volume
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
postgresql:
[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
enabled: false
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
global:
postgresql:
auth:
password: gitea
database: gitea
username: gitea
service:
ports:
postgresql: 5432
2023-01-03 21:34:25 +00:00
primary:
persistence:
size: 10Gi
# By default, removed or moved settings that still remain in a user defined values.yaml will cause Helm to fail running the install/update.
# Set it to false to skip this basic validation check.
## @section Advanced
## @param checkDeprecation Set it to false to skip this basic validation check.
## @param test.enabled Set it to false to disable test-connection Pod.
## @param test.image.name Image name for the wget container used in the test-connection Pod.
## @param test.image.tag Image tag for the wget container used in the test-connection Pod.
checkDeprecation: true
test:
enabled: true
image:
name: busybox
tag: latest
add `extraDeploy` to add arbitrary objects to the release (#441) Signed-off-by: Cyril Jouve <jv.cyril@gmail.com> <!-- Before you open the request please review the following guidelines and tips to help it be more easily integrated: - Describe the scope of your change - i.e. what the change does. - Describe any known limitations with your change. - Please run any tests or examples that can exercise your modified code. Thank you for contributing! We will try to review, test and integrate the change as soon as we can. --> ### Description of the change <!-- Describe the scope of your change - i.e. what the change does. --> add a new value `extraDeploy` to add arbitrary resources inspired by bitnami charts ([example](https://github.com/bitnami/charts/blob/main/bitnami/postgresql/values.yaml#L58) ### Benefits <!-- What benefits will be realized by the code change? --> with the change, I can deploy additional resources and keep them consistent with the chart (reuse macro, same labels, etc)., same workflow (helm upgrade), etc ### Possible drawbacks <!-- Describe any known limitations with your change --> ### Additional information <!-- If there's anything else that's important and relevant to your pull request, mention that information here. Please remove this section if it remains empty. --> ### Checklist <!-- [Place an '[X]' (no spaces) in all applicable fields. Please remove unrelated fields.] --> - [x] Parameters are documented in the `values.yaml` and added to the `README.md` using [readme-generator-for-helm](https://github.com/bitnami-labs/readme-generator-for-helm) Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/441 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: Cyril Jouve <jv.cyril@gmail.com> Co-committed-by: Cyril Jouve <jv.cyril@gmail.com>
2023-05-02 13:32:54 +00:00
## @param extraDeploy Array of extra objects to deploy with the release
##
extraDeploy: []