mirror of
https://github.com/bitnami/charts.git
synced 2026-03-15 06:47:24 +08:00
[bitnami/*] Reorder Chart sections (#24455)
* [bitnami/*] Reorder Chart sections Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> --------- Signed-off-by: Jota Martos <jotamartos@vmware.com>
This commit is contained in:
Juan José Martos
@@ -44,15 +44,83 @@ The command deploys Gitea on the Kubernetes cluster in the default configuration
|
||||
|
||||
> **Tip**: List all releases using `helm list`
|
||||
|
||||
## Uninstalling the Chart
|
||||
## Configuration and installation details
|
||||
|
||||
To uninstall/delete the `my-release` deployment:
|
||||
### Resource requests and limits
|
||||
|
||||
Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the `resources` value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.
|
||||
|
||||
To make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcePreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers)
|
||||
|
||||
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Image
|
||||
|
||||
The `image` parameter allows specifying which image will be pulled for the chart.
|
||||
|
||||
#### Private registry
|
||||
|
||||
If you configure the `image` value to one in a private registry, you will need to [specify an image pull secret](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
|
||||
1. Manually create image pull secret(s) in the namespace. See [this YAML example reference](https://kubernetes.io/docs/concepts/containers/images/#creating-a-secret-with-a-docker-config). Consult your image registry's documentation about getting the appropriate secret.
|
||||
2. Note that the `imagePullSecrets` configuration value cannot currently be passed to helm using the `--set` parameter, so you must supply these using a `values.yaml` file, such as:
|
||||
|
||||
```yaml
|
||||
imagePullSecrets:
|
||||
- name: SECRET_NAME
|
||||
```
|
||||
|
||||
3. Install the chart
|
||||
|
||||
### Setting Pod's affinity
|
||||
|
||||
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod's affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters.
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami Gitea](https://github.com/bitnami/containers/tree/main/bitnami/gitea) image stores the Gitea data and configurations at the `/bitnami/gitea` path of the container.
|
||||
|
||||
Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
|
||||
See the [Parameters](#parameters) section to configure the PVC or to disable persistence.
|
||||
|
||||
### Existing PersistentVolumeClaim
|
||||
|
||||
1. Create the PersistentVolume
|
||||
2. Create the PersistentVolumeClaim
|
||||
3. Install the chart
|
||||
|
||||
```console
|
||||
helm delete my-release
|
||||
helm install my-release --set persistence.existingClaim=PVC_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/gitea
|
||||
```
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.
|
||||
|
||||
### Host path
|
||||
|
||||
#### System compatibility
|
||||
|
||||
- The local filesystem accessibility to a container in a pod with `hostPath` has been tested on OSX/MacOS with xhyve, and Linux with VirtualBox.
|
||||
- Windows has not been tested with the supported VM drivers. Minikube does however officially support [Mounting Host Folders](https://minikube.sigs.k8s.io/docs/handbook/mount/) per pod. Or you may manually sync your container whenever host files are changed with tools like [docker-sync](https://github.com/EugenMayer/docker-sync) or [docker-bg-sync](https://github.com/cweagans/docker-bg-sync).
|
||||
|
||||
#### Mounting steps
|
||||
|
||||
1. The specified `hostPath` directory must already exist (create one if it does not).
|
||||
2. Install the chart
|
||||
|
||||
```console
|
||||
helm install my-release --set persistence.hostPath=/PATH/TO/HOST/MOUNT oci://REGISTRY_NAME/REPOSITORY_NAME/gitea
|
||||
```
|
||||
|
||||
> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.
|
||||
|
||||
This will mount the `gitea-data` volume into the `hostPath` directory. The site data will be persisted if the mount path contains valid data, else the site data will be initialized at first launch.
|
||||
3. Because the container cannot control the host machine's directory permissions, you must set the Gitea file directory permissions yourself
|
||||
|
||||
## Parameters
|
||||
|
||||
@@ -273,84 +341,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/gitea
|
||||
> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.
|
||||
> **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/gitea/values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### Resource requests and limits
|
||||
|
||||
Bitnami charts allow setting resource requests and limits for all containers inside the chart deployment. These are inside the `resources` value (check parameter table). Setting requests is essential for production workloads and these should be adapted to your specific use case.
|
||||
|
||||
To make this process easier, the chart contains the `resourcesPreset` values, which automatically sets the `resources` section according to different presets. Check these presets in [the bitnami/common chart](https://github.com/bitnami/charts/blob/main/bitnami/common/templates/_resources.tpl#L15). However, in production workloads using `resourcePreset` is discouraged as it may not fully adapt to your specific needs. Find more information on container resource management in the [official Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/manage-resources-containers/).
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers)
|
||||
|
||||
It is strongly recommended to use immutable tags in a production environment. This ensures your deployment does not change automatically if the same tag is updated with a different image.
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Image
|
||||
|
||||
The `image` parameter allows specifying which image will be pulled for the chart.
|
||||
|
||||
#### Private registry
|
||||
|
||||
If you configure the `image` value to one in a private registry, you will need to [specify an image pull secret](https://kubernetes.io/docs/concepts/containers/images/#specifying-imagepullsecrets-on-a-pod).
|
||||
|
||||
1. Manually create image pull secret(s) in the namespace. See [this YAML example reference](https://kubernetes.io/docs/concepts/containers/images/#creating-a-secret-with-a-docker-config). Consult your image registry's documentation about getting the appropriate secret.
|
||||
2. Note that the `imagePullSecrets` configuration value cannot currently be passed to helm using the `--set` parameter, so you must supply these using a `values.yaml` file, such as:
|
||||
|
||||
```yaml
|
||||
imagePullSecrets:
|
||||
- name: SECRET_NAME
|
||||
```
|
||||
|
||||
3. Install the chart
|
||||
|
||||
### Setting Pod's affinity
|
||||
|
||||
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod's affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters.
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami Gitea](https://github.com/bitnami/containers/tree/main/bitnami/gitea) image stores the Gitea data and configurations at the `/bitnami/gitea` path of the container.
|
||||
|
||||
Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
|
||||
See the [Parameters](#parameters) section to configure the PVC or to disable persistence.
|
||||
|
||||
### Existing PersistentVolumeClaim
|
||||
|
||||
1. Create the PersistentVolume
|
||||
2. Create the PersistentVolumeClaim
|
||||
3. Install the chart
|
||||
|
||||
```console
|
||||
helm install my-release --set persistence.existingClaim=PVC_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/gitea
|
||||
```
|
||||
|
||||
> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.
|
||||
|
||||
### Host path
|
||||
|
||||
#### System compatibility
|
||||
|
||||
- The local filesystem accessibility to a container in a pod with `hostPath` has been tested on OSX/MacOS with xhyve, and Linux with VirtualBox.
|
||||
- Windows has not been tested with the supported VM drivers. Minikube does however officially support [Mounting Host Folders](https://minikube.sigs.k8s.io/docs/handbook/mount/) per pod. Or you may manually sync your container whenever host files are changed with tools like [docker-sync](https://github.com/EugenMayer/docker-sync) or [docker-bg-sync](https://github.com/cweagans/docker-bg-sync).
|
||||
|
||||
#### Mounting steps
|
||||
|
||||
1. The specified `hostPath` directory must already exist (create one if it does not).
|
||||
2. Install the chart
|
||||
|
||||
```console
|
||||
helm install my-release --set persistence.hostPath=/PATH/TO/HOST/MOUNT oci://REGISTRY_NAME/REPOSITORY_NAME/gitea
|
||||
```
|
||||
|
||||
> Note: You need to substitute the placeholders `REGISTRY_NAME` and `REPOSITORY_NAME` with a reference to your Helm chart registry and repository. For example, in the case of Bitnami, you need to use `REGISTRY_NAME=registry-1.docker.io` and `REPOSITORY_NAME=bitnamicharts`.
|
||||
|
||||
This will mount the `gitea-data` volume into the `hostPath` directory. The site data will be persisted if the mount path contains valid data, else the site data will be initialized at first launch.
|
||||
3. Because the container cannot control the host machine's directory permissions, you must set the Gitea file directory permissions yourself
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
Find more information about how to deal with common errors related to Bitnami's Helm charts in [this troubleshooting guide](https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues).
|
||||
|
||||
Reference in New Issue
Block a user