mirror of
https://github.com/bitnami/charts.git
synced 2026-03-16 06:47:30 +08:00
[bitnami/*] Move documentation sections from docs.bitnami.com back to the README (#22203)
* [bitnami/*] Move documentation sections from docs.bitnami.com back to the README Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move use-external-database section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move configure-sidecar-init-containers section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move configure-sidecar-init-containers section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move configure-ingress section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move enable-tls-ingress section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Remove upgrade-helm3 section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move upgrade section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move upgrade section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move configure-sidecar-init-containers section to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Remove get-started link in GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Move rest of docs sections to GitHub Signed-off-by: Jota Martos <jotamartos@vmware.com> * [CONTENT-6404] Remove some docs.bitnami.com urls from the READMEs Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Fix linter Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Ignore img folder when packaging the helm chart Signed-off-by: Jota Martos <jotamartos@vmware.com> * [bitnami/*] Update template's README file Signed-off-by: Jota Martos <jotamartos@vmware.com> --------- Signed-off-by: Jota Martos <jotamartos@vmware.com> Signed-off-by: Juan José Martos <jotamartos@gmail.com>
This commit is contained in:
Juan José Martos
@@ -23,8 +23,6 @@ Bitnami charts for Helm are carefully engineered, actively maintained and are th
|
||||
This chart bootstraps a [Supabase](https://www.supabase.com/) deployment in a [Kubernetes](https://kubernetes.io) cluster using the [Helm](https://helm.sh) package manager.
|
||||
Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters.
|
||||
|
||||
[Learn more about the default configuration of the chart](https://docs.bitnami.com/kubernetes/infrastructure/supabase/get-started/).
|
||||
|
||||
## Prerequisites
|
||||
|
||||
- Kubernetes 1.23+
|
||||
@@ -876,13 +874,55 @@ externalDatabase.port=5432
|
||||
|
||||
### Ingress
|
||||
|
||||
This chart provides support for Ingress resources. If you have an ingress controller installed on your cluster, such as [nginx-ingress-controller](https://github.com/bitnami/charts/tree/main/bitnami/nginx-ingress-controller) or [contour](https://github.com/bitnami/charts/tree/main/bitnami/contour) you can utilize the ingress controller to serve your application.
|
||||
This chart provides support for Ingress resources. If you have an ingress controller installed on your cluster, such as [nginx-ingress-controller](https://github.com/bitnami/charts/tree/main/bitnami/nginx-ingress-controller) or [contour](https://github.com/bitnami/charts/tree/main/bitnami/contour) you can utilize the ingress controller to serve your application.To enable Ingress integration, set `studio.ingress.enabled` to `true`.
|
||||
|
||||
To enable Ingress integration, set `studio.ingress.enabled` to `true`. The `studio.ingress.hostname` property can be used to set the host name. The `studio.ingress.tls` parameter can be used to add the TLS configuration for this host. It is also possible to have more than one host, with a separate TLS configuration for each host. [Learn more about configuring and using Ingress](https://docs.bitnami.com/kubernetes/infrastructure/supabase/configuration/configure-ingress/).
|
||||
The most common scenario is to have one host name mapped to the deployment. In this case, the `studio.ingress.hostname` property can be used to set the host name. The `studio.ingress.tls` parameter can be used to add the TLS configuration for this host.
|
||||
|
||||
However, it is also possible to have more than one host. To facilitate this, the `studio.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `studio.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts.
|
||||
|
||||
> NOTE: For each host specified in the `studio.ingress.extraHosts` parameter, it is necessary to set a name, path, and any annotations that the Ingress controller should know about. Not all annotations are supported by all Ingress controllers, but [this annotation reference document](https://github.com/kubernetes/ingress-nginx/blob/master/docs/user-guide/nginx-configuration/annotations.md) lists the annotations supported by many popular Ingress controllers.
|
||||
|
||||
Adding the TLS parameter (where available) will cause the chart to generate HTTPS URLs, and the application will be available on port 443. The actual TLS secrets do not have to be generated by this chart. However, if TLS is enabled, the Ingress record will not work until the TLS secret exists.
|
||||
|
||||
[Learn more about Ingress controllers](https://kubernetes.io/docs/concepts/services-networking/ingress-controllers/).
|
||||
|
||||
### TLS secrets
|
||||
|
||||
The chart also facilitates the creation of TLS secrets for use with the Ingress controller, with different options for certificate management. [Learn more about TLS secrets](https://docs.bitnami.com/kubernetes/infrastructure/supabase/administration/enable-tls-ingress/).
|
||||
This chart facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). There are several common use cases:
|
||||
|
||||
- Generate certificate secrets based on chart parameters.
|
||||
- Enable externally generated certificates.
|
||||
- Manage application certificates via an external service (like [cert-manager](https://github.com/jetstack/cert-manager/)).
|
||||
- Create self-signed certificates within the chart (if supported).
|
||||
|
||||
In the first two cases, a certificate and a key are needed. Files are expected in `.pem` format.
|
||||
|
||||
Here is an example of a certificate file:
|
||||
|
||||
> NOTE: There may be more than one certificate if there is a certificate chain.
|
||||
|
||||
```text
|
||||
-----BEGIN CERTIFICATE-----
|
||||
MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
|
||||
...
|
||||
jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
Here is an example of a certificate key:
|
||||
|
||||
```text
|
||||
-----BEGIN RSA PRIVATE KEY-----
|
||||
MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4
|
||||
...
|
||||
wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc=
|
||||
-----END RSA PRIVATE KEY-----
|
||||
```
|
||||
|
||||
- If using Helm to manage the certificates based on the parameters, copy these values into the `certificate` and `key` values for a given `*.ingress.secrets` entry.
|
||||
- If managing TLS secrets separately, it is necessary to create a TLS secret with name `INGRESS_HOSTNAME-tls` (where INGRESS_HOSTNAME is a placeholder to be replaced with the hostname you set using the `*.ingress.hostname` parameter).
|
||||
- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, add to `*.ingress.annotations` the [corresponding ones](https://cert-manager.io/docs/usage/ingress/#supported-annotations) for cert-manager.
|
||||
- If using self-signed certificates created by Helm, set both `*.ingress.tls` and `*.ingress.selfSigned` to `true`.
|
||||
|
||||
## Persistence
|
||||
|
||||
@@ -905,7 +945,43 @@ Alternatively, you can use a ConfigMap or a Secret with the environment variable
|
||||
|
||||
### Sidecars
|
||||
|
||||
If additional containers are needed in the same pod as supabase (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the component specific sections. If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter. [Learn more about configuring and using sidecar containers](https://docs.bitnami.com/kubernetes/infrastructure/supabase/configuration/configure-sidecar-init-containers/).
|
||||
If additional containers are needed in the same pod as supabase (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the component specific sections.
|
||||
|
||||
```yaml
|
||||
sidecars:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter (where available), as shown in the example below:
|
||||
|
||||
```yaml
|
||||
service:
|
||||
extraPorts:
|
||||
- name: extraPort
|
||||
port: 11311
|
||||
targetPort: 11311
|
||||
```
|
||||
|
||||
> NOTE: This Helm chart already includes sidecar containers for the Prometheus exporters (where applicable). These can be activated by adding the `--enable-metrics=true` parameter at deployment time. The `sidecars` parameter should therefore only be used for any extra sidecar containers.
|
||||
|
||||
If additional init containers are needed in the same pod, they can be defined using the `initContainers` parameter. Here is an example:
|
||||
|
||||
```yaml
|
||||
initContainers:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
Learn more about [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/) and [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
|
||||
|
||||
### Pod affinity
|
||||
|
||||
@@ -941,4 +1017,4 @@ Unless required by applicable law or agreed to in writing, software
|
||||
distributed under the License is distributed on an "AS IS" BASIS,
|
||||
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
||||
See the License for the specific language governing permissions and
|
||||
limitations under the License.
|
||||
limitations under the License.
|
||||
|
||||
Reference in New Issue
Block a user