gitea-mirror
/
helm-chart
mirror of https://gitea.com/gitea/helm-chart.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
helm-chart/templates/gitea/deployment.yaml

401 lines
15 KiB
YAML
Raw 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 23:26:55 +05:30
apiVersion: apps/v1
[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-18 00:39:42 +05:30
kind: 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 23:26:55 +05:30
metadata:
name: {{ include "gitea.fullname" . }}
feat: configurable annotations for gitea StatefulSet (#315) Fixes #314 Right now, the gitea StatefulSet does not allow any annotations to be configured via the helmchart - see https://gitea.com/gitea/helm-chart/src/tag/v5.0.4/templates/gitea/statefulset.yaml#L4-L6 My use case: I am trying to use Reloader (https://github.com/stakater/Reloader) so that I can configure my values.yaml such that i can set some annotations on the StatefulSet and thus Reloader can rollout a restart of gitea StatefulSet whenever a watched secret or configmap is updated. Co-authored-by: Tarun Gupta Akirala <tarugupta.92@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/315 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: takirala <takirala@noreply.gitea.io> Co-committed-by: takirala <takirala@noreply.gitea.io>
2022-04-21 21:25:53 +05:30
annotations:
[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-18 00:39:42 +05:30
{{- if .Values.deployment.annotations }}
{{- toYaml .Values.deployment.annotations | nindent 4 }}
feat: configurable annotations for gitea StatefulSet (#315) Fixes #314 Right now, the gitea StatefulSet does not allow any annotations to be configured via the helmchart - see https://gitea.com/gitea/helm-chart/src/tag/v5.0.4/templates/gitea/statefulset.yaml#L4-L6 My use case: I am trying to use Reloader (https://github.com/stakater/Reloader) so that I can configure my values.yaml such that i can set some annotations on the StatefulSet and thus Reloader can rollout a restart of gitea StatefulSet whenever a watched secret or configmap is updated. Co-authored-by: Tarun Gupta Akirala <tarugupta.92@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/315 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: takirala <takirala@noreply.gitea.io> Co-committed-by: takirala <takirala@noreply.gitea.io>
2022-04-21 21:25:53 +05:30
{{- end }}
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 23:26:55 +05:30
labels:
{{- include "gitea.labels" . | nindent 4 }}
spec:
replicas: {{ .Values.replicaCount }}
[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-18 00:39:42 +05:30
strategy:
type: {{ .Values.strategy.type }}
{{- if eq .Values.strategy.type "RollingUpdate" }}
rollingUpdate:
maxUnavailable: {{ .Values.strategy.rollingUpdate.maxUnavailable }}
maxSurge: {{ .Values.strategy.rollingUpdate.maxSurge }}
{{- end }}
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 23:26:55 +05:30
selector:
matchLabels:
{{- include "gitea.selectorLabels" . | nindent 6 }}
[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-18 00:39:42 +05:30
{{- if .Values.deployment.labels }}
{{- toYaml .Values.deployment.labels | nindent 6 }}
Add possibiliy to define statefulset labels (#130) This change adds a new value *statefulset.labels* to allow the user to add custom labels to the StatefulSet. An example of where this could be useful is if gitea's pvc is stored on OpenEBS. With this new option, the user can add the extra *openebs.io/sts-target-affinity* label to specify that the volume target pod should run on the same node as gitea's StatefulSet. Co-authored-by: Baptiste Covolato <b.covolato@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/130 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Nakrez <nakrez@noreply.gitea.io> Co-committed-by: Nakrez <nakrez@noreply.gitea.io>
2021-03-17 05:37:42 +05:30
{{- end }}
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 23:26:55 +05:30
template:
metadata:
annotations:
checksum/config: {{ include (print $.Template.BasePath "/gitea/config.yaml") . | sha256sum }}
Add multiple LDAP sources (#222) Add multiple add sources. Instead of a single entry for ldap configuration we now would have a dictionary for ldap config. This would be a breaking change for those working with the ldap config. fixes: #190 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/222 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-10-08 17:46:24 +05:30
{{- range $idx, $value := .Values.gitea.ldap }}
checksum/ldap_{{ $idx }}: {{ include "gitea.ldap_settings" (list $idx $value) | sha256sum }}
{{- end }}
Rework OAuth sources (#244) This change request includes two different things to improve OAuth source handling: - Allow multiple OAuth source configuration (Fixes: #191) - Support reading sensitive OAuth configuration data from Kubernetes secrets (Closes: #242) ⚠️ BREAKING ⚠️ --- Users need to migrate their `gitea.oauth` configuration. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/244 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-12-20 20:13:55 +05:30
{{- range $idx, $value := .Values.gitea.oauth }}
checksum/oauth_{{ $idx }}: {{ include "gitea.oauth_settings" (list $idx $value) | sha256sum }}
{{- end }}
Ability to add pod annotation to statefulset (#24) ability to add pod annotation Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/24 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io>
2020-09-24 22:02:11 +05:30
{{- with .Values.gitea.podAnnotations }}
{{- toYaml . | nindent 8 }}
{{- end }}
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 23:26:55 +05:30
labels:
Add `app` and `version` labels (#121) This pull request adds the `app` and `version` labels that are used by Istio. > Pods with app and version labels: We recommend adding an explicit app label and version label to the specification of the pods deployed using a Kubernetes Deployment. The app and version labels add contextual information to the metrics and telemetry that Istio collects. > > * The app label: Each deployment should have a distinct app label with a meaningful value. The app label is used to add contextual information in distributed tracing. > > * The version label: This label indicates the version of the application corresponding to the particular deployment. From https://istio.io/latest/docs/ops/deployment/requirements/#pod-requirements Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/121 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Starefossen <starefossen@noreply.gitea.io> Co-committed-by: Starefossen <starefossen@noreply.gitea.io>
2021-03-01 17:50:55 +05:30
{{- include "gitea.labels" . | nindent 8 }}
[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-18 00:39:42 +05:30
{{- if .Values.deployment.labels }}
{{- toYaml .Values.deployment.labels | nindent 8 }}
Add possibiliy to define statefulset labels (#130) This change adds a new value *statefulset.labels* to allow the user to add custom labels to the StatefulSet. An example of where this could be useful is if gitea's pvc is stored on OpenEBS. With this new option, the user can add the extra *openebs.io/sts-target-affinity* label to specify that the volume target pod should run on the same node as gitea's StatefulSet. Co-authored-by: Baptiste Covolato <b.covolato@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/130 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Nakrez <nakrez@noreply.gitea.io> Co-committed-by: Nakrez <nakrez@noreply.gitea.io>
2021-03-17 05:37:42 +05:30
{{- end }}
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 23:26:55 +05:30
spec:
Add value option to define schedulerName (#150) For those who have a need to configure the schedulerName like us, make this an option just as it is for example in the postgres chart Co-authored-by: Dimitri Ars <dimitri.ars@kpn.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/150 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: mrdima <mrdima@noreply.gitea.io> Co-committed-by: mrdima <mrdima@noreply.gitea.io>
2021-06-07 14:11:16 +05:30
{{- if .Values.schedulerName }}
schedulerName: "{{ .Values.schedulerName }}"
{{- end }}
Add support for ServiceAccount configuration (#451) ### Description of the change This adds a new values object `serviceAccount`, that allows creating a dedicated ServiceAccount with the Helm Release into the cluster. It supports all common options like labels, annotations, name override (or referring to an externally created ServiceAccount), auto-mount token, image pull secrets. It supersedes the stale PR #357. ### Benefits Users can deploy Gitea with more fine-tuned security settings. ### Applicable issues - related to #448 ### Additional information I've bumped the helm-unittest plugin in the CI build, to be able to use the `exists` and `notExists` feature in the new tests. ### Checklist - [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) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/451 Reviewed-by: pat-s <pat-s@noreply.gitea.com> Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Co-committed-by: justusbunsi <sk.bunsenbrenner@gmail.com>
2023-05-31 14:17:58 +05:30
{{- if (or .Values.serviceAccount.create .Values.serviceAccount.name) }}
serviceAccountName: {{ include "gitea.serviceAccountName" . }}
{{- end }}
feat: Add support for setting priorityClassName (#430) ### Description of the change Adds support for setting priorityClassName on the Gitea pod. ### Benefits Users can take advantage of https://kubernetes.io/docs/concepts/scheduling-eviction/pod-priority-preemption/ with Gitea. ### Applicable issues - fixes #429 ### 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) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/430 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Co-authored-by: Casey Buto <cbuto@d2iq.com> Co-committed-by: Casey Buto <cbuto@d2iq.com>
2023-04-07 16:28:34 +05:30
{{- if .Values.priorityClassName }}
priorityClassName: "{{ .Values.priorityClassName }}"
{{- end }}
add global values support (#322) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/322 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:25:08 +05:30
{{- include "gitea.images.pullSecrets" . | nindent 6 }}
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 23:26:55 +05:30
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 16:40:48 +05:30
{{- toYaml .Values.podSecurityContext | nindent 8 }}
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 23:26:55 +05:30
initContainers:
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
- name: init-directories
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
image: "{{ include "gitea.image" . }}"
Consider imagePullPolicy for init containers (#317) The default behaviour for container image pulls depend on different values such as image tag usage and its value. See https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting It leads to an unintended behaviour for this Helm Chart. Kubernetes will always pull the image for init containers when using the `latest` Gitea image tag, even if `Values.image.pullPolicy` defines a different value for the runtime container. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/317 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Gusted <williamzijl7@hotmail.com> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-04-22 03:43:19 +05:30
imagePullPolicy: {{ .Values.image.pullPolicy }}
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
command: ["/usr/sbin/init_directory_structure.sh"]
env:
- name: GITEA_APP_INI
value: /data/gitea/conf/app.ini
- name: GITEA_CUSTOM
value: /data/gitea
- name: GITEA_WORK_DIR
value: /data
- name: GITEA_TEMP
value: /tmp/gitea
[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-18 00:39:42 +05:30
{{- if .Values.deployment.env }}
{{- toYaml .Values.deployment.env | nindent 12 }}
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
{{- end }}
Re-add GPG configuration feature (#374) This reverts d5ce1a47eaad935ea709b7a03bfdf6c69bac8f32 and therefore adds the GPG feature back into main. As it is a breaking change, this PR now also contains the required upgrade notes. Closes #107 again. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/374 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com>
2023-01-17 22:28:10 +05:30
{{- if .Values.signing.enabled }}
- name: GNUPGHOME
value: {{ .Values.signing.gpgHome }}
{{- end }}
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
volumeMounts:
- name: init
mountPath: /usr/sbin
- name: temp
mountPath: /tmp
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
- name: data
mountPath: /data
add support for persistence.subPath option (#263) Hello, PR adds a `persistence.subPath` option to provide user more flexibility on mounting the `data` PV. https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath The setting is similar to e.g. `primary.persistence.subPath` in MariaDB helm chart: https://github.com/bitnami/charts/tree/master/bitnami/mariadb Co-authored-by: Aleksey Sergey <sergey.aleksey90@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/263 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io> Co-committed-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io>
2021-12-20 17:28:44 +05:30
{{- if .Values.persistence.subPath }}
subPath: {{ .Values.persistence.subPath }}
{{- end }}
Split "extraVolumeMounts" into init and container mounts (#337) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/337 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-08-08 01:02:19 +05:30
{{- include "gitea.init-additional-mounts" . | nindent 12 }}
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 16:40:48 +05:30
securityContext:
{{- toYaml .Values.containerSecurityContext | nindent 12 }}
Add resource specs to init container (#423) Supersedes stalled #362 I opted for defining `requests` while leaving `limits` open. This might help for scheduling without restricting performance during init. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/423 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-04-01 17:05:11 +05:30
resources:
{{- toYaml .Values.initContainers.resources | nindent 12 }}
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
- name: init-app-ini
image: "{{ include "gitea.image" . }}"
Consider imagePullPolicy for init containers (#317) The default behaviour for container image pulls depend on different values such as image tag usage and its value. See https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting It leads to an unintended behaviour for this Helm Chart. Kubernetes will always pull the image for init containers when using the `latest` Gitea image tag, even if `Values.image.pullPolicy` defines a different value for the runtime container. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/317 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Gusted <williamzijl7@hotmail.com> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-04-22 03:43:19 +05:30
imagePullPolicy: {{ .Values.image.pullPolicy }}
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
command: ["/usr/sbin/config_environment.sh"]
env:
- name: GITEA_APP_INI
value: /data/gitea/conf/app.ini
- name: GITEA_CUSTOM
value: /data/gitea
- name: GITEA_WORK_DIR
value: /data
- name: GITEA_TEMP
value: /tmp/gitea
[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-18 00:39:42 +05:30
{{- if .Values.deployment.env }}
{{- toYaml .Values.deployment.env | nindent 12 }}
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
{{- end }}
Consider environment variables during app.ini creation (#298) This PR improves the handling and injection into _app.ini_ of user defined environment variables via env-to-ini script. Fixes #297 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/298 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de>
2022-03-09 12:17:55 +05:30
{{- if .Values.gitea.additionalConfigFromEnvs }}
{{- toYaml .Values.gitea.additionalConfigFromEnvs | nindent 12 }}
{{- end }}
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
volumeMounts:
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
- name: config
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
mountPath: /usr/sbin
- name: temp
mountPath: /tmp
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
- name: data
mountPath: /data
add support for persistence.subPath option (#263) Hello, PR adds a `persistence.subPath` option to provide user more flexibility on mounting the `data` PV. https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath The setting is similar to e.g. `primary.persistence.subPath` in MariaDB helm chart: https://github.com/bitnami/charts/tree/master/bitnami/mariadb Co-authored-by: Aleksey Sergey <sergey.aleksey90@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/263 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io> Co-committed-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io>
2021-12-20 17:28:44 +05:30
{{- if .Values.persistence.subPath }}
subPath: {{ .Values.persistence.subPath }}
{{- end }}
Generic way for configuring Gitea app.ini (#240) With the result of PR #239 it is much easier to provide additional values to the _app.ini_ configuration from different sources. These changes adds an _additionalConfigSources_ field where the users can define such sources. This enables the users to choose on their own whether to store values in _values.yaml_ or load them from Kuberetes Secrets or ConfigMaps. - Fixes #243 - Fixes #174 - Fixes #260 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/240 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-12-22 16:14:04 +05:30
- name: inline-config-sources
mountPath: /env-to-ini-mounts/inlines/
{{- range $idx, $value := .Values.gitea.additionalConfigSources }}
- name: additional-config-sources-{{ $idx }}
mountPath: "/env-to-ini-mounts/additionals/{{ $idx }}/"
{{- end }}
Split "extraVolumeMounts" into init and container mounts (#337) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/337 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-08-08 01:02:19 +05:30
{{- include "gitea.init-additional-mounts" . | nindent 12 }}
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 16:40:48 +05:30
securityContext:
{{- toYaml .Values.containerSecurityContext | nindent 12 }}
Add resource specs to init container (#423) Supersedes stalled #362 I opted for defining `requests` while leaving `limits` open. This might help for scheduling without restricting performance during init. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/423 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-04-01 17:05:11 +05:30
resources:
{{- toYaml .Values.initContainers.resources | nindent 12 }}
Re-add GPG configuration feature (#374) This reverts d5ce1a47eaad935ea709b7a03bfdf6c69bac8f32 and therefore adds the GPG feature back into main. As it is a breaking change, this PR now also contains the required upgrade notes. Closes #107 again. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/374 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com>
2023-01-17 22:28:10 +05:30
{{- if .Values.signing.enabled }}
- name: configure-gpg
image: "{{ include "gitea.image" . }}"
command: ["/usr/sbin/configure_gpg_environment.sh"]
imagePullPolicy: {{ .Values.image.pullPolicy }}
securityContext:
{{- /* By default this container runs as user 1000 unless otherwise stated */ -}}
{{- $csc := deepCopy .Values.containerSecurityContext -}}
{{- if not (hasKey $csc "runAsUser") -}}
{{- $_ := set $csc "runAsUser" 1000 -}}
{{- end -}}
{{- toYaml $csc | nindent 12 }}
env:
- name: GNUPGHOME
value: {{ .Values.signing.gpgHome }}
volumeMounts:
- name: init
mountPath: /usr/sbin
- name: data
mountPath: /data
{{- if .Values.persistence.subPath }}
subPath: {{ .Values.persistence.subPath }}
{{- end }}
- name: gpg-private-key
mountPath: /raw
readOnly: true
{{- if .Values.extraVolumeMounts }}
{{- toYaml .Values.extraVolumeMounts | nindent 12 }}
{{- end }}
Add resource specs to init container (#423) Supersedes stalled #362 I opted for defining `requests` while leaving `limits` open. This might help for scheduling without restricting performance during init. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/423 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-04-01 17:05:11 +05:30
resources:
{{- toYaml .Values.initContainers.resources | nindent 12 }}
Re-add GPG configuration feature (#374) This reverts d5ce1a47eaad935ea709b7a03bfdf6c69bac8f32 and therefore adds the GPG feature back into main. As it is a breaking change, this PR now also contains the required upgrade notes. Closes #107 again. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/374 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com>
2023-01-17 22:28:10 +05:30
{{- end }}
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
- name: configure-gitea
image: "{{ include "gitea.image" . }}"
command: ["/usr/sbin/configure_gitea.sh"]
Consider imagePullPolicy for init containers (#317) The default behaviour for container image pulls depend on different values such as image tag usage and its value. See https://kubernetes.io/docs/concepts/containers/images/#imagepullpolicy-defaulting It leads to an unintended behaviour for this Helm Chart. Kubernetes will always pull the image for init containers when using the `latest` Gitea image tag, even if `Values.image.pullPolicy` defines a different value for the runtime container. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/317 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Gusted <williamzijl7@hotmail.com> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-04-22 03:43:19 +05:30
imagePullPolicy: {{ .Values.image.pullPolicy }}
Rewrite init script (#178) These changes rewrite the init script to be error aware, informative and have a bit more security awareness. During rewrite several hidden bugs could be identified and fixed, such as: - LDAP configuration options interpreted by the shell before passed to command - Finding multiple ldap ids instead of one during lookup when their names are almost identical e.g. `_my-ldap-auth` and `my-ldap-auth` - Properly filter auth sources by their types to prevent unintended type converting attempts that fail In addition to that the script is a bit cleaner. Some commands do not exist anymore and would cause false-positive errors during script execution. Helps for: #149 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/178 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 01:39:16 +05:30
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 16:40:48 +05:30
{{- /* By default this container runs as user 1000 unless otherwise stated */ -}}
{{- $csc := deepCopy .Values.containerSecurityContext -}}
{{- if not (hasKey $csc "runAsUser") -}}
{{- $_ := set $csc "runAsUser" 1000 -}}
{{- end -}}
{{- toYaml $csc | nindent 12 }}
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 16:58:39 +05:30
env:
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
- name: GITEA_APP_INI
value: /data/gitea/conf/app.ini
- name: GITEA_CUSTOM
value: /data/gitea
- name: GITEA_WORK_DIR
value: /data
Fix regression for creating repositories in root-based containers (#172) Due to #160 it was no longer possible to create repositories in root-based containers. This was caused by the missing `/tmp/gitea` directory in that image. It was dynamically created by Gitea internal functionality with less privileges than necessary. Explicitly creating the directory and set proper permissions fix this. Fixes: #171 Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/172 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-09 20:05:50 +05:30
- name: GITEA_TEMP
value: /tmp/gitea
Set `$HOME` to `/data/gitea/git` for rootless image (#447) fix #396 Set the default of `$HOME` to `/data/gitea/git` for rootless images to make chart openshift compliant. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/447 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-05-24 02:31:22 +05:30
{{- if .Values.image.rootless }}
- name: HOME
value: /data/gitea/git
{{- end }}
Add multiple LDAP sources (#222) Add multiple add sources. Instead of a single entry for ldap configuration we now would have a dictionary for ldap config. This would be a breaking change for those working with the ldap config. fixes: #190 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/222 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-10-08 17:46:24 +05:30
{{- if .Values.gitea.ldap }}
{{- range $idx, $value := .Values.gitea.ldap }}
{{- if $value.existingSecret }}
- name: GITEA_LDAP_BIND_DN_{{ $idx }}
Allow existing secrets for passwords (#170) Allow admin user and password to be configured via existing secrets Allow LDAP bindDn and bindPassword to be configured via existing secrets Update Readme Fixes: #169 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/170 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-06-10 16:43:33 +05:30
valueFrom:
secretKeyRef:
key: bindDn
Add multiple LDAP sources (#222) Add multiple add sources. Instead of a single entry for ldap configuration we now would have a dictionary for ldap config. This would be a breaking change for those working with the ldap config. fixes: #190 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/222 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-10-08 17:46:24 +05:30
name: {{ $value.existingSecret }}
- name: GITEA_LDAP_PASSWORD_{{ $idx }}
Allow existing secrets for passwords (#170) Allow admin user and password to be configured via existing secrets Allow LDAP bindDn and bindPassword to be configured via existing secrets Update Readme Fixes: #169 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/170 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-06-10 16:43:33 +05:30
valueFrom:
secretKeyRef:
key: bindPassword
Add multiple LDAP sources (#222) Add multiple add sources. Instead of a single entry for ldap configuration we now would have a dictionary for ldap config. This would be a breaking change for those working with the ldap config. fixes: #190 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/222 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-10-08 17:46:24 +05:30
name: {{ $value.existingSecret }}
Allow existing secrets for passwords (#170) Allow admin user and password to be configured via existing secrets Allow LDAP bindDn and bindPassword to be configured via existing secrets Update Readme Fixes: #169 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/170 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-06-10 16:43:33 +05:30
{{- else }}
Add multiple LDAP sources (#222) Add multiple add sources. Instead of a single entry for ldap configuration we now would have a dictionary for ldap config. This would be a breaking change for those working with the ldap config. fixes: #190 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/222 Reviewed-by: Andrew Thornton <art27@cantab.net> Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-10-08 17:46:24 +05:30
- name: GITEA_LDAP_BIND_DN_{{ $idx }}
value: {{ $value.bindDn | quote }}
- name: GITEA_LDAP_PASSWORD_{{ $idx }}
value: {{ $value.bindPassword | quote }}
{{- end }}
Drop kebab-case configuration notation (#196) Currently there are two different styles for defining both ldap and oauth configuration in _values.yaml_ file: `camelCase` and `kebab-case`. Supporting both styles created multiple regressions in the past. ⚠️ BREAKING ⚠️ --------------- These changes completely remove any support for `kebab-case` notation in _values.yaml_ in favor of `camelCase`. Configuration keys must use `camelCase`. Only exception are Kubernetes resource keys for annotations or labels. Fixes: #188 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/196 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-07-06 10:58:13 +05:30
{{- end }}
Allow existing secrets for passwords (#170) Allow admin user and password to be configured via existing secrets Allow LDAP bindDn and bindPassword to be configured via existing secrets Update Readme Fixes: #169 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/170 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-06-10 16:43:33 +05:30
{{- end }}
Rework OAuth sources (#244) This change request includes two different things to improve OAuth source handling: - Allow multiple OAuth source configuration (Fixes: #191) - Support reading sensitive OAuth configuration data from Kubernetes secrets (Closes: #242) ⚠️ BREAKING ⚠️ --- Users need to migrate their `gitea.oauth` configuration. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/244 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-12-20 20:13:55 +05:30
{{- if .Values.gitea.oauth }}
{{- range $idx, $value := .Values.gitea.oauth }}
{{- if $value.existingSecret }}
- name: GITEA_OAUTH_KEY_{{ $idx }}
valueFrom:
secretKeyRef:
key: key
name: {{ $value.existingSecret }}
- name: GITEA_OAUTH_SECRET_{{ $idx }}
valueFrom:
secretKeyRef:
key: secret
name: {{ $value.existingSecret }}
{{- end }}
{{- end }}
{{- end }}
Allow existing secrets for passwords (#170) Allow admin user and password to be configured via existing secrets Allow LDAP bindDn and bindPassword to be configured via existing secrets Update Readme Fixes: #169 Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/170 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-06-10 16:43:33 +05:30
{{- if .Values.gitea.admin.existingSecret }}
- name: GITEA_ADMIN_USERNAME
valueFrom:
secretKeyRef:
key: username
name: {{ .Values.gitea.admin.existingSecret }}
- name: GITEA_ADMIN_PASSWORD
valueFrom:
secretKeyRef:
key: password
name: {{ .Values.gitea.admin.existingSecret }}
{{- else }}
- name: GITEA_ADMIN_USERNAME
value: {{ .Values.gitea.admin.username | quote }}
- name: GITEA_ADMIN_PASSWORD
value: {{ .Values.gitea.admin.password | quote }}
{{- end }}
[Breaking] Add HA-support; switch to `Deployment` (#437) # Changes A big shoutout to @luhahn for all his work in #205 which served as the base for this PR. ## Documentation - [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long). Most of the information below should go into it with more details and explanations behind all of the individual components. ## Chart deps ~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~ ~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~ - Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2. - Removes `memcached` instead of `redis-cluster` - Add `postgresql-ha` as default DB dep in favor of `postgres` ## Adds smart HA chart logic The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1. - If `replicaCount` > 1, - `gitea.config.session.PROVIDER` is automatically set to `redis-cluster` - `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch` - `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc. ## Deployment vs Statefulset Given all the discussions about this lately (#428), I think we could use both. In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets. On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment. Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption. Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case. This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet. The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way? ## Chart PVC Creation I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation. In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial. A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse... - New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim` - New `persistence.create`: whether to create a new PVC ## Testing As this PR does a lot of things, we need proper testing. The helm chart can be installed from the Git branch via `helm-git` as follows: ``` helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment helm install gitea --version 0.0.0 ``` It is **highly recommended** to test the chart in a dedicated namespace. I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine. I just did some basic operations though and we should do more niche testing before merging. Examplary `values.yml` for testing (only needs a valid RWX storage class): <details> <summary>values.yaml</summary> ```yml image: tag: "dev" PullPolicy: "Always" rootless: true replicaCount: 2 persistence: enabled: true accessModes: - ReadWriteMany storageClass: FIXME redis-cluster: enabled: false global: redis: password: gitea gitea: config: indexer: ISSUE_INDEXER_ENABLED: true REPO_INDEXER_ENABLED: false ``` </details> ## Preferred setup The preferred HA setup with respect to performance and stability might currently be as follows: - Repos: RWX (e.g. EFS or Azurefiles NFS) - Issue indexer: Meilisearch (HA) - Session and cache: Redis Cluster (HA) - Attachments/Avatars: Minio (HA) This will result in a ~ 10-pod HA setup overall. All pods have very low resource requests. fix #98 Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437 Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-18 00:39:42 +05:30
{{- if .Values.deployment.env }}
{{- toYaml .Values.deployment.env | nindent 12 }}
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
{{- end }}
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 23:26:55 +05:30
volumeMounts:
Move all password related data to secrets (#28) Bump Chart version Move all password related data to secrets Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/28 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-25 19:07:55 +05:30
- name: init
mountPath: /usr/sbin
Fix regression for creating repositories in root-based containers (#172) Due to #160 it was no longer possible to create repositories in root-based containers. This was caused by the missing `/tmp/gitea` directory in that image. It was dynamically created by Gitea internal functionality with less privileges than necessary. Explicitly creating the directory and set proper permissions fix this. Fixes: #171 Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/172 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-09 20:05:50 +05:30
- name: temp
mountPath: /tmp
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 23:26:55 +05:30
- name: data
mountPath: /data
add support for persistence.subPath option (#263) Hello, PR adds a `persistence.subPath` option to provide user more flexibility on mounting the `data` PV. https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath The setting is similar to e.g. `primary.persistence.subPath` in MariaDB helm chart: https://github.com/bitnami/charts/tree/master/bitnami/mariadb Co-authored-by: Aleksey Sergey <sergey.aleksey90@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/263 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io> Co-committed-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io>
2021-12-20 17:28:44 +05:30
{{- if .Values.persistence.subPath }}
subPath: {{ .Values.persistence.subPath }}
{{- end }}
Split "extraVolumeMounts" into init and container mounts (#337) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/337 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-08-08 01:02:19 +05:30
{{- include "gitea.init-additional-mounts" . | nindent 12 }}
Add resource specs to init container (#423) Supersedes stalled #362 I opted for defining `requests` while leaving `limits` open. This might help for scheduling without restricting performance during init. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/423 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-04-01 17:05:11 +05:30
resources:
{{- toYaml .Values.initContainers.resources | nindent 12 }}
[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-18 00:39:42 +05:30
terminationGracePeriodSeconds: {{ .Values.deployment.terminationGracePeriodSeconds }}
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 23:26:55 +05:30
containers:
- name: {{ .Chart.Name }}
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
image: "{{ include "gitea.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 23:26:55 +05:30
imagePullPolicy: {{ .Values.image.pullPolicy }}
env:
# SSH Port values have to be set here as well for openssh configuration
- name: SSH_LISTEN_PORT
value: {{ .Values.gitea.config.server.SSH_LISTEN_PORT | quote }}
- name: SSH_PORT
value: {{ .Values.gitea.config.server.SSH_PORT | quote }}
Support for SSH log level (#358) Re https://gitea.com/gitea/helm-chart/issues/224#issuecomment-717087 Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/358 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: strk <strk@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: pi3ch <pi3ch@noreply.gitea.io> Co-committed-by: pi3ch <pi3ch@noreply.gitea.io>
2023-03-22 13:43:31 +05:30
{{- if not .Values.image.rootless }}
- name: SSH_LOG_LEVEL
value: {{ .Values.gitea.ssh.logLevel | quote }}
{{- end }}
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
- name: GITEA_APP_INI
value: /data/gitea/conf/app.ini
- name: GITEA_CUSTOM
value: /data/gitea
- name: GITEA_WORK_DIR
value: /data
- name: GITEA_TEMP
value: /tmp/gitea
Fix rootless image usage with enhanced security-context (#160) I've noticed that the commented `securityContext` is not really useable with the rootless image due to different directory structure compared to the default image. Important for the `readOnlyRootFilesystem` is to declare the `TMPDIR` environment variable, so that the tmp directory (which is readonly in this case) won't be used. Instead, another writeable directory can be used. Another thing is the explicit hint that all these security options cannot be used with the default (root-based) image, because of its design. ~~Although this PR would fix the referenced issue, I am not totally happy with the current implementation. It would be more straight forward to use the same mount points for both image variants. Unfortunately, this is not possible right now due to hard coded paths in the default (root) image startup scripts.~~ ~~Anyone have suggestions on how this could be more simple?~~ ------- **Sum-up:** As mentioned in Discord, this PR tried to make too many changes. The necessary changes made in 1f331a7e6577fc798196a84a957330aca0d663cd will fix an error that occurs due to restricted access to the `/tmp` directory in a rootless image with all the `securityContext` options enabled. I also updated the default image to 1.14.2. Fixes: #158 Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/160 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-07 18:57:25 +05:30
- name: TMPDIR
value: /tmp/gitea
Set `$HOME` to `/data/gitea/git` for rootless image (#447) fix #396 Set the default of `$HOME` to `/data/gitea/git` for rootless images to make chart openshift compliant. Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/447 Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-05-24 02:31:22 +05:30
{{- if .Values.image.rootless }}
- name: HOME
value: /data/gitea/git
{{- end }}
Customizable .gnupg folder location (#186) The `HOME` path is not persistent when using the rootless image, so the `.gnupg` folder isn't either. Since the chart always used `/data/...` as mount point for storage of all kinds, it is a minimal impact to just relocate the dynamic `$HOME/.gnupg` folder location to the persistent `/data/git/.gnupg`. This is where the signing keys are stored when running root based environments. Doing so will - allow migrations between both image variants - persist signing keys for rootless environments Fixes: #155 Co-authored-by: techknowlogick <techknowlogick@gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/186 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-30 00:53:32 +05:30
{{- if .Values.signing.enabled }}
- name: GNUPGHOME
value: {{ .Values.signing.gpgHome }}
{{- end }}
[Breaking] Add HA-support; switch to `Deployment` (#437) # Changes A big shoutout to @luhahn for all his work in #205 which served as the base for this PR. ## Documentation - [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long). Most of the information below should go into it with more details and explanations behind all of the individual components. ## Chart deps ~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~ ~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~ - Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2. - Removes `memcached` instead of `redis-cluster` - Add `postgresql-ha` as default DB dep in favor of `postgres` ## Adds smart HA chart logic The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1. - If `replicaCount` > 1, - `gitea.config.session.PROVIDER` is automatically set to `redis-cluster` - `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch` - `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc. ## Deployment vs Statefulset Given all the discussions about this lately (#428), I think we could use both. In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets. On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment. Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption. Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case. This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet. The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way? ## Chart PVC Creation I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation. In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial. A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse... - New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim` - New `persistence.create`: whether to create a new PVC ## Testing As this PR does a lot of things, we need proper testing. The helm chart can be installed from the Git branch via `helm-git` as follows: ``` helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment helm install gitea --version 0.0.0 ``` It is **highly recommended** to test the chart in a dedicated namespace. I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine. I just did some basic operations though and we should do more niche testing before merging. Examplary `values.yml` for testing (only needs a valid RWX storage class): <details> <summary>values.yaml</summary> ```yml image: tag: "dev" PullPolicy: "Always" rootless: true replicaCount: 2 persistence: enabled: true accessModes: - ReadWriteMany storageClass: FIXME redis-cluster: enabled: false global: redis: password: gitea gitea: config: indexer: ISSUE_INDEXER_ENABLED: true REPO_INDEXER_ENABLED: false ``` </details> ## Preferred setup The preferred HA setup with respect to performance and stability might currently be as follows: - Repos: RWX (e.g. EFS or Azurefiles NFS) - Issue indexer: Meilisearch (HA) - Session and cache: Redis Cluster (HA) - Attachments/Avatars: Minio (HA) This will result in a ~ 10-pod HA setup overall. All pods have very low resource requests. fix #98 Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437 Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-18 00:39:42 +05:30
{{- if .Values.deployment.env }}
{{- toYaml .Values.deployment.env | nindent 12 }}
allow for additional container environment variables (#16) Co-authored-by: Jasper Orschulko <Jasper.Orschulko@irisgmbh.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/16 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-10 15:45:34 +05:30
{{- end }}
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 23:26:55 +05:30
ports:
- name: ssh
containerPort: {{ .Values.gitea.config.server.SSH_LISTEN_PORT }}
added hostPort support for ssh (#276) This fixes my feature request (#275) to support hostPort to expose the ssh port. Co-authored-by: alex <alex@zengers.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/276 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: a-zen <a-zen@noreply.gitea.io> Co-committed-by: a-zen <a-zen@noreply.gitea.io>
2022-02-25 14:48:57 +05:30
{{- if .Values.service.ssh.hostPort }}
hostPort: {{ .Values.service.ssh.hostPort }}
{{- end }}
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 23:26:55 +05:30
- name: http
containerPort: {{ .Values.gitea.config.server.HTTP_PORT }}
Fix typo enabling pprof (#114) Nothing critical, but had a typo in the naming of the config entry to enable `pprof`. Co-authored-by: josef <josef.nilsen@outlook.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/114 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com> Co-authored-by: JosefWN <josefwn@noreply.gitea.io> Co-committed-by: JosefWN <josefwn@noreply.gitea.io>
2021-02-17 15:14:40 +05:30
{{- if .Values.gitea.config.server.ENABLE_PPROF }}
Add support for metrics and pprof (#100) Adds support for toggling support for `pprof` and metrics: ```yaml gitea: pprofEnabled: true metrics: enabled: true serviceMonitor: enabled: true ``` Co-authored-by: josef <josef.nilsen@outlook.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/100 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: techknowlogick <techknowlogick@gitea.io> Co-authored-by: JosefWN <josefwn@noreply.gitea.io> Co-committed-by: JosefWN <josefwn@noreply.gitea.io>
2021-01-21 21:15:26 +05:30
- name: profiler
containerPort: 6060
{{- end }}
generate readme Parameters from values.yaml (#323) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:51:25 +05:30
{{- if .Values.gitea.livenessProbe.enabled }}
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 23:26:55 +05:30
livenessProbe:
generate readme Parameters from values.yaml (#323) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:51:25 +05:30
{{- toYaml (omit .Values.gitea.livenessProbe "enabled") | nindent 12 }}
Allow override kubernetes probes (#117) - Allow overriding liveness and readiness probe - Add optional startup probe closes #118 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/117 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
2021-03-01 20:16:05 +05:30
{{- end }}
generate readme Parameters from values.yaml (#323) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:51:25 +05:30
{{- if .Values.gitea.readinessProbe.enabled }}
Allow override kubernetes probes (#117) - Allow overriding liveness and readiness probe - Add optional startup probe closes #118 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/117 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
2021-03-01 20:16:05 +05:30
readinessProbe:
generate readme Parameters from values.yaml (#323) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:51:25 +05:30
{{- toYaml (omit .Values.gitea.readinessProbe "enabled") | nindent 12 }}
Allow override kubernetes probes (#117) - Allow overriding liveness and readiness probe - Add optional startup probe closes #118 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/117 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
2021-03-01 20:16:05 +05:30
{{- end }}
generate readme Parameters from values.yaml (#323) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:51:25 +05:30
{{- if .Values.gitea.startupProbe.enabled }}
Allow override kubernetes probes (#117) - Allow overriding liveness and readiness probe - Add optional startup probe closes #118 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/117 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
2021-03-01 20:16:05 +05:30
startupProbe:
generate readme Parameters from values.yaml (#323) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/323 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: cnfatal <cnfatal@noreply.gitea.io> Co-committed-by: cnfatal <cnfatal@noreply.gitea.io>
2022-06-09 16:51:25 +05:30
{{- toYaml (omit .Values.gitea.startupProbe "enabled") | nindent 12 }}
Allow override kubernetes probes (#117) - Allow overriding liveness and readiness probe - Add optional startup probe closes #118 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/117 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: Michael Kriese <michael.kriese@visualon.de> Co-committed-by: Michael Kriese <michael.kriese@visualon.de>
2021-03-01 20:16:05 +05:30
{{- end }}
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 23:26:55 +05:30
resources:
{{- toYaml .Values.resources | nindent 12 }}
Add support to run gitea with an optional securityContext (#115) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/115 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: martencassel <martencassel@noreply.gitea.io> Co-committed-by: martencassel <martencassel@noreply.gitea.io>
2021-03-01 17:46:49 +05:30
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 16:40:48 +05:30
{{- /* Honor the deprecated securityContext variable when defined */ -}}
{{- if .Values.containerSecurityContext -}}
{{ toYaml .Values.containerSecurityContext | nindent 12 -}}
{{- else -}}
{{ toYaml .Values.securityContext | nindent 12 -}}
{{- end }}
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 23:26:55 +05:30
volumeMounts:
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
- name: temp
Fix rootless image usage with enhanced security-context (#160) I've noticed that the commented `securityContext` is not really useable with the rootless image due to different directory structure compared to the default image. Important for the `readOnlyRootFilesystem` is to declare the `TMPDIR` environment variable, so that the tmp directory (which is readonly in this case) won't be used. Instead, another writeable directory can be used. Another thing is the explicit hint that all these security options cannot be used with the default (root-based) image, because of its design. ~~Although this PR would fix the referenced issue, I am not totally happy with the current implementation. It would be more straight forward to use the same mount points for both image variants. Unfortunately, this is not possible right now due to hard coded paths in the default (root) image startup scripts.~~ ~~Anyone have suggestions on how this could be more simple?~~ ------- **Sum-up:** As mentioned in Discord, this PR tried to make too many changes. The necessary changes made in 1f331a7e6577fc798196a84a957330aca0d663cd will fix an error that occurs due to restricted access to the `/tmp` directory in a rootless image with all the `securityContext` options enabled. I also updated the default image to 1.14.2. Fixes: #158 Co-authored-by: JustusBunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/160 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: 6543 <6543@obermui.de> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-06-07 18:57:25 +05:30
mountPath: /tmp
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 23:26:55 +05:30
- name: data
mountPath: /data
add support for persistence.subPath option (#263) Hello, PR adds a `persistence.subPath` option to provide user more flexibility on mounting the `data` PV. https://kubernetes.io/docs/concepts/storage/volumes/#using-subpath The setting is similar to e.g. `primary.persistence.subPath` in MariaDB helm chart: https://github.com/bitnami/charts/tree/master/bitnami/mariadb Co-authored-by: Aleksey Sergey <sergey.aleksey90@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/263 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io> Co-committed-by: aleksey.sergey <aleksey.sergey@noreply.gitea.io>
2021-12-20 17:28:44 +05:30
{{- if .Values.persistence.subPath }}
subPath: {{ .Values.persistence.subPath }}
{{- end }}
Split "extraVolumeMounts" into init and container mounts (#337) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/337 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-08-08 01:02:19 +05:30
{{- include "gitea.container-additional-mounts" . | nindent 12 }}
Add support for hostAliases (#401) ### Description of the change It is required to add custom mapping between hostnames and IP addresses for the gitea pods to be able to access external services like oauth providers or webhook servers. It is common to take global variables for the entires and set them using hostAliases in the pod template. ### Benefits Give us more flexibility when using gitea in various network environments. ### Applicable issues - fixes #400 ### Checklist - [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: Taekyun Kim <tkq.kim@samsung.com> Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/401 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-authored-by: podain77 <podain77@noreply.gitea.io> Co-committed-by: podain77 <podain77@noreply.gitea.io>
2023-02-21 23:23:25 +05:30
{{- with .Values.global.hostAliases }}
hostAliases:
{{- toYaml . | nindent 8 }}
{{- end }}
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 23:26:55 +05:30
{{- with .Values.nodeSelector }}
nodeSelector:
{{- toYaml . | nindent 8 }}
{{- end }}
{{- with .Values.affinity }}
affinity:
{{- toYaml . | nindent 8 }}
{{- end }}
[Breaking] Add HA-support; switch to `Deployment` (#437) # Changes A big shoutout to @luhahn for all his work in #205 which served as the base for this PR. ## Documentation - [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long). Most of the information below should go into it with more details and explanations behind all of the individual components. ## Chart deps ~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~ ~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~ - Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2. - Removes `memcached` instead of `redis-cluster` - Add `postgresql-ha` as default DB dep in favor of `postgres` ## Adds smart HA chart logic The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1. - If `replicaCount` > 1, - `gitea.config.session.PROVIDER` is automatically set to `redis-cluster` - `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch` - `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc. ## Deployment vs Statefulset Given all the discussions about this lately (#428), I think we could use both. In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets. On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment. Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption. Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case. This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet. The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way? ## Chart PVC Creation I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation. In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial. A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse... - New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim` - New `persistence.create`: whether to create a new PVC ## Testing As this PR does a lot of things, we need proper testing. The helm chart can be installed from the Git branch via `helm-git` as follows: ``` helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment helm install gitea --version 0.0.0 ``` It is **highly recommended** to test the chart in a dedicated namespace. I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine. I just did some basic operations though and we should do more niche testing before merging. Examplary `values.yml` for testing (only needs a valid RWX storage class): <details> <summary>values.yaml</summary> ```yml image: tag: "dev" PullPolicy: "Always" rootless: true replicaCount: 2 persistence: enabled: true accessModes: - ReadWriteMany storageClass: FIXME redis-cluster: enabled: false global: redis: password: gitea gitea: config: indexer: ISSUE_INDEXER_ENABLED: true REPO_INDEXER_ENABLED: false ``` </details> ## Preferred setup The preferred HA setup with respect to performance and stability might currently be as follows: - Repos: RWX (e.g. EFS or Azurefiles NFS) - Issue indexer: Meilisearch (HA) - Session and cache: Redis Cluster (HA) - Attachments/Avatars: Minio (HA) This will result in a ~ 10-pod HA setup overall. All pods have very low resource requests. fix #98 Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437 Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-18 00:39:42 +05:30
{{- with .Values.topologySpreadConstraints }}
topologySpreadConstraints:
{{- toYaml . | nindent 8 }}
{{- end }}
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 23:26:55 +05:30
{{- with .Values.tolerations }}
tolerations:
{{- toYaml . | nindent 8 }}
add dnsConfig value support (#329) Description of the change Add support for a new value: dnsConfig, to be passed to the statefulset pod template configuration. Default is {}, and does not change anything from current default pod configuration. Benefits Ability to fix some issues encountered with Alpine-based docker images, which may break DNS resolving on some clusters. In particular, this allows to lower the ndots value, which fixes DNS resolving of FQDNs. dnsConfig: options: - name: ndots value: "1" Also, with this setting, one can set other parameters to finely tune DNS configuration for Gitea pods, if needed: https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-dns-config Possible drawbacks None. Additional information Some relevant links about the issue this setting allows to fix: https://stackoverflow.com/questions/65181012/does-alpine-have-known-dns-issue-within-kubernetes https://gitlab.alpinelinux.org/alpine/aports/-/issues/9017 Checklist Parameters are documented in the values.yaml and added to the README.md using readme-generator-for-helm Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/329 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: luhahn <luhahn@noreply.gitea.io> Co-authored-by: dek <dek@noreply.gitea.io> Co-committed-by: dek <dek@noreply.gitea.io>
2022-06-27 12:05:55 +05:30
{{- end }}
{{- if .Values.dnsConfig }}
dnsConfig:
{{- toYaml .Values.dnsConfig | nindent 8 }}
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 23:26:55 +05:30
{{- end }}
volumes:
Move all password related data to secrets (#28) Bump Chart version Move all password related data to secrets Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/28 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-25 19:07:55 +05:30
- name: init
secret:
secretName: {{ include "gitea.fullname" . }}-init
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
defaultMode: 110
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 23:26:55 +05:30
- name: config
Move all password related data to secrets (#28) Bump Chart version Move all password related data to secrets Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/28 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Lunny Xiao <xiaolunwen@gmail.com>
2020-09-25 19:07:55 +05:30
secret:
secretName: {{ include "gitea.fullname" . }}
Rework app.ini generation (#239) App ini is now generated by environment-to-ini This should prevent some of the problems we had earlier with persisting the app.ini Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/239 Reviewed-by: justusbunsi <justusbunsi@noreply.gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-11-20 02:45:45 +05:30
defaultMode: 110
Split "extraVolumeMounts" into init and container mounts (#337) Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/337 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: lafriks <lafriks@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2022-08-08 01:02:19 +05:30
{{- if gt (len .Values.extraVolumes) 0 }}
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 16:58:39 +05:30
{{- toYaml .Values.extraVolumes | nindent 8 }}
{{- end }}
Generic way for configuring Gitea app.ini (#240) With the result of PR #239 it is much easier to provide additional values to the _app.ini_ configuration from different sources. These changes adds an _additionalConfigSources_ field where the users can define such sources. This enables the users to choose on their own whether to store values in _values.yaml_ or load them from Kuberetes Secrets or ConfigMaps. - Fixes #243 - Fixes #174 - Fixes #260 Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/240 Reviewed-by: luhahn <luhahn@noreply.gitea.io> Reviewed-by: wxiaoguang <wxiaoguang@noreply.gitea.io> Co-authored-by: justusbunsi <justusbunsi@noreply.gitea.io> Co-committed-by: justusbunsi <justusbunsi@noreply.gitea.io>
2021-12-22 16:14:04 +05:30
- name: inline-config-sources
secret:
secretName: {{ include "gitea.fullname" . }}-inline-config
{{- range $idx, $value := .Values.gitea.additionalConfigSources }}
- name: additional-config-sources-{{ $idx }}
{{- toYaml $value | nindent 10 }}
{{- end }}
gitea-1.14.x-updates (#148) This PR includes the changes from: - https://gitea.com/gitea/helm-chart/pulls/129 - https://gitea.com/gitea/helm-chart/pulls/140 In addition it adds the possibility to include secrets via environment variables as mentioned in #60 Co-authored-by: Hans Kristian Flaatten <hans.flaatten@evry.com> Co-authored-by: flavio.prado <flavio.prado@noreply.gitea.io> Co-authored-by: Lucas Hahn <lucas.hahn@novum-rgi.de> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/148 Reviewed-by: techknowlogick <techknowlogick@gitea.io> Reviewed-by: Andrew Thornton <art27@cantab.net> Co-authored-by: luhahn <luhahn@noreply.gitea.io> Co-committed-by: luhahn <luhahn@noreply.gitea.io>
2021-04-29 14:42:48 +05:30
- name: temp
emptyDir: {}
Re-add GPG configuration feature (#374) This reverts d5ce1a47eaad935ea709b7a03bfdf6c69bac8f32 and therefore adds the GPG feature back into main. As it is a breaking change, this PR now also contains the required upgrade notes. Closes #107 again. Co-authored-by: justusbunsi <sk.bunsenbrenner@gmail.com> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/374 Reviewed-by: pat-s <pat-s@noreply.gitea.io> Reviewed-by: John Olheiser <john+gitea@jolheiser.com>
2023-01-17 22:28:10 +05:30
{{- if .Values.signing.enabled }}
- name: gpg-private-key
secret:
secretName: {{ include "gitea.gpg-key-secret-name" . }}
items:
- key: privateKey
path: private.asc
defaultMode: 0100
{{- end }}
[Breaking] Add HA-support; switch to `Deployment` (#437) # Changes A big shoutout to @luhahn for all his work in #205 which served as the base for this PR. ## Documentation - [x] After thinking for some time about it, I still prefer the distinct option (as started in #350), i.e. having a standalone "HA" doc under `docs/ha-setup.md` to not have a very long README (which is already quite long). Most of the information below should go into it with more details and explanations behind all of the individual components. ## Chart deps ~~- Adds `meilisearch` as a chart dependency for a HA-ready issue indexer. Only works with >= Gitea 1.20~~ ~~- Adds `redis` as a chart dependency for a HA-ready session and queue store.~~ - Adds `redis-cluster` as a chart dependency for a HA-ready session and queue store (alternative to `redis`). Only works with >= Gitea 1.19.2. - Removes `memcached` instead of `redis-cluster` - Add `postgresql-ha` as default DB dep in favor of `postgres` ## Adds smart HA chart logic The goal is to set smart config values that result in a HA-ready Gitea deployment if `replicaCount` > 1. - If `replicaCount` > 1, - `gitea.config.session.PROVIDER` is automatically set to `redis-cluster` - `gitea.config.indexer.REPO_INDEXER_ENABLED` is automatically set to `false` unless the value is `elasticsearch` or `meilisearch` - `redis-cluster` is used for `[queue]` and `[cache]` and `[session]`mode or not Configuration of external instances of `meilisearch` and `minio` are documented in a new markdown doc. ## Deployment vs Statefulset Given all the discussions about this lately (#428), I think we could use both. In the end, we do not have the requirement for a sequential pod scale up/scale down as it would happen in statefulsets. On the other side, we do not have actual stateless pods as we are attaching a RWX to the deployment. Yet I think because we do not have a leader-election requirement, spawning the pods as a deployment makes "Rolling Updates" easier and also signals users that there is no "leader election" logic and each pod can just be "destroyed" at anytime without causing interruption. Hence I think we should be able to switch from a statefulset to a deployment, even in the single-replica case. This change also brought up a templating/linting issue: the definition of `.Values.gitea.config.server.SSH_LISTEN_PORT` in `ssh-svc.yaml` just "luckily" worked so far due to naming-related lint processing. Due to the change from "statefulset" to "deployment", the processing queue changed and caused a failure complaining about `config.server.SSH_LISTEN_PORT` not being defined yet. The only way I could see to fix this was to "properly" define the value in `values.yaml` instead of conditionally definining it in `helpers.tpl`. Maybe there's a better way? ## Chart PVC Creation I've adapted the automated PVC creation from another chart to be able to provide the `storageClassName` as I couldn't get dynamic provisioning for EFS going with the current implementation. In addition the naming and approach within the Gitea chart for PV creation is a bit unusual and aligning it might be beneficial. A semi-unrelated change which will result in a breaking change for existing users but this PR includes a lot of breaking changes already, so including another one might not make it much worse... - New `persistence.mount`: whether to mount an existing PVC (via `persistence.existingClaim` - New `persistence.create`: whether to create a new PVC ## Testing As this PR does a lot of things, we need proper testing. The helm chart can be installed from the Git branch via `helm-git` as follows: ``` helm repo add gitea-charts git+https://gitea.com/gitea/helm-chart@/?ref=deployment helm install gitea --version 0.0.0 ``` It is **highly recommended** to test the chart in a dedicated namespace. I've tested this myself with both `redis` and `redis-cluster` and it seemed to work fine. I just did some basic operations though and we should do more niche testing before merging. Examplary `values.yml` for testing (only needs a valid RWX storage class): <details> <summary>values.yaml</summary> ```yml image: tag: "dev" PullPolicy: "Always" rootless: true replicaCount: 2 persistence: enabled: true accessModes: - ReadWriteMany storageClass: FIXME redis-cluster: enabled: false global: redis: password: gitea gitea: config: indexer: ISSUE_INDEXER_ENABLED: true REPO_INDEXER_ENABLED: false ``` </details> ## Preferred setup The preferred HA setup with respect to performance and stability might currently be as follows: - Repos: RWX (e.g. EFS or Azurefiles NFS) - Issue indexer: Meilisearch (HA) - Session and cache: Redis Cluster (HA) - Attachments/Avatars: Minio (HA) This will result in a ~ 10-pod HA setup overall. All pods have very low resource requests. fix #98 Co-authored-by: pat-s <pat-s@noreply.gitea.io> Reviewed-on: https://gitea.com/gitea/helm-chart/pulls/437 Co-authored-by: pat-s <patrick.schratz@gmail.com> Co-committed-by: pat-s <patrick.schratz@gmail.com>
2023-07-18 00:39:42 +05:30
{{- if .Values.persistence.enabled }}
{{- if .Values.persistence.mount }}
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 23:26:55 +05:30
- name: data
persistentVolumeClaim:
[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-18 00:39:42 +05:30
claimName: {{ .Values.persistence.claimName }}
{{- end }}
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 23:26:55 +05:30
{{- else if not .Values.persistence.enabled }}
- name: data
emptyDir: {}
{{- end }}