diff --git a/bitnami/airflow/README.md b/bitnami/airflow/README.md index 38b2ac3016..2fd4d1be43 100644 --- a/bitnami/airflow/README.md +++ b/bitnami/airflow/README.md @@ -27,29 +27,181 @@ Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment - Kubernetes 1.23+ - Helm 3.8.0+ -## Installing the Chart +## Configuration and installation details -To install the chart with the release name `my-release`: +### 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. + +### Generate a Fernet key + +A Fernet key is required in order to encrypt password within connections. The Fernet key must be a base64-encoded 32-byte key. + +Learn how to generate one [here](https://airflow.apache.org/docs/apache-airflow/stable/security/secrets/fernet.html#generating-fernet-key) + +### Generate a Secret key + +Secret key used to run your flask app. It should be as random as possible. However, when running more than 1 instances of webserver, make sure all of them use the same secret_key otherwise one of them will error with "CSRF session token is missing". + +### Load DAG files + +There are two different ways to load your custom DAG files into the Airflow chart. All of them are compatible so you can use more than one at the same time. + +#### Option 1: Specify an existing config map + +You can manually create a config map containing all your DAG files and then pass the name when deploying Airflow chart. For that, you can pass the option `dags.existingConfigmap`. + +#### Option 2: Get your DAG files from a git repository + +You can store all your DAG files on GitHub repositories and then clone to the Airflow pods with an initContainer. The repositories will be periodically updated using a sidecar container. In order to do that, you can deploy airflow with the following options: + +> NOTE: When enabling git synchronization, an init container and sidecar container will be added for all the pods running airflow, this will allow scheduler, worker and web component to reach dags if it was needed. ```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/airflow +git.dags.enabled=true +git.dags.repositories[0].repository=https://github.com/USERNAME/REPOSITORY +git.dags.repositories[0].name=REPO-IDENTIFIER +git.dags.repositories[0].branch=master ``` -> 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`. +If you use a private repository from GitHub, a possible option to clone the files is using a [Personal Access Token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) and using it as part of the URL: `https://USERNAME:PERSONAL_ACCESS_TOKEN@github.com/USERNAME/REPOSITORY` -These commands deploy Airflow on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. +### Loading Plugins -> **Tip**: List all releases using `helm list` +You can load plugins into the chart by specifying a git repository containing the plugin files. The repository will be periodically updated using a sidecar container. In order to do that, you can deploy airflow with the following options: -## Uninstalling the Chart - -To uninstall/delete the `my-release` deployment: +> NOTE: When enabling git synchronization, an init container and sidecar container will be added for all the pods running airflow, this will allow scheduler, worker and web component to reach plugins if it was needed. ```console -helm delete my-release +git.plugins.enabled=true +git.plugins.repositories[0].repository=https://github.com/teamclairvoyant/airflow-rest-api-plugin.git +git.plugins.repositories[0].branch=v1.0.9-branch +git.plugins.repositories[0].path=plugins ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Existing Secrets + +You can use an existing secret to configure your Airflow auth, external Postgres, and external Redis® passwords: + +```console +postgresql.enabled=false +externalDatabase.host=my.external.postgres.host +externalDatabase.user=bn_airflow +externalDatabase.database=bitnami_airflow +externalDatabase.existingSecret=all-my-secrets +externalDatabase.existingSecretPasswordKey=postgresql-password + +redis.enabled=false +externalRedis.host=my.external.redis.host +externalRedis.existingSecret=all-my-secrets +externalRedis.existingSecretPasswordKey=redis-password + +auth.existingSecret=all-my-secrets +``` + +The expected secret resource looks as follows: + +```yaml +apiVersion: v1 +kind: Secret +metadata: + name: all-my-secrets +type: Opaque +data: + airflow-password: "Smo1QTJLdGxXMg==" + airflow-fernet-key: "YVRZeVJVWnlXbU4wY1dOalVrdE1SV3cxWWtKeFIzWkVRVTVrVjNaTFR6WT0=" + airflow-secret-key: "a25mQ1FHTUh3MnFRSk5KMEIyVVU2YmN0VGRyYTVXY08=" + postgresql-password: "cG9zdGdyZXMK" + redis-password: "cmVkaXMK" +``` + +This is useful if you plan on using [Bitnami's sealed secrets](https://github.com/bitnami-labs/sealed-secrets) to manage your passwords. + +### 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. + +### Install extra python packages + +This chart allows you to mount volumes using `extraVolumes` and `extraVolumeMounts` in all 3 airflow components (web, scheduler, worker). Mounting a requirements.txt using these options to `/bitnami/python/requirements.txt` will execute `pip install -r /bitnami/python/requirements.txt` on container start. + +### Enabling network policies + +This chart allows you to set network policies that will rectrict the access to the deployed pods in the cluster. Basically, no other pods apart from Scheduler's pods may access Worker's pods and no other pods apart from Web's pods may access Worker's ones. To do so, set `networkPolicies.enabled=true`. + +### Executors + +Airflow supports different executors runtimes and this chart provides support for the following ones. + +#### CeleryExecutor + +Celery executor is the default value for this chart with it you can scale out the number of workers. To point the `executor` parameter to `CeleryExecutor` you need to do something, you just install the chart with default parameters. + +#### KubernetesExecutor + +The kubernetes executor is introduced in Apache Airflow 1.10.0. The Kubernetes executor will create a new pod for every task instance using the `pod_template.yaml` that you can find [templates/config/configmap.yaml](https://github.com/bitnami/charts/blob/main/bitnami/airflow/templates/config/configmap.yaml), otherwise you can override this template using `worker.podTemplate`. To enable `KubernetesExecutor` set the following parameters. + +> NOTE: Redis® is not needed to be deployed when using KubernetesExecutor so you must disable it using `redis.enabled=false`. + +```console +executor=KubernetesExecutor +redis.enabled=false +rbac.create=true +serviceaccount.create=true +``` + +### CeleryKubernetesExecutor + +The CeleryKubernetesExecutor is introduced in Airflow 2.0 and is a combination of both the Celery and the Kubernetes executors. Tasks will be executed using Celery by default, but those tasks that require it can be executed in a Kubernetes pod using the 'kubernetes' queue. + +#### LocalExecutor + +Local executor runs tasks by spawning processes in the Scheduler pods. To enable `LocalExecutor` set the following parameters. + +```console +executor=LocalExecutor +redis.enabled=false +``` + +### LocalKubernetesExecutor + +The LocalKubernetesExecutor is introduced in Airflow 2.3 and is a combination of both the Local and the Kubernetes executors. Tasks will be executed in the scheduler by default, but those tasks that require it can be executed in a Kubernetes pod using the 'kubernetes' queue. + +#### SequentialExecutor + +This executor will only run one task instance at a time in the Scheduler pods. For production use case, please use other executors. To enable `SequentialExecutor` set the following parameters. + +```console +executor=SequentialExecutor +redis.enabled=false +``` + +### Scaling worker pods + +Sometime when using large workloads a fixed number of worker pods may make task to take a long time to be executed. This chart provide two ways for scaling worker pods. + +- If you are using `KubernetesExecutor` auto scaling pods would be done by the Scheduler without adding anything more. +- If you are using `SequentialExecutor` you would have to enable `worker.autoscaling` to do so, please, set the following parameters. It will use autoscaling by default configuration that you can change using `worker.autoscaling.replicas.*` and `worker.autoscaling.targets.*`. + +```console +worker.autoscaling.enabled=true +worker.resources.requests.cpu=200m +worker.resources.requests.memory=250Mi +``` + +## Persistence + +The Bitnami Airflow chart relies on the PostgreSQL chart persistence. This means that Airflow does not persist anything. ## Parameters @@ -592,182 +744,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/airfl > 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/airflow/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. - -### Generate a Fernet key - -A Fernet key is required in order to encrypt password within connections. The Fernet key must be a base64-encoded 32-byte key. - -Learn how to generate one [here](https://airflow.apache.org/docs/apache-airflow/stable/security/secrets/fernet.html#generating-fernet-key) - -### Generate a Secret key - -Secret key used to run your flask app. It should be as random as possible. However, when running more than 1 instances of webserver, make sure all of them use the same secret_key otherwise one of them will error with "CSRF session token is missing". - -### Load DAG files - -There are two different ways to load your custom DAG files into the Airflow chart. All of them are compatible so you can use more than one at the same time. - -#### Option 1: Specify an existing config map - -You can manually create a config map containing all your DAG files and then pass the name when deploying Airflow chart. For that, you can pass the option `dags.existingConfigmap`. - -#### Option 2: Get your DAG files from a git repository - -You can store all your DAG files on GitHub repositories and then clone to the Airflow pods with an initContainer. The repositories will be periodically updated using a sidecar container. In order to do that, you can deploy airflow with the following options: - -> NOTE: When enabling git synchronization, an init container and sidecar container will be added for all the pods running airflow, this will allow scheduler, worker and web component to reach dags if it was needed. - -```console -git.dags.enabled=true -git.dags.repositories[0].repository=https://github.com/USERNAME/REPOSITORY -git.dags.repositories[0].name=REPO-IDENTIFIER -git.dags.repositories[0].branch=master -``` - -If you use a private repository from GitHub, a possible option to clone the files is using a [Personal Access Token](https://docs.github.com/en/github/authenticating-to-github/creating-a-personal-access-token) and using it as part of the URL: `https://USERNAME:PERSONAL_ACCESS_TOKEN@github.com/USERNAME/REPOSITORY` - -### Loading Plugins - -You can load plugins into the chart by specifying a git repository containing the plugin files. The repository will be periodically updated using a sidecar container. In order to do that, you can deploy airflow with the following options: - -> NOTE: When enabling git synchronization, an init container and sidecar container will be added for all the pods running airflow, this will allow scheduler, worker and web component to reach plugins if it was needed. - -```console -git.plugins.enabled=true -git.plugins.repositories[0].repository=https://github.com/teamclairvoyant/airflow-rest-api-plugin.git -git.plugins.repositories[0].branch=v1.0.9-branch -git.plugins.repositories[0].path=plugins -``` - -### Existing Secrets - -You can use an existing secret to configure your Airflow auth, external Postgres, and external Redis® passwords: - -```console -postgresql.enabled=false -externalDatabase.host=my.external.postgres.host -externalDatabase.user=bn_airflow -externalDatabase.database=bitnami_airflow -externalDatabase.existingSecret=all-my-secrets -externalDatabase.existingSecretPasswordKey=postgresql-password - -redis.enabled=false -externalRedis.host=my.external.redis.host -externalRedis.existingSecret=all-my-secrets -externalRedis.existingSecretPasswordKey=redis-password - -auth.existingSecret=all-my-secrets -``` - -The expected secret resource looks as follows: - -```yaml -apiVersion: v1 -kind: Secret -metadata: - name: all-my-secrets -type: Opaque -data: - airflow-password: "Smo1QTJLdGxXMg==" - airflow-fernet-key: "YVRZeVJVWnlXbU4wY1dOalVrdE1SV3cxWWtKeFIzWkVRVTVrVjNaTFR6WT0=" - airflow-secret-key: "a25mQ1FHTUh3MnFRSk5KMEIyVVU2YmN0VGRyYTVXY08=" - postgresql-password: "cG9zdGdyZXMK" - redis-password: "cmVkaXMK" -``` - -This is useful if you plan on using [Bitnami's sealed secrets](https://github.com/bitnami-labs/sealed-secrets) to manage your passwords. - -### 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. - -### Install extra python packages - -This chart allows you to mount volumes using `extraVolumes` and `extraVolumeMounts` in all 3 airflow components (web, scheduler, worker). Mounting a requirements.txt using these options to `/bitnami/python/requirements.txt` will execute `pip install -r /bitnami/python/requirements.txt` on container start. - -### Enabling network policies - -This chart allows you to set network policies that will rectrict the access to the deployed pods in the cluster. Basically, no other pods apart from Scheduler's pods may access Worker's pods and no other pods apart from Web's pods may access Worker's ones. To do so, set `networkPolicies.enabled=true`. - -### Executors - -Airflow supports different executors runtimes and this chart provides support for the following ones. - -#### CeleryExecutor - -Celery executor is the default value for this chart with it you can scale out the number of workers. To point the `executor` parameter to `CeleryExecutor` you need to do something, you just install the chart with default parameters. - -#### KubernetesExecutor - -The kubernetes executor is introduced in Apache Airflow 1.10.0. The Kubernetes executor will create a new pod for every task instance using the `pod_template.yaml` that you can find [templates/config/configmap.yaml](https://github.com/bitnami/charts/blob/main/bitnami/airflow/templates/config/configmap.yaml), otherwise you can override this template using `worker.podTemplate`. To enable `KubernetesExecutor` set the following parameters. - -> NOTE: Redis® is not needed to be deployed when using KubernetesExecutor so you must disable it using `redis.enabled=false`. - -```console -executor=KubernetesExecutor -redis.enabled=false -rbac.create=true -serviceaccount.create=true -``` - -### CeleryKubernetesExecutor - -The CeleryKubernetesExecutor is introduced in Airflow 2.0 and is a combination of both the Celery and the Kubernetes executors. Tasks will be executed using Celery by default, but those tasks that require it can be executed in a Kubernetes pod using the 'kubernetes' queue. - -#### LocalExecutor - -Local executor runs tasks by spawning processes in the Scheduler pods. To enable `LocalExecutor` set the following parameters. - -```console -executor=LocalExecutor -redis.enabled=false -``` - -### LocalKubernetesExecutor - -The LocalKubernetesExecutor is introduced in Airflow 2.3 and is a combination of both the Local and the Kubernetes executors. Tasks will be executed in the scheduler by default, but those tasks that require it can be executed in a Kubernetes pod using the 'kubernetes' queue. - -#### SequentialExecutor - -This executor will only run one task instance at a time in the Scheduler pods. For production use case, please use other executors. To enable `SequentialExecutor` set the following parameters. - -```console -executor=SequentialExecutor -redis.enabled=false -``` - -### Scaling worker pods - -Sometime when using large workloads a fixed number of worker pods may make task to take a long time to be executed. This chart provide two ways for scaling worker pods. - -- If you are using `KubernetesExecutor` auto scaling pods would be done by the Scheduler without adding anything more. -- If you are using `SequentialExecutor` you would have to enable `worker.autoscaling` to do so, please, set the following parameters. It will use autoscaling by default configuration that you can change using `worker.autoscaling.replicas.*` and `worker.autoscaling.targets.*`. - -```console -worker.autoscaling.enabled=true -worker.resources.requests.cpu=200m -worker.resources.requests.memory=250Mi -``` - -## Persistence - -The Bitnami Airflow chart relies on the PostgreSQL chart persistence. This means that Airflow does not persist anything. - ## 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). diff --git a/bitnami/apache/README.md b/bitnami/apache/README.md index 6ca970a839..f058065afa 100644 --- a/bitnami/apache/README.md +++ b/bitnami/apache/README.md @@ -45,15 +45,45 @@ These commands deploy Apache on the Kubernetes cluster in the default configurat > **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 -```console -helm delete my-release +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. + +### Deploying a custom web application + +The Apache chart allows you to deploy a custom web application using one of the following methods: + +- Cloning from a git repository: Set `cloneHtdocsFromGit.enabled` to `true` and set the repository and branch using the `cloneHtdocsFromGit.repository` and `cloneHtdocsFromGit.branch` parameters. A sidecar will also pull the latest changes in an interval set by `cloneHtdocsFromGit.interval`. +- Providing a ConfigMap: Set the `htdocsConfigMap` value to mount a ConfigMap in the Apache htdocs folder. +- Using an existing PVC: Set the `htdocsPVC` value to mount an PersistentVolumeClaim with the web application content. + +Here is an example of deploying a web application from a Git repository using the first method: + +```text +cloneHtdocsFromGit.enabled=true +cloneHtdocsFromGit.repository=https://github.com/mdn/beginner-html-site-styled.git +cloneHtdocsFromGit.branch=master ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +To use a custom `httpd.conf` file, mount it using the `httpdConfConfigMap` parameter, which references a Kubernetes ConfigMap with the contents of the `httpd.conf` file. Alternatively, copy the `httpd.conf` file to `files/httpd.conf` in the current working directory to mount it in the container. + +To mount different virtual host configurations, use the `vhostsConfigMap` value. This is a pointer to a Kubernetes ConfigMap with the desired Apache virtual host configurations. You can also copy the virtual host configurations under the `files/vhosts/` directory in your current working directory to mount them as a ConfigMap in the container. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use the preset configurations for pod affinity, pod anti-affinity, and node affinity available in the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters. ## Parameters @@ -286,64 +316,10 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/apach > 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/apache/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. - -### Deploying a custom web application - -The Apache chart allows you to deploy a custom web application using one of the following methods: - -- Cloning from a git repository: Set `cloneHtdocsFromGit.enabled` to `true` and set the repository and branch using the `cloneHtdocsFromGit.repository` and `cloneHtdocsFromGit.branch` parameters. A sidecar will also pull the latest changes in an interval set by `cloneHtdocsFromGit.interval`. -- Providing a ConfigMap: Set the `htdocsConfigMap` value to mount a ConfigMap in the Apache htdocs folder. -- Using an existing PVC: Set the `htdocsPVC` value to mount an PersistentVolumeClaim with the web application content. - -Here is an example of deploying a web application from a Git repository using the first method: - -```text -cloneHtdocsFromGit.enabled=true -cloneHtdocsFromGit.repository=https://github.com/mdn/beginner-html-site-styled.git -cloneHtdocsFromGit.branch=master -``` - -To use a custom `httpd.conf` file, mount it using the `httpdConfConfigMap` parameter, which references a Kubernetes ConfigMap with the contents of the `httpd.conf` file. Alternatively, copy the `httpd.conf` file to `files/httpd.conf` in the current working directory to mount it in the container. - -To mount different virtual host configurations, use the `vhostsConfigMap` value. This is a pointer to a Kubernetes ConfigMap with the desired Apache virtual host configurations. You can also copy the virtual host configurations under the `files/vhosts/` directory in your current working directory to mount them as a ConfigMap in the container. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use the preset configurations for pod affinity, pod anti-affinity, and node affinity available in the [bitnami/common](https://github.com/bitnami/charts/tree/main/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters. - ## 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). -## Notable changes - -### 7.4.0 - -This version also introduces `bitnami/common`, a [library chart](https://helm.sh/docs/topics/library_charts/#helm) as a dependency. More documentation about this new utility could be found [here](https://github.com/bitnami/charts/tree/main/bitnami/common#bitnami-common-library-chart). Please, make sure that you have updated the chart dependencies before executing any upgrade. - -### 7.0.0 - -This release updates the Bitnami Apache container to `2.4.41-debian-9-r40`, which is based on Bash instead of Node.js. - -### 6.0.0 - -This release allows you to use your custom static application. In order to do so, check [this section](#deploying-a-custom-web-application). - ## Upgrading ### To 10.0.0 @@ -364,6 +340,18 @@ Affected values: [On November 13, 2020, Helm v2 support formally ended](https://github.com/helm/charts#status-of-the-project). This major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL. +### To 7.4.0 + +This version introduces `bitnami/common`, a [library chart](https://helm.sh/docs/topics/library_charts/#helm) as a dependency. More documentation about this new utility could be found [here](https://github.com/bitnami/charts/tree/main/bitnami/common#bitnami-common-library-chart). Please, make sure that you have updated the chart dependencies before executing any upgrade. + +### To 7.0.0 + +This release updates the Bitnami Apache container to `2.4.41-debian-9-r40`, which is based on Bash instead of Node.js. + +### To 6.0.0 + +This release allows you to use your custom static application. In order to do so, check [this section](#deploying-a-custom-web-application). + ### To 2.0.0 Backwards compatibility is not guaranteed unless you modify the labels used on the chart's deployments. diff --git a/bitnami/apisix/README.md b/bitnami/apisix/README.md index e81fde68ec..e0396bc779 100644 --- a/bitnami/apisix/README.md +++ b/bitnami/apisix/README.md @@ -39,15 +39,209 @@ The command deploys apisix on the Kubernetes cluster in the default configuratio > **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 -```console -helm delete my-release +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. + +### Deployment modes + +Apache APISIX supports [multiple deployment modes](https://apisix.apache.org/docs/apisix/deployment-modes/). The Bitnami APISIX chart deploys the `decoupled` mode by default, but it is possible to deploy in `traditional` or `standalone` modes as well. + +#### Traditional mode + +The following values configure the traditional mode: + +``` yaml +dataPlane: + enabled: false +controlPlane: + extraConfig: + deployment: + role: traditional + role_traditional: + config_provider: etcd + service: + extraPorts: + - name: http + port: 80 + targetPort: 9080 + - name: https + port: 443 + targetPort: 9443 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +#### Standalone mode + +The following values configure the standalone mode: + +``` yaml +controlPlane: + enabled: false +ingressController: + enabled: false +etcd: + enabled: false +dataPlane: + extraConfig: + deployment: + role_data_plane: + config_provider: yaml + extraVolumes: + - name: routes + configMap: + name: apisix-routes + extraVolumeMounts: + - name: routes + mountPath: /opt/bitnami/apisix/conf/apisix.yaml + subPath: apisix.yaml +extraDeploy: + - apiVersion: v1 + kind: ConfigMap + metadata: + name: apisix-routes + data: + apisix.yaml: |- + routes: + - + uri: /hello + upstream: + nodes: + "127.0.0.1:1980": 1 + type: roundrobin +``` + +### 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### External etcd support + +You may want to have Mastodon connect to an external etcd rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalEtcd` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example: + +```yaml +etcd: + enabled: false +externalEtcd: + hosts: + - externalhost +``` + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections. + +```yaml +dataPlane: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections. + +### Sidecars + +If additional containers are needed in the same pod as APISIX (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` 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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections. ## Parameters @@ -854,210 +1048,6 @@ helm install my-release -f values.yaml my-repo/apisix > **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/apisix/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. - -### Deployment modes - -Apache APISIX supports [multiple deployment modes](https://apisix.apache.org/docs/apisix/deployment-modes/). The Bitnami APISIX chart deploys the `decoupled` mode by default, but it is possible to deploy in `traditional` or `standalone` modes as well. - -#### Traditional mode - -The following values configure the traditional mode: - -``` yaml -dataPlane: - enabled: false -controlPlane: - extraConfig: - deployment: - role: traditional - role_traditional: - config_provider: etcd - service: - extraPorts: - - name: http - port: 80 - targetPort: 9080 - - name: https - port: 443 - targetPort: 9443 -``` - -#### Standalone mode - -The following values configure the standalone mode: - -``` yaml -controlPlane: - enabled: false -ingressController: - enabled: false -etcd: - enabled: false -dataPlane: - extraConfig: - deployment: - role_data_plane: - config_provider: yaml - extraVolumes: - - name: routes - configMap: - name: apisix-routes - extraVolumeMounts: - - name: routes - mountPath: /opt/bitnami/apisix/conf/apisix.yaml - subPath: apisix.yaml -extraDeploy: - - apiVersion: v1 - kind: ConfigMap - metadata: - name: apisix-routes - data: - apisix.yaml: |- - routes: - - - uri: /hello - upstream: - nodes: - "127.0.0.1:1980": 1 - type: roundrobin -``` - -### 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### External etcd support - -You may want to have Mastodon connect to an external etcd rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalEtcd` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example: - -```yaml -etcd: - enabled: false -externalEtcd: - hosts: - - externalhost -``` - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections. - -```yaml -dataPlane: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections. - -### Sidecars - -If additional containers are needed in the same pod as APISIX (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` 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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the `dataPlane`, `controlPlane`, `dashboard` and `ingressController` sections. - ## 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). diff --git a/bitnami/appsmith/README.md b/bitnami/appsmith/README.md index 7895c3bf7b..0abf649b23 100644 --- a/bitnami/appsmith/README.md +++ b/bitnami/appsmith/README.md @@ -45,15 +45,161 @@ The command deploys Appsmith on the Kubernetes cluster in the default configurat > **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. + +### External database support + +You may want to have appsmith connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the MongoDB installation with the `mongodb.enabled` option. Here is an example: ```console -helm delete my-release +mongodb.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=3306 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### External redis support + +You may want to have appsmith connect to an external redis rather than installing one inside your cluster. Typical reasons for this are to use a managed redis service, or to share a common redis server for all your applications. To achieve this, the chart allows you to specify credentials for an external redis with the [`externalDatabase` parameter](#parameters). You should also disable the Redis installation with the `redis.enabled` option. Here is an example: + +```console +redis.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.redis=myredis +externalDatabase.port=3306 +``` + +### 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.To enable Ingress integration, set `client.ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `client.ingress.hostname` property can be used to set the host name. The `client.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 `client.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `client.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `client.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 + +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `client`, `backend` and `rts` sections. + +```yaml +appsmith: + backend: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `client`, `backend` and `rts` sections. + +### Sidecars + +If additional containers are needed in the same pod as appsmith (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `client`, `backend` and `rts` 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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the `client`, `backend` and `rts` sections. + +## Persistence + +The [Bitnami appsmith](https://github.com/bitnami/containers/tree/main/bitnami/appsmith) image stores the appsmith data and configurations at the `/bitnami` 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. ## Parameters @@ -520,162 +666,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/appsm > 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/appsmith/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. - -### External database support - -You may want to have appsmith connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the MongoDB installation with the `mongodb.enabled` option. Here is an example: - -```console -mongodb.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=3306 -``` - -### External redis support - -You may want to have appsmith connect to an external redis rather than installing one inside your cluster. Typical reasons for this are to use a managed redis service, or to share a common redis server for all your applications. To achieve this, the chart allows you to specify credentials for an external redis with the [`externalDatabase` parameter](#parameters). You should also disable the Redis installation with the `redis.enabled` option. Here is an example: - -```console -redis.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.redis=myredis -externalDatabase.port=3306 -``` - -### 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.To enable Ingress integration, set `client.ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `client.ingress.hostname` property can be used to set the host name. The `client.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 `client.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `client.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `client.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 - -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 - -The [Bitnami appsmith](https://github.com/bitnami/containers/tree/main/bitnami/appsmith) image stores the appsmith data and configurations at the `/bitnami` 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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `client`, `backend` and `rts` sections. - -```yaml -appsmith: - backend: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `client`, `backend` and `rts` sections. - -### Sidecars - -If additional containers are needed in the same pod as appsmith (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `client`, `backend` and `rts` 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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the `client`, `backend` and `rts` sections. - ## 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). diff --git a/bitnami/argo-cd/README.md b/bitnami/argo-cd/README.md index b3b2049149..184f1ac431 100644 --- a/bitnami/argo-cd/README.md +++ b/bitnami/argo-cd/README.md @@ -43,15 +43,195 @@ The command deploys argo-cd on the Kubernetes cluster in the default configurati > **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 -```console -helm delete my-release +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. + +### 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.To enable Ingress integration, set `server.ingress.enabled` to `true` for the http ingress or `server.grpcIngress.enabled` to `true` for the gRPC ingress. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `xxx.ingress.hostname` property can be used to set the host name. The `xxx.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 `xxx.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `xxx.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `xxx.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 + +This chart facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). Apart from the Ingress TLS certificates, Argo CD repo server will auto-generate a secret named `argocd-repo-server-tls`. This secret contains the TLS configuration for the Argo CD components. The secret will be created only if it does not exist, so if you want to add custom TLS configuration you can create a secret with that name before installing the chart. There are several common use cases for the TLS secrets generation: + +- 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----- ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +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`. + +### Default config maps and secrets + +The chart has hardcoded names for some ConfigMaps and Secrets like `argocd-ssh-known-hosts-cm`, `argocd-repo-server-tls` or `argocd-ssh-known-hosts-cm`. Argo CD will search for those specific names when the chart installed, so installing the chart twice in the same namespaces is not possible due to this restriction. +For more information about each configmap or secret check the references at the corresponding YAML files. + +### Using SSO + +In order to use SSO you need to enable Dex by setting `dex.enabled=true`. You can follow [this guide](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#1-register-the-application-in-the-identity-provider) to configure your Argo CD deployment into your identity provider. After that, you need to configure Argo CD like described [here](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#2-configure-argo-cd-for-sso). You can set the Dex configuration at `server.config.dex\.config` that will populate the `argocd-cm` config map. + +> NOTE: `dex.config` is the key of the object. IF you are using the Helm CLI to set the parameter you need to scape the `.` like `--set server.config.dex\.config`. +> IMPORTANT: if you enable Dex without configuring it you will get an error similar to `msg="dex is not configured"`, and the Dex pod will never reach the running state. + +### Installing a Config Management Plugin + +In order to install a Config Management Plugin as described in the official [documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/config-management-plugins/), it's recommended to run a sidecar container & mount the plugin configuration from a ConfigMap. You can achieve so by using `repoServer.extraVolumes`, `repoServer.sidecars` and `extraDeploy` parameters as shown in the example below: + +```yaml +repoServer: + extraVolumes: + - name: plugin-config + configMap: + name: my-plugin-config + - name: plugins + emptyDir: {} + - name: plugin-tmp + emptyDir: {} + - name: var-files + emptyDir: {} + sidecars: + - name: plugin-sidecar + command: [argocd-cmp-server, --config-dir-path, /app/config] + image: "{{ include \"argocd.image\" . }}" + env: + - name: ARGOCD_PLUGINSOCKFILEPATH + value: /app/plugins + securityContext: + runAsNonRoot: true + runAsUser: 1001 + volumeMounts: + - mountPath: /app/plugins + name: plugins + - mountPath: /tmp + name: plugin-tmp + - mountPath: /var/run/argocd + name: var-files + # Insert plugin configuration + - mountPath: /app/config/plugin.yaml + subPath: plugin.yaml + name: plugin-config +extraDeploy: +- apiVersion: v1 + kind: ConfigMap + metadata: + name: my-plugin-config + data: + plugin.yaml: | + apiVersion: argoproj.io/v1alpha1 + kind: ConfigManagementPlugin + metadata: + name: my-plugin + spec: + version: v1.0 + (...) +``` + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +argo-cd: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as Argo-CD (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. ## Parameters @@ -1056,196 +1236,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/argo- > 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/argo-cd/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. - -### 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.To enable Ingress integration, set `server.ingress.enabled` to `true` for the http ingress or `server.grpcIngress.enabled` to `true` for the gRPC ingress. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `xxx.ingress.hostname` property can be used to set the host name. The `xxx.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 `xxx.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `xxx.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `xxx.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 - -This chart facilitates the creation of TLS secrets for use with the Ingress controller (although this is not mandatory). Apart from the Ingress TLS certificates, Argo CD repo server will auto-generate a secret named `argocd-repo-server-tls`. This secret contains the TLS configuration for the Argo CD components. The secret will be created only if it does not exist, so if you want to add custom TLS configuration you can create a secret with that name before installing the chart. There are several common use cases for the TLS secrets generation: - -- 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`. - -### Default config maps and secrets - -The chart has hardcoded names for some ConfigMaps and Secrets like `argocd-ssh-known-hosts-cm`, `argocd-repo-server-tls` or `argocd-ssh-known-hosts-cm`. Argo CD will search for those specific names when the chart installed, so installing the chart twice in the same namespaces is not possible due to this restriction. -For more information about each configmap or secret check the references at the corresponding YAML files. - -### Using SSO - -In order to use SSO you need to enable Dex by setting `dex.enabled=true`. You can follow [this guide](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#1-register-the-application-in-the-identity-provider) to configure your Argo CD deployment into your identity provider. After that, you need to configure Argo CD like described [here](https://argo-cd.readthedocs.io/en/stable/operator-manual/user-management/#2-configure-argo-cd-for-sso). You can set the Dex configuration at `server.config.dex\.config` that will populate the `argocd-cm` config map. - -> NOTE: `dex.config` is the key of the object. IF you are using the Helm CLI to set the parameter you need to scape the `.` like `--set server.config.dex\.config`. -> IMPORTANT: if you enable Dex without configuring it you will get an error similar to `msg="dex is not configured"`, and the Dex pod will never reach the running state. - -### Installing a Config Management Plugin - -In order to install a Config Management Plugin as described in the official [documentation](https://argo-cd.readthedocs.io/en/stable/operator-manual/config-management-plugins/), it's recommended to run a sidecar container & mount the plugin configuration from a ConfigMap. You can achieve so by using `repoServer.extraVolumes`, `repoServer.sidecars` and `extraDeploy` parameters as shown in the example below: - -```yaml -repoServer: - extraVolumes: - - name: plugin-config - configMap: - name: my-plugin-config - - name: plugins - emptyDir: {} - - name: plugin-tmp - emptyDir: {} - - name: var-files - emptyDir: {} - sidecars: - - name: plugin-sidecar - command: [argocd-cmp-server, --config-dir-path, /app/config] - image: "{{ include \"argocd.image\" . }}" - env: - - name: ARGOCD_PLUGINSOCKFILEPATH - value: /app/plugins - securityContext: - runAsNonRoot: true - runAsUser: 1001 - volumeMounts: - - mountPath: /app/plugins - name: plugins - - mountPath: /tmp - name: plugin-tmp - - mountPath: /var/run/argocd - name: var-files - # Insert plugin configuration - - mountPath: /app/config/plugin.yaml - subPath: plugin.yaml - name: plugin-config -extraDeploy: -- apiVersion: v1 - kind: ConfigMap - metadata: - name: my-plugin-config - data: - plugin.yaml: | - apiVersion: argoproj.io/v1alpha1 - kind: ConfigManagementPlugin - metadata: - name: my-plugin - spec: - version: v1.0 - (...) -``` - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -argo-cd: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as Argo-CD (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/argo-workflows/README.md b/bitnami/argo-workflows/README.md index cb96285140..9179ac9a96 100644 --- a/bitnami/argo-workflows/README.md +++ b/bitnami/argo-workflows/README.md @@ -43,15 +43,154 @@ The command deploys Argo Workflows on the Kubernetes cluster in the default conf > **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. + +### Database support + +You may want to have Argo Workflows controller connected to a database to store controller evidences. To achieve this, the chart can be deployed with the PostgreSQL or MySQL dependency (see next section to configure an external database instead of using the dependency). In order to configure the database, just change `postgresql.enabled=true` (default configuration) or `mysql.enabled=true`. The database will be configured automatically. Here is an example: ```console -helm delete my-release +postgresql.enabled=true ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +If your installation does not require to to store controller evidences, you can disable the controller persistence by setting `postgresql.enabled=false`, `mysql.enabled=false` and `externalDatabase.enabled=false`. + +#### External database + +You may want to have Argo Workflows controller connected to an external database to store controller evidences. To achieve this, the chart allows you to specify credentials for an external database (using either postgresql or mysql) with the [`controller.persistence.postgresql.enabled` or `controller.persistence.mysql.enabled` parameter](#parameters). You should also set `persistence.enabled` to `true`. Here is an example: + +```console +externalDatabase.enabled=true +externalDatabase.type=postgresql +externalDatabase.host= +externalDatabase.port=5432 +externalDatabase.user= +externalDatabase.password= +externalDatabase.database=bitnami_wordpress +``` + +### 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. To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +argo-workflows: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as argo-workflows (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. ## Parameters @@ -433,155 +572,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/argo- > 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/argo-workflows/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. - -### Database support - -You may want to have Argo Workflows controller connected to a database to store controller evidences. To achieve this, the chart can be deployed with the PostgreSQL or MySQL dependency (see next section to configure an external database instead of using the dependency). In order to configure the database, just change `postgresql.enabled=true` (default configuration) or `mysql.enabled=true`. The database will be configured automatically. Here is an example: - -```console -postgresql.enabled=true -``` - -If your installation does not require to to store controller evidences, you can disable the controller persistence by setting `postgresql.enabled=false`, `mysql.enabled=false` and `externalDatabase.enabled=false`. - -#### External database - -You may want to have Argo Workflows controller connected to an external database to store controller evidences. To achieve this, the chart allows you to specify credentials for an external database (using either postgresql or mysql) with the [`controller.persistence.postgresql.enabled` or `controller.persistence.mysql.enabled` parameter](#parameters). You should also set `persistence.enabled` to `true`. Here is an example: - -```console -externalDatabase.enabled=true -externalDatabase.type=postgresql -externalDatabase.host= -externalDatabase.port=5432 -externalDatabase.user= -externalDatabase.password= -externalDatabase.database=bitnami_wordpress -``` - -### 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. To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -argo-workflows: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as argo-workflows (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/aspnet-core/README.md b/bitnami/aspnet-core/README.md index d29d118e1e..d6d53fe32f 100644 --- a/bitnami/aspnet-core/README.md +++ b/bitnami/aspnet-core/README.md @@ -41,15 +41,165 @@ These commands deploy a ASP.NET Core application on the Kubernetes cluster in th > **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. + +### Deploying your custom ASP.NET Core application + +The ASP.NET Core chart allows you to deploy a custom application using one of the following methods: + +- Using a Docker image containing your ASP.NET Core application ready to be executed. +- Cloning your ASP.NET Core application code from a GIT repository. +- Mounting your ASP.NET Core application from an existing PVC + +#### Using a Docker image containing your ASP.NET Core application ready to be executed + +You can build your own Docker image containing your ASP.NET Core application ready to be executed. To do so, overwrite the default image setting the `image.*` parameters, and set your custom command and arguments setting the `command` and `args` parameters: ```console -helm delete my-release +appFromExternalRepo.enabled=false +image.registry=docker.io +image.repository=your-image +image.tag=your-tag +command=[command] +args=[arguments] ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Find more information about the process to create your own image in the guide below: + +- [Develop and Publish an ASP.NET Core Web Application using Bitnami Containers](https://docs.bitnami.com/tutorials/develop-aspnet-application-bitnami-containers). + +#### Cloning your ASP.NET Core application code from a GIT repository + +This is done using two different init containers: + +- `clone-repository`: uses the [Bitnami GIT Image](https://github.com/bitnami/containers/tree/main/bitnami/git) to download the repository. +- `dotnet-publish`: uses the [Bitnami .Net SDK Image](https://github.com/bitnami/containers/tree/main/bitnami/dotnet-sdk) to build/publish the ASP.NET Core application. + +To use this feature, set the `appFromExternalRepo.enabled` to `true` and set the repository and branch to use setting the `appFromExternalRepo.clone.repository` and `appFromExternalRepo.clone.revision` parameters. Then, specify the sub folder under the Git repository containing the ASP.NET Core app setting the `appFromExternalRepo.publish.subFolder` parameter. Finally, provide the start command to use setting the `appFromExternalRepo.startCommand`. + +> Note: you can append any custom flag for the "dotnet publish" command setting the `appFromExternalRepo.publish.extraFlags` parameter. + +For example, you can deploy a sample [OCMinimal](https://learn.microsoft.com/en-us/aspnet/core/performance/caching/output) using the parameters below: + +```console +appFromExternalRepo.enabled=true +appFromExternalRepo.clone.repository=https://github.com/dotnet/AspNetCore.Docs.git +appFromExternalRepo.clone.revision=main +appFromExternalRepo.publish.aspnetcore/performance/caching/output/samples/7.x/ +appFromExternalRepo.startCommand[0]=dotnet +appFromExternalRepo.startCommand[1]=OCMinimal.dll +``` + +#### Mounting your ASP.NET Core application from an existing PVC + +If you previously created a PVC with your application code ready to be executed, you can mount it in the ASP.NET Core container setting the `appFromExistingPVC.enabled` parameter to `true`. Then, specify the name of your existing PVC setting the `appFromExistingPVC.existingClaim` parameter. + +For example, if you created a PVC named `my-custom-apsnet-core-app` containing your application, use the parameters below: + +```console +appFromExistingPVC.enabled=true +appFromExistingPVC.existingClaim=my-custom-apsnet-core-app +``` + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +kong: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the ASP.NET Core app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would create a ConfigMap including some app's configuration, and it will mount it in the ASP.NET Core app's container: + +```yaml +extraDeploy: |- + - apiVersion: v1 + kind: ConfigMap + metadata: + name: aspnet-core-configuration + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} + {{- if .Values.commonAnnotations }} + annotations: {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 6 }} + {{- end }} + data: + appsettings.json: |- + { + "AllowedHosts": "*" + } +extraVolumeMounts: + - name: configuration + mountPath: /app/config/ + readOnly: true +extraVolumes: + - name: configuration + configMap: + name: aspnet-core-configuration +``` + +### 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. + +### 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. + +To enable ingress integration, please set `ingress.enabled` to `true`. + +#### Hosts + +Most likely you will only want to have one hostname that maps to this ASP.NET Core installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. ## Parameters @@ -257,166 +407,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/aspne > 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/aspnet-core/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. - -### Deploying your custom ASP.NET Core application - -The ASP.NET Core chart allows you to deploy a custom application using one of the following methods: - -- Using a Docker image containing your ASP.NET Core application ready to be executed. -- Cloning your ASP.NET Core application code from a GIT repository. -- Mounting your ASP.NET Core application from an existing PVC - -#### Using a Docker image containing your ASP.NET Core application ready to be executed - -You can build your own Docker image containing your ASP.NET Core application ready to be executed. To do so, overwrite the default image setting the `image.*` parameters, and set your custom command and arguments setting the `command` and `args` parameters: - -```console -appFromExternalRepo.enabled=false -image.registry=docker.io -image.repository=your-image -image.tag=your-tag -command=[command] -args=[arguments] -``` - -Find more information about the process to create your own image in the guide below: - -- [Develop and Publish an ASP.NET Core Web Application using Bitnami Containers](https://docs.bitnami.com/tutorials/develop-aspnet-application-bitnami-containers). - -#### Cloning your ASP.NET Core application code from a GIT repository - -This is done using two different init containers: - -- `clone-repository`: uses the [Bitnami GIT Image](https://github.com/bitnami/containers/tree/main/bitnami/git) to download the repository. -- `dotnet-publish`: uses the [Bitnami .Net SDK Image](https://github.com/bitnami/containers/tree/main/bitnami/dotnet-sdk) to build/publish the ASP.NET Core application. - -To use this feature, set the `appFromExternalRepo.enabled` to `true` and set the repository and branch to use setting the `appFromExternalRepo.clone.repository` and `appFromExternalRepo.clone.revision` parameters. Then, specify the sub folder under the Git repository containing the ASP.NET Core app setting the `appFromExternalRepo.publish.subFolder` parameter. Finally, provide the start command to use setting the `appFromExternalRepo.startCommand`. - -> Note: you can append any custom flag for the "dotnet publish" command setting the `appFromExternalRepo.publish.extraFlags` parameter. - -For example, you can deploy a sample [OCMinimal](https://learn.microsoft.com/en-us/aspnet/core/performance/caching/output) using the parameters below: - -```console -appFromExternalRepo.enabled=true -appFromExternalRepo.clone.repository=https://github.com/dotnet/AspNetCore.Docs.git -appFromExternalRepo.clone.revision=main -appFromExternalRepo.publish.aspnetcore/performance/caching/output/samples/7.x/ -appFromExternalRepo.startCommand[0]=dotnet -appFromExternalRepo.startCommand[1]=OCMinimal.dll -``` - -#### Mounting your ASP.NET Core application from an existing PVC - -If you previously created a PVC with your application code ready to be executed, you can mount it in the ASP.NET Core container setting the `appFromExistingPVC.enabled` parameter to `true`. Then, specify the name of your existing PVC setting the `appFromExistingPVC.existingClaim` parameter. - -For example, if you created a PVC named `my-custom-apsnet-core-app` containing your application, use the parameters below: - -```console -appFromExistingPVC.enabled=true -appFromExistingPVC.existingClaim=my-custom-apsnet-core-app -``` - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -kong: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the ASP.NET Core app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would create a ConfigMap including some app's configuration, and it will mount it in the ASP.NET Core app's container: - -```yaml -extraDeploy: |- - - apiVersion: v1 - kind: ConfigMap - metadata: - name: aspnet-core-configuration - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} - {{- if .Values.commonAnnotations }} - annotations: {{- include "common.tplvalues.render" ( dict "value" .Values.commonAnnotations "context" $ ) | nindent 6 }} - {{- end }} - data: - appsettings.json: |- - { - "AllowedHosts": "*" - } -extraVolumeMounts: - - name: configuration - mountPath: /app/config/ - readOnly: true -extraVolumes: - - name: configuration - configMap: - name: aspnet-core-configuration -``` - -### 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. - -### 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. - -To enable ingress integration, please set `ingress.enabled` to `true`. - -#### Hosts - -Most likely you will only want to have one hostname that maps to this ASP.NET Core installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. - ## 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). diff --git a/bitnami/cassandra/README.md b/bitnami/cassandra/README.md index d4e260654a..43ee415c49 100644 --- a/bitnami/cassandra/README.md +++ b/bitnami/cassandra/README.md @@ -42,15 +42,99 @@ These commands deploy one node with Apache Cassandra on the Kubernetes cluster i > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` release: +### Resource requests and limits -```console -helm delete my-release +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. + +### Enable TLS + +This chart supports TLS between client and server and between nodes, as explained below: + +- For internode cluster encryption, set the `tls.internodeEncryption` chart parameter to a value different from `none`. Available values are `all`, `dc` or `rack`. +- For client-server encryption, set the `tls.clientEncryption` chart parameter to `true`. + +In both cases, it is also necessary to create a secret containing the keystore and truststore certificates and their corresponding protection passwords. This secret is to be passed to the chart via the `tls.existingSecret` parameter at deployment-time, as shown below: + +```text +tls.internodeEncryption=all +tls.clientEncryption=true +tls.existingSecret=my-exisiting-stores +tls.passwordsSecret=my-stores-password ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +> TIP: The secret may be created in the standard way with the `--from-file=./keystore`, `--from-file=./truststore`, `--from-literal=keystore-password=KEYSTORE_PASSWORD` and `--from-literal=truststore-password=TRUSTSTORE_PASSWORD` options. This assumes that the stores are in the current working directory and the KEYSTORE_PASSWORD and TRUSTSTORE_PASSWORD placeholders are replaced with the correct keystore and truststore passwords respectively. Example: + +```console +kubectl create secret generic my-exisiting-stores --from-file=./keystore --from-file=./truststore +kubectl create secret generic my-stores-password --from-literal=keystore-password=KEYSTORE_PASSWORD --from-literal=truststore-password=TRUSTSTORE_PASSWORD +``` + +Keystore and Truststore files can be dinamycally created from the certificates files. In this case a secret with the tls.crt, tls.key and ca.crt in pem format is required. The following example shows how the secret can be created and assumes that all certificate files are in the working directory: + +```console +kubectl create secret tls my-certs --cert ./tls.crt --key ./tls.key +kubectl patch secret my-certs -p="{\"data\":{\"ca.crt\": \"$(cat ./ca.crt | base64 )\"}}" +``` + +To enable this feature `tls.autoGenerated` must be set and the new secret should be set in `tls.certificateSecret`: + +```text +tls.internodeEncryption=all +tls.clientEncryption=true +tls.autoGenerated=true +tls.certificatesSecret=my-certs +tls.passwordsSecret=my-stores-password +``` + +### Initialize the database + +The [Apache Cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image supports the use of custom scripts to initialize a fresh instance. This may be done by creating a Kubernetes ConfigMap that includes the necessary `.sh` or `.cql` scripts and passing this ConfigMap to the chart via the `initDBConfigMap` parameter. + +### Use a custom configuration file + +This chart also supports mounting custom configuration file(s) for Apache Cassandra. This is achieved by setting the `existingConfiguration` parameter with the name of a ConfigMap that includes the custom configuration file(s). Here is an example of deploying the chart with a custom configuration file stored in a ConfigMap named `cassandra-configuration`: + +```text +existingConfiguration=cassandra-configuration +``` + +> NOTE: This ConfigMap will override other Apache Cassandra configuration variables set in the chart. + +### Backup and restore + +Refer to our detailed tutorial on [backing up and restoring Bitnami Apache Cassandra deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-cassandra-kubernetes/). + +### Set pod affinity + +This chart allows you to set custom pod affinity using the `XXX.affinity` parameter(s). Find more information about pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami Apache Cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image stores the Apache Cassandra data at the `/bitnami/cassandra` 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. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. There are two approaches to achieve this: + +- Use Kubernetes SecurityContexts by setting the `podSecurityContext.enabled` and `containerSecurityContext.enabled` to `true`. This option is enabled by default in the chart. However, this feature does not work in all Kubernetes distributions. +- Use an init container to change the ownership of the volume before mounting it in the final destination. Enable this container by setting the `volumePermissions.enabled` parameter to `true`. ## Parameters @@ -330,100 +414,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/cassa > 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/cassandra/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. - -### Enable TLS - -This chart supports TLS between client and server and between nodes, as explained below: - -- For internode cluster encryption, set the `tls.internodeEncryption` chart parameter to a value different from `none`. Available values are `all`, `dc` or `rack`. -- For client-server encryption, set the `tls.clientEncryption` chart parameter to `true`. - -In both cases, it is also necessary to create a secret containing the keystore and truststore certificates and their corresponding protection passwords. This secret is to be passed to the chart via the `tls.existingSecret` parameter at deployment-time, as shown below: - -```text -tls.internodeEncryption=all -tls.clientEncryption=true -tls.existingSecret=my-exisiting-stores -tls.passwordsSecret=my-stores-password -``` - -> TIP: The secret may be created in the standard way with the `--from-file=./keystore`, `--from-file=./truststore`, `--from-literal=keystore-password=KEYSTORE_PASSWORD` and `--from-literal=truststore-password=TRUSTSTORE_PASSWORD` options. This assumes that the stores are in the current working directory and the KEYSTORE_PASSWORD and TRUSTSTORE_PASSWORD placeholders are replaced with the correct keystore and truststore passwords respectively. Example: - -```console -kubectl create secret generic my-exisiting-stores --from-file=./keystore --from-file=./truststore -kubectl create secret generic my-stores-password --from-literal=keystore-password=KEYSTORE_PASSWORD --from-literal=truststore-password=TRUSTSTORE_PASSWORD -``` - -Keystore and Truststore files can be dinamycally created from the certificates files. In this case a secret with the tls.crt, tls.key and ca.crt in pem format is required. The following example shows how the secret can be created and assumes that all certificate files are in the working directory: - -```console -kubectl create secret tls my-certs --cert ./tls.crt --key ./tls.key -kubectl patch secret my-certs -p="{\"data\":{\"ca.crt\": \"$(cat ./ca.crt | base64 )\"}}" -``` - -To enable this feature `tls.autoGenerated` must be set and the new secret should be set in `tls.certificateSecret`: - -```text -tls.internodeEncryption=all -tls.clientEncryption=true -tls.autoGenerated=true -tls.certificatesSecret=my-certs -tls.passwordsSecret=my-stores-password -``` - -### Initialize the database - -The [Apache Cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image supports the use of custom scripts to initialize a fresh instance. This may be done by creating a Kubernetes ConfigMap that includes the necessary `.sh` or `.cql` scripts and passing this ConfigMap to the chart via the `initDBConfigMap` parameter. - -### Use a custom configuration file - -This chart also supports mounting custom configuration file(s) for Apache Cassandra. This is achieved by setting the `existingConfiguration` parameter with the name of a ConfigMap that includes the custom configuration file(s). Here is an example of deploying the chart with a custom configuration file stored in a ConfigMap named `cassandra-configuration`: - -```text -existingConfiguration=cassandra-configuration -``` - -> NOTE: This ConfigMap will override other Apache Cassandra configuration variables set in the chart. - -### Set pod affinity - -This chart allows you to set custom pod affinity using the `XXX.affinity` parameter(s). Find more information about pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -## Persistence - -The [Bitnami Apache Cassandra](https://github.com/bitnami/containers/tree/main/bitnami/cassandra) image stores the Apache Cassandra data at the `/bitnami/cassandra` 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. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. There are two approaches to achieve this: - -- Use Kubernetes SecurityContexts by setting the `podSecurityContext.enabled` and `containerSecurityContext.enabled` to `true`. This option is enabled by default in the chart. However, this feature does not work in all Kubernetes distributions. -- Use an init container to change the ownership of the volume before mounting it in the final destination. Enable this container by setting the `volumePermissions.enabled` parameter to `true`. - -## Backup and restore - -Refer to our detailed tutorial on [backing up and restoring Bitnami Apache Cassandra deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-cassandra-kubernetes/). - ## 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). diff --git a/bitnami/cert-manager/README.md b/bitnami/cert-manager/README.md index 507befefc4..e58be2b07d 100644 --- a/bitnami/cert-manager/README.md +++ b/bitnami/cert-manager/README.md @@ -41,15 +41,224 @@ helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/cert-manager > 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**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` helm release: +### Resource requests and limits -```console -helm uninstall my-release +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. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the cert-manager app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Generate TLS certificates using Self Signed Issuers + +Cert Manager supports issuing certificates through different Issuers. For instance, you can use a Self Signed Issuer to issue the certificates. + +The Self Signed issuer doesn't represent a certificate authority as such, but instead denotes that certificates will "sign themselves" using a given private key. + +> NOTE: Find the list of available Issuers in the [Cert Manager official documentation](https://cert-manager.io/docs/configuration/#supported-issuer-types). + +To configure Cert Manager, create an Issuer object. The structure of this object differs depending on the Issuer type. Self Signed issuer are really easy to configure. + +To create a self signed issuer to generate a self signed certificate, declare an Issuer, a ClusterIssuer and a Certificate, as shown below: + +```yaml +apiVersion: cert-manager.io/v1 +kind: ClusterIssuer +metadata: + name: letsencrypt-prod +spec: + selfSigned: {} +--- +apiVersion: cert-manager.io/v1 +kind: Issuer +metadata: + name: letsencrypt-ca + namespace: sandbox +spec: + ca: + secretName: letsencrypt-ca +--- +apiVersion: cert-manager.io/v1 +kind: Certificate +metadata: + name: letsencrypt-ca + namespace: sandbox +spec: + isCA: true + commonName: osm-system + secretName: letsencrypt-ca + issuerRef: + name: letsencrypt-prod + kind: ClusterIssuer + group: cert-manager.io +``` + +Next, use the ClusterIssuer to generate certificates for the applications in your Kubernetes cluster. [Learn how to secure your Ingress resources](#secure-ingress-resources-with-cert-manager). + +After the Ingress resource is ready, Cert Manager will create a secret. This secret contains the generated TLS certificate. This can be checked as shown below: + +```text +$ kubectl get secret --namespace=sandbox +NAME TYPE DATA AGE +letsencrypt-ca kubernetes.io/tls 3 Xs +``` + +### Generate TLS certificates using ACME Issuers + +Cert Manager supports issuing certificates through different Issuers. For instance, you can use a public ACME (Automated Certificate Management Environment) server to issue the certificates. + +> NOTE: Find the list of available Issuers in the [Cert Manager official documentation](https://cert-manager.io/docs/configuration/#supported-issuer-types). + +To configure Cert Manager, create an Issuer object. The structure of this object differs depending on the Issuer type. For ACME, it is necessary to include the information for a single account registered in the ACME Certificate Authority server. + +Once Cert Manager is configured to use ACME, it will verify that you are the owner of the domains for which certificates are being requested. Cert Manager uses two different challenges to verify that you are the owner of your domain: HTTP01 or DNS01. [Learn more about ACME challenges](https://cert-manager.io/docs/concepts/acme-orders-challenges/#challenge-scheduling). + +> NOTE: Learn more about the process to solve challenges in the [official documentation](https://cert-manager.io/docs/configuration/acme/#solving-challenges). + +To create a ACME issuer for use with Let's Encrypt, declare an Issuer as shown below: + +```yaml +apiVersion: cert-manager.io/v1alpha2 +kind: ClusterIssuer +metadata: + name: letsencrypt-prod +spec: + acme: + # You must replace this email address with your own. + # Let's Encrypt will use this to contact you about expiring + # certificates, and issues related to your account. + # Replace the EMAIL-ADDRESS placeholder with the correct email account + email: EMAIL-ADDRESS + server: https://acme-v02.api.letsencrypt.org/directory + privateKeySecretRef: + name: letsencrypt-prod + # Add a single challenge solver, HTTP01 using nginx + solvers: + - http01: + ingress: + class: nginx +``` + +Next, use the ClusterIssuer to generate certificates for the applications in your Kubernetes cluster. [Learn how to secure your Ingress resources](#secure-ingress-resources-with-cert-manager). + +After the Ingress resource is ready, Cert Manager verifies the domain using HTTP01/DNS01 challenges. During this verification process, the controller log can be used to check the status, as shown below: + +```text +$ kubectl get certificates +NAME READY SECRET AGE +letencrypt-ca False letencrypt-ca X +``` + +The status remains *False* whilst verification is in progress. This status will change to *True* when the HTTP01 verification is completed successfully. + +```text +$ kubectl get certificates +NAME READY SECRET AGE +letencrypt-ca True letencrypt-ca X + +$ kubectl get secrets +NAME TYPE DATA AGE +letencrypt-ca kubernetes.io/tls 3 Xm +``` + +### Secure Ingress resources with Cert Manager + +Once you configure an Issuer for Cert Manager (either [a Self-Signed Issuer](#generate-tls-certificates-using-self-signed-issuers) or [an ACME Issuer](#generate-tls-certificates-using-acme-issuers)), Cert Manager will make use of this Issuer to create a TLS secret containing the certificates. Cert Manager can only create this secret if the application is already exposed. One way to do this is with an Ingress Resource which exposes the application and includes the corresponding annotations for Cert Manager. + +There are two options to expose your application through an Ingress Controller using Cert Manager to manage the TLS certificates: + +- Deploy another Helm chart which supports exposing the application through an Ingress controller. For instance, use the [Bitnami Helm Chart for WordPress](https://github.com/bitnami/charts/tree/main/bitnami/wordpress) and [configure Ingress for WordPress](https://github.com/bitnami/charts/tree/main/bitnami/wordpress#ingress). To enable the integration with CertManager, add the annotations below to the *ingress.annotations* parameter: + + ```text + # Set up your ingress.class below (in this example, we are using nginx ingress controller) + kubernetes.io/ingress.class: nginx + cert-manager.io/cluster-issuer: letsencrypt-prod + ``` + +- Create your own Ingress resource as shown in the example below: + + ```yaml + apiVersion: networking.k8s.io/v1 + kind: Ingress + metadata: + name: ingress-test + annotations: + # Set up your ingress.class below (in this example, we are using nginx ingress controller) + kubernetes.io/ingress.class: "nginx" + cert-manager.io/issuer: "letsencrypt-prod" + spec: + tls: + # Replace the DOMAIN placeholder with the correct domain name + - hosts: + - DOMAIN + secretName: letsencrypt-ca + rules: + # Replace the DOMAIN placeholder with the correct domain name + - host: DOMAIN + http: + paths: + - path: / + pathType: Exact + backend: + service: + name: ingress-test + port: + number: 80 + ``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `controller.affinity`, `cainjector.affinity` or `webhook.affinity` parameters. 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 make 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 `controller.podAffinityPreset`, `cainjector.podAffinityPreset`, `webhook.podAffinityPreset`, `controller.podAntiAffinityPreset`, `cainjector.podAntiAffinityPreset`, `webhook.podAntiAffinityPreset`, `controller.nodeAffinityPreset`, `cainjector.nodeAffinityPreset` or `webhook.nodeAffinityPreset` parameters. ## Parameters @@ -399,225 +608,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/cert- > 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/cert-manager/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. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the cert-manager app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Generate TLS certificates using Self Signed Issuers - -Cert Manager supports issuing certificates through different Issuers. For instance, you can use a Self Signed Issuer to issue the certificates. - -The Self Signed issuer doesn't represent a certificate authority as such, but instead denotes that certificates will "sign themselves" using a given private key. - -> NOTE: Find the list of available Issuers in the [Cert Manager official documentation](https://cert-manager.io/docs/configuration/#supported-issuer-types). - -To configure Cert Manager, create an Issuer object. The structure of this object differs depending on the Issuer type. Self Signed issuer are really easy to configure. - -To create a self signed issuer to generate a self signed certificate, declare an Issuer, a ClusterIssuer and a Certificate, as shown below: - -```yaml -apiVersion: cert-manager.io/v1 -kind: ClusterIssuer -metadata: - name: letsencrypt-prod -spec: - selfSigned: {} ---- -apiVersion: cert-manager.io/v1 -kind: Issuer -metadata: - name: letsencrypt-ca - namespace: sandbox -spec: - ca: - secretName: letsencrypt-ca ---- -apiVersion: cert-manager.io/v1 -kind: Certificate -metadata: - name: letsencrypt-ca - namespace: sandbox -spec: - isCA: true - commonName: osm-system - secretName: letsencrypt-ca - issuerRef: - name: letsencrypt-prod - kind: ClusterIssuer - group: cert-manager.io -``` - -Next, use the ClusterIssuer to generate certificates for the applications in your Kubernetes cluster. [Learn how to secure your Ingress resources](#secure-ingress-resources-with-cert-manager). - -After the Ingress resource is ready, Cert Manager will create a secret. This secret contains the generated TLS certificate. This can be checked as shown below: - -```text -$ kubectl get secret --namespace=sandbox -NAME TYPE DATA AGE -letsencrypt-ca kubernetes.io/tls 3 Xs -``` - -### Generate TLS certificates using ACME Issuers - -Cert Manager supports issuing certificates through different Issuers. For instance, you can use a public ACME (Automated Certificate Management Environment) server to issue the certificates. - -> NOTE: Find the list of available Issuers in the [Cert Manager official documentation](https://cert-manager.io/docs/configuration/#supported-issuer-types). - -To configure Cert Manager, create an Issuer object. The structure of this object differs depending on the Issuer type. For ACME, it is necessary to include the information for a single account registered in the ACME Certificate Authority server. - -Once Cert Manager is configured to use ACME, it will verify that you are the owner of the domains for which certificates are being requested. Cert Manager uses two different challenges to verify that you are the owner of your domain: HTTP01 or DNS01. [Learn more about ACME challenges](https://cert-manager.io/docs/concepts/acme-orders-challenges/#challenge-scheduling). - -> NOTE: Learn more about the process to solve challenges in the [official documentation](https://cert-manager.io/docs/configuration/acme/#solving-challenges). - -To create a ACME issuer for use with Let's Encrypt, declare an Issuer as shown below: - -```yaml -apiVersion: cert-manager.io/v1alpha2 -kind: ClusterIssuer -metadata: - name: letsencrypt-prod -spec: - acme: - # You must replace this email address with your own. - # Let's Encrypt will use this to contact you about expiring - # certificates, and issues related to your account. - # Replace the EMAIL-ADDRESS placeholder with the correct email account - email: EMAIL-ADDRESS - server: https://acme-v02.api.letsencrypt.org/directory - privateKeySecretRef: - name: letsencrypt-prod - # Add a single challenge solver, HTTP01 using nginx - solvers: - - http01: - ingress: - class: nginx -``` - -Next, use the ClusterIssuer to generate certificates for the applications in your Kubernetes cluster. [Learn how to secure your Ingress resources](#secure-ingress-resources-with-cert-manager). - -After the Ingress resource is ready, Cert Manager verifies the domain using HTTP01/DNS01 challenges. During this verification process, the controller log can be used to check the status, as shown below: - -```text -$ kubectl get certificates -NAME READY SECRET AGE -letencrypt-ca False letencrypt-ca X -``` - -The status remains *False* whilst verification is in progress. This status will change to *True* when the HTTP01 verification is completed successfully. - -```text -$ kubectl get certificates -NAME READY SECRET AGE -letencrypt-ca True letencrypt-ca X - -$ kubectl get secrets -NAME TYPE DATA AGE -letencrypt-ca kubernetes.io/tls 3 Xm -``` - -### Secure Ingress resources with Cert Manager - -Once you configure an Issuer for Cert Manager (either [a Self-Signed Issuer](#generate-tls-certificates-using-self-signed-issuers) or [an ACME Issuer](#generate-tls-certificates-using-acme-issuers)), Cert Manager will make use of this Issuer to create a TLS secret containing the certificates. Cert Manager can only create this secret if the application is already exposed. One way to do this is with an Ingress Resource which exposes the application and includes the corresponding annotations for Cert Manager. - -There are two options to expose your application through an Ingress Controller using Cert Manager to manage the TLS certificates: - -- Deploy another Helm chart which supports exposing the application through an Ingress controller. For instance, use the [Bitnami Helm Chart for WordPress](https://github.com/bitnami/charts/tree/main/bitnami/wordpress) and [configure Ingress for WordPress](https://github.com/bitnami/charts/tree/main/bitnami/wordpress#ingress). To enable the integration with CertManager, add the annotations below to the *ingress.annotations* parameter: - - ```text - # Set up your ingress.class below (in this example, we are using nginx ingress controller) - kubernetes.io/ingress.class: nginx - cert-manager.io/cluster-issuer: letsencrypt-prod - ``` - -- Create your own Ingress resource as shown in the example below: - - ```yaml - apiVersion: networking.k8s.io/v1 - kind: Ingress - metadata: - name: ingress-test - annotations: - # Set up your ingress.class below (in this example, we are using nginx ingress controller) - kubernetes.io/ingress.class: "nginx" - cert-manager.io/issuer: "letsencrypt-prod" - spec: - tls: - # Replace the DOMAIN placeholder with the correct domain name - - hosts: - - DOMAIN - secretName: letsencrypt-ca - rules: - # Replace the DOMAIN placeholder with the correct domain name - - host: DOMAIN - http: - paths: - - path: / - pathType: Exact - backend: - service: - name: ingress-test - port: - number: 80 - ``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `controller.affinity`, `cainjector.affinity` or `webhook.affinity` parameters. 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 make 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 `controller.podAffinityPreset`, `cainjector.podAffinityPreset`, `webhook.podAffinityPreset`, `controller.podAntiAffinityPreset`, `cainjector.podAntiAffinityPreset`, `webhook.podAntiAffinityPreset`, `controller.nodeAffinityPreset`, `cainjector.nodeAffinityPreset` or `webhook.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/clickhouse/README.md b/bitnami/clickhouse/README.md index 2d5735b9d6..caecae708a 100644 --- a/bitnami/clickhouse/README.md +++ b/bitnami/clickhouse/README.md @@ -49,15 +49,202 @@ The command deploys ClickHouse on the Kubernetes cluster in the default configur > **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. + +### ClickHouse keeper support + +You can set `keeper.enabled` to use ClickHouse keeper. If `keeper.enabled=true`, Zookeeper settings will not be ignore. + +### External Zookeeper support + +You may want to have ClickHouse connect to an external zookeeper rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalZookeeper` parameter](#parameters). You should also disable the Zookeeper installation with the `zookeeper.enabled` option. Here is an example: ```console -helm delete my-release +zookeper.enabled=false +externalZookeeper.host=myexternalhost +externalZookeeper.user=myuser +externalZookeeper.password=mypassword +externalZookeeper.database=mydatabase +externalZookeeper.port=3306 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Ingress without TLS + +For using ingress (example without TLS): + +```yaml +ingress: + ## If true, ClickHouse server Ingress will be created + ## + enabled: true + + ## ClickHouse server Ingress annotations + ## + annotations: {} + # kubernetes.io/ingress.class: nginx + # kubernetes.io/tls-acme: 'true' + + ## ClickHouse server Ingress hostnames + ## Must be provided if Ingress is enabled + ## + hosts: + - clickhouse.domain.com +``` + +### Ingress TLS + +If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. + +To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `clickhouse-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: + +```yaml +ingress: + ## If true, ClickHouse server Ingress will be created + ## + enabled: true + + ## ClickHouse server Ingress annotations + ## + annotations: {} + # kubernetes.io/ingress.class: nginx + # kubernetes.io/tls-acme: 'true' + + ## ClickHouse server Ingress hostnames + ## Must be provided if Ingress is enabled + ## + hosts: + - clickhouse.domain.com + + ## ClickHouse server Ingress TLS configuration + ## Secrets must be manually created in the namespace + ## + tls: + - secretName: clickhouse-server-tls + hosts: + - clickhouse.domain.com +``` + +### TLS secrets + +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +clickhouse: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as ClickHouse (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +### Using custom scripts + +For advanced operations, the Bitnami ClickHouse chart allows using custom init and start scripts that will be mounted in `/docker-entrypoint.initdb.d` and `/docker-entrypoint.startdb.d` . The `init` scripts will be run on the first boot whereas the `start` scripts will be run on every container start. For adding the scripts directly as values use the `initdbScripts` and `startdbScripts` values. For using Secrets use the `initdbScriptsSecret` and `startdbScriptsSecret`. + +```yaml +initdbScriptsSecret: init-scripts-secret +startdbScriptsSecret: start-scripts-secret +``` + +### Pod affinity + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 ClickHouse](https://github.com/bitnami/containers/tree/main/bitnami/clickhouse) image stores the ClickHouse data and configurations at the `/bitnami` 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. ## Parameters @@ -400,203 +587,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/click > 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/clickhouse/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. - -### ClickHouse keeper support - -You can set `keeper.enabled` to use ClickHouse keeper. If `keeper.enabled=true`, Zookeeper settings will not be ignore. - -### External Zookeeper support - -You may want to have ClickHouse connect to an external zookeeper rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalZookeeper` parameter](#parameters). You should also disable the Zookeeper installation with the `zookeeper.enabled` option. Here is an example: - -```console -zookeper.enabled=false -externalZookeeper.host=myexternalhost -externalZookeeper.user=myuser -externalZookeeper.password=mypassword -externalZookeeper.database=mydatabase -externalZookeeper.port=3306 -``` - -### TLS secrets - -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 - -The [Bitnami ClickHouse](https://github.com/bitnami/containers/tree/main/bitnami/clickhouse) image stores the ClickHouse data and configurations at the `/bitnami` 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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -clickhouse: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as ClickHouse (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -### Ingress without TLS - -For using ingress (example without TLS): - -```yaml -ingress: - ## If true, ClickHouse server Ingress will be created - ## - enabled: true - - ## ClickHouse server Ingress annotations - ## - annotations: {} - # kubernetes.io/ingress.class: nginx - # kubernetes.io/tls-acme: 'true' - - ## ClickHouse server Ingress hostnames - ## Must be provided if Ingress is enabled - ## - hosts: - - clickhouse.domain.com -``` - -### Ingress TLS - -If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. - -To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `clickhouse-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: - -```yaml -ingress: - ## If true, ClickHouse server Ingress will be created - ## - enabled: true - - ## ClickHouse server Ingress annotations - ## - annotations: {} - # kubernetes.io/ingress.class: nginx - # kubernetes.io/tls-acme: 'true' - - ## ClickHouse server Ingress hostnames - ## Must be provided if Ingress is enabled - ## - hosts: - - clickhouse.domain.com - - ## ClickHouse server Ingress TLS configuration - ## Secrets must be manually created in the namespace - ## - tls: - - secretName: clickhouse-server-tls - hosts: - - clickhouse.domain.com -``` - -### Using custom scripts - -For advanced operations, the Bitnami ClickHouse chart allows using custom init and start scripts that will be mounted in `/docker-entrypoint.initdb.d` and `/docker-entrypoint.startdb.d` . The `init` scripts will be run on the first boot whereas the `start` scripts will be run on every container start. For adding the scripts directly as values use the `initdbScripts` and `startdbScripts` values. For using Secrets use the `initdbScriptsSecret` and `startdbScriptsSecret`. - -```yaml -initdbScriptsSecret: init-scripts-secret -startdbScriptsSecret: start-scripts-secret -``` - -### Pod affinity - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/concourse/README.md b/bitnami/concourse/README.md index 8aadc03361..1e05a1917c 100644 --- a/bitnami/concourse/README.md +++ b/bitnami/concourse/README.md @@ -43,15 +43,146 @@ The command deploys concourse on the Kubernetes cluster in the default configura > **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 -```console -helm delete my-release +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. + +### Use an external database + +Sometimes, you may want to have Concourse connect to an external database rather than a database within your cluster - for example, when using a managed database service, or when running a single database server for all your applications. To do this, set the `postgresql.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: + +```text +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=5432 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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/). + +### Configure TLS Secrets for use with 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`. + +### Configure extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG +``` + +Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Configure Sidecars and Init Containers + +If additional containers are needed in the same pod as Concourse (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +### Set Pod affinity + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 Concourse](https://github.com/bitnami/containers/tree/main/bitnami/concourse) image stores the concourse data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. ## Parameters @@ -458,147 +589,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/conco > 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/concourse/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. - -### Use an external database - -Sometimes, you may want to have Concourse connect to an external database rather than a database within your cluster - for example, when using a managed database service, or when running a single database server for all your applications. To do this, set the `postgresql.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: - -```text -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=5432 -``` - -### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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/). - -### Configure TLS Secrets for use with 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 - -The [Bitnami Concourse](https://github.com/bitnami/containers/tree/main/bitnami/concourse) image stores the concourse data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -### Configure extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Configure Sidecars and Init Containers - -If additional containers are needed in the same pod as Concourse (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/consul/README.md b/bitnami/consul/README.md index 8944dde59c..4ecfdf43d4 100644 --- a/bitnami/consul/README.md +++ b/bitnami/consul/README.md @@ -42,20 +42,161 @@ These commands deploy HashiCorp Consul on the Kubernetes cluster in the default > **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. + +### Using custom configuration + +This helm chart supports to customize the whole configuration file. + +You can specify the Hashicorp Consul configuration using the `configuration` parameter. + +In addition to this option, you can also set an external ConfigMap with all the configuration files. This is done by setting the `existingConfigmap` parameter. Note that this will override the previous option. + +### 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. + +To enable ingress integration, please set `ingress.enabled` to `true`. + +#### Hosts + +Most likely you will only want to have one hostname that maps to this ASP.NET Core installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. + +### TLS Secrets + +This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are three common use cases: + +- Helm generates/manages certificate secrets +- User generates/manages certificates separately +- An additional tool (like cert-manager) manages the secrets for the application + +In the first two cases, one will need a certificate and a key. We would expect them to look like this: + +- certificate files should look like (and there can be more than one certificate if there is a certificate chain) ```console -helm delete my-release +-----BEGIN CERTIFICATE----- +MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV +... +jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 +-----END CERTIFICATE----- ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Remove also the chart using `--purge` option: +- keys should look like: ```console -helm delete --purge my-release +-----BEGIN RSA PRIVATE KEY----- +MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 +... +wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= +-----END RSA PRIVATE KEY----- ``` +If you are going to use Helm to manage the certificates, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. + +If you are going to manage TLS secrets outside of Helm, please know that you can create a TLS secret (named `consul-ui.local-tls` for example). + +Please see [this example](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples/tls) for more information. + +#### Enable TLS encryption between servers + +You must manually create a secret containing your PEM-encoded certificate authority, your PEM-encoded certificate, and your PEM-encoded private key. + +> Take into account that you will need to create a config map with the proper configuration. + +If the secret is specified, the chart will locate those files at `/opt/bitnami/consul/certs/`, so you will want to use the below snippet to configure HashiCorp Consul TLS encryption in your config map: + +```json + "ca_file": "/opt/bitnami/consul/certs/ca.pem", + "cert_file": "/opt/bitnami/consul/certs/consul.pem", + "key_file": "/opt/bitnami/consul/certs/consul-key.pem", + "verify_incoming": true, + "verify_outgoing": true, + "verify_server_hostname": true, +``` + +After creating the secret, you can install the helm chart specyfing the secret name using `tlsEncryptionSecretName=consul-tls-encryption`. + +### Metrics + +The chart can optionally start a metrics exporter endpoint on port `9107` for [prometheus](https://prometheus.io). The data exposed by the endpoint is intended to be consumed by a prometheus chart deployed within the cluster and as such the endpoint is not exposed outside the cluster. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `.extraEnvVarsCM` or the `extraEnvVarsSecret` properties. + +### 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. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as MongoDB®, you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +## Persistence + +The [Bitnami HashiCorp Consul](https://github.com/bitnami/containers/tree/main/bitnami/consul) image stores the HashiCorp Consul data at the `/bitnami` 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. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + ## Parameters ### Global parameters @@ -307,161 +448,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/consu > 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/consul/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. - -### Using custom configuration - -This helm chart supports to customize the whole configuration file. - -You can specify the Hashicorp Consul configuration using the `configuration` parameter. - -In addition to this option, you can also set an external ConfigMap with all the configuration files. This is done by setting the `existingConfigmap` parameter. Note that this will override the previous option. - -### 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. - -To enable ingress integration, please set `ingress.enabled` to `true`. - -#### Hosts - -Most likely you will only want to have one hostname that maps to this ASP.NET Core installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. - -### TLS Secrets - -This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are three common use cases: - -- Helm generates/manages certificate secrets -- User generates/manages certificates separately -- An additional tool (like cert-manager) manages the secrets for the application - -In the first two cases, one will need a certificate and a key. We would expect them to look like this: - -- certificate files should look like (and there can be more than one certificate if there is a certificate chain) - -```console ------BEGIN CERTIFICATE----- -MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV -... -jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 ------END CERTIFICATE----- -``` - -- keys should look like: - -```console ------BEGIN RSA PRIVATE KEY----- -MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 -... -wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= ------END RSA PRIVATE KEY----- -``` - -If you are going to use Helm to manage the certificates, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. - -If you are going to manage TLS secrets outside of Helm, please know that you can create a TLS secret (named `consul-ui.local-tls` for example). - -Please see [this example](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples/tls) for more information. - -#### Enable TLS encryption between servers - -You must manually create a secret containing your PEM-encoded certificate authority, your PEM-encoded certificate, and your PEM-encoded private key. - -> Take into account that you will need to create a config map with the proper configuration. - -If the secret is specified, the chart will locate those files at `/opt/bitnami/consul/certs/`, so you will want to use the below snippet to configure HashiCorp Consul TLS encryption in your config map: - -```json - "ca_file": "/opt/bitnami/consul/certs/ca.pem", - "cert_file": "/opt/bitnami/consul/certs/consul.pem", - "key_file": "/opt/bitnami/consul/certs/consul-key.pem", - "verify_incoming": true, - "verify_outgoing": true, - "verify_server_hostname": true, -``` - -After creating the secret, you can install the helm chart specyfing the secret name using `tlsEncryptionSecretName=consul-tls-encryption`. - -### Metrics - -The chart can optionally start a metrics exporter endpoint on port `9107` for [prometheus](https://prometheus.io). The data exposed by the endpoint is intended to be consumed by a prometheus chart deployed within the cluster and as such the endpoint is not exposed outside the cluster. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `.extraEnvVarsCM` or the `extraEnvVarsSecret` properties. - -### 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. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as MongoDB®, you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -## Persistence - -The [Bitnami HashiCorp Consul](https://github.com/bitnami/containers/tree/main/bitnami/consul) image stores the HashiCorp Consul data at the `/bitnami` 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. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/contour/README.md b/bitnami/contour/README.md index e116122def..ad61941723 100644 --- a/bitnami/contour/README.md +++ b/bitnami/contour/README.md @@ -44,20 +44,122 @@ These commands deploy contour on the Kubernetes cluster in the default configura > **Tip**: List all releases using `helm list` or `helm ls --all-namespaces` -## Uninstalling the Chart +## Configuration and installation details -:warning: Uninstalling this chart will also remove CRDs. Removing CRDs will **remove all instances of it's Custom Resources**. If you wish to retain your Custom Resources for the future, run the following commands before uninstalling. +### Resource requests and limits -```console -kubectl get -o yaml extensionservice,httpproxy,tlscertificatedelegation -A > backup.yaml +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. + +To configure [Contour](https://projectcontour.io) please look into the configuration section [Contour Configuration](https://projectcontour.io/docs/main/configuration/). + +### Example Quickstart Contour Confiuration + +```yaml +configInline: + # should contour expect to be running inside a k8s cluster + # incluster: true + # + # path to kubeconfig (if not running inside a k8s cluster) + # kubeconfig: /path/to/.kube/config + # + # Client request timeout to be passed to Envoy + # as the connection manager request_timeout. + # Defaults to 0, which Envoy interprets as disabled. + # Note that this is the timeout for the whole request, + # not an idle timeout. + # request-timeout: 0s + # disable ingressroute permitInsecure field + disablePermitInsecure: false + tls: + # minimum TLS version that Contour will negotiate + # minimum-protocol-version: "1.1" + # Defines the Kubernetes name/namespace matching a secret to use + # as the fallback certificate when requests which don't match the + # SNI defined for a vhost. + fallback-certificate: + # name: fallback-secret-name + # namespace: projectcontour + # The following config shows the defaults for the leader election. + # leaderelection: + # configmap-name: leader-elect + # configmap-namespace: projectcontour + ### Logging options + # Default setting + accesslog-format: envoy + # To enable JSON logging in Envoy + # accesslog-format: json + # The default fields that will be logged are specified below. + # To customise this list, just add or remove entries. + # The canonical list is available at + # https://godoc.org/github.com/projectcontour/contour/internal/envoy#JSONFields + # json-fields: + # - "@timestamp" + # - "authority" + # - "bytes_received" + # - "bytes_sent" + # - "downstream_local_address" + # - "downstream_remote_address" + # - "duration" + # - "method" + # - "path" + # - "protocol" + # - "request_id" + # - "requested_server_name" + # - "response_code" + # - "response_flags" + # - "uber_trace_id" + # - "upstream_cluster" + # - "upstream_host" + # - "upstream_local_address" + # - "upstream_service_time" + # - "user_agent" + # - "x_forwarded_for" + # + # default-http-versions: + # - "HTTP/2" + # - "HTTP/1.1" + # + # The following shows the default proxy timeout settings. + # timeouts: + # request-timeout: infinity + # connection-idle-timeout: 60s + # stream-idle-timeout: 5m + # max-connection-duration: infinity + # connection-shutdown-grace-period: 5s ``` -To uninstall/delete the `my-release` helm release: +### Deploying Contour with an AWS NLB -```console -helm uninstall my-release +By default, Contour is launched with an AWS Classic ELB. To launch contour backed by a NLB, please set [these settings](https://github.com/projectcontour/contour/tree/master/examples/contour#deploying-with-host-networking-enabled-for-envoy): + +```yaml +envoy: + service: + annotations: + service.beta.kubernetes.io/aws-load-balancer-type: nlb + service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https" + service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600" + service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm: arn:aws:acm:XX-XXXX-X:XXXXXXXXX:certificate/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX + + containerPorts: + http: 80 + https: 80 ``` +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + ## Parameters ### Global parameters @@ -558,122 +660,6 @@ helm install my-release \ The above command sets the `envoy.readinessProbe.successThreshold` to `5`. -## 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. - -To configure [Contour](https://projectcontour.io) please look into the configuration section [Contour Configuration](https://projectcontour.io/docs/main/configuration/). - -### Example Quickstart Contour Confiuration - -```yaml -configInline: - # should contour expect to be running inside a k8s cluster - # incluster: true - # - # path to kubeconfig (if not running inside a k8s cluster) - # kubeconfig: /path/to/.kube/config - # - # Client request timeout to be passed to Envoy - # as the connection manager request_timeout. - # Defaults to 0, which Envoy interprets as disabled. - # Note that this is the timeout for the whole request, - # not an idle timeout. - # request-timeout: 0s - # disable ingressroute permitInsecure field - disablePermitInsecure: false - tls: - # minimum TLS version that Contour will negotiate - # minimum-protocol-version: "1.1" - # Defines the Kubernetes name/namespace matching a secret to use - # as the fallback certificate when requests which don't match the - # SNI defined for a vhost. - fallback-certificate: - # name: fallback-secret-name - # namespace: projectcontour - # The following config shows the defaults for the leader election. - # leaderelection: - # configmap-name: leader-elect - # configmap-namespace: projectcontour - ### Logging options - # Default setting - accesslog-format: envoy - # To enable JSON logging in Envoy - # accesslog-format: json - # The default fields that will be logged are specified below. - # To customise this list, just add or remove entries. - # The canonical list is available at - # https://godoc.org/github.com/projectcontour/contour/internal/envoy#JSONFields - # json-fields: - # - "@timestamp" - # - "authority" - # - "bytes_received" - # - "bytes_sent" - # - "downstream_local_address" - # - "downstream_remote_address" - # - "duration" - # - "method" - # - "path" - # - "protocol" - # - "request_id" - # - "requested_server_name" - # - "response_code" - # - "response_flags" - # - "uber_trace_id" - # - "upstream_cluster" - # - "upstream_host" - # - "upstream_local_address" - # - "upstream_service_time" - # - "user_agent" - # - "x_forwarded_for" - # - # default-http-versions: - # - "HTTP/2" - # - "HTTP/1.1" - # - # The following shows the default proxy timeout settings. - # timeouts: - # request-timeout: infinity - # connection-idle-timeout: 60s - # stream-idle-timeout: 5m - # max-connection-duration: infinity - # connection-shutdown-grace-period: 5s -``` - -### Deploying Contour with an AWS NLB - -By default, Contour is launched with an AWS Classic ELB. To launch contour backed by a NLB, please set [these settings](https://github.com/projectcontour/contour/tree/master/examples/contour#deploying-with-host-networking-enabled-for-envoy): - -```yaml -envoy: - service: - annotations: - service.beta.kubernetes.io/aws-load-balancer-type: nlb - service.beta.kubernetes.io/aws-load-balancer-ssl-ports: "https" - service.beta.kubernetes.io/aws-load-balancer-connection-idle-timeout: "3600" - service.beta.kubernetes.io/aws-load-balancer-ssl-cert: arn:aws:acm: arn:aws:acm:XX-XXXX-X:XXXXXXXXX:certificate/XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXX - - containerPorts: - http: 80 - https: 80 -``` - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/deepspeed/README.md b/bitnami/deepspeed/README.md index 36be57e2ef..8a9cac443c 100644 --- a/bitnami/deepspeed/README.md +++ b/bitnami/deepspeed/README.md @@ -54,6 +54,125 @@ helm delete my-release The command removes all the Kubernetes components associated with the chart and deletes the release. +## 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. + +### Deploy as Job + +By default, the chart will deploy the client container (the one that connects to the Deepspeed workers) as a Deployment. This allows you to enter the container via `kubectl exec` and perform operations. In case you want to deploy it as a Kubernetes job, set the `client.useJob=true` value. + +### Loading your files + +The DeepSpeed chart supports three different ways to load your files. In order of priority, they are: + +1. Existing config map +2. Add files in the values.yaml +3. Cloning a git repository + +This means that if you specify a config map with your files, it won't check the files defined in `values.yaml` directory nor the git repository. + +In order to use an existing config map, set the `source.existingConfigMap=my-config-map` parameter. + +To add your files in the values.yaml file, set the `source.configmap` object with the files. + +Finally, if you want to clone a git repository you can use those parameters: + +```console +source.type=git +source.git.repository=https://github.com/my-user/oci://REGISTRY_NAME/REPOSITORY_NAME +source.git.revision=master +``` + +### 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. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `client`, `worker`. + +```yaml +client: + extraEnvVars: + - name: LOG_LEVEL + value: error + +worker: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as Milvus (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +## Persistence + +The [Bitnami DeepSpeed](https://github.com/bitnami/containers/tree/main/bitnami/deepspeed) image can persist data. If enabled, the persisted path is `/bitnami/deepspeed/data` by default. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + ## Parameters ### Global parameters @@ -370,124 +489,9 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/deeps > 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/deepspeed/values.yaml) -## Configuration and installation details +## Troubleshooting -### 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. - -### Deploy as Job - -By default, the chart will deploy the client container (the one that connects to the Deepspeed workers) as a Deployment. This allows you to enter the container via `kubectl exec` and perform operations. In case you want to deploy it as a Kubernetes job, set the `client.useJob=true` value. - -### Loading your files - -The DeepSpeed chart supports three different ways to load your files. In order of priority, they are: - -1. Existing config map -2. Add files in the values.yaml -3. Cloning a git repository - -This means that if you specify a config map with your files, it won't check the files defined in `values.yaml` directory nor the git repository. - -In order to use an existing config map, set the `source.existingConfigMap=my-config-map` parameter. - -To add your files in the values.yaml file, set the `source.configmap` object with the files. - -Finally, if you want to clone a git repository you can use those parameters: - -```console -source.type=git -source.git.repository=https://github.com/my-user/oci://REGISTRY_NAME/REPOSITORY_NAME -source.git.revision=master -``` - -## Persistence - -The [Bitnami DeepSpeed](https://github.com/bitnami/containers/tree/main/bitnami/deepspeed) image can persist data. If enabled, the persisted path is `/bitnami/deepspeed/data` by default. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### 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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `client`, `worker`. - -```yaml -client: - extraEnvVars: - - name: LOG_LEVEL - value: error - -worker: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as Milvus (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). +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). ## Upgrading @@ -500,10 +504,6 @@ This major bump changes the following security defaults: This could potentially break any customization or init scripts used in your deployment. If this is the case, change the default values to the previous ones. -## 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). - ## License Copyright © 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. diff --git a/bitnami/discourse/README.md b/bitnami/discourse/README.md index 4d8d378261..ecdfe7794d 100644 --- a/bitnami/discourse/README.md +++ b/bitnami/discourse/README.md @@ -45,15 +45,191 @@ The command deploys Discourse on the Kubernetes cluster in the default configura > **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 -```console -helm delete my-release +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. + +### Setting up replication + +By default, this Chart only deploys a single pod running Discourse. Should you want to increase the number of replicas, you may follow these simple steps to ensure everything works smoothly: + +> **Tip**: Running these steps ensures the PostgreSQL instance is correctly populated. If you already have an initialised DB, you may directly create a release with the desired number of replicas. Remind to set `discourse.skipInstall` to `true`! + +1. Create a conventional release, that will be scaled later: + + ```console + helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/discourse + ... + ``` + + > 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`. + +2. Wait for the release to complete and Discourse to be running successfully. + + ```console + $ kubectl get pods + NAME READY STATUS RESTARTS AGE + my-release-discourse-744c48dd97-wx5h9 2/2 Running 0 5m11s + my-release-postgresql-0 1/1 Running 0 5m10s + my-release-redis-master-0 1/1 Running 0 5m11s + ``` + +3. Perform an upgrade specifying the number of replicas and the credentials used. + + ```console + helm upgrade my-release --set replicaCount=2,discourse.skipInstall=true oci://REGISTRY_NAME/REPOSITORY_NAME/discourse + ``` + + > 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`. + + Note that for this to work properly, you need to provide ReadWriteMany PVCs. If you don't have a provisioner for this type of storage, we recommend that you install the NFS provisioner chart (with the correct parameters, such as `persistence.enabled=true` and `persistence.size=10Gi`) and map it to a RWO volume. + + Then you can deploy Discourse chart using the proper parameters: + + ```console + persistence.storageClass=nfs + postgresql.primary.persistence.storageClass=nfs + ``` + +### Installing plugins + +You can install custom Discourse plugins during the release installation listing the desired plugin repositories via the `discourse.plugins` parameter. For example: + +```yaml +discourse: + plugins: + - https://github.com/discourse/discourse-oauth2-basic ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +> Note: By default, plugins are persisted after the 1st installation, therefore it's not possible to update them on subsequent upgrades. If you want plugins to be updated on every upgrade, set the `discourse.persistPlugins` parameter to `false`. + +### Sidecars + +If you have a need for additional containers to run within the same pod as Discourse (e.g. metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +If these sidecars export extra ports, you can add extra port definitions using the `service.extraPorts` value: + +```yaml +service: +... + extraPorts: + - name: extraPort + port: 11311 + targetPort: 11311 +``` + +### Using an external database + +Sometimes you may want to have Discourse connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use run a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#parameters). You should also disable the PostgreSQL installation with the `postgresql.enabled` option. For example with the following parameters: + +```console +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.postgresUser=postgres +externalDatabase.postgresPassword=rootpassword +externalDatabase.database=mydatabase +externalDatabase.port=5432 +``` + +Note also that if you disable PostgreSQL per above you MUST supply values for the `externalDatabase` connection. + +In case the database already contains data from a previous Discourse installation, you need to set the `discourse.skipInstall` parameter to _true_. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. This parameter force the container to not execute the Discourse installation wizard. + +Similarly, you can specify an external Redis® instance rather than installing one inside your cluster. First, you may disable the Redis® installation with the `redis.enabled` option. As aforementioned, used the provided parameters to provide data about your instance: + +```console +redis.enabled=false +externalRedis.host=myexternalhost +externalRedis.password=mypassword +externalRedis.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. To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### 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 Discourse](https://github.com/bitnami/containers/tree/main/bitnami/discourse) image stores the Discourse data and configurations at the `/bitnami` 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. ## Parameters @@ -362,192 +538,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/disco > 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/discourse/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. - -### Setting up replication - -By default, this Chart only deploys a single pod running Discourse. Should you want to increase the number of replicas, you may follow these simple steps to ensure everything works smoothly: - -> **Tip**: Running these steps ensures the PostgreSQL instance is correctly populated. If you already have an initialised DB, you may directly create a release with the desired number of replicas. Remind to set `discourse.skipInstall` to `true`! - -1. Create a conventional release, that will be scaled later: - - ```console - helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/discourse - ... - ``` - - > 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`. - -2. Wait for the release to complete and Discourse to be running successfully. - - ```console - $ kubectl get pods - NAME READY STATUS RESTARTS AGE - my-release-discourse-744c48dd97-wx5h9 2/2 Running 0 5m11s - my-release-postgresql-0 1/1 Running 0 5m10s - my-release-redis-master-0 1/1 Running 0 5m11s - ``` - -3. Perform an upgrade specifying the number of replicas and the credentials used. - - ```console - helm upgrade my-release --set replicaCount=2,discourse.skipInstall=true oci://REGISTRY_NAME/REPOSITORY_NAME/discourse - ``` - - > 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`. - - Note that for this to work properly, you need to provide ReadWriteMany PVCs. If you don't have a provisioner for this type of storage, we recommend that you install the NFS provisioner chart (with the correct parameters, such as `persistence.enabled=true` and `persistence.size=10Gi`) and map it to a RWO volume. - - Then you can deploy Discourse chart using the proper parameters: - - ```console - persistence.storageClass=nfs - postgresql.primary.persistence.storageClass=nfs - ``` - -### Installing plugins - -You can install custom Discourse plugins during the release installation listing the desired plugin repositories via the `discourse.plugins` parameter. For example: - -```yaml -discourse: - plugins: - - https://github.com/discourse/discourse-oauth2-basic -``` - -> Note: By default, plugins are persisted after the 1st installation, therefore it's not possible to update them on subsequent upgrades. If you want plugins to be updated on every upgrade, set the `discourse.persistPlugins` parameter to `false`. - -### Sidecars - -If you have a need for additional containers to run within the same pod as Discourse (e.g. metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: -- name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -If these sidecars export extra ports, you can add extra port definitions using the `service.extraPorts` value: - -```yaml -service: -... - extraPorts: - - name: extraPort - port: 11311 - targetPort: 11311 -``` - -### Using an external database - -Sometimes you may want to have Discourse connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use run a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#parameters). You should also disable the PostgreSQL installation with the `postgresql.enabled` option. For example with the following parameters: - -```console -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.postgresUser=postgres -externalDatabase.postgresPassword=rootpassword -externalDatabase.database=mydatabase -externalDatabase.port=5432 -``` - -Note also that if you disable PostgreSQL per above you MUST supply values for the `externalDatabase` connection. - -In case the database already contains data from a previous Discourse installation, you need to set the `discourse.skipInstall` parameter to _true_. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. This parameter force the container to not execute the Discourse installation wizard. - -Similarly, you can specify an external Redis® instance rather than installing one inside your cluster. First, you may disable the Redis® installation with the `redis.enabled` option. As aforementioned, used the provided parameters to provide data about your instance: - -```console -redis.enabled=false -externalRedis.host=myexternalhost -externalRedis.password=mypassword -externalRedis.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. To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### 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 Discourse](https://github.com/bitnami/containers/tree/main/bitnami/discourse) image stores the Discourse data and configurations at the `/bitnami` 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. - ## 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). diff --git a/bitnami/dokuwiki/README.md b/bitnami/dokuwiki/README.md index d2140e6e3d..27a1b02249 100644 --- a/bitnami/dokuwiki/README.md +++ b/bitnami/dokuwiki/README.md @@ -43,15 +43,87 @@ The command deploys DokuWiki on the Kubernetes cluster in the default configurat > **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 -```console -helm delete my-release +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. + +### 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. + +### Certificates + +#### CA Certificates + +Custom CA certificates not included in the base docker image can be added with +the following configuration. The secret must exist in the same namespace as the +deployment. Will load all certificates files it finds in the secret. + +```yaml +certificates: + customCAs: + - secret: my-ca-1 + - secret: my-ca-2 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +##### CA Certificates secret + +Secret can be created with: + +```console +kubectl create secret generic my-ca-1 --from-file my-ca-1.crt +``` + +#### TLS Certificate + +A web server TLS Certificate can be injected into the container with the +following configuration. The certificate will be stored at the location +specified in the certificateLocation value. + +```yaml +certificates: + customCertificate: + certificateSecret: my-secret + certificateLocation: /ssl/server.pem + keyLocation: /ssl/key.pem + chainSecret: + name: my-cert-chain-secret + key: chain.pem +``` + +##### TLS secret + +The certificate tls secret can be created with: + +```console +kubectl create secret tls my-secret --cert tls.crt --key tls.key +``` + +The certificate chain is created with: + +```console +kubectl create secret generic my-ca-1 --from-file my-ca-1.crt +``` + +## Persistence + +The [Bitnami DokuWiki](https://github.com/bitnami/containers/tree/main/bitnami/dokuwiki) image stores the DokuWiki data and configurations at the `/bitnami/dokuwiki` path of the container. + +Persistent Volume Claims are used to keep the data across deployments. There is a [known issue](https://github.com/kubernetes/kubernetes/issues/39178) in Kubernetes Clusters with EBS in different availability zones. Ensure your cluster is configured properly to create Volumes in the same availability zone where the nodes are running. Kuberentes 1.12 solved this issue with the [Volume Binding Mode](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode). + +See the [Parameters](#parameters) section to configure the PVC or to disable persistence. ## Parameters @@ -277,88 +349,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/dokuw > 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/dokuwiki/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. - -### 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 DokuWiki](https://github.com/bitnami/containers/tree/main/bitnami/dokuwiki) image stores the DokuWiki data and configurations at the `/bitnami/dokuwiki` path of the container. - -Persistent Volume Claims are used to keep the data across deployments. There is a [known issue](https://github.com/kubernetes/kubernetes/issues/39178) in Kubernetes Clusters with EBS in different availability zones. Ensure your cluster is configured properly to create Volumes in the same availability zone where the nodes are running. Kuberentes 1.12 solved this issue with the [Volume Binding Mode](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode). - -See the [Parameters](#parameters) section to configure the PVC or to disable persistence. - -## Certificates - -### CA Certificates - -Custom CA certificates not included in the base docker image can be added with -the following configuration. The secret must exist in the same namespace as the -deployment. Will load all certificates files it finds in the secret. - -```yaml -certificates: - customCAs: - - secret: my-ca-1 - - secret: my-ca-2 -``` - -#### CA Certificates secret - -Secret can be created with: - -```console -kubectl create secret generic my-ca-1 --from-file my-ca-1.crt -``` - -### TLS Certificate - -A web server TLS Certificate can be injected into the container with the -following configuration. The certificate will be stored at the location -specified in the certificateLocation value. - -```yaml -certificates: - customCertificate: - certificateSecret: my-secret - certificateLocation: /ssl/server.pem - keyLocation: /ssl/key.pem - chainSecret: - name: my-cert-chain-secret - key: chain.pem -``` - -#### TLS secret - -The certificate tls secret can be created with: - -```console -kubectl create secret tls my-secret --cert tls.crt --key tls.key -``` - -The certificate chain is created with: - -```console -kubectl create secret generic my-ca-1 --from-file my-ca-1.crt -``` - ## 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). diff --git a/bitnami/drupal/README.md b/bitnami/drupal/README.md index 014f936402..4280bf3982 100644 --- a/bitnami/drupal/README.md +++ b/bitnami/drupal/README.md @@ -45,15 +45,83 @@ The command deploys Drupal on the Kubernetes cluster in the default configuratio > **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 Drupal](https://github.com/bitnami/containers/tree/main/bitnami/drupal) image stores the Drupal data and configurations at the `/bitnami/drupal` 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/drupal ``` -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/drupal + ``` + + > 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 `drupal-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 Drupal file directory permissions yourself and disable or clear Drupal cache. See Drupal Core's [INSTALL.txt](https://cgit.drupalcode.org/drupal/tree/core/INSTALL.txt?h=8.3.x#n152) for setting file permissions, and see [Drupal handbook page](https://www.drupal.org/node/2598914) to disable the cache, or [Drush handbook](https://drushcommands.com/drush-8x/cache/cache-rebuild/) to clear cache. ## Parameters @@ -347,84 +415,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/drupa > 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/drupal/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 Drupal](https://github.com/bitnami/containers/tree/main/bitnami/drupal) image stores the Drupal data and configurations at the `/bitnami/drupal` 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/drupal -``` - -> 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/drupal - ``` - - > 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 `drupal-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 Drupal file directory permissions yourself and disable or clear Drupal cache. See Drupal Core's [INSTALL.txt](https://cgit.drupalcode.org/drupal/tree/core/INSTALL.txt?h=8.3.x#n152) for setting file permissions, and see [Drupal handbook page](https://www.drupal.org/node/2598914) to disable the cache, or [Drush handbook](https://drushcommands.com/drush-8x/cache/cache-rebuild/) to clear cache. - ## 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). diff --git a/bitnami/ejbca/README.md b/bitnami/ejbca/README.md index aae1d982d7..c96459b39b 100644 --- a/bitnami/ejbca/README.md +++ b/bitnami/ejbca/README.md @@ -44,15 +44,100 @@ The command deploys EJBCA 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 -```console -helm delete my-release +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. + +### Set up replication + +By default, this chart only deploys a single pod running EJBCA. To increase the number of replicas, follow the steps below: + +1. Create a conventional release with only one replica. This will be scaled later. +2. Wait for the release to complete and for EJBCA to be running. Verify access to the main page of the application. +3. Perform an upgrade specifying the number of replicas and the credentials that were previously used. Set the parameters `replicaCount`, `ejbcaAdminPassword` and `mariadb.auth.password` accordingly. + +For example, for a release using `secretPassword` and `dbPassword` to scale up to a total of `2` replicas, the aforementioned parameters should hold these values `replicaCount=2`, `ejbcaAdminPassword=secretPassword`, `mariadb.auth.password=dbPassword`. + +> **Tip**: You can modify the file [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/ejbca/values.yaml) + +### Configure Sidecars and Init Containers + +If additional containers are needed in the same pod as EJBCA (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```yaml +sidecars: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +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/). + +### Use an external database + +Sometimes, you may want to have EJBCA connect to an external database rather than a database within your cluster - for example, when using a managed database service, or when running a single database server for all your applications. To do this, set the `mariadb.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: + +```text +mysql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=3306 +``` + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod 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. + +### Use a different EJBCA version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +## Persistence + +The [Bitnami EJBCA](https://github.com/bitnami/containers/tree/main/bitnami/discourse) image stores the EJBCA data and configurations at the `/bitnami` 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. ## Parameters @@ -274,101 +359,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/ejbca > 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/ejbca/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. - -### Set up replication - -By default, this chart only deploys a single pod running EJBCA. To increase the number of replicas, follow the steps below: - -1. Create a conventional release with only one replica. This will be scaled later. -2. Wait for the release to complete and for EJBCA to be running. Verify access to the main page of the application. -3. Perform an upgrade specifying the number of replicas and the credentials that were previously used. Set the parameters `replicaCount`, `ejbcaAdminPassword` and `mariadb.auth.password` accordingly. - -For example, for a release using `secretPassword` and `dbPassword` to scale up to a total of `2` replicas, the aforementioned parameters should hold these values `replicaCount=2`, `ejbcaAdminPassword=secretPassword`, `mariadb.auth.password=dbPassword`. - -> **Tip**: You can modify the file [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/ejbca/values.yaml) - -### Configure Sidecars and Init Containers - -If additional containers are needed in the same pod as EJBCA (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -### Use an external database - -Sometimes, you may want to have EJBCA connect to an external database rather than a database within your cluster - for example, when using a managed database service, or when running a single database server for all your applications. To do this, set the `mariadb.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: - -```text -mysql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=3306 -``` - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod 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. - -### Use a different EJBCA version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -## Persistence - -The [Bitnami EJBCA](https://github.com/bitnami/containers/tree/main/bitnami/discourse) image stores the EJBCA data and configurations at the `/bitnami` 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. - ## 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). diff --git a/bitnami/elasticsearch/README.md b/bitnami/elasticsearch/README.md index 731715a06e..b7ee8d1ce1 100644 --- a/bitnami/elasticsearch/README.md +++ b/bitnami/elasticsearch/README.md @@ -42,20 +42,200 @@ These commands deploy Elasticsearch on the Kubernetes cluster in the default con > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` release: +### Resource requests and limits -```console -helm delete my-release +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. + +### Change ElasticSearch version + +To modify the ElasticSearch version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/elasticsearch/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. + +### Default kernel settings + +Currently, Elasticsearch requires some changes in the kernel of the host machine to work as expected. If those values are not set in the underlying operating system, the ES containers fail to boot with ERROR messages. More information about these requirements can be found in the links below: + +- [File Descriptor requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html) +- [Virtual memory requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html) + +This chart uses a **privileged** initContainer to change those settings in the Kernel by running: `sysctl -w vm.max_map_count=262144 && sysctl -w fs.file-max=65536`. +You can disable the initContainer using the `sysctlImage.enabled=false` parameter. + +### Enable bundled Kibana + +This Elasticsearch chart contains Kibana as subchart, you can enable it just setting the `global.kibanaEnabled=true` parameter. +To see the notes with some operational instructions from the Kibana chart, please use the `--render-subchart-notes` as part of your `helm install` command, in this way you can see the Kibana and ES notes in your terminal. + +When enabling the bundled kibana subchart, there are a few gotchas that you should be aware of listed below. + +#### Elasticsearch rest Encryption + +When enabling elasticsearch' rest endpoint encryption you will also need to set `kibana.elasticsearch.security.tls.enabled` to the SAME value along with some additional values shown below for an "out of the box experience": + +```yaml +security: + enabled: true + # PASSWORD must be the same value passed to elasticsearch to get an "out of the box" experience + elasticPassword: "" + tls: + # AutoGenerate TLS certs for elastic + autoGenerated: true + +kibana: + elasticsearch: + security: + auth: + enabled: true + # default in the elasticsearch chart is elastic + kibanaUsername: "" + kibanaPassword: "" + tls: + # Instruct kibana to connect to elastic over https + enabled: true + # Bit of a catch 22, as you will need to know the name upfront of your release + existingSecret: RELEASENAME-elasticsearch-coordinating-crt # or just 'elasticsearch-coordinating-crt' if the release name happens to be 'elasticsearch' + # As the certs are auto-generated, they are pemCerts so set to true + usePemCerts: true ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Remove also the chart using `--purge` option: +At a bare-minimum, when working with kibana and elasticsearch together the following values MUST be the same, otherwise things will fail: + +```yaml +security: + tls: + restEncryption: true + +# assumes global.kibanaEnabled=true +kibana: + elasticsearch: + security: + tls: + enabled: true +``` + +### How to deploy a single node + +This chart allows you to deploy Elasticsearch as a "single-node" cluster (one master node replica) that assumes all the roles. The following inputs should be provided: + +```yaml +master: + masterOnly: false + replicaCount: 1 +data: + replicaCount: 0 +coordinating: + replicaCount: 0 +ingest: + replicaCount: 0 +``` + +The "single-node" cluster will be configured with [single-node discovery](https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html#single-node-discovery). + +If you want to scale up to more replicas, make sure you refresh the configuration of the existing StatefulSet. For example, scale down to 0 replicas first to avoid inconsistencies in the configuration: ```console -helm delete --purge my-release +kubectl scale statefulset -master --replicas=0 +helm upgrade oci://REGISTRY_NAME/REPOSITORY_NAME/elasticsearch --reset-values --set master.masterOnly=false ``` +> 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`. + +Please note that the master nodes should continue assuming all the roles (`master.masterOnly: false`) since there is shard data on the first replica. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: ELASTICSEARCH_VERSION + value: 7.0 +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Using custom init scripts + +For advanced operations, the Bitnami Elasticsearch charts allows using custom init scripts that will be mounted inside `/docker-entrypoint.init-db`. You can include the file directly in your `values.yaml` with `initScripts`, or use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. In this case you use the `initScriptsCM` and `initScriptsSecret` values. + +```console +initScriptsCM=special-scripts +initScriptsSecret=special-scripts-sensitive +``` + +### Snapshot and restore operations + +As it's described in the [official documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html#snapshots-filesystem-repository), it's necessary to register a snapshot repository before you can perform snapshot and restore operations. + +This chart allows you to configure Elasticsearch to use a shared file system to store snapshots. To do so, you need to mount a RWX volume on every Elasticsearch node, and set the parameter `snapshotRepoPath` with the path where the volume is mounted. In the example below, you can find the values to set when using a NFS Perstitent Volume: + +```yaml +extraVolumes: + - name: snapshot-repository + nfs: + server: nfs.example.com # Please change this to your NFS server + path: /share1 +extraVolumeMounts: + - name: snapshot-repository + mountPath: /snapshots +snapshotRepoPath: "/snapshots" +``` + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Elasticsearch components (e.g. an additional metrics or logging exporter), you can do so via the `XXX.sidecars` parameter(s), where XXX is placeholder you need to replace with the actual component(s). Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname +``` + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami Elasticsearch](https://github.com/bitnami/containers/tree/main/bitnami/elasticsearch) image stores the Elasticsearch data at the `/bitnami/elasticsearch/data` path of the container. + +By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. See the [Parameters](#parameters) section to configure the PVC. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + ## Parameters ### Global parameters @@ -760,200 +940,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/elast > 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/elasticsearch/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. - -### Change ElasticSearch version - -To modify the ElasticSearch version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/elasticsearch/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. - -### Default kernel settings - -Currently, Elasticsearch requires some changes in the kernel of the host machine to work as expected. If those values are not set in the underlying operating system, the ES containers fail to boot with ERROR messages. More information about these requirements can be found in the links below: - -- [File Descriptor requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html) -- [Virtual memory requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html) - -This chart uses a **privileged** initContainer to change those settings in the Kernel by running: `sysctl -w vm.max_map_count=262144 && sysctl -w fs.file-max=65536`. -You can disable the initContainer using the `sysctlImage.enabled=false` parameter. - -### Enable bundled Kibana - -This Elasticsearch chart contains Kibana as subchart, you can enable it just setting the `global.kibanaEnabled=true` parameter. -To see the notes with some operational instructions from the Kibana chart, please use the `--render-subchart-notes` as part of your `helm install` command, in this way you can see the Kibana and ES notes in your terminal. - -When enabling the bundled kibana subchart, there are a few gotchas that you should be aware of listed below. - -#### Elasticsearch rest Encryption - -When enabling elasticsearch' rest endpoint encryption you will also need to set `kibana.elasticsearch.security.tls.enabled` to the SAME value along with some additional values shown below for an "out of the box experience": - -```yaml -security: - enabled: true - # PASSWORD must be the same value passed to elasticsearch to get an "out of the box" experience - elasticPassword: "" - tls: - # AutoGenerate TLS certs for elastic - autoGenerated: true - -kibana: - elasticsearch: - security: - auth: - enabled: true - # default in the elasticsearch chart is elastic - kibanaUsername: "" - kibanaPassword: "" - tls: - # Instruct kibana to connect to elastic over https - enabled: true - # Bit of a catch 22, as you will need to know the name upfront of your release - existingSecret: RELEASENAME-elasticsearch-coordinating-crt # or just 'elasticsearch-coordinating-crt' if the release name happens to be 'elasticsearch' - # As the certs are auto-generated, they are pemCerts so set to true - usePemCerts: true -``` - -At a bare-minimum, when working with kibana and elasticsearch together the following values MUST be the same, otherwise things will fail: - -```yaml -security: - tls: - restEncryption: true - -# assumes global.kibanaEnabled=true -kibana: - elasticsearch: - security: - tls: - enabled: true -``` - -### How to deploy a single node - -This chart allows you to deploy Elasticsearch as a "single-node" cluster (one master node replica) that assumes all the roles. The following inputs should be provided: - -```yaml -master: - masterOnly: false - replicaCount: 1 -data: - replicaCount: 0 -coordinating: - replicaCount: 0 -ingest: - replicaCount: 0 -``` - -The "single-node" cluster will be configured with [single-node discovery](https://www.elastic.co/guide/en/elasticsearch/reference/current/bootstrap-checks.html#single-node-discovery). - -If you want to scale up to more replicas, make sure you refresh the configuration of the existing StatefulSet. For example, scale down to 0 replicas first to avoid inconsistencies in the configuration: - -```console -kubectl scale statefulset -master --replicas=0 -helm upgrade oci://REGISTRY_NAME/REPOSITORY_NAME/elasticsearch --reset-values --set master.masterOnly=false -``` - -> 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`. - -Please note that the master nodes should continue assuming all the roles (`master.masterOnly: false`) since there is shard data on the first replica. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: ELASTICSEARCH_VERSION - value: 7.0 -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Using custom init scripts - -For advanced operations, the Bitnami Elasticsearch charts allows using custom init scripts that will be mounted inside `/docker-entrypoint.init-db`. You can include the file directly in your `values.yaml` with `initScripts`, or use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. In this case you use the `initScriptsCM` and `initScriptsSecret` values. - -```console -initScriptsCM=special-scripts -initScriptsSecret=special-scripts-sensitive -``` - -### Snapshot and restore operations - -As it's described in the [official documentation](https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-register-repository.html#snapshots-filesystem-repository), it's necessary to register a snapshot repository before you can perform snapshot and restore operations. - -This chart allows you to configure Elasticsearch to use a shared file system to store snapshots. To do so, you need to mount a RWX volume on every Elasticsearch node, and set the parameter `snapshotRepoPath` with the path where the volume is mounted. In the example below, you can find the values to set when using a NFS Perstitent Volume: - -```yaml -extraVolumes: - - name: snapshot-repository - nfs: - server: nfs.example.com # Please change this to your NFS server - path: /share1 -extraVolumeMounts: - - name: snapshot-repository - mountPath: /snapshots -snapshotRepoPath: "/snapshots" -``` - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Elasticsearch components (e.g. an additional metrics or logging exporter), you can do so via the `XXX.sidecars` parameter(s), where XXX is placeholder you need to replace with the actual component(s). Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname -``` - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -## Persistence - -The [Bitnami Elasticsearch](https://github.com/bitnami/containers/tree/main/bitnami/elasticsearch) image stores the Elasticsearch data at the `/bitnami/elasticsearch/data` path of the container. - -By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. See the [Parameters](#parameters) section to configure the PVC. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/etcd/README.md b/bitnami/etcd/README.md index 190f0ec74b..3e00af9feb 100644 --- a/bitnami/etcd/README.md +++ b/bitnami/etcd/README.md @@ -42,15 +42,274 @@ These commands deploy etcd on the Kubernetes cluster in the default configuratio > **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 -```console -helm delete my-release +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. + +### Cluster configuration + +The Bitnami etcd chart can be used to bootstrap an etcd cluster, easy to scale and with available features to implement disaster recovery. It uses static discovery configured via environment variables to bootstrap the etcd cluster. Based on the number of initial replicas, and using the A records added to the DNS configuration by the headless service, the chart can calculate every advertised peer URL. + +The chart makes use of some extra elements offered by Kubernetes to ensure the bootstrapping is successful: + +- It sets a "Parallel" Pod Management Policy. This is critical, since all the etcd replicas should be created simultaneously to guarantee they can find each other. +- It records "not ready" pods in the DNS, so etcd replicas are reachable using their associated FQDN before they're actually ready. + +Learn more about [etcd discovery](https://etcd.io/docs/current/op-guide/clustering/#discovery), [Pod Management Policies](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-management-policies) and [recording "not ready" pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-hostname-and-subdomain-fields). + +Here is an example of the environment configuration bootstrapping an etcd cluster with 3 replicas: + +| Member | Variable | Value | +|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 0 | ETCD_NAME | etcd-0 | +| 0 | ETCD_INITIAL_ADVERTISE_PEER_URLS | | +|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 1 | ETCD_NAME | etcd-1 | +| 1 | ETCD_INITIAL_ADVERTISE_PEER_URLS | | +|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| 2 | ETCD_NAME | etcd-2 | +| 2 | ETCD_INITIAL_ADVERTISE_PEER_URLS | | +|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| +| * | ETCD_INITIAL_CLUSTER_STATE | new | +| * | ETCD_INITIAL_CLUSTER_TOKEN | etcd-cluster-k8s | +| * | ETCD_INITIAL_CLUSTER | etcd-0=,etcd-1=,etcd-2= | + +The probes (readiness & liveness) are delayed 60 seconds by default, to give the etcd replicas time to start and find each other. After that period, the *etcdctl endpoint health* command is used to periodically perform health checks on every replica. + +#### Scalability + +The Bitnami etcd chart uses etcd reconfiguration operations to add/remove members of the cluster during scaling. + +When scaling down, a "pre-stop" lifecycle hook is used to ensure that the `etcdctl member remove` command is executed. The hook stores the output of this command in the persistent volume attached to the etcd pod. This hook is also executed when the pod is manually removed using the `kubectl delete pod` command or rescheduled by Kubernetes for any reason. This implies that the cluster can be scaled up/down without human intervention. + +Here is an example to explain how this works: + +1. An etcd cluster with three members running on a three-nodes Kubernetes cluster is bootstrapped. +2. After a few days, the cluster administrator decides to upgrade the kernel on one of the cluster nodes. To do so, the administrator drains the node. Pods running on that node are rescheduled to a different one. +3. During the pod eviction process, the "pre-stop" hook removes the etcd member from the cluster. Thus, the etcd cluster is scaled down to only two members. +4. Once the pod is scheduled on another node and initialized, the etcd member is added again to the cluster using the *etcdctl member add* command. Thus, the etcd cluster is scaled up to three replicas. + +If, for whatever reason, the "pre-stop" hook fails at removing the member, the initialization logic is able to detect that something went wrong by checking the `etcdctl member remove` command output that was stored in the persistent volume. It then uses the `etcdctl member update` command to add back the member. In this case, the cluster isn't automatically scaled down/up while the pod is recovered. Therefore, when other members attempt to connect to the pod, it may cause warnings or errors like the one below: + +```text +E | rafthttp: failed to dial XXXXXXXX on stream Message (peer XXXXXXXX failed to find local node YYYYYYYYY) +I | rafthttp: peer XXXXXXXX became inactive (message send to peer failed) +W | rafthttp: health check for peer XXXXXXXX could not connect: dial tcp A.B.C.D:2380: i/o timeout ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Learn more about [etcd runtime configuration](https://etcd.io/docs/current/op-guide/runtime-configuration/) and how to safely drain a Kubernetes node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/). + +#### Cluster updates + +When updating the etcd StatefulSet (such as when upgrading the chart version via the *helm upgrade* command), every pod must be replaced following the StatefulSet update strategy. + +The chart uses a "RollingUpdate" strategy by default and with default Kubernetes values. In other words, it updates each Pod, one at a time, in the same order as Pod termination (from the largest ordinal to the smallest). It will wait until an updated Pod is "Running" and "Ready" prior to updating its predecessor. + +Learn more about [StatefulSet update strategies](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies). + +#### Disaster recovery + +If, for whatever reason, (N-1)/2 members of the cluster fail and the "pre-stop" hooks also fail at removing them from the cluster, the cluster disastrously fails, irrevocably losing quorum. Once quorum is lost, the cluster cannot reach consensus and therefore cannot continue accepting updates. Under this circumstance, the only possible solution is usually to restore the cluster from a snapshot. + +> IMPORTANT: All members should restore using the same snapshot. + +The Bitnami etcd chart solves this problem by optionally offering a Kubernetes cron job that periodically snapshots the keyspace and stores it in a RWX volume. In case the cluster disastrously fails, the pods will automatically try to restore it using the last avalable snapshot. + +[Learn how to enable this disaster recovery feature](#enable-disaster-recovery-features). + +The chart also sets by default a "soft" Pod AntiAffinity to reduce the risk of the cluster failing disastrously. + +Learn more about [etcd recovery](https://etcd.io/docs/current/op-guide/recovery), [Kubernetes cron jobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) and [pod affinity and anti-affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) + +### Enable security for etcd + +The etcd chart can be configured with Role-based access control and TLS encryption to improve its security. + +#### Configure RBAC + +In order to enable Role-Based Access Control for etcd, set the following parameters: + +```text +auth.rbac.enabled=true +auth.rbac.rootPassword=ETCD_ROOT_PASSWORD +``` + +These parameters create a `root` user with an associate `root` role with access to everything. The remaining users will use the `guest` role and won't have permissions to do anything. + +#### Configure TLS for server-to-server communications + +In order to enable secure transport between peer nodes deploy the helm chart with these options: + +```text +auth.peer.secureTransport=true +auth.peer.useAutoTLS=true +``` + +#### Configure certificates for client communication + +In order to enable secure transport between client and server, create a secret containing the certificate and key files and the CA used to sign the client certificates. In this case, create the secret and then deploy the chart with these options: + +```text +auth.client.secureTransport=true +auth.client.enableAuthentication=true +auth.client.existingSecret=etcd-client-certs +``` + +Learn more about the [etcd security model](https://etcd.io/) and how to [generate self-signed certificates for etcd](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html). + +### Enable disaster recovery features + +The Bitnami etcd Helm chart supports automatic disaster recovery by periodically snapshotting the keyspace. If the cluster permanently loses more than (N-1)/2 members, it tries to recover the cluster from a previous snapshot. + +Enable this feature with the following parameters: + +```text +persistence.enabled=true +disasterRecovery.enabled=true +disasterRecovery.pvc.size=2Gi +disasterRecovery.pvc.storageClassName=nfs +``` + +If the `startFromSnapshot.*` parameters are used at the same time as the `disasterRecovery.*` parameters, the PVC provided via the `startFromSnapshot.existingClaim` parameter will be used to store the periodical snapshots. + +> NOTE: The disaster recovery feature requires volumes with ReadWriteMany access mode. + +### Backup and restore the etcd keyspace + +Two different approaches are available to back up and restore this Helm Chart: + +- Back up the data from the source deployment and restore it in a new deployment using etcd's built-in backup/restore tools. +- Back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool. + +#### Method 1: Backup and restore data using etcd's built-in tools + +This method involves the following steps: + +- Use the *etcdctl* tool to create a snapshot of the data in the source cluster. +- Make the snapshot available in a Kubernetes PersistentVolumeClaim (PVC) that supports ReadWriteMany access (for example, a PVC created with the NFS storage class) +- Restore the data snapshot in a new cluster using the <%= variable :catalog_name, :platform %> etcd Helm chart's *startFromSnapshot.existingClaim* and *startFromSnapshot.snapshotFilename* parameters to define the source PVC and source filename for the snapshot. + +> NOTE: Under this approach, it is important to create the new deployment on the destination cluster using the same credentials as the original deployment on the source cluster. + +#### Method 2: Back up and restore persistent data volumes + +This method involves copying the persistent data volumes for the etcd nodes and reusing them in a new deployment with [Velero](https://velero.io/), an open source Kubernetes backup/restore tool. This method is only suitable when: + +- The Kubernetes provider is [supported by Velero](https://velero.io/docs/latest/supported-providers/). +- Both clusters are on the same Kubernetes provider, as this is a requirement of [Velero's native support for migrating persistent volumes](https://velero.io/docs/latest/migration-case/). +- The restored deployment on the destination cluster will have the same name, namespace, topology and credentials as the original deployment on the source cluster. + +This method involves the following steps: + +- Install Velero on the source and destination clusters. +- Use Velero to back up the PersistentVolumes (PVs) used by the etcd deployment on the source cluster. +- Use Velero to restore the backed-up PVs on the destination cluster. +- Create a new etcd deployment on the destination cluster with the same deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. + +### Exposing etcd metrics + +The metrics exposed by etcd can be exposed to be scraped by Prometheus. Metrics can be scraped from within the cluster using any of the following approaches: + +- Adding the required annotations for Prometheus to discover the metrics endpoints, as in the example below: + +```yaml +podAnnotations: + prometheus.io/scrape: "true" + prometheus.io/path: "/metrics/cluster" + prometheus.io/port: "9000" +``` + +- Creating a ServiceMonitor or PodMonitor entry (when the Prometheus Operator is available in the cluster) +- Using something similar to the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). + +If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. + +### Using custom configuration + +In order to use custom configuration parameters, two options are available: + +- Using environment variables: etcd allows setting environment variables that map to configuration settings. In order to set extra environment variables, you can use the `extraEnvVars` property. Alternatively, you can use a ConfigMap or a Secret with the environment variables using the `extraEnvVarsCM` or the `extraEnvVarsSecret` properties. + +```yaml +extraEnvVars: + - name: ETCD_AUTO_COMPACTION_RETENTION + value: "0" + - name: ETCD_HEARTBEAT_INTERVAL + value: "150" +``` + +- Using a custom `etcd.conf.yml`: The etcd chart allows mounting a custom `etcd.conf.yml` file as ConfigMap. In order to so, you can use the `configuration` property. Alternatively, you can use an existing ConfigMap using the `existingConfigmap` parameter. + +### Auto Compaction + +Since etcd keeps an exact history of its keyspace, this history should be periodically compacted to avoid performance degradation and eventual storage space exhaustion. Compacting the keyspace history drops all information about keys superseded prior to a given keyspace revision. The space used by these keys then becomes available for additional writes to the keyspace. + +`autoCompactionMode`, by default periodic. Valid values: "periodic", "revision". + +- 'periodic' for duration based retention, defaulting to hours if no time unit is provided (e.g. "5m"). +- 'revision' for revision number based retention. +`autoCompactionRetention` for mvcc key value store in hour, by default 0, means disabled. + +You can enable auto compaction by using following parameters: + +```console +autoCompactionMode=periodic +autoCompactionRetention=10m +``` + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the etcd app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### 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 etcd](https://github.com/bitnami/containers/tree/main/bitnami/etcd) image stores the etcd data at the `/bitnami/etcd` path of the container. Persistent Volume Claims are used to keep the data across statefulsets. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning by default. An existing PersistentVolumeClaim can also be defined for this purpose. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). ## Parameters @@ -351,275 +610,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/etcd > 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/etcd/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. - -### Cluster configuration - -The Bitnami etcd chart can be used to bootstrap an etcd cluster, easy to scale and with available features to implement disaster recovery. It uses static discovery configured via environment variables to bootstrap the etcd cluster. Based on the number of initial replicas, and using the A records added to the DNS configuration by the headless service, the chart can calculate every advertised peer URL. - -The chart makes use of some extra elements offered by Kubernetes to ensure the bootstrapping is successful: - -- It sets a "Parallel" Pod Management Policy. This is critical, since all the etcd replicas should be created simultaneously to guarantee they can find each other. -- It records "not ready" pods in the DNS, so etcd replicas are reachable using their associated FQDN before they're actually ready. - -Learn more about [etcd discovery](https://etcd.io/docs/current/op-guide/clustering/#discovery), [Pod Management Policies](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#pod-management-policies) and [recording "not ready" pods](https://kubernetes.io/docs/concepts/services-networking/dns-pod-service/#pod-s-hostname-and-subdomain-fields). - -Here is an example of the environment configuration bootstrapping an etcd cluster with 3 replicas: - -| Member | Variable | Value | -|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 0 | ETCD_NAME | etcd-0 | -| 0 | ETCD_INITIAL_ADVERTISE_PEER_URLS | | -|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 1 | ETCD_NAME | etcd-1 | -| 1 | ETCD_INITIAL_ADVERTISE_PEER_URLS | | -|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| 2 | ETCD_NAME | etcd-2 | -| 2 | ETCD_INITIAL_ADVERTISE_PEER_URLS | | -|---------|----------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| -| * | ETCD_INITIAL_CLUSTER_STATE | new | -| * | ETCD_INITIAL_CLUSTER_TOKEN | etcd-cluster-k8s | -| * | ETCD_INITIAL_CLUSTER | etcd-0=,etcd-1=,etcd-2= | - -The probes (readiness & liveness) are delayed 60 seconds by default, to give the etcd replicas time to start and find each other. After that period, the *etcdctl endpoint health* command is used to periodically perform health checks on every replica. - -#### Scalability - -The Bitnami etcd chart uses etcd reconfiguration operations to add/remove members of the cluster during scaling. - -When scaling down, a "pre-stop" lifecycle hook is used to ensure that the `etcdctl member remove` command is executed. The hook stores the output of this command in the persistent volume attached to the etcd pod. This hook is also executed when the pod is manually removed using the `kubectl delete pod` command or rescheduled by Kubernetes for any reason. This implies that the cluster can be scaled up/down without human intervention. - -Here is an example to explain how this works: - -1. An etcd cluster with three members running on a three-nodes Kubernetes cluster is bootstrapped. -2. After a few days, the cluster administrator decides to upgrade the kernel on one of the cluster nodes. To do so, the administrator drains the node. Pods running on that node are rescheduled to a different one. -3. During the pod eviction process, the "pre-stop" hook removes the etcd member from the cluster. Thus, the etcd cluster is scaled down to only two members. -4. Once the pod is scheduled on another node and initialized, the etcd member is added again to the cluster using the *etcdctl member add* command. Thus, the etcd cluster is scaled up to three replicas. - -If, for whatever reason, the "pre-stop" hook fails at removing the member, the initialization logic is able to detect that something went wrong by checking the `etcdctl member remove` command output that was stored in the persistent volume. It then uses the `etcdctl member update` command to add back the member. In this case, the cluster isn't automatically scaled down/up while the pod is recovered. Therefore, when other members attempt to connect to the pod, it may cause warnings or errors like the one below: - -```text -E | rafthttp: failed to dial XXXXXXXX on stream Message (peer XXXXXXXX failed to find local node YYYYYYYYY) -I | rafthttp: peer XXXXXXXX became inactive (message send to peer failed) -W | rafthttp: health check for peer XXXXXXXX could not connect: dial tcp A.B.C.D:2380: i/o timeout -``` - -Learn more about [etcd runtime configuration](https://etcd.io/docs/current/op-guide/runtime-configuration/) and how to safely drain a Kubernetes node](https://kubernetes.io/docs/tasks/administer-cluster/safely-drain-node/). - -#### Cluster updates - -When updating the etcd StatefulSet (such as when upgrading the chart version via the *helm upgrade* command), every pod must be replaced following the StatefulSet update strategy. - -The chart uses a "RollingUpdate" strategy by default and with default Kubernetes values. In other words, it updates each Pod, one at a time, in the same order as Pod termination (from the largest ordinal to the smallest). It will wait until an updated Pod is "Running" and "Ready" prior to updating its predecessor. - -Learn more about [StatefulSet update strategies](https://kubernetes.io/docs/concepts/workloads/controllers/statefulset/#update-strategies). - -#### Disaster recovery - -If, for whatever reason, (N-1)/2 members of the cluster fail and the "pre-stop" hooks also fail at removing them from the cluster, the cluster disastrously fails, irrevocably losing quorum. Once quorum is lost, the cluster cannot reach consensus and therefore cannot continue accepting updates. Under this circumstance, the only possible solution is usually to restore the cluster from a snapshot. - -> IMPORTANT: All members should restore using the same snapshot. - -The Bitnami etcd chart solves this problem by optionally offering a Kubernetes cron job that periodically snapshots the keyspace and stores it in a RWX volume. In case the cluster disastrously fails, the pods will automatically try to restore it using the last avalable snapshot. - -[Learn how to enable this disaster recovery feature](#enable-disaster-recovery-features). - -The chart also sets by default a "soft" Pod AntiAffinity to reduce the risk of the cluster failing disastrously. - -Learn more about [etcd recovery](https://etcd.io/docs/current/op-guide/recovery), [Kubernetes cron jobs](https://kubernetes.io/docs/concepts/workloads/controllers/cron-jobs/) and [pod affinity and anti-affinity](https://kubernetes.io/docs/concepts/scheduling-eviction/assign-pod-node/#affinity-and-anti-affinity) - -### Enable security for etcd - -The etcd chart can be configured with Role-based access control and TLS encryption to improve its security. - -#### Configure RBAC - -In order to enable Role-Based Access Control for etcd, set the following parameters: - -```text -auth.rbac.enabled=true -auth.rbac.rootPassword=ETCD_ROOT_PASSWORD -``` - -These parameters create a `root` user with an associate `root` role with access to everything. The remaining users will use the `guest` role and won't have permissions to do anything. - -#### Configure TLS for server-to-server communications - -In order to enable secure transport between peer nodes deploy the helm chart with these options: - -```text -auth.peer.secureTransport=true -auth.peer.useAutoTLS=true -``` - -#### Configure certificates for client communication - -In order to enable secure transport between client and server, create a secret containing the certificate and key files and the CA used to sign the client certificates. In this case, create the secret and then deploy the chart with these options: - -```text -auth.client.secureTransport=true -auth.client.enableAuthentication=true -auth.client.existingSecret=etcd-client-certs -``` - -Learn more about the [etcd security model](https://etcd.io/) and how to [generate self-signed certificates for etcd](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html). - -### Persistence - -The [Bitnami etcd](https://github.com/bitnami/containers/tree/main/bitnami/etcd) image stores the etcd data at the `/bitnami/etcd` path of the container. Persistent Volume Claims are used to keep the data across statefulsets. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning by default. An existing PersistentVolumeClaim can also be defined for this purpose. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Enable disaster recovery features - -The Bitnami etcd Helm chart supports automatic disaster recovery by periodically snapshotting the keyspace. If the cluster permanently loses more than (N-1)/2 members, it tries to recover the cluster from a previous snapshot. - -Enable this feature with the following parameters: - -```text -persistence.enabled=true -disasterRecovery.enabled=true -disasterRecovery.pvc.size=2Gi -disasterRecovery.pvc.storageClassName=nfs -``` - -If the `startFromSnapshot.*` parameters are used at the same time as the `disasterRecovery.*` parameters, the PVC provided via the `startFromSnapshot.existingClaim` parameter will be used to store the periodical snapshots. - -> NOTE: The disaster recovery feature requires volumes with ReadWriteMany access mode. - -### Backup and restore the etcd keyspace - -Two different approaches are available to back up and restore this Helm Chart: - -- Back up the data from the source deployment and restore it in a new deployment using etcd's built-in backup/restore tools. -- Back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool. - -#### Method 1: Backup and restore data using etcd's built-in tools - -This method involves the following steps: - -- Use the *etcdctl* tool to create a snapshot of the data in the source cluster. -- Make the snapshot available in a Kubernetes PersistentVolumeClaim (PVC) that supports ReadWriteMany access (for example, a PVC created with the NFS storage class) -- Restore the data snapshot in a new cluster using the <%= variable :catalog_name, :platform %> etcd Helm chart's *startFromSnapshot.existingClaim* and *startFromSnapshot.snapshotFilename* parameters to define the source PVC and source filename for the snapshot. - -> NOTE: Under this approach, it is important to create the new deployment on the destination cluster using the same credentials as the original deployment on the source cluster. - -#### Method 2: Back up and restore persistent data volumes - -This method involves copying the persistent data volumes for the etcd nodes and reusing them in a new deployment with [Velero](https://velero.io/), an open source Kubernetes backup/restore tool. This method is only suitable when: - -- The Kubernetes provider is [supported by Velero](https://velero.io/docs/latest/supported-providers/). -- Both clusters are on the same Kubernetes provider, as this is a requirement of [Velero's native support for migrating persistent volumes](https://velero.io/docs/latest/migration-case/). -- The restored deployment on the destination cluster will have the same name, namespace, topology and credentials as the original deployment on the source cluster. - -This method involves the following steps: - -- Install Velero on the source and destination clusters. -- Use Velero to back up the PersistentVolumes (PVs) used by the etcd deployment on the source cluster. -- Use Velero to restore the backed-up PVs on the destination cluster. -- Create a new etcd deployment on the destination cluster with the same deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. - -### Exposing etcd metrics - -The metrics exposed by etcd can be exposed to be scraped by Prometheus. Metrics can be scraped from within the cluster using any of the following approaches: - -- Adding the required annotations for Prometheus to discover the metrics endpoints, as in the example below: - -```yaml -podAnnotations: - prometheus.io/scrape: "true" - prometheus.io/path: "/metrics/cluster" - prometheus.io/port: "9000" -``` - -- Creating a ServiceMonitor or PodMonitor entry (when the Prometheus Operator is available in the cluster) -- Using something similar to the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). - -If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. - -### Using custom configuration - -In order to use custom configuration parameters, two options are available: - -- Using environment variables: etcd allows setting environment variables that map to configuration settings. In order to set extra environment variables, you can use the `extraEnvVars` property. Alternatively, you can use a ConfigMap or a Secret with the environment variables using the `extraEnvVarsCM` or the `extraEnvVarsSecret` properties. - -```yaml -extraEnvVars: - - name: ETCD_AUTO_COMPACTION_RETENTION - value: "0" - - name: ETCD_HEARTBEAT_INTERVAL - value: "150" -``` - -- Using a custom `etcd.conf.yml`: The etcd chart allows mounting a custom `etcd.conf.yml` file as ConfigMap. In order to so, you can use the `configuration` property. Alternatively, you can use an existing ConfigMap using the `existingConfigmap` parameter. - -### Auto Compaction - -Since etcd keeps an exact history of its keyspace, this history should be periodically compacted to avoid performance degradation and eventual storage space exhaustion. Compacting the keyspace history drops all information about keys superseded prior to a given keyspace revision. The space used by these keys then becomes available for additional writes to the keyspace. - -`autoCompactionMode`, by default periodic. Valid values: "periodic", "revision". - -- 'periodic' for duration based retention, defaulting to hours if no time unit is provided (e.g. "5m"). -- 'revision' for revision number based retention. -`autoCompactionRetention` for mvcc key value store in hour, by default 0, means disabled. - -You can enable auto compaction by using following parameters: - -```console -autoCompactionMode=periodic -autoCompactionRetention=10m -``` - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the etcd app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### 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. - ## 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). diff --git a/bitnami/external-dns/README.md b/bitnami/external-dns/README.md index 1d2faec813..6cf36cb90a 100644 --- a/bitnami/external-dns/README.md +++ b/bitnami/external-dns/README.md @@ -41,15 +41,59 @@ The command deploys ExternalDNS on the Kubernetes cluster in the default configu > **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. + +### 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. + +### Using IRSA + +If you are deploying to AWS EKS and you want to leverage [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). You will need to override `fsGroup` and `runAsUser` with `65534`(nfsnobody) and `0` respectively. Otherwise service account token will not be properly mounted. +You can use the following arguments: ```console -helm delete my-release +--set podSecurityContext.fsGroup=65534 --set podSecurityContext.runAsUser=0 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +## Tutorials + +Find information about the requirements for each DNS provider on the link below: + +- [ExternalDNS Tutorials](https://github.com/kubernetes-sigs/external-dns/tree/master/docs/tutorials) + +For instance, to install ExternalDNS on AWS, you need to: + +- Provide the K8s worker node which runs the cluster autoscaler with a minimum IAM policy (check [IAM permissions docs](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md#iam-permissions) for more information). +- Setup a hosted zone on Route53 and annotate the Hosted Zone ID and its associated "nameservers" as described on [these docs](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md#set-up-a-hosted-zone). +- Install ExternalDNS chart using the command below: + +> Note: replace the placeholder HOSTED_ZONE_IDENTIFIER and HOSTED_ZONE_NAME, with your hosted zoned identifier and name, respectively. + +```console +helm install my-release \ + --set provider=aws \ + --set aws.zoneType=public \ + --set txtOwnerId=HOSTED_ZONE_IDENTIFIER \ + --set domainFilters[0]=HOSTED_ZONE_NAME \ + oci://REGISTRY_NAME/REPOSITORY_NAME/external-dns +``` + +> 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`. ## Parameters @@ -401,60 +445,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/exter > 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/external-dns/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. - -### 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. - -### Using IRSA - -If you are deploying to AWS EKS and you want to leverage [IRSA](https://docs.aws.amazon.com/eks/latest/userguide/iam-roles-for-service-accounts.html). You will need to override `fsGroup` and `runAsUser` with `65534`(nfsnobody) and `0` respectively. Otherwise service account token will not be properly mounted. -You can use the following arguments: - -```console ---set podSecurityContext.fsGroup=65534 --set podSecurityContext.runAsUser=0 -``` - -## Tutorials - -Find information about the requirements for each DNS provider on the link below: - -- [ExternalDNS Tutorials](https://github.com/kubernetes-sigs/external-dns/tree/master/docs/tutorials) - -For instance, to install ExternalDNS on AWS, you need to: - -- Provide the K8s worker node which runs the cluster autoscaler with a minimum IAM policy (check [IAM permissions docs](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md#iam-permissions) for more information). -- Setup a hosted zone on Route53 and annotate the Hosted Zone ID and its associated "nameservers" as described on [these docs](https://github.com/kubernetes-sigs/external-dns/blob/master/docs/tutorials/aws.md#set-up-a-hosted-zone). -- Install ExternalDNS chart using the command below: - -> Note: replace the placeholder HOSTED_ZONE_IDENTIFIER and HOSTED_ZONE_NAME, with your hosted zoned identifier and name, respectively. - -```console -helm install my-release \ - --set provider=aws \ - --set aws.zoneType=public \ - --set txtOwnerId=HOSTED_ZONE_IDENTIFIER \ - --set domainFilters[0]=HOSTED_ZONE_NAME \ - oci://REGISTRY_NAME/REPOSITORY_NAME/external-dns -``` - -> 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`. - ## 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). diff --git a/bitnami/flink/README.md b/bitnami/flink/README.md index 63d1573f44..0f900590f5 100644 --- a/bitnami/flink/README.md +++ b/bitnami/flink/README.md @@ -43,15 +43,86 @@ These commands deploy flink on the Kubernetes cluster in the default configurati > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` statefulset: +### Resource requests and limits -```console -helm delete my-release +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. + +### Persistence + +The [Bitnami Flink](https://github.com/bitnami/containers/tree/main/bitnami/flink) image stores the trace onto an external database. Persistent Volume Claims are used to keep the data across deployments. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `jobmanager`, `taskmanager`. + +```yaml +jobmanager: + extraEnvVars: + - name: ENV_VAR_NAME + value: ENV_VAR_VALUE +taskmanager: + extraEnvVars: + - name: ENV_VAR_NAME + value: ENV_VAR_VALUE ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as flink (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `jobmanager`, `taskmanager` . + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside each of the subsections: `jobmanager`, `taskmanager`. ## Parameters @@ -288,87 +359,6 @@ The command removes all the Kubernetes components associated with the chart and | `taskmanager.initContainers` | Add additional init containers to the flink pods | `[]` | | `taskmanager.sidecars` | Add additional sidecar containers to the flink pods | `[]` | -## 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. - -### Persistence - -The [Bitnami Flink](https://github.com/bitnami/containers/tree/main/bitnami/flink) image stores the trace onto an external database. Persistent Volume Claims are used to keep the data across deployments. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `jobmanager`, `taskmanager`. - -```yaml -jobmanager: - extraEnvVars: - - name: ENV_VAR_NAME - value: ENV_VAR_VALUE -taskmanager: - extraEnvVars: - - name: ENV_VAR_NAME - value: ENV_VAR_VALUE -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as flink (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `jobmanager`, `taskmanager` . - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside each of the subsections: `jobmanager`, `taskmanager`. - ## 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). diff --git a/bitnami/fluent-bit/README.md b/bitnami/fluent-bit/README.md index 46dca16e1a..60d9707a3b 100644 --- a/bitnami/fluent-bit/README.md +++ b/bitnami/fluent-bit/README.md @@ -43,15 +43,73 @@ These commands deploy fluent-bit on the Kubernetes cluster in the default config > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` statefulset: +### Resource requests and limits -```console -helm delete my-release +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. + +### Persistence + +The [Bitnami Fluent Bit](https://github.com/bitnami/containers/tree/main/bitnami/fluent-bit) doesn't implement storage persistence by default, but you could mount an extraVolume with Persistent Volume Claims to keep the buffer and/or the output if configured out-of-memory (see [Buffering & Storage](https://docs.fluentbit.io/manual/administration/buffering-and-storage)) + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +### Sidecars + +If additional containers are needed in the same pod as fluent-bit (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the main section. + +```yaml +sidecars: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the main section. ## Parameters @@ -265,74 +323,6 @@ The command removes all the Kubernetes components associated with the chart and | `metrics.serviceMonitor.selector` | Prometheus instance selector labels | `{}` | | `extraDeploy` | Array of extra objects to deploy with the release | `[]` | -## 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. - -### Persistence - -The [Bitnami Fluent Bit](https://github.com/bitnami/containers/tree/main/bitnami/fluent-bit) doesn't implement storage persistence by default, but you could mount an extraVolume with Persistent Volume Claims to keep the buffer and/or the output if configured out-of-memory (see [Buffering & Storage](https://docs.fluentbit.io/manual/administration/buffering-and-storage)) - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -### Sidecars - -If additional containers are needed in the same pod as fluent-bit (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the main section. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the main section. - ## 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). diff --git a/bitnami/fluentd/README.md b/bitnami/fluentd/README.md index 4eb942d77a..2328061918 100644 --- a/bitnami/fluentd/README.md +++ b/bitnami/fluentd/README.md @@ -44,15 +44,157 @@ These commands deploy Fluentd on the Kubernetes cluster in the default configura > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` resources: +### Resource requests and limits -```console -helm delete my-release +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. + +### Forwarding the logs to another service + +By default, the aggregators in this chart will send the processed logs to the standard output. However, a common practice is to send them to another service, like Elasticsearch, instead. This can be achieved with this Helm Chart by mounting your own configuration files. For example: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: elasticsearch-output +data: + fluentd.conf: | + # Prometheus Exporter Plugin + # input plugin that exports metrics + + @type prometheus + port 24231 + + + # input plugin that collects metrics from MonitorAgent + + @type prometheus_monitor + + host ${hostname} + + + + # input plugin that collects metrics for output plugin + + @type prometheus_output_monitor + + host ${hostname} + + + + # Ignore fluentd own events + + @type null + + + # TCP input to receive logs from the forwarders + + @type forward + bind 0.0.0.0 + port 24224 + + + # HTTP input for the liveness and readiness probes + + @type http + bind 0.0.0.0 + port 9880 + + + # Throw the healthcheck to the standard output instead of forwarding it + + @type stdout + + + # Send the logs to the standard output + + @type elasticsearch + include_tag_key true + host "#{ENV['ELASTICSEARCH_HOST']}" + port "#{ENV['ELASTICSEARCH_PORT']}" + logstash_format true + + + @type file + path /opt/bitnami/fluentd/logs/buffers/logs.buffer + flush_thread_count 2 + flush_interval 5s + + ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +As an example, using the above configmap, you should specify the required parameters when upgrading or installing the chart: + +```console +aggregator.configMap=elasticsearch-output +aggregator.extraEnv[0].name=ELASTICSEARCH_HOST +aggregator.extraEnv[0].value=your-ip-here +aggregator.extraEnv[1].name=ELASTICSEARCH_PORT +aggregator.extraEnv[1].value=your-port-here +``` + +### Using custom init scripts + +For advanced operations, the Bitnami Fluentd charts allows using custom init scripts that will be mounted inside `/docker-entrypoint.init-db`. You can include the file directly in your `values.yaml`, depending on where you are going to initialize your scripts with `aggregator.initScripts` (or `forwarder.initScripts`), or use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. In this case you use the `aggregator.initScriptsCM` and `aggregator.initScriptsSecret` values (the same for `forwarder`). + +```console +initScriptsCM=special-scripts +initScriptsSecret=special-scripts-sensitive +``` + +### Forwarder Security Context & Policy + +By default, the **forwarder** `DaemonSet` from this chart **runs as the `root` user**, within the `root` group, assigning `root` file system permissions. This is different to the default behaviour of most Bitnami Helm charts where we [prefer to work with non-root containers](https://docs.bitnami.com/tutorials/work-with-non-root-containers/). + +The default behaviour is to run as `root` because: + +- the forwarder needs to mount `hostPath` volumes from the underlying node to read Docker container (& potentially other) logs +- in many Kubernetes node distributions, these log files are not readable by anyone other than `root` +- `fsGroup` doesn't work with `hostPath` volumes to allow the process to run non-root with alternate file system permissions + +Since we would like the chart to work out-of-the-box for as many users as possible, the `forwarder` thus runs as root by default. You can read more about the motivation for this at [#1905](https://github.com/bitnami/charts/issues/1905) and [#2323](https://github.com/bitnami/charts/pull/2323), however you should be aware of this, and the risks of running root containers in general. + +If you enable the forwarder's [bundled PodSecurityPolicy](https://github.com/bitnami/charts/tree/main/bitnami/fluentd/templates/forwarder-psp.yaml) with `forwarder.rbac.pspEnabled=true` it will allow the pod to run as `root` by default, while ensuring as many other privileges as possible are dropped. + +#### Running as non-root + +You can run as the `fluentd` user/group (non-root) with the below overrides if: + +- you have control of the `hostPath` filesystem permissions on your nodes sufficient to allow the fluentd user to read from them +- don't need to write to the `hostPath`s + +Note that if you have enabled the [bundled PodSecurityPolicy](https://github.com/bitnami/charts/tree/main/bitnami/fluentd/templates/forwarder-psp.yaml), it will adapt to the Chart values overrides. + +```yaml +forwarder: + daemonUser: fluentd + daemonGroup: fluentd + + securityContext: + runAsUser: 1001 + runAsGroup: 1001 + fsGroup: 1001 +``` + +#### Pod Security Policy & Custom `hostPath`s + +Mounting additional `hostPath`s is sometimes required to deal with `/var/lib` being symlinked on some Kubernetes environments. If you need to do so, the [bundled PodSecurityPolicy](https://github.com/bitnami/charts/tree/main/bitnami/fluentd/templates/forwarder-psp.yaml) will likely not meet your needs, as it whitelists only the standard `hostPath`s. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. ## Parameters @@ -378,158 +520,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/fluen > 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/fluentd/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. - -### Forwarding the logs to another service - -By default, the aggregators in this chart will send the processed logs to the standard output. However, a common practice is to send them to another service, like Elasticsearch, instead. This can be achieved with this Helm Chart by mounting your own configuration files. For example: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: elasticsearch-output -data: - fluentd.conf: | - # Prometheus Exporter Plugin - # input plugin that exports metrics - - @type prometheus - port 24231 - - - # input plugin that collects metrics from MonitorAgent - - @type prometheus_monitor - - host ${hostname} - - - - # input plugin that collects metrics for output plugin - - @type prometheus_output_monitor - - host ${hostname} - - - - # Ignore fluentd own events - - @type null - - - # TCP input to receive logs from the forwarders - - @type forward - bind 0.0.0.0 - port 24224 - - - # HTTP input for the liveness and readiness probes - - @type http - bind 0.0.0.0 - port 9880 - - - # Throw the healthcheck to the standard output instead of forwarding it - - @type stdout - - - # Send the logs to the standard output - - @type elasticsearch - include_tag_key true - host "#{ENV['ELASTICSEARCH_HOST']}" - port "#{ENV['ELASTICSEARCH_PORT']}" - logstash_format true - - - @type file - path /opt/bitnami/fluentd/logs/buffers/logs.buffer - flush_thread_count 2 - flush_interval 5s - - -``` - -As an example, using the above configmap, you should specify the required parameters when upgrading or installing the chart: - -```console -aggregator.configMap=elasticsearch-output -aggregator.extraEnv[0].name=ELASTICSEARCH_HOST -aggregator.extraEnv[0].value=your-ip-here -aggregator.extraEnv[1].name=ELASTICSEARCH_PORT -aggregator.extraEnv[1].value=your-port-here -``` - -### Using custom init scripts - -For advanced operations, the Bitnami Fluentd charts allows using custom init scripts that will be mounted inside `/docker-entrypoint.init-db`. You can include the file directly in your `values.yaml`, depending on where you are going to initialize your scripts with `aggregator.initScripts` (or `forwarder.initScripts`), or use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. In this case you use the `aggregator.initScriptsCM` and `aggregator.initScriptsSecret` values (the same for `forwarder`). - -```console -initScriptsCM=special-scripts -initScriptsSecret=special-scripts-sensitive -``` - -### Forwarder Security Context & Policy - -By default, the **forwarder** `DaemonSet` from this chart **runs as the `root` user**, within the `root` group, assigning `root` file system permissions. This is different to the default behaviour of most Bitnami Helm charts where we [prefer to work with non-root containers](https://docs.bitnami.com/tutorials/work-with-non-root-containers/). - -The default behaviour is to run as `root` because: - -- the forwarder needs to mount `hostPath` volumes from the underlying node to read Docker container (& potentially other) logs -- in many Kubernetes node distributions, these log files are not readable by anyone other than `root` -- `fsGroup` doesn't work with `hostPath` volumes to allow the process to run non-root with alternate file system permissions - -Since we would like the chart to work out-of-the-box for as many users as possible, the `forwarder` thus runs as root by default. You can read more about the motivation for this at [#1905](https://github.com/bitnami/charts/issues/1905) and [#2323](https://github.com/bitnami/charts/pull/2323), however you should be aware of this, and the risks of running root containers in general. - -If you enable the forwarder's [bundled PodSecurityPolicy](https://github.com/bitnami/charts/tree/main/bitnami/fluentd/templates/forwarder-psp.yaml) with `forwarder.rbac.pspEnabled=true` it will allow the pod to run as `root` by default, while ensuring as many other privileges as possible are dropped. - -#### Running as non-root - -You can run as the `fluentd` user/group (non-root) with the below overrides if: - -- you have control of the `hostPath` filesystem permissions on your nodes sufficient to allow the fluentd user to read from them -- don't need to write to the `hostPath`s - -Note that if you have enabled the [bundled PodSecurityPolicy](https://github.com/bitnami/charts/tree/main/bitnami/fluentd/templates/forwarder-psp.yaml), it will adapt to the Chart values overrides. - -```yaml -forwarder: - daemonUser: fluentd - daemonGroup: fluentd - - securityContext: - runAsUser: 1001 - runAsGroup: 1001 - fsGroup: 1001 -``` - -#### Pod Security Policy & Custom `hostPath`s - -Mounting additional `hostPath`s is sometimes required to deal with `/var/lib` being symlinked on some Kubernetes environments. If you need to do so, the [bundled PodSecurityPolicy](https://github.com/bitnami/charts/tree/main/bitnami/fluentd/templates/forwarder-psp.yaml) will likely not meet your needs, as it whitelists only the standard `hostPath`s. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/flux/README.md b/bitnami/flux/README.md index cd9e93b6cf..f4a134eeb6 100644 --- a/bitnami/flux/README.md +++ b/bitnami/flux/README.md @@ -41,16 +41,6 @@ The command deploys flux on the Kubernetes cluster in the default configuration. > **Tip**: List all releases using `helm list` -## Uninstalling the Chart - -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Parameters ### Global parameters diff --git a/bitnami/ghost/README.md b/bitnami/ghost/README.md index c12634646f..b77b014001 100644 --- a/bitnami/ghost/README.md +++ b/bitnami/ghost/README.md @@ -45,15 +45,153 @@ The command deploys Ghost 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 -```console -helm delete my-release +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. + +### External database support + +You may want to have Ghost connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#database-parameters). You should also disable the MySQL installation with the `mysql.enabled` option. Here is an example: + +```text +mysql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=3306 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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/). + +### Configure TLS Secrets for use with 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`. + +### Configure extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG +``` + +Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Configure Sidecars and Init Containers + +If additional containers are needed in the same pod as Ghost (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 Ghost](https://github.com/bitnami/containers/tree/main/bitnami/ghost) image stores the Ghost data and configurations at the `/bitnami/ghost` and `/bitnami/apache` paths 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. ## Parameters @@ -322,154 +460,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/ghost > 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/ghost/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. - -### External database support - -You may want to have Ghost connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#database-parameters). You should also disable the MySQL installation with the `mysql.enabled` option. Here is an example: - -```text -mysql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=3306 -``` - -### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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/). - -### Configure TLS Secrets for use with 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`. - -### Configure extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Configure Sidecars and Init Containers - -If additional containers are needed in the same pod as Ghost (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 Ghost](https://github.com/bitnami/containers/tree/main/bitnami/ghost) image stores the Ghost data and configurations at the `/bitnami/ghost` and `/bitnami/apache` paths 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. - ## 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). diff --git a/bitnami/gitea/README.md b/bitnami/gitea/README.md index d9941bf2a5..bce9712d5d 100644 --- a/bitnami/gitea/README.md +++ b/bitnami/gitea/README.md @@ -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). diff --git a/bitnami/grafana-loki/README.md b/bitnami/grafana-loki/README.md index 74ef7d3726..e1bc45307f 100644 --- a/bitnami/grafana-loki/README.md +++ b/bitnami/grafana-loki/README.md @@ -44,15 +44,127 @@ The command deploys grafana-loki on the Kubernetes cluster in the default config > **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 -```console -helm delete my-release +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. + +### Loki configuration + +The loki configuration file `loki.yaml` is shared across the different components: `distributor`, `compactor`, `ingester`, `querier` and `queryFrontend`. This is set in the `loki.configuration` value. Check the official [Loki Grafana documentation](https://grafana.com/docs/loki/latest/configuration/) for the list of possible configurations. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. + +```yaml +compactor: + extraEnvVars: + - name: LOG_LEVEL + value: error + +distributor: + extraEnvVars: + - name: LOG_LEVEL + value: error + +ingester: + extraEnvVars: + - name: LOG_LEVEL + value: error + +querier: + extraEnvVars: + - name: LOG_LEVEL + value: error + +queryFrontend: + extraEnvVars: + - name: LOG_LEVEL + value: error + +vulture: + extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as grafana-loki (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. + +### External cache support + +You may want to have Grafana Loki connect to an external Memcached rather than installing one inside your cluster. Typical reasons for this are to use a managed cache service, or to share a common cache server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalMemcached` parameter](#parameters). You should also disable the Memcached installation with the `memcached.enabled` option. Here is an example: + +```console +memcached.enabled=false +externalMemcached.host=myexternalhost +externalMemcached.port=11211 +``` + +## Persistence + +### Limitation + +This chart does not function fully when using local filesystem as a persistence store. When using a local filesystem as a persistence store, querying will not be possible (or limited to the ingesters' in-memory caches). For a fully functional deployment of this helm chart, an object storage backend is required. + +### Data + +The [Bitnami grafana-loki](https://github.com/bitnami/containers/tree/main/bitnami/grafana-loki) image stores the grafana-loki `ingester` data at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. ## Parameters @@ -1397,128 +1509,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/grafa > 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/grafana-loki/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. - -### Loki configuration - -The loki configuration file `loki.yaml` is shared across the different components: `distributor`, `compactor`, `ingester`, `querier` and `queryFrontend`. This is set in the `loki.configuration` value. Check the official [Loki Grafana documentation](https://grafana.com/docs/loki/latest/configuration/) for the list of possible configurations. - -## Persistence - -### Limitation - -This chart does not function fully when using local filesystem as a persistence store. When using a local filesystem as a persistence store, querying will not be possible (or limited to the ingesters' in-memory caches). For a fully functional deployment of this helm chart, an object storage backend is required. - -### Data - -The [Bitnami grafana-loki](https://github.com/bitnami/containers/tree/main/bitnami/grafana-loki) image stores the grafana-loki `ingester` data at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. - -```yaml -compactor: - extraEnvVars: - - name: LOG_LEVEL - value: error - -distributor: - extraEnvVars: - - name: LOG_LEVEL - value: error - -ingester: - extraEnvVars: - - name: LOG_LEVEL - value: error - -querier: - extraEnvVars: - - name: LOG_LEVEL - value: error - -queryFrontend: - extraEnvVars: - - name: LOG_LEVEL - value: error - -vulture: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as grafana-loki (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. - -### External cache support - -You may want to have Grafana Loki connect to an external Memcached rather than installing one inside your cluster. Typical reasons for this are to use a managed cache service, or to share a common cache server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalMemcached` parameter](#parameters). You should also disable the Memcached installation with the `memcached.enabled` option. Here is an example: - -```console -memcached.enabled=false -externalMemcached.host=myexternalhost -externalMemcached.port=11211 -``` - ## 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). diff --git a/bitnami/grafana-mimir/README.md b/bitnami/grafana-mimir/README.md index 8feec86147..03ab25cbe4 100644 --- a/bitnami/grafana-mimir/README.md +++ b/bitnami/grafana-mimir/README.md @@ -44,15 +44,73 @@ The command deploys grafana-mimir on the Kubernetes cluster in the default confi > **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 -```console -helm delete my-release +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. + +### Mimir configuration + +The mimir configuration file `mimir.yaml` is shared across the different components: `distributor`, `compactor`, `ingester`, `querier`, `query-frontend` and `store-gateway`. This is set in the `mimir.configuration` value. That value is templated, so you can use other chart values or templates in your configuration. Check the official [Mimir Mimir documentation](https://grafana.com/docs/mimir/latest/operators-guide/configure/reference-configuration-parameters) for the list of possible configurations. + +### Data + +The [Bitnami grafana-mimir](https://github.com/bitnami/containers/tree/main/bitnami/grafana-mimir) image stores the data at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `storeGateway`. This is very useful if you need to [use enviroment variables in your config file](https://grafana.com/docs/mimir/v2.6.x/reference-configuration-parameters/#use-environment-variables-in-the-configuration) for example to set + +```yaml +mimir: + blockStorage: + backend: s3 + config: | + access_key_id: ${S3_ACCESS_KEY_ID} + secret_access_key: ${S3_SECRET_ACCESS_KEY} + bucket_name: mimir + endpoint: s3.us-east-1.amazonaws.com + insecure: false +storeGateway: + extraEnvVars: + - name: S3_ACCESS_KEY_ID + valueFrom: + secretKeyRef: + name: s3-credentials-secret + key: access-key-id + - name: S3_SECRET_ACCESS_KEY + valueFrom: + secretKeyRef: + name: s3-credentials-secret + key: secret-access-key ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Pod affinity + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `storeGateway`. + +### External cache support + +You may want to have Grafana Mimir connect to an external Memcached rather than installing one inside your cluster. Typical reasons for this are to use a managed cache service, or to share a common cache server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalMemcached*` parameters](#parameters). You should also disable the Memcached installation with the `enabled` option. Here is an example: + +```console +memcachedchunks.enabled=false +externalMemcachedChunks.host=myexternalhost +externalMemcachedChunks.port=11211 +``` ## Parameters @@ -1445,74 +1503,6 @@ Once the chart is installed the remote write endpoints for Prometheus or Grafana http://grafana-mimir-gateway.default.svc.cluster.local/prometheus ``` -## 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. - -### Mimir configuration - -The mimir configuration file `mimir.yaml` is shared across the different components: `distributor`, `compactor`, `ingester`, `querier`, `query-frontend` and `store-gateway`. This is set in the `mimir.configuration` value. That value is templated, so you can use other chart values or templates in your configuration. Check the official [Mimir Mimir documentation](https://grafana.com/docs/mimir/latest/operators-guide/configure/reference-configuration-parameters) for the list of possible configurations. - -### Data - -The [Bitnami grafana-mimir](https://github.com/bitnami/containers/tree/main/bitnami/grafana-mimir) image stores the data at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `storeGateway`. This is very useful if you need to [use enviroment variables in your config file](https://grafana.com/docs/mimir/v2.6.x/reference-configuration-parameters/#use-environment-variables-in-the-configuration) for example to set - -```yaml -mimir: - blockStorage: - backend: s3 - config: | - access_key_id: ${S3_ACCESS_KEY_ID} - secret_access_key: ${S3_SECRET_ACCESS_KEY} - bucket_name: mimir - endpoint: s3.us-east-1.amazonaws.com - insecure: false -storeGateway: - extraEnvVars: - - name: S3_ACCESS_KEY_ID - valueFrom: - secretKeyRef: - name: s3-credentials-secret - key: access-key-id - - name: S3_SECRET_ACCESS_KEY - valueFrom: - secretKeyRef: - name: s3-credentials-secret - key: secret-access-key -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Pod affinity - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `storeGateway`. - -### External cache support - -You may want to have Grafana Mimir connect to an external Memcached rather than installing one inside your cluster. Typical reasons for this are to use a managed cache service, or to share a common cache server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalMemcached*` parameters](#parameters). You should also disable the Memcached installation with the `enabled` option. Here is an example: - -```console -memcachedchunks.enabled=false -externalMemcachedChunks.host=myexternalhost -externalMemcachedChunks.port=11211 -``` - ## 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). diff --git a/bitnami/grafana-operator/README.md b/bitnami/grafana-operator/README.md index e25effb541..5ee39a37d1 100644 --- a/bitnami/grafana-operator/README.md +++ b/bitnami/grafana-operator/README.md @@ -24,35 +24,6 @@ This chart bootstraps a [Grafana Operator](https://github.com/integr8ly/grafana- Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters. -## Prerequisites - -- Kubernetes 1.23+ -- Helm 3.8.0+ - -## Installing the Chart - -To install the chart with the release name `my-release`: - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/grafana-operator -``` - -> 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`. - -These commands deploy grafana-operator on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. - -> **Tip**: List all releases using `helm list` - -## Uninstalling the Chart - -To uninstall/delete the `my-release` helm release: - -```console -helm uninstall my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Differences between the Bitnami Grafana chart and the Bitnami Grafana Operator chart The Bitnami catalog offers both the `bitnami/grafana` and `bitnami/grafana-operator` charts. Each solution covers different needs and use cases. @@ -137,6 +108,89 @@ The Operator will extend the Kubernetes API with the following objects: _Grafana [Learn more about managing multiple Grafana instances and dashboards on Kubernetes with the Grafana Operator](https://docs.bitnami.com/tutorials/manage-multiple-grafana-operator). +## Prerequisites + +- Kubernetes 1.23+ +- Helm 3.8.0+ + +## Installing the Chart + +To install the chart with the release name `my-release`: + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/grafana-operator +``` + +> 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`. + +These commands deploy grafana-operator on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. + +> **Tip**: List all releases using `helm list` + +## 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. + +### Create Grafana Dashboards + +After the installation, create Dashboards under a CRD of your Kubernetes cluster. + +For more details regarding what is possible with those CRDs please have a look at [Working with Dashboards](https://github.com/integr8ly/grafana-operator/blob/master/documentation/dashboards.md). + +### Deploy extra Grafana resources or objects + +There are cases where you may want to deploy extra objects, such as custom _Grafana_, _GrafanaDashboard_ or _GrafanaDataSource_ objects. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +For instance, to deploy a custom Grafana definition, install the Grafana Operator chart using the values below: + +```yaml +grafana: + enabled: false +extraDeploy: + - apiVersion: integreatly.org/v1alpha1 + baseImage: docker.io/bitnami/grafana:7 + kind: Grafana + metadata: + name: grafana + spec: + deployment: + securityContext: + runAsUser: 1001 + fsGroup: 1001 + containerSecurityContext: + runAsUser: 1001 + fsGroup: 1001 + allowPrivilegeEscalation: false + service: + type: LoadBalancer + ingress: + enabled: false + config: + log: + mode: "console" + level: "warn" + security: + admin_user: "admin" + admin_password: "hello" + auth.anonymous: + enabled: true + dashboardLabelSelector: + - matchExpressions: + - { key: app, operator: In, values: [grafana] } +``` + +[Learn more about managing multiple Grafana instances and dashboards on Kubernetes with the Grafana Operator](https://docs.bitnami.com/tutorials/manage-multiple-grafana-operator). + ## Parameters ### Global parameters @@ -369,70 +423,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/grafa > 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`. -## 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. - -### Create Grafana Dashboards - -After the installation, create Dashboards under a CRD of your Kubernetes cluster. - -For more details regarding what is possible with those CRDs please have a look at [Working with Dashboards](https://github.com/integr8ly/grafana-operator/blob/master/documentation/dashboards.md). - -### Deploy extra Grafana resources or objects - -There are cases where you may want to deploy extra objects, such as custom _Grafana_, _GrafanaDashboard_ or _GrafanaDataSource_ objects. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -For instance, to deploy a custom Grafana definition, install the Grafana Operator chart using the values below: - -```yaml -grafana: - enabled: false -extraDeploy: - - apiVersion: integreatly.org/v1alpha1 - baseImage: docker.io/bitnami/grafana:7 - kind: Grafana - metadata: - name: grafana - spec: - deployment: - securityContext: - runAsUser: 1001 - fsGroup: 1001 - containerSecurityContext: - runAsUser: 1001 - fsGroup: 1001 - allowPrivilegeEscalation: false - service: - type: LoadBalancer - ingress: - enabled: false - config: - log: - mode: "console" - level: "warn" - security: - admin_user: "admin" - admin_password: "hello" - auth.anonymous: - enabled: true - dashboardLabelSelector: - - matchExpressions: - - { key: app, operator: In, values: [grafana] } -``` - -[Learn more about managing multiple Grafana instances and dashboards on Kubernetes with the Grafana Operator](https://docs.bitnami.com/tutorials/manage-multiple-grafana-operator). - ## 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). diff --git a/bitnami/grafana-tempo/README.md b/bitnami/grafana-tempo/README.md index 9ef06d3e61..f637d77217 100644 --- a/bitnami/grafana-tempo/README.md +++ b/bitnami/grafana-tempo/README.md @@ -44,15 +44,121 @@ The command deploys grafana-tempo on the Kubernetes cluster in the default confi > **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 -```console -helm delete my-release +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. + +### Tempo configuration + +The tempo configuration file `tempo.yaml` is shared across the different components: `distributor`, `compactor`, `ingester`, `querier` and `queryFrontend`. This is set in the `tempo.configuration` value. Check the official [Tempo Grafana documentation](https://grafana.com/docs/tempo/latest/configuration/) for the list of possible configurations. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. + +```yaml +compactor: + extraEnvVars: + - name: LOG_LEVEL + value: error + +distributor: + extraEnvVars: + - name: LOG_LEVEL + value: error + +ingester: + extraEnvVars: + - name: LOG_LEVEL + value: error + +querier: + extraEnvVars: + - name: LOG_LEVEL + value: error + +queryFrontend: + extraEnvVars: + - name: LOG_LEVEL + value: error + +vulture: + extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as grafana-tempo (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture` . + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. + +### External cache support + +You may want to have Grafana Tempo connect to an external Memcached rather than installing one inside your cluster. Typical reasons for this are to use a managed cache service, or to share a common cache server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalMemcached` parameter](#parameters). You should also disable the Memcached installation with the `memcached.enabled` option. Here is an example: + +```console +memcached.enabled=false +externalMemcached.host=myexternalhost +externalMemcached.port=11211 +``` + +## Persistence + +The [Bitnami grafana-tempo](https://github.com/bitnami/containers/tree/main/bitnami/grafana-tempo) image stores the grafana-tempo `ingester` data at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. ## Parameters @@ -926,122 +1032,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/grafa > 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/grafana-tempo/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. - -### Tempo configuration - -The tempo configuration file `tempo.yaml` is shared across the different components: `distributor`, `compactor`, `ingester`, `querier` and `queryFrontend`. This is set in the `tempo.configuration` value. Check the official [Tempo Grafana documentation](https://grafana.com/docs/tempo/latest/configuration/) for the list of possible configurations. - -## Persistence - -The [Bitnami grafana-tempo](https://github.com/bitnami/containers/tree/main/bitnami/grafana-tempo) image stores the grafana-tempo `ingester` data at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. - -```yaml -compactor: - extraEnvVars: - - name: LOG_LEVEL - value: error - -distributor: - extraEnvVars: - - name: LOG_LEVEL - value: error - -ingester: - extraEnvVars: - - name: LOG_LEVEL - value: error - -querier: - extraEnvVars: - - name: LOG_LEVEL - value: error - -queryFrontend: - extraEnvVars: - - name: LOG_LEVEL - value: error - -vulture: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as grafana-tempo (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture` . - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. - -### External cache support - -You may want to have Grafana Tempo connect to an external Memcached rather than installing one inside your cluster. Typical reasons for this are to use a managed cache service, or to share a common cache server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalMemcached` parameter](#parameters). You should also disable the Memcached installation with the `memcached.enabled` option. Here is an example: - -```console -memcached.enabled=false -externalMemcached.host=myexternalhost -externalMemcached.port=11211 -``` - ## 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). diff --git a/bitnami/grafana/README.md b/bitnami/grafana/README.md index 3896a67d69..03a83e3e1f 100644 --- a/bitnami/grafana/README.md +++ b/bitnami/grafana/README.md @@ -22,37 +22,6 @@ This chart bootstraps a [grafana](https://github.com/bitnami/containers/tree/mai Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters. -## Prerequisites - -- Kubernetes 1.23+ -- Helm 3.8.0+ -- PV provisioner support in the underlying infrastructure -- ReadWriteMany volumes for deployment scaling - -## Installing the Chart - -To install the chart with the release name `my-release`: - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/grafana -``` - -> 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`. - -These commands deploy grafana on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. - -> **Tip**: List all releases using `helm list` - -## Uninstalling the Chart - -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all persistent volumes too. - ## Differences between the Bitnami Grafana chart and the Bitnami Grafana Operator chart In the Bitnami catalog we offer both the bitnami/grafana and bitnami/grafana-operator charts. Each solution covers different needs and use cases. @@ -136,6 +105,261 @@ The operator will extend the Kubernetes API with the following objects: *Grafana This solution allows to easily deploy multiple Grafana instances compared to the *bitnami/grafana* chart. As the operator automatically deploys Grafana installations, the Grafana Operator pods will require a ServiceAccount with privileges to create and destroy mulitple Kubernetes objects. This may be problematic for Kubernetes clusters with strict role-based access policies. +## Prerequisites + +- Kubernetes 1.23+ +- Helm 3.8.0+ +- PV provisioner support in the underlying infrastructure +- ReadWriteMany volumes for deployment scaling + +## Installing the Chart + +To install the chart with the release name `my-release`: + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/grafana +``` + +> 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`. + +These commands deploy grafana on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. + +> **Tip**: List all releases using `helm list` + +## 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. + +### Using custom configuration + +Grafana supports multiples configuration files. Using kubernetes you can mount a file using a ConfigMap or a Secret. For example, to mount a custom `grafana.ini` file or `custom.ini` file you can create a ConfigMap like the following: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: myconfig +data: + grafana.ini: |- + # Raw text of the file +``` + +And now you need to pass the ConfigMap name, to the corresponding parameters: `config.useGrafanaIniFile=true` and `config.grafanaIniConfigMap=myconfig`. + +To provide dashboards on deployment time, Grafana needs a dashboards provider and the dashboards themselves. +A default provider is created if enabled, or you can mount your own provider using a ConfigMap, but have in mind that the path to the dashboard folder must be `/opt/bitnami/grafana/dashboards`. + + 1. To create a dashboard, it is needed to have a datasource for it. The datasources must be created mounting a secret with all the datasource files in it. In this case, it is not a ConfigMap because the datasource could contain sensitive information. + 2. To load the dashboards themselves you need to create a ConfigMap for each one containing the `json` file that defines the dashboard and set the array with the ConfigMap names into the `dashboardsConfigMaps` parameter. +Note the difference between the datasources and the dashboards creation. For the datasources we can use just one secret with all of the files, while for the dashboards we need one ConfigMap per file. + +For example, create the dashboard ConfigMap(s) and datasource Secret as described below: + +```console +kubectl create secret generic datasource-secret --from-file=datasource-secret.yaml +kubectl create configmap my-dashboard-1 --from-file=my-dashboard-1.json +kubectl create configmap my-dashboard-2 --from-file=my-dashboard-2.json +``` + +> Note: the commands above assume you had previously exported your dashboards in the JSON files: *my-dashboard-1.json* and *my-dashboard-2.json* +> Note: the commands above assume you had previously created a datasource config file *datasource-secret.yaml*. Find an example at + +Once you have them, use the following parameters to deploy Grafana with 2 custom dashboards: + +```console +dashboardsProvider.enabled=true +datasources.secretName=datasource-secret +dashboardsConfigMaps[0].configMapName=my-dashboard-1 +dashboardsConfigMaps[0].fileName=my-dashboard-1.json +dashboardsConfigMaps[1].configMapName=my-dashboard-2 +dashboardsConfigMaps[1].fileName=my-dashboard-2.json +``` + +More info at [Grafana documentation](https://grafana.com/docs/grafana/latest/administration/provisioning/#dashboards). + +### LDAP configuration + +To enable LDAP authentication it is necessary to provide a ConfigMap with the Grafana LDAP configuration file. For instance: + +**configmap.yaml**: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: ldap-config +data: + ldap.toml: |- + [[servers]] + # Ldap server host (specify multiple hosts space separated) + host = "ldap" + # Default port is 389 or 636 if use_ssl = true + port = 389 + # Set to true if ldap server supports TLS + use_ssl = false + # Set to true if connect ldap server with STARTTLS pattern (create connection in insecure, then upgrade to secure connection with TLS) + start_tls = false + # set to true if you want to skip ssl cert validation + ssl_skip_verify = false + # set to the path to your root CA certificate or leave unset to use system defaults + # root_ca_cert = "/path/to/certificate.crt" + # Authentication against LDAP servers requiring client certificates + # client_cert = "/path/to/client.crt" + # client_key = "/path/to/client.key" + + # Search user bind dn + bind_dn = "cn=admin,dc=example,dc=org" + # Search user bind password + # If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;""" + bind_password = 'admin' + + # User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)" + # Allow login from email or username, example "(|(sAMAccountName=%s)(userPrincipalName=%s))" + search_filter = "(uid=%s)" + + # An array of base dns to search through + search_base_dns = ["ou=People,dc=support,dc=example,dc=org"] + + # group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))" + # group_search_filter_user_attribute = "distinguishedName" + # group_search_base_dns = ["ou=groups,dc=grafana,dc=org"] + + # Specify names of the ldap attributes your ldap uses + [servers.attributes] + name = "givenName" + surname = "sn" + username = "cn" + member_of = "memberOf" + email = "email" +``` + +Create the ConfigMap into the cluster and deploy the Grafana Helm Chart using the existing ConfigMap and the following parameters: + +```console +ldap.enabled=true +ldap.configMapName=ldap-config +ldap.allowSignUp=true +``` + +### Installing Grafana Image Renderer Plugin + +In order to install the [Grafana Image Renderer Plugin](https://github.com/grafana/grafana-image-renderer) so you rely on it to render images and save memory on Grafana pods, follow the steps below: + +1. Create a Grafana Image Renderer deployment and service using the K8s manifests below: + +```yaml +# deployment.yaml +apiVersion: apps/v1 +kind: Deployment +metadata: + name: grafana-image-renderer + namespace: default + labels: + app.kubernetes.io/name: grafana-image-renderer + app.kubernetes.io/instance: grafana-image-renderer + app.kubernetes.io/component: image-renderer-plugin + app.kubernetes.io/part-of: grafana +spec: + replicas: 1 + strategy: + type: RollingUpdate + selector: + matchLabels: + app.kubernetes.io/name: grafana-image-renderer + app.kubernetes.io/instance: grafana-image-renderer + app.kubernetes.io/component: image-renderer-plugin + template: + metadata: + labels: + app.kubernetes.io/name: grafana-image-renderer + app.kubernetes.io/instance: grafana-image-renderer + app.kubernetes.io/component: image-renderer-plugin + app.kubernetes.io/part-of: grafana + spec: + securityContext: + fsGroup: 1001 + runAsNonRoot: true + runAsUser: 1001 + containers: + - name: grafana-image-renderer + image: docker.io/bitnami/grafana-image-renderer:3 + securityContext: + runAsUser: 1001 + env: + - name: HTTP_HOST + value: "::" + - name: HTTP_PORT + value: "8080" + ports: + - name: http + containerPort: 8080 + protocol: TCP +# service.yaml +apiVersion: v1 +kind: Service +metadata: + name: grafana-image-renderer + namespace: default + labels: + app.kubernetes.io/name: grafana-image-renderer + app.kubernetes.io/instance: grafana-image-renderer + app.kubernetes.io/component: image-renderer-plugin + app.kubernetes.io/part-of: grafana +spec: + type: ClusterIP + sessionAffinity: None + ports: + - port: 8080 + targetPort: http + protocol: TCP + name: http + selector: + app.kubernetes.io/name: grafana-image-renderer + app.kubernetes.io/instance: grafana-image-renderer + app.kubernetes.io/component: image-renderer-plugin +``` + +1. Upgrade your chart release adding the following block to your `values.yaml` file: + +```yaml +imageRenderer: + enabled: true + serverURL: "http://grafana-image-renderer.default.svc.cluster.local:8080/render" + callbackURL: "http://grafana.default.svc.cluster.local:3000/" +``` + +> Note: the steps above assume an installation in the `default` namespace. If you are installing the chart in a different namespace, adjust the manifests and the `serverURL` & `callbackURL` values accordingly. + +### Supporting HA (High Availability) + +To support HA Grafana just need an external database where store dashboards, users and other persistent data. +To configure the external database provide a configuration file containing the [database section](https://grafana.com/docs/installation/configuration/#database) + +More information about Grafana HA [here](https://grafana.com/docs/tutorials/ha_setup/) + +### 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 Grafana](https://github.com/bitnami/containers/tree/main/bitnami/grafana) image stores the Grafana data and configurations at the `/opt/bitnami/grafana/data` 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. + ## Parameters ### Global parameters @@ -423,240 +647,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/grafa > 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/grafana/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. - -### Using custom configuration - -Grafana supports multiples configuration files. Using kubernetes you can mount a file using a ConfigMap or a Secret. For example, to mount a custom `grafana.ini` file or `custom.ini` file you can create a ConfigMap like the following: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: myconfig -data: - grafana.ini: |- - # Raw text of the file -``` - -And now you need to pass the ConfigMap name, to the corresponding parameters: `config.useGrafanaIniFile=true` and `config.grafanaIniConfigMap=myconfig`. - -To provide dashboards on deployment time, Grafana needs a dashboards provider and the dashboards themselves. -A default provider is created if enabled, or you can mount your own provider using a ConfigMap, but have in mind that the path to the dashboard folder must be `/opt/bitnami/grafana/dashboards`. - - 1. To create a dashboard, it is needed to have a datasource for it. The datasources must be created mounting a secret with all the datasource files in it. In this case, it is not a ConfigMap because the datasource could contain sensitive information. - 2. To load the dashboards themselves you need to create a ConfigMap for each one containing the `json` file that defines the dashboard and set the array with the ConfigMap names into the `dashboardsConfigMaps` parameter. -Note the difference between the datasources and the dashboards creation. For the datasources we can use just one secret with all of the files, while for the dashboards we need one ConfigMap per file. - -For example, create the dashboard ConfigMap(s) and datasource Secret as described below: - -```console -kubectl create secret generic datasource-secret --from-file=datasource-secret.yaml -kubectl create configmap my-dashboard-1 --from-file=my-dashboard-1.json -kubectl create configmap my-dashboard-2 --from-file=my-dashboard-2.json -``` - -> Note: the commands above assume you had previously exported your dashboards in the JSON files: *my-dashboard-1.json* and *my-dashboard-2.json* -> Note: the commands above assume you had previously created a datasource config file *datasource-secret.yaml*. Find an example at - -Once you have them, use the following parameters to deploy Grafana with 2 custom dashboards: - -```console -dashboardsProvider.enabled=true -datasources.secretName=datasource-secret -dashboardsConfigMaps[0].configMapName=my-dashboard-1 -dashboardsConfigMaps[0].fileName=my-dashboard-1.json -dashboardsConfigMaps[1].configMapName=my-dashboard-2 -dashboardsConfigMaps[1].fileName=my-dashboard-2.json -``` - -More info at [Grafana documentation](https://grafana.com/docs/grafana/latest/administration/provisioning/#dashboards). - -### LDAP configuration - -To enable LDAP authentication it is necessary to provide a ConfigMap with the Grafana LDAP configuration file. For instance: - -**configmap.yaml**: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: ldap-config -data: - ldap.toml: |- - [[servers]] - # Ldap server host (specify multiple hosts space separated) - host = "ldap" - # Default port is 389 or 636 if use_ssl = true - port = 389 - # Set to true if ldap server supports TLS - use_ssl = false - # Set to true if connect ldap server with STARTTLS pattern (create connection in insecure, then upgrade to secure connection with TLS) - start_tls = false - # set to true if you want to skip ssl cert validation - ssl_skip_verify = false - # set to the path to your root CA certificate or leave unset to use system defaults - # root_ca_cert = "/path/to/certificate.crt" - # Authentication against LDAP servers requiring client certificates - # client_cert = "/path/to/client.crt" - # client_key = "/path/to/client.key" - - # Search user bind dn - bind_dn = "cn=admin,dc=example,dc=org" - # Search user bind password - # If the password contains # or ; you have to wrap it with triple quotes. Ex """#password;""" - bind_password = 'admin' - - # User search filter, for example "(cn=%s)" or "(sAMAccountName=%s)" or "(uid=%s)" - # Allow login from email or username, example "(|(sAMAccountName=%s)(userPrincipalName=%s))" - search_filter = "(uid=%s)" - - # An array of base dns to search through - search_base_dns = ["ou=People,dc=support,dc=example,dc=org"] - - # group_search_filter = "(&(objectClass=posixGroup)(memberUid=%s))" - # group_search_filter_user_attribute = "distinguishedName" - # group_search_base_dns = ["ou=groups,dc=grafana,dc=org"] - - # Specify names of the ldap attributes your ldap uses - [servers.attributes] - name = "givenName" - surname = "sn" - username = "cn" - member_of = "memberOf" - email = "email" -``` - -Create the ConfigMap into the cluster and deploy the Grafana Helm Chart using the existing ConfigMap and the following parameters: - -```console -ldap.enabled=true -ldap.configMapName=ldap-config -ldap.allowSignUp=true -``` - -### Installing Grafana Image Renderer Plugin - -In order to install the [Grafana Image Renderer Plugin](https://github.com/grafana/grafana-image-renderer) so you rely on it to render images and save memory on Grafana pods, follow the steps below: - -1. Create a Grafana Image Renderer deployment and service using the K8s manifests below: - -```yaml -# deployment.yaml -apiVersion: apps/v1 -kind: Deployment -metadata: - name: grafana-image-renderer - namespace: default - labels: - app.kubernetes.io/name: grafana-image-renderer - app.kubernetes.io/instance: grafana-image-renderer - app.kubernetes.io/component: image-renderer-plugin - app.kubernetes.io/part-of: grafana -spec: - replicas: 1 - strategy: - type: RollingUpdate - selector: - matchLabels: - app.kubernetes.io/name: grafana-image-renderer - app.kubernetes.io/instance: grafana-image-renderer - app.kubernetes.io/component: image-renderer-plugin - template: - metadata: - labels: - app.kubernetes.io/name: grafana-image-renderer - app.kubernetes.io/instance: grafana-image-renderer - app.kubernetes.io/component: image-renderer-plugin - app.kubernetes.io/part-of: grafana - spec: - securityContext: - fsGroup: 1001 - runAsNonRoot: true - runAsUser: 1001 - containers: - - name: grafana-image-renderer - image: docker.io/bitnami/grafana-image-renderer:3 - securityContext: - runAsUser: 1001 - env: - - name: HTTP_HOST - value: "::" - - name: HTTP_PORT - value: "8080" - ports: - - name: http - containerPort: 8080 - protocol: TCP -# service.yaml -apiVersion: v1 -kind: Service -metadata: - name: grafana-image-renderer - namespace: default - labels: - app.kubernetes.io/name: grafana-image-renderer - app.kubernetes.io/instance: grafana-image-renderer - app.kubernetes.io/component: image-renderer-plugin - app.kubernetes.io/part-of: grafana -spec: - type: ClusterIP - sessionAffinity: None - ports: - - port: 8080 - targetPort: http - protocol: TCP - name: http - selector: - app.kubernetes.io/name: grafana-image-renderer - app.kubernetes.io/instance: grafana-image-renderer - app.kubernetes.io/component: image-renderer-plugin -``` - -1. Upgrade your chart release adding the following block to your `values.yaml` file: - -```yaml -imageRenderer: - enabled: true - serverURL: "http://grafana-image-renderer.default.svc.cluster.local:8080/render" - callbackURL: "http://grafana.default.svc.cluster.local:3000/" -``` - -> Note: the steps above assume an installation in the `default` namespace. If you are installing the chart in a different namespace, adjust the manifests and the `serverURL` & `callbackURL` values accordingly. - -### Supporting HA (High Availability) - -To support HA Grafana just need an external database where store dashboards, users and other persistent data. -To configure the external database provide a configuration file containing the [database section](https://grafana.com/docs/installation/configuration/#database) - -More information about Grafana HA [here](https://grafana.com/docs/tutorials/ha_setup/) - -### 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 Grafana](https://github.com/bitnami/containers/tree/main/bitnami/grafana) image stores the Grafana data and configurations at the `/opt/bitnami/grafana/data` 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. - ## 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). @@ -726,7 +716,7 @@ Deployment label selector is immutable after it gets created, so you cannot "upg In the deployment label selectors of the resources were updated to add the component name. Resulting in compatibility breakage. -In order to "upgrade" from a previous version, you will need to [uninstall](#uninstalling-the-chart) the existing chart manually. +In order to "upgrade" from a previous version, you will need to uninstall the existing chart manually. This major version signifies this change. @@ -744,4 +734,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. \ No newline at end of file +limitations under the License. diff --git a/bitnami/haproxy/README.md b/bitnami/haproxy/README.md index 5b15189f21..48657bb50a 100644 --- a/bitnami/haproxy/README.md +++ b/bitnami/haproxy/README.md @@ -43,15 +43,135 @@ The command deploys haproxy on the Kubernetes cluster in the default configurati > **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 -```console -helm delete my-release +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. + +### Configure HAProxy + +By default, HAProxy is deployed with a sample, non-functional, configuration. You will need to edit the following values to adapt it to your use case: + +- Set the configuration to be injected in the `haproxy.cfg` file by changing the `configuration` parameter. Alternatively, you can provide an existing ConfigMap with `haproxy.cfg` by using the `existingConfigmap` parameter. + + The example below configures HAProxy to forward all requests to port 8080 to a service called *service1:8080* (it is assumed that this is accessible from inside the cluster). + + ```yaml + configuration: | + global + log 127.0.0.1 local2 + maxconn 4096 + + defaults + mode http + log global + option httplog + option dontlognull + option http-server-close + option forwardfor except 127.0.0.0/8 + option redispatch + retries 3 + timeout http-request 20s + timeout queue 1m + timeout connect 10s + timeout client 1m + timeout server 1m + timeout http-keep-alive 30s + timeout check 10s + maxconn 3000 + + frontend fe_http + option forwardfor except 127.0.0.1 + option httpclose + bind *:8080 + default_backend be_http + + backend be_http + balance roundrobin + server nginx service:8080 check port 8080 + ``` + +- Based on your HAProxy configuration, edit the `containerPorts` and `service.ports` parameters. In the `containerPorts` parameter, set all the ports that the HAProxy configuration uses, and in the `service.ports` parameter, set the ports to be externally exposed. + + For the example above, the configuration would look like this: + + ```yaml + service: + - name: http + port: 80 # We use port 80 in the service + targetPort: http + + containerPorts: + - name: http + containerPort: 8080 + ``` + +### Add extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. ## Parameters @@ -236,136 +356,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/hapro > 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/haproxy/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. - -### Configure HAProxy - -By default, HAProxy is deployed with a sample, non-functional, configuration. You will need to edit the following values to adapt it to your use case: - -- Set the configuration to be injected in the `haproxy.cfg` file by changing the `configuration` parameter. Alternatively, you can provide an existing ConfigMap with `haproxy.cfg` by using the `existingConfigmap` parameter. - - The example below configures HAProxy to forward all requests to port 8080 to a service called *service1:8080* (it is assumed that this is accessible from inside the cluster). - - ```yaml - configuration: | - global - log 127.0.0.1 local2 - maxconn 4096 - - defaults - mode http - log global - option httplog - option dontlognull - option http-server-close - option forwardfor except 127.0.0.0/8 - option redispatch - retries 3 - timeout http-request 20s - timeout queue 1m - timeout connect 10s - timeout client 1m - timeout server 1m - timeout http-keep-alive 30s - timeout check 10s - maxconn 3000 - - frontend fe_http - option forwardfor except 127.0.0.1 - option httpclose - bind *:8080 - default_backend be_http - - backend be_http - balance roundrobin - server nginx service:8080 check port 8080 - ``` - -- Based on your HAProxy configuration, edit the `containerPorts` and `service.ports` parameters. In the `containerPorts` parameter, set all the ports that the HAProxy configuration uses, and in the `service.ports` parameter, set the ports to be externally exposed. - - For the example above, the configuration would look like this: - - ```yaml - service: - - name: http - port: 80 # We use port 80 in the service - targetPort: http - - containerPorts: - - name: http - containerPort: 8080 - ``` - -### Add extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/harbor/README.md b/bitnami/harbor/README.md index bc81dbb4d6..65799ba701 100644 --- a/bitnami/harbor/README.md +++ b/bitnami/harbor/README.md @@ -49,15 +49,120 @@ helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/harbor > 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`. -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` deployment: +### Resource requests and limits -```console -helm delete --purge my-release +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. + +### Configure the way how to expose Harbor core + +You can expose Harbor core using two methods: + +- An Ingress Controller, `exposureType` should be set to `ingress`. + - An ingress controller must be installed in the Kubernetes cluster. + - If the TLS is disabled, the port must be included in the command when pulling/pushing images. Refer to issue [#5291](https://github.com/goharbor/harbor/issues/5291) for the detail. +- An NGINX Proxy, `exposureType` should be set to `proxy`. There are three ways to do so depending on the NGINX Proxy service type: + - **ClusterIP**: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster: + - **NodePort**: Exposes the service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort service, from outside the cluster, by requesting `NodeIP:NodePort`. + - **LoadBalancer**: Exposes the service externally using a cloud provider's load balancer. + +### Configure the external URL + +The external URL for Harbor core service is used to: + +1. populate the docker/helm commands showed on portal + +Format: `protocol://domain[:port]`. Usually: + +- if expose Harbor core service via Ingress, the `domain` should be the value of `ingress.core.hostname`. +- if expose Harbor core via NGINX proxy using a `ClusterIP` service type, the `domain` should be the value of `service.clusterIP`. +- if expose Harbor core via NGINX proxy using a `NodePort` service type, the `domain` should be the IP address of one Kubernetes node. +- if expose Harbor core via NGINX proxy using a `LoadBalancer` service type, set the `domain` as your own domain name and add a CNAME record to map the domain name to the one you got from the cloud provider. + +If Harbor is deployed behind the proxy, set it as the URL of proxy. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as any of the Harbor components (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter inside each component subsection. Simply define your container according to the Kubernetes container spec. + +```yaml +core: + sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -Additionally, if `persistence.resourcePolicy` is set to `keep`, you should manually delete the PVCs. +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +core: + initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each component subsection. + +```yaml +core: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside each component subsection. + +### Configure data persistence + +- **Disable**: The data does not survive the termination of a pod. +- **Persistent Volume Claim(default)**: A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `storageClass` or set `existingClaim` if you have already existing persistent volumes to use. +- **External Storage(only for images and charts)**: For images and charts, the external storages are supported: `azure`, `gcs`, `s3` `swift` and `oss`. + +### Configure the secrets + +- **Secrets**: Secrets are used for encryption and to secure communication between components. Fill `core.secret`, `jobservice.secret` and `registry.secret` to configure then statically through the helm values. it expects the "key or password", not the secret name where secrets are stored. +- **Certificates**: Used for token encryption/decryption. Fill `core.secretName` to configure. + +Secrets and certificates must be setup to avoid changes on every Helm upgrade (see: [#107](https://github.com/goharbor/harbor-helm/issues/107)). + +If you want to manage full Secret objects by your own, you can use existingSecret & existingEnvVarsSecret parameters. This could be useful for some secure GitOps workflows, of course, you will have to ensure to define all expected keys for those secrets. + +The core service have two `Secret` objects, the default one for data & communication which is very important as it's contains the data encryption key of your harbor instance ! and a second one which contains standard passwords, database access password, ... +Keep in mind that the `HARBOR_ADMIN_PASSWORD` is only used to boostrap your harbor instance, if you update it after the deployment, the password is updated in database, but the secret will remain the initial one. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +### Adjust permissions of persistent volume mountpoint + +As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -1057,121 +1162,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/harbo > 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`. -## 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. - -### Configure the way how to expose Harbor core - -You can expose Harbor core using two methods: - -- An Ingress Controller, `exposureType` should be set to `ingress`. - - An ingress controller must be installed in the Kubernetes cluster. - - If the TLS is disabled, the port must be included in the command when pulling/pushing images. Refer to issue [#5291](https://github.com/goharbor/harbor/issues/5291) for the detail. -- An NGINX Proxy, `exposureType` should be set to `proxy`. There are three ways to do so depending on the NGINX Proxy service type: - - **ClusterIP**: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster: - - **NodePort**: Exposes the service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort service, from outside the cluster, by requesting `NodeIP:NodePort`. - - **LoadBalancer**: Exposes the service externally using a cloud provider's load balancer. - -### Configure the external URL - -The external URL for Harbor core service is used to: - -1. populate the docker/helm commands showed on portal - -Format: `protocol://domain[:port]`. Usually: - -- if expose Harbor core service via Ingress, the `domain` should be the value of `ingress.core.hostname`. -- if expose Harbor core via NGINX proxy using a `ClusterIP` service type, the `domain` should be the value of `service.clusterIP`. -- if expose Harbor core via NGINX proxy using a `NodePort` service type, the `domain` should be the IP address of one Kubernetes node. -- if expose Harbor core via NGINX proxy using a `LoadBalancer` service type, set the `domain` as your own domain name and add a CNAME record to map the domain name to the one you got from the cloud provider. - -If Harbor is deployed behind the proxy, set it as the URL of proxy. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as any of the Harbor components (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter inside each component subsection. Simply define your container according to the Kubernetes container spec. - -```yaml -core: - sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -core: - initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each component subsection. - -```yaml -core: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside each component subsection. - -### Configure data persistence - -- **Disable**: The data does not survive the termination of a pod. -- **Persistent Volume Claim(default)**: A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `storageClass` or set `existingClaim` if you have already existing persistent volumes to use. -- **External Storage(only for images and charts)**: For images and charts, the external storages are supported: `azure`, `gcs`, `s3` `swift` and `oss`. - -### Configure the secrets - -- **Secrets**: Secrets are used for encryption and to secure communication between components. Fill `core.secret`, `jobservice.secret` and `registry.secret` to configure then statically through the helm values. it expects the "key or password", not the secret name where secrets are stored. -- **Certificates**: Used for token encryption/decryption. Fill `core.secretName` to configure. - -Secrets and certificates must be setup to avoid changes on every Helm upgrade (see: [#107](https://github.com/goharbor/harbor-helm/issues/107)). - -If you want to manage full Secret objects by your own, you can use existingSecret & existingEnvVarsSecret parameters. This could be useful for some secure GitOps workflows, of course, you will have to ensure to define all expected keys for those secrets. - -The core service have two `Secret` objects, the default one for data & communication which is very important as it's contains the data encryption key of your harbor instance ! and a second one which contains standard passwords, database access password, ... -Keep in mind that the `HARBOR_ADMIN_PASSWORD` is only used to boostrap your harbor instance, if you update it after the deployment, the password is updated in database, but the secret will remain the initial one. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -### Adjust permissions of persistent volume mountpoint - -As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/influxdb/README.md b/bitnami/influxdb/README.md index f752865588..29e9fc5d5e 100644 --- a/bitnami/influxdb/README.md +++ b/bitnami/influxdb/README.md @@ -43,15 +43,101 @@ These commands deploy influxdb on the Kubernetes cluster in the default configur > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` statefulset: +### Resource requests and limits -```console -helm delete my-release +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. + +This chart installs a deployment with the following configuration: + +```text + ------------------ + | Ingress | + | Controller | + ------------------ + | + | /query + | /write + \/ + ---------------- + | InfluxDB(TM) | + | svc | + ---------------- + | + \/ + -------------- + | InfluxDB(TM) | + | Server | + | Pod | + -------------- ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +### Configure the way how to expose InfluxDB™ + +- **Ingress**: The ingress controller must be installed in the Kubernetes cluster. Set `ingress.enabled=true` to expose InfluxDB™ through Ingress. +- **ClusterIP**: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. Set `influxdb.service.type=ClusterIP` to choose this service type. +- **NodePort**: Exposes the service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort service, from outside the cluster, by requesting `NodeIP:NodePort`. Set `influxdb.service.type=NodePort` to choose this service type. +- **LoadBalancer**: Exposes the service externally using a cloud provider's load balancer. Set `influxdb.service.type=LoadBalancer` to choose this service type. + +### Using custom configuration + +This helm chart supports to customize the whole configuration file. + +Add your custom configuration file to "files/conf" in your working directory. This file will be mounted as a configMap to the containers and it will be used for configuring InfluxDB™. + +Alternatively, you can specify the InfluxDB™ configuration using the `influxdb.configuration` parameter. + +In addition to these options, you can also set an external ConfigMap with all the configuration files. This is done by setting the `influxdb.existingConfiguration` parameter. Note that this will override the two previous options. + +### Adding extra environment variables + +In case you want to add extra environment variables, you can use the `influxdb.extraEnvVars` property. + +```yaml +extraEnvVars: + - name: INFLUXDB_DATA_QUERY_LOG_ENABLED + value: "true" +``` + +### Initialize a fresh instance + +The [Bitnami InfluxDB™](https://github.com/bitnami/containers/tree/main/bitnami/influxdb) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, they must be located inside the chart folder `files/docker-entrypoint-initdb.d` so they can be consumed as a ConfigMap. + +Alternatively, you can specify custom scripts using the `influxdb.initdbScripts` parameter. + +In addition to these options, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `influxdb.initdbScriptsCM` parameter. Note that this will override the two previous options. parameter. + +The allowed extensions are `.sh`, and `.txt`. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The data is persisted by default using PVC(s). You can disable the persistence setting the `persistence.enabled` parameter to `false`. +A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `persistence.storageClass` or set `persistence.existingClaim` if you have already existing persistent volumes to use. + +### Adjust permissions of persistent volume mountpoint + +As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this **initContainer** by setting `volumePermissions.enabled` to `true`. +There are K8s distribution, such as OpenShift, where you can dynamically define the UID to run this **initContainer**. To do so, set the `volumePermissions.securityContext.runAsUser` to `auto`. ## Parameters @@ -358,139 +444,11 @@ The command removes all the Kubernetes components associated with the chart and | `backup.uploadProviders.aws.resourcesPreset` | Set container resources according to one common preset (allowed values: none, nano, small, medium, large, xlarge, 2xlarge). This is ignored if influxdb.resources is set (influxdb.resources is recommended for production). | `none` | | `backup.uploadProviders.aws.resources` | Set container requests and limits for different resources like CPU or memory (essential for production workloads) | `{}` | -## RBAC Parameters - -| Name | Description | Value | -| `serviceAccount.create` | Specifies whether a ServiceAccount should be created | `true` | -| `serviceAccount.name` | Name of the service account to use. If not set and create is true, a name is generated using the fullname template. | `""` | -| `serviceAccount.automountServiceAccountToken` | Automount service account token for the server service account | `true` | -| `serviceAccount.annotations` | Annotations for service account. Evaluated as a template. Only used if `create` is `true`. | `{}` | -| `psp.create` | Whether to create a PodSecurityPolicy. WARNING: PodSecurityPolicy is deprecated in Kubernetes v1.21 or later, unavailable in v1.25 or later | `false` | -| `rbac.create` | Create Role and RoleBinding (required for PSP to work) | `false` | - -Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example, - -```console -helm install my-release \ - --set auth.admin.username=admin-user oci://REGISTRY_NAME/REPOSITORY_NAME/influxdb -``` - -> 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`. - -The above command sets the InfluxDB™ admin user to `admin-user`. - -> NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available. - -Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example, - -```console -helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/influxdb -``` - -> 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/influxdb/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. - -This chart installs a deployment with the following configuration: - -```text - ------------------ - | Ingress | - | Controller | - ------------------ - | - | /query - | /write - \/ - ---------------- - | InfluxDB(TM) | - | svc | - ---------------- - | - \/ - -------------- - | InfluxDB(TM) | - | Server | - | Pod | - -------------- -``` - -### Configure the way how to expose InfluxDB™ - -- **Ingress**: The ingress controller must be installed in the Kubernetes cluster. Set `ingress.enabled=true` to expose InfluxDB™ through Ingress. -- **ClusterIP**: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. Set `influxdb.service.type=ClusterIP` to choose this service type. -- **NodePort**: Exposes the service on each Node's IP at a static port (the NodePort). You'll be able to contact the NodePort service, from outside the cluster, by requesting `NodeIP:NodePort`. Set `influxdb.service.type=NodePort` to choose this service type. -- **LoadBalancer**: Exposes the service externally using a cloud provider's load balancer. Set `influxdb.service.type=LoadBalancer` to choose this service type. - -### Using custom configuration - -This helm chart supports to customize the whole configuration file. - -Add your custom configuration file to "files/conf" in your working directory. This file will be mounted as a configMap to the containers and it will be used for configuring InfluxDB™. - -Alternatively, you can specify the InfluxDB™ configuration using the `influxdb.configuration` parameter. - -In addition to these options, you can also set an external ConfigMap with all the configuration files. This is done by setting the `influxdb.existingConfiguration` parameter. Note that this will override the two previous options. - -### Adding extra environment variables - -In case you want to add extra environment variables, you can use the `influxdb.extraEnvVars` property. - -```yaml -extraEnvVars: - - name: INFLUXDB_DATA_QUERY_LOG_ENABLED - value: "true" -``` - -### Initialize a fresh instance - -The [Bitnami InfluxDB™](https://github.com/bitnami/containers/tree/main/bitnami/influxdb) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, they must be located inside the chart folder `files/docker-entrypoint-initdb.d` so they can be consumed as a ConfigMap. - -Alternatively, you can specify custom scripts using the `influxdb.initdbScripts` parameter. - -In addition to these options, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `influxdb.initdbScriptsCM` parameter. Note that this will override the two previous options. parameter. - -The allowed extensions are `.sh`, and `.txt`. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -## Persistence - -The data is persisted by default using PVC(s). You can disable the persistence setting the `persistence.enabled` parameter to `false`. -A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `persistence.storageClass` or set `persistence.existingClaim` if you have already existing persistent volumes to use. - -### Adjust permissions of persistent volume mountpoint - -As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this **initContainer** by setting `volumePermissions.enabled` to `true`. -There are K8s distribution, such as OpenShift, where you can dynamically define the UID to run this **initContainer**. To do so, set the `volumePermissions.securityContext.runAsUser` to `auto`. - ## 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). -## Upgrade +## Upgrading It's necessary to specify the existing passwords while performing an upgrade to ensure the secrets are not updated with invalid randomly generated passwords. Remember to specify the existing values of the `auth.admin.password`, `user.pwd`, `auth.readUser.password` and `auth.writeUser.password` parameters when upgrading the chart: @@ -505,8 +463,6 @@ helm upgrade my-release oci://REGISTRY_NAME/REPOSITORY_NAME/influxdb \ > 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`. > Note: you need to substitute the placeholders _[ADMIN_USER_PASSWORD]_, _[USER_PASSWORD]_, _[READ_USER_PASSWORD]_, and _[WRITE_USER_PASSWORD]_ with the values obtained from instructions in the installation notes. -## Upgrading - ### To 6.0.0 This major bump changes the following security defaults: diff --git a/bitnami/jaeger/README.md b/bitnami/jaeger/README.md index 0afd1fb1b3..063907e0fc 100644 --- a/bitnami/jaeger/README.md +++ b/bitnami/jaeger/README.md @@ -53,6 +53,103 @@ helm delete my-release The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +## 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. + +### External database support + +You may want to have Jaeger connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the Cassandra installation with the `cassandra.enabled` option. Here is an example: + +```console +cassandra.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.port=9042 +``` + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `collector`, `agent`, `query`. + +```yaml +collector: + extraEnvVars: + - name: ENV_VAR_NAME + value: ENV_VAR_VALUE + +agent: + extraEnvVars: + - name: ENV_VAR_NAME + value: ENV_VAR_VALUE + +query: + extraEnvVars: + - name: ENV_VAR_NAME + value: ENV_VAR_VALUE +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as jaeger (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `collector`, `agent`, `query` . + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. + +## Persistence + +The [Bitnami jaeger](https://github.com/bitnami/containers/tree/main/bitnami/jaeger) image stores the trace onto an external database. Persistent Volume Claims are used to keep the data across deployments. + ## Parameters ### Global parameters @@ -463,103 +560,6 @@ The command removes all the Kubernetes components associated with the chart and > **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/jaeger/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. - -### Persistence - -The [Bitnami jaeger](https://github.com/bitnami/containers/tree/main/bitnami/jaeger) image stores the trace onto an external database. Persistent Volume Claims are used to keep the data across deployments. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `collector`, `agent`, `query`. - -```yaml -collector: - extraEnvVars: - - name: ENV_VAR_NAME - value: ENV_VAR_VALUE - -agent: - extraEnvVars: - - name: ENV_VAR_NAME - value: ENV_VAR_VALUE - -query: - extraEnvVars: - - name: ENV_VAR_NAME - value: ENV_VAR_VALUE -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as jaeger (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `collector`, `agent`, `query` . - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside each of the subsections: `distributor`, `compactor`, `ingester`, `querier`, `queryFrontend` and `vulture`. - -### External database support - -You may want to have Jaeger connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the Cassandra installation with the `cassandra.enabled` option. Here is an example: - -```console -cassandra.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.port=9042 -``` - ## 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). diff --git a/bitnami/jenkins/README.md b/bitnami/jenkins/README.md index 23088076fe..fc9632bae0 100644 --- a/bitnami/jenkins/README.md +++ b/bitnami/jenkins/README.md @@ -43,15 +43,140 @@ These commands deploy Jenkins on the Kubernetes cluster in the default configura > **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 -```console -helm delete my-release +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. + +### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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/). + +### Configure TLS Secrets for use with 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----- ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +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`. + +### Configure extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG +``` + +Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Configure Sidecars and Init Containers + +If additional containers are needed in the same pod as Jenkins (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami Jenkins](https://github.com/bitnami/containers/tree/main/bitnami/jenkins) image stores the Jenkins data and configurations at the `/bitnami/jenkins` path of the container. Persistent Volume Claims (PVCs) are used to keep the data across deployments. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). +s ## Parameters @@ -368,141 +493,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/jenki > 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/jenkins/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. - -### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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/). - -### Configure TLS Secrets for use with 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`. - -### Configure extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Configure Sidecars and Init Containers - -If additional containers are needed in the same pod as Jenkins (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -## Persistence - -The [Bitnami Jenkins](https://github.com/bitnami/containers/tree/main/bitnami/jenkins) image stores the Jenkins data and configurations at the `/bitnami/jenkins` path of the container. Persistent Volume Claims (PVCs) are used to keep the data across deployments. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). -s - ## 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). diff --git a/bitnami/joomla/README.md b/bitnami/joomla/README.md index 173d282c44..8e37eef43b 100644 --- a/bitnami/joomla/README.md +++ b/bitnami/joomla/README.md @@ -46,15 +46,81 @@ The command deploys Joomla! on the Kubernetes cluster in the default configurati > **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. + +### Ingress without TLS + +For using ingress (example without TLS): ```console -helm delete my-release +ingress.enabled=True +ingress.hosts[0]=joomla.domain.com +serviceType=ClusterIP +joomlaUsername=admin +joomlaPassword=password +mariadb.mariadbRootPassword=secretpassword ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +These are the *3 mandatory parameters* when *Ingress* is desired: `ingress.enabled=True`, `ingress.hosts[0]=joomla.domain.com` and `serviceType=ClusterIP` + +### Ingress TLS + +If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. + +To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `joomla-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: + +```yaml +ingress: + ## If true, Joomla! server Ingress will be created + ## + enabled: true + + ## Joomla! server Ingress annotations + ## + annotations: {} + # kubernetes.io/ingress.class: nginx + # kubernetes.io/tls-acme: 'true' + + ## Joomla! server Ingress hostnames + ## Must be provided if Ingress is enabled + ## + hosts: + - joomla.domain.com + + ## Joomla! server Ingress TLS configuration + ## Secrets must be manually created in the namespace + ## + tls: + - secretName: joomla-server-tls + hosts: + - joomla.domain.com +``` + +### 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 Joomla!](https://github.com/bitnami/containers/tree/main/bitnami/joomla) image stores the Joomla! data and configurations at the `/bitnami/joomla` and `/bitnami/apache` paths of the container. + +Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, vpshere, and minikube. +See the [Parameters](#parameters) section to configure the PVC or to disable persistence. +You may want to review the [PV reclaim policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) and update as required. By default, it's set to delete, and when Joomla! is uninstalled, data is also removed. ## Parameters @@ -290,82 +356,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/jooml > 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/joomla/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. - -### Ingress without TLS - -For using ingress (example without TLS): - -```console -ingress.enabled=True -ingress.hosts[0]=joomla.domain.com -serviceType=ClusterIP -joomlaUsername=admin -joomlaPassword=password -mariadb.mariadbRootPassword=secretpassword -``` - -These are the *3 mandatory parameters* when *Ingress* is desired: `ingress.enabled=True`, `ingress.hosts[0]=joomla.domain.com` and `serviceType=ClusterIP` - -### Ingress TLS - -If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. - -To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `joomla-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: - -```yaml -ingress: - ## If true, Joomla! server Ingress will be created - ## - enabled: true - - ## Joomla! server Ingress annotations - ## - annotations: {} - # kubernetes.io/ingress.class: nginx - # kubernetes.io/tls-acme: 'true' - - ## Joomla! server Ingress hostnames - ## Must be provided if Ingress is enabled - ## - hosts: - - joomla.domain.com - - ## Joomla! server Ingress TLS configuration - ## Secrets must be manually created in the namespace - ## - tls: - - secretName: joomla-server-tls - hosts: - - joomla.domain.com -``` - -### 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 Joomla!](https://github.com/bitnami/containers/tree/main/bitnami/joomla) image stores the Joomla! data and configurations at the `/bitnami/joomla` and `/bitnami/apache` paths of the container. - -Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, vpshere, and minikube. -See the [Parameters](#parameters) section to configure the PVC or to disable persistence. -You may want to review the [PV reclaim policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) and update as required. By default, it's set to delete, and when Joomla! is uninstalled, data is also removed. - ## 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). diff --git a/bitnami/jupyterhub/README.md b/bitnami/jupyterhub/README.md index d46f83f5e4..0960a66170 100644 --- a/bitnami/jupyterhub/README.md +++ b/bitnami/jupyterhub/README.md @@ -24,36 +24,6 @@ This chart bootstraps a [JupyterHub](https://github.com/jupyterhub/jupyterhub) D Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters. -## Prerequisites - -- Kubernetes 1.23+ -- Helm 3.8.0+ -- PV provisioner support in the underlying infrastructure - -## Installing the Chart - -To install the chart with the release name `my-release`: - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/jupyterhub -``` - -> 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`. - -These commands deploy JupyterHub on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. - -> **Tip**: List all releases using `helm list` - -## Uninstalling the Chart - -To uninstall/delete the `my-release` helm release: - -```console -helm uninstall my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Architecture The JupyterHub chart deploys three basic elements: @@ -110,6 +80,240 @@ After accessing the hub and creating a Single User instance, the deployment look For more information, check the official [JupyterHub documentation](https://github.com/jupyterhub/jupyterhub). +## Prerequisites + +- Kubernetes 1.23+ +- Helm 3.8.0+ +- PV provisioner support in the underlying infrastructure + +## Installing the Chart + +To install the chart with the release name `my-release`: + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/jupyterhub +``` + +> 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`. + +These commands deploy JupyterHub on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. + +> **Tip**: List all releases using `helm list` + +## 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/). + +### Understand the default configuration + +This chart deploys three basic elements: + +- JupyterHub: Central element of the chart. Manages authentication and is responsible for creating the Jupyter Notebook instances (called Single User instances). As a consequence, the Hub requires special RBAC privileges in order to access the Kubernetes API to create and manage Deployments. +- Proxy: This is the external endpoint for users. It manages the communication with the Hub and the Single User instances. +- Image Puller: In order to improve the Single User instance boot time, a DaemonSet object is deployed that pre-pulls all the necessary images to run the Single User Notebooks. + +The following diagram shows a deployed release of the chart: + +```text + | + | + | + | + ------------------ | + | | | + | Image Puller |<------Pull images to------ + | | all nodes + ------------------ + + ------------- --------------- + | | | | + | Proxy |---------->| Hub | + | | | | + ------------- --------------- +``` + +After accessing the hub and creating a Single User instance, the deployment looks as follows: + +```text + | + | + | + | + ---------------- | + | | | + | Image Puller |<------Pull images to----- + | | all nodes + ---------------- + ----------- ------------- + | | | | + | Proxy |---------->| Hub | + | | | | + ----------- ------------- + | | + | | + | | + | --------------- | + | | Single User | | + ---->| Instance |<----- + --------------- +``` + +For more information, check the official [JupyterHub documentation](https://github.com/jupyterhub/jupyterhub). + +### [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. + +### Configure authentication + +The chart configures the Hub [DummyAuthenticator](https://github.com/jupyterhub/dummyauthenticator) by default, with the password set in the `hub.password` (auto-generated if not set) chart parameter and `user` as the administrator user. In order to change the authentication mechanism, change the `hub.config.JupyterHub` section inside the `hub.configuration` value. + +The following example sets the [NativeAuthenticator](https://github.com/jupyterhub/nativeauthenticator) authenticator, and configures an admin user called *test*. + +```yaml +hub: + configuration: | + ... + hub: + config: + JupyterHub: + admin_access: true + authenticator_class: nativeauthenticator.NativeAuthenticator + Authenticator: + admin_users: + - test + ... +``` + +When deploying, you will need to sign up to set the password for the `test`` user. + +For more information on Authenticators, check the [official JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/getting-started/authenticators-users-basics.html). + +### Configure the Single User instances + +As explained in this [section](#understand-the-default-configuration), the Hub is responsible for deploying the Single User instances. The configuration of these instances is passed to the Hub instance via the `hub.configuration` chart parameter. + +In order to make the chart follow standards and to ease the generation of this configuration file, the chart has a `singleuser` section, which is then used for generating the `hub.configuration` value. This value can be easily overridden by modifying its default value or by providing a secret via the `hub.existingSecret` value. In this case, all the settings in the `singleuser` section will be ignored. + +All the settings specified in the `hub.configuration` value are consumed by the `jupyter_config.py` script available in the [templates/hub/configmap.yaml](https://github.com/bitnami/charts/blob/main/bitnami/jupyterhub/templates/hub/configmap.yaml) file. This script can be changed by providing a custom ConfigMap via the `hub.existingConfigmap` value. The [official JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/reference/config-examples.html) has more examples of the `jupyter_config.py` script. + +### Restrict traffic using NetworkPolicies + +The Bitnami JupyterHub chart enables NetworkPolicies by default. This restricts the communication between the three main components: the Proxy, the Hub and the Single User instances. There are two elements that were left open on purpose: + +- Ingress access to the Proxy instance HTTP port: by default, it is open to any IP, as it is the entry point to the JupyterHub instance. This behavior can be changed by tweaking the `proxy.networkPolicy.extraIngress` value. +- Hub egress access: As the Hub requires access to the Kubernetes API, the Hub can access to any IP by default (depending on the Kubernetes platform, the Service IP ranges can vary and so there is no easy way to detect the Kubernetes API internal IP). This behavior can be changed by tweaking the `hub.networkPolicy.extraEgress` value. + +### Use sidecars and init containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `proxy.sidecars`, `hub.sidecars` or `singleuser.sidecars` config parameters. + +```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. + +Similarly, extra init containers can be added using the `hub.initContainers`, `proxy.initContainers` and `singleuser.initContainers` parameters. + +```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/). + +### Configure 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.To enable Ingress integration, set `proxy.ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `proxy.ingress.hostname` property can be used to set the host name. The `proxy.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 `proxy.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `proxy.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `proxy.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/). + +### Configure TLS secrets + +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`. + +### Set pod affinity + +This chart allows you to set your custom affinity using the `*.affinity` parameter(s). + +As an alternative, you can use the preset configurations for pod affinity, pod anti-affinity, and node affinity available in the `bitnami/common` chart. To do so, set the `*.podAffinityPreset`, `*.podAntiAffinityPreset`, or `*.nodeAffinityPreset` parameters. + +[Learn more about pod affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + ## Parameters ### Global parameters @@ -614,220 +818,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/jupyt > 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`. -## 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/). - -### Understand the default configuration - -This chart deploys three basic elements: - -- JupyterHub: Central element of the chart. Manages authentication and is responsible for creating the Jupyter Notebook instances (called Single User instances). As a consequence, the Hub requires special RBAC privileges in order to access the Kubernetes API to create and manage Deployments. -- Proxy: This is the external endpoint for users. It manages the communication with the Hub and the Single User instances. -- Image Puller: In order to improve the Single User instance boot time, a DaemonSet object is deployed that pre-pulls all the necessary images to run the Single User Notebooks. - -The following diagram shows a deployed release of the chart: - -```text - | - | - | - | - ------------------ | - | | | - | Image Puller |<------Pull images to------ - | | all nodes - ------------------ - - ------------- --------------- - | | | | - | Proxy |---------->| Hub | - | | | | - ------------- --------------- -``` - -After accessing the hub and creating a Single User instance, the deployment looks as follows: - -```text - | - | - | - | - ---------------- | - | | | - | Image Puller |<------Pull images to----- - | | all nodes - ---------------- - ----------- ------------- - | | | | - | Proxy |---------->| Hub | - | | | | - ----------- ------------- - | | - | | - | | - | --------------- | - | | Single User | | - ---->| Instance |<----- - --------------- -``` - -For more information, check the official [JupyterHub documentation](https://github.com/jupyterhub/jupyterhub). - -### [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. - -### Configure authentication - -The chart configures the Hub [DummyAuthenticator](https://github.com/jupyterhub/dummyauthenticator) by default, with the password set in the `hub.password` (auto-generated if not set) chart parameter and `user` as the administrator user. In order to change the authentication mechanism, change the `hub.config.JupyterHub` section inside the `hub.configuration` value. - -The following example sets the [NativeAuthenticator](https://github.com/jupyterhub/nativeauthenticator) authenticator, and configures an admin user called *test*. - -```yaml -hub: - configuration: | - ... - hub: - config: - JupyterHub: - admin_access: true - authenticator_class: nativeauthenticator.NativeAuthenticator - Authenticator: - admin_users: - - test - ... -``` - -When deploying, you will need to sign up to set the password for the `test`` user. - -For more information on Authenticators, check the [official JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/getting-started/authenticators-users-basics.html). - -### Configure the Single User instances - -As explained in this [section](#understand-the-default-configuration), the Hub is responsible for deploying the Single User instances. The configuration of these instances is passed to the Hub instance via the `hub.configuration` chart parameter. - -In order to make the chart follow standards and to ease the generation of this configuration file, the chart has a `singleuser` section, which is then used for generating the `hub.configuration` value. This value can be easily overridden by modifying its default value or by providing a secret via the `hub.existingSecret` value. In this case, all the settings in the `singleuser` section will be ignored. - -All the settings specified in the `hub.configuration` value are consumed by the `jupyter_config.py` script available in the [templates/hub/configmap.yaml](https://github.com/bitnami/charts/blob/main/bitnami/jupyterhub/templates/hub/configmap.yaml) file. This script can be changed by providing a custom ConfigMap via the `hub.existingConfigmap` value. The [official JupyterHub documentation](https://jupyterhub.readthedocs.io/en/stable/reference/config-examples.html) has more examples of the `jupyter_config.py` script. - -### Restrict traffic using NetworkPolicies - -The Bitnami JupyterHub chart enables NetworkPolicies by default. This restricts the communication between the three main components: the Proxy, the Hub and the Single User instances. There are two elements that were left open on purpose: - -- Ingress access to the Proxy instance HTTP port: by default, it is open to any IP, as it is the entry point to the JupyterHub instance. This behavior can be changed by tweaking the `proxy.networkPolicy.extraIngress` value. -- Hub egress access: As the Hub requires access to the Kubernetes API, the Hub can access to any IP by default (depending on the Kubernetes platform, the Service IP ranges can vary and so there is no easy way to detect the Kubernetes API internal IP). This behavior can be changed by tweaking the `hub.networkPolicy.extraEgress` value. - -### Use sidecars and init containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `proxy.sidecars`, `hub.sidecars` or `singleuser.sidecars` config parameters. - -```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. - -Similarly, extra init containers can be added using the `hub.initContainers`, `proxy.initContainers` and `singleuser.initContainers` parameters. - -```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/). - -### Configure 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.To enable Ingress integration, set `proxy.ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `proxy.ingress.hostname` property can be used to set the host name. The `proxy.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 `proxy.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `proxy.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `proxy.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/). - -### Configure TLS secrets - -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`. - -### Set pod affinity - -This chart allows you to set your custom affinity using the `*.affinity` parameter(s). - -As an alternative, you can use the preset configurations for pod affinity, pod anti-affinity, and node affinity available in the `bitnami/common` chart. To do so, set the `*.podAffinityPreset`, `*.podAntiAffinityPreset`, or `*.nodeAffinityPreset` parameters. - -[Learn more about pod affinity](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - ## 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). diff --git a/bitnami/kafka/README.md b/bitnami/kafka/README.md index 5d39aa298f..fb4abfb178 100644 --- a/bitnami/kafka/README.md +++ b/bitnami/kafka/README.md @@ -42,15 +42,380 @@ These commands deploy Kafka on the Kubernetes cluster in the default configurati > **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. + +### Listeners configuration + +This chart allows you to automatically configure Kafka with 3 listeners: + +- One for inter-broker communications. +- A second one for communications with clients within the K8s cluster. +- (optional) a third listener for communications with clients outside the K8s cluster. Check [this section](#accessing-kafka-brokers-from-outside-the-cluster) for more information. + +For more complex configurations, set the `listeners`, `advertisedListeners` and `listenerSecurityProtocolMap` parameters as needed. + +### Enable security for Kafka and Zookeeper + +You can configure different authentication protocols for each listener you configure in Kafka. For instance, you can use `sasl_tls` authentication for client communications, while using `tls` for inter-broker communications. This table shows the available protocols and the security they provide: + +| Method | Authentication | Encryption via TLS | +|-----------|------------------------------|--------------------| +| plaintext | None | No | +| tls | None | Yes | +| mtls | Yes (two-way authentication) | Yes | +| sasl | Yes (via SASL) | No | +| sasl_tls | Yes (via SASL) | Yes | + +Configure the authentication protocols for client and inter-broker communications by setting the *auth.clientProtocol* and *auth.interBrokerProtocol* parameters to the desired ones, respectively. + +If you enabled SASL authentication on any listener, you can set the SASL credentials using the parameters below: + +- `auth.sasl.jaas.clientUsers`/`auth.sasl.jaas.clientPasswords`: when enabling SASL authentication for communications with clients. +- `auth.sasl.jaas.interBrokerUser`/`auth.sasl.jaas.interBrokerPassword`: when enabling SASL authentication for inter-broker communications. +- `auth.jaas.zookeeperUser`/`auth.jaas.zookeeperPassword`: In the case that the Zookeeper chart is deployed with SASL authentication enabled. + +In order to configure TLS authentication/encryption, you **can** create a secret per Kafka broker you have in the cluster containing the Java Key Stores (JKS) files: the truststore (`kafka.truststore.jks`) and the keystore (`kafka.keystore.jks`). Then, you need pass the secret names with the `tls.existingSecret` parameter when deploying the chart. + +> **Note**: If the JKS files are password protected (recommended), you will need to provide the password to get access to the keystores. To do so, use the `tls.password` parameter to provide your password. + +For instance, to configure TLS authentication on a Kafka cluster with 2 Kafka brokers use the commands below to create the secrets: ```console -helm delete my-release +kubectl create secret generic kafka-jks-0 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-0.keystore.jks +kubectl create secret generic kafka-jks-1 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-1.keystore.jks ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +> **Note**: the command above assumes you already created the truststore and keystores files. This [script](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh) can help you with the JKS files generation. + +If, for some reason (like using Cert-Manager) you can not use the default JKS secret scheme, you can use the additional parameters: + +- `tls.jksTruststoreSecret` to define additional secret, where the `kafka.truststore.jks` is being kept. The truststore password **must** be the same as in `tls.password` +- `tls.jksTruststore` to overwrite the default value of the truststore key (`kafka.truststore.jks`). + +> **Note**: If you are using cert-manager, particularly when an ACME issuer is used, the `ca.crt` field is not put in the `Secret` that cert-manager creates. To handle this, the `tls.pemChainIncluded` property can be set to `true` and the initContainer created by this Chart will attempt to extract the intermediate certs from the `tls.crt` field of the secret (which is a PEM chain) +> **Note**: The truststore/keystore from above **must** be protected with the same password as in `tls.password` + +You can deploy the chart with authentication using the following parameters: + +```console +replicaCount=2 +listeners.client.client.protocol=SASL +listeners.client.interbroker.protocol=TLS +tls.existingSecret=kafka-jks +tls.password=jksPassword +sasl.client.users[0]=brokerUser +sasl.client.passwords[0]=brokerPassword +sasl.zookeeper.user=zookeeperUser +sasl.zookeeper.password=zookeeperPassword +zookeeper.auth.enabled=true +zookeeper.auth.serverUsers=zookeeperUser +zookeeper.auth.serverPasswords=zookeeperPassword +zookeeper.auth.clientUser=zookeeperUser +zookeeper.auth.clientPassword=zookeeperPassword +``` + +You can deploy the chart with AclAuthorizer using the following parameters: + +```console +replicaCount=2 +listeners.client.protocol=SASL +listeners.interbroker.protocol=SASL_TLS +tls.existingSecret=kafka-jks-0 +tls.password=jksPassword +sasl.client.users[0]=brokerUser +sasl.client.passwords[0]=brokerPassword +sasl.zookeeper.user=zookeeperUser +sasl.zookeeper.password=zookeeperPassword +zookeeper.auth.enabled=true +zookeeper.auth.serverUsers=zookeeperUser +zookeeper.auth.serverPasswords=zookeeperPassword +zookeeper.auth.clientUser=zookeeperUser +zookeeper.auth.clientPassword=zookeeperPassword +authorizerClassName=kafka.security.authorizer.AclAuthorizer +allowEveryoneIfNoAclFound=false +superUsers=User:admin +``` + +If you are using Kafka ACLs, you might encounter in kafka-authorizer.log the following event: `[...] Principal = User:ANONYMOUS is Allowed Operation [...]`. + +By setting the following parameter: `listeners.client.protocol=SSL` and `listener.client.sslClientAuth=required`, Kafka will require the clients to authenticate to Kafka brokers via certificate. + +As result, we will be able to see in kafka-authorizer.log the events specific Subject: `[...] Principal = User:CN=kafka,OU=...,O=...,L=...,C=..,ST=... is [...]`. + +If you also enable exposing metrics using the Kafka exporter, and you are using `SSL` or `SASL_SSL` security protocols protocols, you need to mount the CA certificated used to sign the brokers certificates in the exporter so it can validate the Kafka brokers. To do so, create a secret containing the CA, and set the `metrics.certificatesSecret` parameter. As an alternative, you can skip TLS validation using extra flags: + +```console +metrics.kafka.extraFlags={tls.insecure-skip-tls-verify: ""} +``` + +### Accessing Kafka brokers from outside the cluster + +In order to access Kafka Brokers from outside the cluster, an additional listener and advertised listener must be configured. Additionally, a specific service per kafka pod will be created. + +There are three ways of configuring external access. Using LoadBalancer services, using NodePort services or using ClusterIP services. + +#### Using LoadBalancer services + +You have two alternatives to use LoadBalancer services: + +- Option A) Use random load balancer IPs using an **initContainer** that waits for the IPs to be ready and discover them automatically. + +```console +externalAccess.enabled=true +externalAccess.service.broker.type=LoadBalancer +externalAccess.service.controller.type=LoadBalancer +externalAccess.service.broker.ports.external=9094 +externalAccess.service.controller.containerPorts.external=9094 +externalAccess.autoDiscovery.enabled=true +serviceAccount.create=true +rbac.create=true +``` + +Note: This option requires creating RBAC rules on clusters where RBAC policies are enabled. + +- Option B) Manually specify the load balancer IPs: + +```console +externalAccess.enabled=true +externalAccess.service.controller.type=LoadBalancer +externalAccess.service.controller.containerPorts.external=9094 +externalAccess.service.controller.loadBalancerIPs[0]='external-ip-1' +externalAccess.service.controller.loadBalancerIPs[1]='external-ip-2' +externalAccess.service.broker.type=LoadBalancer +externalAccess.service.broker.ports.external=9094 +externalAccess.service.broker.loadBalancerIPs[0]='external-ip-3' +externalAccess.service.broker.loadBalancerIPs[1]='external-ip-4' +``` + +Note: You need to know in advance the load balancer IPs so each Kafka broker advertised listener is configured with it. + +Following the aforementioned steps will also allow to connect the brokers from the outside using the cluster's default service (when `service.type` is `LoadBalancer` or `NodePort`). Use the property `service.externalPort` to specify the port used for external connections. + +#### Using NodePort services + +You have two alternatives to use NodePort services: + +- Option A) Use random node ports using an **initContainer** that discover them automatically. + + ```console + externalAccess.enabled=true + externalAccess.controller.service.type=NodePort + externalAccess.broker.service.type=NodePort + externalAccess.autoDiscovery.enabled=true + serviceAccount.create=true + rbac.create=true + ``` + + Note: This option requires creating RBAC rules on clusters where RBAC policies are enabled. + +- Option B) Manually specify the node ports: + + ```console + externalAccess.enabled=true + externalAccess.controller.service.type=NodePort + externalAccess.controller.service.nodePorts[0]='node-port-1' + externalAccess.controller.service.nodePorts[1]='node-port-2' + ``` + + Note: You need to know in advance the node ports that will be exposed so each Kafka broker advertised listener is configured with it. + + The pod will try to get the external ip of the node using `curl -s https://ipinfo.io/ip` unless `externalAccess.service.domain` or `externalAccess.service.useHostIPs` is provided. + +- Option C) Manually specify distinct external IPs (using controller+broker nodes) + + ```console + externalAccess.enabled=true + externalAccess.controller.service.type=NodePort + externalAccess.controller.service.externalIPs[0]='172.16.0.20' + externalAccess.controller.service.externalIPs[1]='172.16.0.21' + externalAccess.controller.service.externalIPs[2]='172.16.0.22' + ``` + + Note: You need to know in advance the available IP of your cluster that will be exposed so each Kafka broker advertised listener is configured with it. + +#### Using ClusterIP services + +Note: This option requires that an ingress is deployed within your cluster + +```console +externalAccess.enabled=true +externalAccess.controller.service.type=ClusterIP +externalAccess.controller.service.ports.external=9094 +externalAccess.controller.service.domain='ingress-ip' +externalAccess.broker.service.type=ClusterIP +externalAccess.broker.service.ports.external=9094 +externalAccess.broker.service.domain='ingress-ip' +``` + +Note: the deployed ingress must contain the following block: + +```console +tcp: + 9094: "{{ include "common.names.namespace" . }}/{{ include "common.names.fullname" . }}-0-external:9094" + 9095: "{{ include "common.names.namespace" . }}/{{ include "common.names.fullname" . }}-1-external:9094" + 9096: "{{ include "common.names.namespace" . }}/{{ include "common.names.fullname" . }}-2-external:9094" +``` + +#### Name resolution with External-DNS + +You can use the following values to generate External-DNS annotations which automatically creates DNS records for each ReplicaSet pod: + +```yaml +externalAccess: + service: + annotations: + external-dns.alpha.kubernetes.io/hostname: "{{ .targetPod }}.example.com" +``` + +### Enable metrics + +The chart can optionally start two metrics exporters: + +- Kafka exporter, to expose Kafka metrics. By default, it uses port 9308. +- JMX exporter, to expose JMX metrics. By default, it uses port 5556. + +To create a separate Kafka exporter, use the parameter below: + +```text +metrics.kafka.enabled: true +``` + +To expose JMX metrics to Prometheus, use the parameter below: + +```text +metrics.jmx.enabled: true +``` + +- To enable Zookeeper chart metrics, use the parameter below: + +```text +zookeeper.metrics.enabled: true +``` + +### Sidecars + +If you have a need for additional containers to run within the same pod as Kafka (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### 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. + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such as Kafka Connect. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would create a deployment including a Kafka Connect deployment so you can connect Kafka with MongoDB®: + +```yaml +## Extra objects to deploy (value evaluated as a template) +## +extraDeploy: + - | + apiVersion: apps/v1 + kind: Deployment + metadata: + name: {{ include "common.names.fullname" . }}-connect + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} + app.kubernetes.io/component: connector + spec: + replicas: 1 + selector: + matchLabels: {{- include "common.labels.matchLabels" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} + app.kubernetes.io/component: connector + template: + metadata: + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 8 }} + app.kubernetes.io/component: connector + spec: + containers: + - name: connect + image: KAFKA-CONNECT-IMAGE + imagePullPolicy: IfNotPresent + ports: + - name: connector + containerPort: 8083 + volumeMounts: + - name: configuration + mountPath: /bitnami/kafka/config + volumes: + - name: configuration + configMap: + name: {{ include "common.names.fullname" . }}-connect + - | + apiVersion: v1 + kind: ConfigMap + metadata: + name: {{ include "common.names.fullname" . }}-connect + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} + app.kubernetes.io/component: connector + data: + connect-standalone.properties: |- + bootstrap.servers = {{ include "common.names.fullname" . }}-0.{{ include "common.names.fullname" . }}-headless.{{ include "common.names.namespace" . }}.svc.{{ .Values.clusterDomain }}:{{ .Values.service.port }} + ... + mongodb.properties: |- + connection.uri=mongodb://root:password@mongodb-hostname:27017 + ... + - | + apiVersion: v1 + kind: Service + metadata: + name: {{ include "common.names.fullname" . }}-connect + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} + app.kubernetes.io/component: connector + spec: + ports: + - protocol: TCP + port: 8083 + targetPort: connector + selector: {{- include "common.labels.matchLabels" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} + app.kubernetes.io/component: connector +``` + +You can create the Kafka Connect image using the Dockerfile below: + +```Dockerfile +FROM bitnami/kafka:latest +# Download MongoDB® Connector for Apache Kafka https://www.confluent.io/hub/mongodb/kafka-connect-mongodb +RUN mkdir -p /opt/bitnami/kafka/plugins && \ + cd /opt/bitnami/kafka/plugins && \ + curl --remote-name --location --silent https://search.maven.org/remotecontent?filepath=org/mongodb/kafka/mongo-kafka-connect/1.2.0/mongo-kafka-connect-1.2.0-all.jar +CMD /opt/bitnami/kafka/bin/connect-standalone.sh /opt/bitnami/kafka/config/connect-standalone.properties /opt/bitnami/kafka/config/mongo.properties +``` + +## Persistence + +The [Bitnami Kafka](https://github.com/bitnami/containers/tree/main/bitnami/kafka) image stores the Kafka data at the `/bitnami/kafka` 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. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -734,461 +1099,10 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/kafka > 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/kafka/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. - -### Listeners configuration - -This chart allows you to automatically configure Kafka with 3 listeners: - -- One for inter-broker communications. -- A second one for communications with clients within the K8s cluster. -- (optional) a third listener for communications with clients outside the K8s cluster. Check [this section](#accessing-kafka-brokers-from-outside-the-cluster) for more information. - -For more complex configurations, set the `listeners`, `advertisedListeners` and `listenerSecurityProtocolMap` parameters as needed. - -### Enable security for Kafka and Zookeeper - -You can configure different authentication protocols for each listener you configure in Kafka. For instance, you can use `sasl_tls` authentication for client communications, while using `tls` for inter-broker communications. This table shows the available protocols and the security they provide: - -| Method | Authentication | Encryption via TLS | -|-----------|------------------------------|--------------------| -| plaintext | None | No | -| tls | None | Yes | -| mtls | Yes (two-way authentication) | Yes | -| sasl | Yes (via SASL) | No | -| sasl_tls | Yes (via SASL) | Yes | - -Configure the authentication protocols for client and inter-broker communications by setting the *auth.clientProtocol* and *auth.interBrokerProtocol* parameters to the desired ones, respectively. - -If you enabled SASL authentication on any listener, you can set the SASL credentials using the parameters below: - -- `auth.sasl.jaas.clientUsers`/`auth.sasl.jaas.clientPasswords`: when enabling SASL authentication for communications with clients. -- `auth.sasl.jaas.interBrokerUser`/`auth.sasl.jaas.interBrokerPassword`: when enabling SASL authentication for inter-broker communications. -- `auth.jaas.zookeeperUser`/`auth.jaas.zookeeperPassword`: In the case that the Zookeeper chart is deployed with SASL authentication enabled. - -In order to configure TLS authentication/encryption, you **can** create a secret per Kafka broker you have in the cluster containing the Java Key Stores (JKS) files: the truststore (`kafka.truststore.jks`) and the keystore (`kafka.keystore.jks`). Then, you need pass the secret names with the `tls.existingSecret` parameter when deploying the chart. - -> **Note**: If the JKS files are password protected (recommended), you will need to provide the password to get access to the keystores. To do so, use the `tls.password` parameter to provide your password. - -For instance, to configure TLS authentication on a Kafka cluster with 2 Kafka brokers use the commands below to create the secrets: - -```console -kubectl create secret generic kafka-jks-0 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-0.keystore.jks -kubectl create secret generic kafka-jks-1 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-1.keystore.jks -``` - -> **Note**: the command above assumes you already created the truststore and keystores files. This [script](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh) can help you with the JKS files generation. - -If, for some reason (like using Cert-Manager) you can not use the default JKS secret scheme, you can use the additional parameters: - -- `tls.jksTruststoreSecret` to define additional secret, where the `kafka.truststore.jks` is being kept. The truststore password **must** be the same as in `tls.password` -- `tls.jksTruststore` to overwrite the default value of the truststore key (`kafka.truststore.jks`). - -> **Note**: If you are using cert-manager, particularly when an ACME issuer is used, the `ca.crt` field is not put in the `Secret` that cert-manager creates. To handle this, the `tls.pemChainIncluded` property can be set to `true` and the initContainer created by this Chart will attempt to extract the intermediate certs from the `tls.crt` field of the secret (which is a PEM chain) -> **Note**: The truststore/keystore from above **must** be protected with the same password as in `tls.password` - -You can deploy the chart with authentication using the following parameters: - -```console -replicaCount=2 -listeners.client.client.protocol=SASL -listeners.client.interbroker.protocol=TLS -tls.existingSecret=kafka-jks -tls.password=jksPassword -sasl.client.users[0]=brokerUser -sasl.client.passwords[0]=brokerPassword -sasl.zookeeper.user=zookeeperUser -sasl.zookeeper.password=zookeeperPassword -zookeeper.auth.enabled=true -zookeeper.auth.serverUsers=zookeeperUser -zookeeper.auth.serverPasswords=zookeeperPassword -zookeeper.auth.clientUser=zookeeperUser -zookeeper.auth.clientPassword=zookeeperPassword -``` - -You can deploy the chart with AclAuthorizer using the following parameters: - -```console -replicaCount=2 -listeners.client.protocol=SASL -listeners.interbroker.protocol=SASL_TLS -tls.existingSecret=kafka-jks-0 -tls.password=jksPassword -sasl.client.users[0]=brokerUser -sasl.client.passwords[0]=brokerPassword -sasl.zookeeper.user=zookeeperUser -sasl.zookeeper.password=zookeeperPassword -zookeeper.auth.enabled=true -zookeeper.auth.serverUsers=zookeeperUser -zookeeper.auth.serverPasswords=zookeeperPassword -zookeeper.auth.clientUser=zookeeperUser -zookeeper.auth.clientPassword=zookeeperPassword -authorizerClassName=kafka.security.authorizer.AclAuthorizer -allowEveryoneIfNoAclFound=false -superUsers=User:admin -``` - -If you are using Kafka ACLs, you might encounter in kafka-authorizer.log the following event: `[...] Principal = User:ANONYMOUS is Allowed Operation [...]`. - -By setting the following parameter: `listeners.client.protocol=SSL` and `listener.client.sslClientAuth=required`, Kafka will require the clients to authenticate to Kafka brokers via certificate. - -As result, we will be able to see in kafka-authorizer.log the events specific Subject: `[...] Principal = User:CN=kafka,OU=...,O=...,L=...,C=..,ST=... is [...]`. - -If you also enable exposing metrics using the Kafka exporter, and you are using `SSL` or `SASL_SSL` security protocols protocols, you need to mount the CA certificated used to sign the brokers certificates in the exporter so it can validate the Kafka brokers. To do so, create a secret containing the CA, and set the `metrics.certificatesSecret` parameter. As an alternative, you can skip TLS validation using extra flags: - -```console -metrics.kafka.extraFlags={tls.insecure-skip-tls-verify: ""} -``` - -### Accessing Kafka brokers from outside the cluster - -In order to access Kafka Brokers from outside the cluster, an additional listener and advertised listener must be configured. Additionally, a specific service per kafka pod will be created. - -There are three ways of configuring external access. Using LoadBalancer services, using NodePort services or using ClusterIP services. - -#### Using LoadBalancer services - -You have two alternatives to use LoadBalancer services: - -- Option A) Use random load balancer IPs using an **initContainer** that waits for the IPs to be ready and discover them automatically. - -```console -externalAccess.enabled=true -externalAccess.service.broker.type=LoadBalancer -externalAccess.service.controller.type=LoadBalancer -externalAccess.service.broker.ports.external=9094 -externalAccess.service.controller.containerPorts.external=9094 -externalAccess.autoDiscovery.enabled=true -serviceAccount.create=true -rbac.create=true -``` - -Note: This option requires creating RBAC rules on clusters where RBAC policies are enabled. - -- Option B) Manually specify the load balancer IPs: - -```console -externalAccess.enabled=true -externalAccess.service.controller.type=LoadBalancer -externalAccess.service.controller.containerPorts.external=9094 -externalAccess.service.controller.loadBalancerIPs[0]='external-ip-1' -externalAccess.service.controller.loadBalancerIPs[1]='external-ip-2' -externalAccess.service.broker.type=LoadBalancer -externalAccess.service.broker.ports.external=9094 -externalAccess.service.broker.loadBalancerIPs[0]='external-ip-3' -externalAccess.service.broker.loadBalancerIPs[1]='external-ip-4' -``` - -Note: You need to know in advance the load balancer IPs so each Kafka broker advertised listener is configured with it. - -Following the aforementioned steps will also allow to connect the brokers from the outside using the cluster's default service (when `service.type` is `LoadBalancer` or `NodePort`). Use the property `service.externalPort` to specify the port used for external connections. - -#### Using NodePort services - -You have two alternatives to use NodePort services: - -- Option A) Use random node ports using an **initContainer** that discover them automatically. - - ```console - externalAccess.enabled=true - externalAccess.controller.service.type=NodePort - externalAccess.broker.service.type=NodePort - externalAccess.autoDiscovery.enabled=true - serviceAccount.create=true - rbac.create=true - ``` - - Note: This option requires creating RBAC rules on clusters where RBAC policies are enabled. - -- Option B) Manually specify the node ports: - - ```console - externalAccess.enabled=true - externalAccess.controller.service.type=NodePort - externalAccess.controller.service.nodePorts[0]='node-port-1' - externalAccess.controller.service.nodePorts[1]='node-port-2' - ``` - - Note: You need to know in advance the node ports that will be exposed so each Kafka broker advertised listener is configured with it. - - The pod will try to get the external ip of the node using `curl -s https://ipinfo.io/ip` unless `externalAccess.service.domain` or `externalAccess.service.useHostIPs` is provided. - -- Option C) Manually specify distinct external IPs (using controller+broker nodes) - - ```console - externalAccess.enabled=true - externalAccess.controller.service.type=NodePort - externalAccess.controller.service.externalIPs[0]='172.16.0.20' - externalAccess.controller.service.externalIPs[1]='172.16.0.21' - externalAccess.controller.service.externalIPs[2]='172.16.0.22' - ``` - - Note: You need to know in advance the available IP of your cluster that will be exposed so each Kafka broker advertised listener is configured with it. - -#### Using ClusterIP services - -Note: This option requires that an ingress is deployed within your cluster - -```console -externalAccess.enabled=true -externalAccess.controller.service.type=ClusterIP -externalAccess.controller.service.ports.external=9094 -externalAccess.controller.service.domain='ingress-ip' -externalAccess.broker.service.type=ClusterIP -externalAccess.broker.service.ports.external=9094 -externalAccess.broker.service.domain='ingress-ip' -``` - -Note: the deployed ingress must contain the following block: - -```console -tcp: - 9094: "{{ include "common.names.namespace" . }}/{{ include "common.names.fullname" . }}-0-external:9094" - 9095: "{{ include "common.names.namespace" . }}/{{ include "common.names.fullname" . }}-1-external:9094" - 9096: "{{ include "common.names.namespace" . }}/{{ include "common.names.fullname" . }}-2-external:9094" -``` - -#### Name resolution with External-DNS - -You can use the following values to generate External-DNS annotations which automatically creates DNS records for each ReplicaSet pod: - -```yaml -externalAccess: - service: - annotations: - external-dns.alpha.kubernetes.io/hostname: "{{ .targetPod }}.example.com" -``` - -### Enable metrics - -The chart can optionally start two metrics exporters: - -- Kafka exporter, to expose Kafka metrics. By default, it uses port 9308. -- JMX exporter, to expose JMX metrics. By default, it uses port 5556. - -To create a separate Kafka exporter, use the parameter below: - -```text -metrics.kafka.enabled: true -``` - -To expose JMX metrics to Prometheus, use the parameter below: - -```text -metrics.jmx.enabled: true -``` - -- To enable Zookeeper chart metrics, use the parameter below: - -```text -zookeeper.metrics.enabled: true -``` - -### Sidecars - -If you have a need for additional containers to run within the same pod as Kafka (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### 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. - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such as Kafka Connect. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would create a deployment including a Kafka Connect deployment so you can connect Kafka with MongoDB®: - -```yaml -## Extra objects to deploy (value evaluated as a template) -## -extraDeploy: - - | - apiVersion: apps/v1 - kind: Deployment - metadata: - name: {{ include "common.names.fullname" . }}-connect - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} - app.kubernetes.io/component: connector - spec: - replicas: 1 - selector: - matchLabels: {{- include "common.labels.matchLabels" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} - app.kubernetes.io/component: connector - template: - metadata: - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 8 }} - app.kubernetes.io/component: connector - spec: - containers: - - name: connect - image: KAFKA-CONNECT-IMAGE - imagePullPolicy: IfNotPresent - ports: - - name: connector - containerPort: 8083 - volumeMounts: - - name: configuration - mountPath: /bitnami/kafka/config - volumes: - - name: configuration - configMap: - name: {{ include "common.names.fullname" . }}-connect - - | - apiVersion: v1 - kind: ConfigMap - metadata: - name: {{ include "common.names.fullname" . }}-connect - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} - app.kubernetes.io/component: connector - data: - connect-standalone.properties: |- - bootstrap.servers = {{ include "common.names.fullname" . }}-0.{{ include "common.names.fullname" . }}-headless.{{ include "common.names.namespace" . }}.svc.{{ .Values.clusterDomain }}:{{ .Values.service.port }} - ... - mongodb.properties: |- - connection.uri=mongodb://root:password@mongodb-hostname:27017 - ... - - | - apiVersion: v1 - kind: Service - metadata: - name: {{ include "common.names.fullname" . }}-connect - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} - app.kubernetes.io/component: connector - spec: - ports: - - protocol: TCP - port: 8083 - targetPort: connector - selector: {{- include "common.labels.matchLabels" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 4 }} - app.kubernetes.io/component: connector -``` - -You can create the Kafka Connect image using the Dockerfile below: - -```Dockerfile -FROM bitnami/kafka:latest -# Download MongoDB® Connector for Apache Kafka https://www.confluent.io/hub/mongodb/kafka-connect-mongodb -RUN mkdir -p /opt/bitnami/kafka/plugins && \ - cd /opt/bitnami/kafka/plugins && \ - curl --remote-name --location --silent https://search.maven.org/remotecontent?filepath=org/mongodb/kafka/mongo-kafka-connect/1.2.0/mongo-kafka-connect-1.2.0-all.jar -CMD /opt/bitnami/kafka/bin/connect-standalone.sh /opt/bitnami/kafka/config/connect-standalone.properties /opt/bitnami/kafka/config/mongo.properties -``` - -## Persistence - -The [Bitnami Kafka](https://github.com/bitnami/containers/tree/main/bitnami/kafka) image stores the Kafka data at the `/bitnami/kafka` 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. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). -## Migrating from Zookeeper (Early access) - -This guide is an adaptation from upstream documentation: [Migrate from ZooKeeper to KRaft](https://docs.confluent.io/platform/current/installation/migrate-zk-kraft.html) - -1. Retrieve the cluster ID from Zookeeper: - - ```console - $ kubectl exec -it -- zkCli.sh get /cluster/id - /opt/bitnami/java/bin/java - Connecting to localhost:2181 - - WATCHER:: - - WatchedEvent state:SyncConnected type:None path:null - {"version":"1","id":"TEr3HVPvTqSWixWRHngP5g"} - ``` - -2. Deploy at least one Kraft controller-only in your deployment and enable `zookeeperMigrationMode=true`. The Kraft controllers will migrate the data from your Kafka ZkBroker to Kraft mode. - - To do so add the following values to your Zookeeper deployment when upgrading: - - ```yaml - controller: - replicaCount: 1 - controllerOnly: true - zookeeperMigrationMode: true - # If needed, set controllers minID to avoid conflict with your ZK brokers' ids. - # minID: 0 - broker: - zookeeperMigrationMode: true - kraft: - enabled: true - clusterId: "" - ``` - -3. Wait until until all brokers are ready. You should see the following log in the broker logs: - - ```console - INFO [KafkaServer id=100] Finished catching up on KRaft metadata log, requesting that the KRaft controller unfence this broker (kafka.server.KafkaServer) - INFO [BrokerLifecycleManager id=100 isZkBroker=true] The broker has been unfenced. Transitioning from RECOVERY to RUNNING. (kafka.server.BrokerLifecycleManager) - ``` - - In the controllers, the following message should show up: - - ```console - Transitioning ZK migration state from PRE_MIGRATION to MIGRATION (org.apache.kafka.controller.FeatureControlManager) - ``` - -4. Once all brokers have been successfully migrated, set `broker.zookeeperMigrationMode=false` to fully migrate them. - - ```yaml - broker: - zookeeperMigrationMode: false - ``` - -5. To conclude the migration, switch off migration mode on controllers and stop Zookeeper: - - ```yaml - controller: - zookeeperMigrationMode: false - zookeeper: - enabled: false - ``` - - After migration is complete, you should see the following message in your controllers: - - ```console - [2023-07-13 13:07:45,226] INFO [QuorumController id=1] Transitioning ZK migration state from MIGRATION to POST_MIGRATION (org.apache.kafka.controller.FeatureControlManager) - ``` - -6. (**Optional**) If you would like to switch to a non-dedicated cluster, set `controller.controllerOnly=false`. This will cause controller-only nodes to switch to controller+broker nodes. - - At that point, you could manually decommission broker-only nodes by reassigning its partitions to controller-eligible nodes. - - For more information about decommissioning kafka broker check the [Kafka documentation](https://www.confluent.io/blog/remove-kafka-brokers-from-any-cluster-the-easy-way/). - ## Upgrading ### To 26.0.0 @@ -1275,7 +1189,83 @@ If upgrading from Kraft mode, existing PVCs from Kafka containers should be reat #### Upgrading from Zookeeper mode If upgrading from Zookeeper mode, make sure you set 'controller.replicaCount=0' and reattach the existing PVCs to 'broker' pods. -This will allow you to perform a migration to Kraft mode in the future by following the 'Migrating from Zookeeper' section of this documentation. +This will allow you to perform a migration to Kraft mode in the future by following the following section. + +##### Migrating from Zookeeper (Early access) + +This guide is an adaptation from upstream documentation: [Migrate from ZooKeeper to KRaft](https://docs.confluent.io/platform/current/installation/migrate-zk-kraft.html) + +1. Retrieve the cluster ID from Zookeeper: + + ```console + $ kubectl exec -it -- zkCli.sh get /cluster/id + /opt/bitnami/java/bin/java + Connecting to localhost:2181 + + WATCHER:: + + WatchedEvent state:SyncConnected type:None path:null + {"version":"1","id":"TEr3HVPvTqSWixWRHngP5g"} + ``` + +2. Deploy at least one Kraft controller-only in your deployment and enable `zookeeperMigrationMode=true`. The Kraft controllers will migrate the data from your Kafka ZkBroker to Kraft mode. + + To do so add the following values to your Zookeeper deployment when upgrading: + + ```yaml + controller: + replicaCount: 1 + controllerOnly: true + zookeeperMigrationMode: true + # If needed, set controllers minID to avoid conflict with your ZK brokers' ids. + # minID: 0 + broker: + zookeeperMigrationMode: true + kraft: + enabled: true + clusterId: "" + ``` + +3. Wait until until all brokers are ready. You should see the following log in the broker logs: + + ```console + INFO [KafkaServer id=100] Finished catching up on KRaft metadata log, requesting that the KRaft controller unfence this broker (kafka.server.KafkaServer) + INFO [BrokerLifecycleManager id=100 isZkBroker=true] The broker has been unfenced. Transitioning from RECOVERY to RUNNING. (kafka.server.BrokerLifecycleManager) + ``` + + In the controllers, the following message should show up: + + ```console + Transitioning ZK migration state from PRE_MIGRATION to MIGRATION (org.apache.kafka.controller.FeatureControlManager) + ``` + +4. Once all brokers have been successfully migrated, set `broker.zookeeperMigrationMode=false` to fully migrate them. + + ```yaml + broker: + zookeeperMigrationMode: false + ``` + +5. To conclude the migration, switch off migration mode on controllers and stop Zookeeper: + + ```yaml + controller: + zookeeperMigrationMode: false + zookeeper: + enabled: false + ``` + + After migration is complete, you should see the following message in your controllers: + + ```console + [2023-07-13 13:07:45,226] INFO [QuorumController id=1] Transitioning ZK migration state from MIGRATION to POST_MIGRATION (org.apache.kafka.controller.FeatureControlManager) + ``` + +6. (**Optional**) If you would like to switch to a non-dedicated cluster, set `controller.controllerOnly=false`. This will cause controller-only nodes to switch to controller+broker nodes. + + At that point, you could manually decommission broker-only nodes by reassigning its partitions to controller-eligible nodes. + + For more information about decommissioning kafka broker check the [Kafka documentation](https://www.confluent.io/blog/remove-kafka-brokers-from-any-cluster-the-easy-way/). #### Retaining PersistentVolumes diff --git a/bitnami/keycloak/README.md b/bitnami/keycloak/README.md index 16ecd70c9b..8117e507e8 100644 --- a/bitnami/keycloak/README.md +++ b/bitnami/keycloak/README.md @@ -43,15 +43,251 @@ These commands deploy a Keycloak application on the Kubernetes cluster in the de > **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 -```console -helm delete my-release +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. + +### Use an external database + +Sometimes, you may want to have Keycloak connect to an external PostgreSQL database rather than a database within your cluster - for example, when using a managed database service, or when running a single database server for all your applications. To do this, set the `postgresql.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: + +```text +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=5432 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +> NOTE: Only PostgreSQL database server is supported as external database + +It is not supported but possible to run Keycloak with an external MSSQL database with the following settings: + +```yaml +externalDatabase: + host: "mssql.example.com" + port: 1433 + user: keycloak + database: keycloak + existingSecret: passwords +extraEnvVars: + - name: KC_DB # override values from the conf file + value: 'mssql' + - name: KC_DB_URL + value: 'jdbc:sqlserver://mssql.example.com:1433;databaseName=keycloak;' +``` + +### Importing and exporting a realm + +#### Importing a realm + +You can import a realm by setting the `KEYCLOAK_EXTRA_ARGS` to contain the `--import-realm` argument. + +This will import all `*.json` under `/opt/bitnami/keycloak/data/import` files as a realm into keycloak as per the +official documentation [here](https://www.keycloak.org/server/importExport#_importing_a_realm_from_a_directory). You +can supply the files by mounting a volume e.g. with docker compose as follows: + +```yaml +keycloak: + image: bitnami/keycloak:latest + volumes: + - /local/path/to/realms/folder:/opt/bitnami/keycloak/data/import +``` + +#### Exporting a realm + +You can export a realm through the GUI but it will not export users even the option is set, this is a known keycloak +[bug](https://github.com/keycloak/keycloak/issues/23970). + +By using the `kc.sh` script you can export a realm with users. Be sure to mount the export folder to a local folder: + +```yaml +keycloak: + image: bitnami/keycloak:latest + volumes: + - /local/path/to/export/folder:/export +``` + +Then open a terminal in the running keycloak container and run: + +```bash +kc.sh export --dir /export/ --users realm_file +```` + +This will export the all the realms with users to the `/export` folder. + +### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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/). + +### Configure admin Ingress + +In addition to the Ingress resource described above, this chart also provides the ability to define an Ingress for the admin area of Keycloak, for example the `master` realm. + +For this scenario, you can use the Keycloak Config CLI integration with the following values, where `keycloak-admin.example.com` is to be replaced by the actual hostname: + +```yaml +adminIngress: + enabled: true + hostname: keycloak-admin.example.com +keycloakConfigCli: + configuration: | + { + "realm" : "master", + "attributes": { + "frontendUrl": "https://keycloak-admin.example.com" + } + } +``` + +### Configure TLS Secrets for use with 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`. + +### Use with ingress offloading SSL + +If your ingress controller has the SSL Termination, you should set `proxy` to `edge`. + +### Manage secrets and passwords + +This chart provides several ways to manage passwords: + +- Values passed to the chart: In this scenario, a new secret including all the passwords will be created during the chart installation. When upgrading, it is necessary to provide the secrets to the chart as shown below. Replace the KEYCLOAK_ADMIN_PASSWORD, KEYCLOAK_MANAGEMENT_PASSWORD, POSTGRESQL_PASSWORD and POSTGRESQL_PVC placeholders with the correct passwords and PVC name. + +```console +helm upgrade keycloak bitnami/keycloak \ + --set auth.adminPassword=KEYCLOAK_ADMIN_PASSWORD \ + --set auth.managementPassword=KEYCLOAK_MANAGEMENT_PASSWORD \ + --set postgresql.postgresqlPassword=POSTGRESQL_PASSWORD \ + --set postgresql.persistence.existingClaim=POSTGRESQL_PVC +``` + +- An existing secret with all the passwords via the `existingSecret` parameter. + +### Add extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: KEYCLOAK_LOG_LEVEL + value: DEBUG +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Initialize a fresh instance + +The [Bitnami Keycloak](https://github.com/bitnami/containers/tree/main/bitnami/keycloak) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, you can specify custom scripts using the `initdbScripts` parameter as dict. + +In addition to this option, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `initdbScriptsConfigMap` parameter. Note that this will override the previous option. + +The allowed extensions is `.sh`. + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Set Pod 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. ## Parameters @@ -423,252 +659,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/keycl Keycloak realms, users and clients can be created from the Keycloak administration panel. Refer to the [tutorial on adding user authentication to applications with Keycloak](https://docs.bitnami.com/tutorials/integrate-keycloak-authentication-kubernetes) for more details on these operations. -## 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. - -### Use an external database - -Sometimes, you may want to have Keycloak connect to an external PostgreSQL database rather than a database within your cluster - for example, when using a managed database service, or when running a single database server for all your applications. To do this, set the `postgresql.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: - -```text -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=5432 -``` - -> NOTE: Only PostgreSQL database server is supported as external database - -It is not supported but possible to run Keycloak with an external MSSQL database with the following settings: - -```yaml -externalDatabase: - host: "mssql.example.com" - port: 1433 - user: keycloak - database: keycloak - existingSecret: passwords -extraEnvVars: - - name: KC_DB # override values from the conf file - value: 'mssql' - - name: KC_DB_URL - value: 'jdbc:sqlserver://mssql.example.com:1433;databaseName=keycloak;' -``` - -### Importing and exporting a realm - -#### Importing a realm - -You can import a realm by setting the `KEYCLOAK_EXTRA_ARGS` to contain the `--import-realm` argument. - -This will import all `*.json` under `/opt/bitnami/keycloak/data/import` files as a realm into keycloak as per the -official documentation [here](https://www.keycloak.org/server/importExport#_importing_a_realm_from_a_directory). You -can supply the files by mounting a volume e.g. with docker compose as follows: - -```yaml -keycloak: - image: bitnami/keycloak:latest - volumes: - - /local/path/to/realms/folder:/opt/bitnami/keycloak/data/import -``` - -#### Exporting a realm - -You can export a realm through the GUI but it will not export users even the option is set, this is a known keycloak -[bug](https://github.com/keycloak/keycloak/issues/23970). - -By using the `kc.sh` script you can export a realm with users. Be sure to mount the export folder to a local folder: - -```yaml -keycloak: - image: bitnami/keycloak:latest - volumes: - - /local/path/to/export/folder:/export -``` - -Then open a terminal in the running keycloak container and run: - -```bash -kc.sh export --dir /export/ --users realm_file -```` - -This will export the all the realms with users to the `/export` folder. - -### Add extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: KEYCLOAK_LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Initialize a fresh instance - -The [Bitnami Keycloak](https://github.com/bitnami/containers/tree/main/bitnami/keycloak) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, you can specify custom scripts using the `initdbScripts` parameter as dict. - -In addition to this option, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `initdbScriptsConfigMap` parameter. Note that this will override the previous option. - -The allowed extensions is `.sh`. - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Set Pod 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. - -### Configure 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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/). - -### Configure admin Ingress - -In addition to the Ingress resource described above, this chart also provides the ability to define an Ingress for the admin area of Keycloak, for example the `master` realm. - -For this scenario, you can use the Keycloak Config CLI integration with the following values, where `keycloak-admin.example.com` is to be replaced by the actual hostname: - -```yaml -adminIngress: - enabled: true - hostname: keycloak-admin.example.com -keycloakConfigCli: - configuration: | - { - "realm" : "master", - "attributes": { - "frontendUrl": "https://keycloak-admin.example.com" - } - } -``` - -### Configure TLS Secrets for use with 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`. - -### Use with ingress offloading SSL - -If your ingress controller has the SSL Termination, you should set `proxy` to `edge`. - -### Manage secrets and passwords - -This chart provides several ways to manage passwords: - -- Values passed to the chart: In this scenario, a new secret including all the passwords will be created during the chart installation. When upgrading, it is necessary to provide the secrets to the chart as shown below. Replace the KEYCLOAK_ADMIN_PASSWORD, KEYCLOAK_MANAGEMENT_PASSWORD, POSTGRESQL_PASSWORD and POSTGRESQL_PVC placeholders with the correct passwords and PVC name. - -```console -helm upgrade keycloak bitnami/keycloak \ - --set auth.adminPassword=KEYCLOAK_ADMIN_PASSWORD \ - --set auth.managementPassword=KEYCLOAK_MANAGEMENT_PASSWORD \ - --set postgresql.postgresqlPassword=POSTGRESQL_PASSWORD \ - --set postgresql.persistence.existingClaim=POSTGRESQL_PVC -``` - -- An existing secret with all the passwords via the `existingSecret` parameter. - ## 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). diff --git a/bitnami/kiam/README.md b/bitnami/kiam/README.md index 636b9bf175..f117666ebc 100644 --- a/bitnami/kiam/README.md +++ b/bitnami/kiam/README.md @@ -46,15 +46,116 @@ These commands deploy a kiam application on the Kubernetes cluster in the defaul > **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 -```console -helm delete my-release +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. + +### Add extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `server.extraEnvVars` and `agent.extraEnvVars` property. + +```yaml +server: + extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `server.extraEnvVarsCM`, `agent.extraEnvVarsCM` or the `server.extraEnvVarsSecret` and `agent.extraEnvVarsSecret` values. + +### Configure Sidecars and Init Containers + +If additional containers are needed in the same pod as Kiam (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Set Pod affinity + +This chart allows you to set your custom affinity using the `server.affinity` and `agent.affinity` parameters. Find more information about Pod 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 `server.podAffinityPreset`, `agent.podAffinityPreset`, `server.podAntiAffinityPreset`, `agent.podAntiAffinityPreset`, or `server.nodeAffinityPreset` and `agent.nodeAffinityPreset` parameters. + +### Configure TLS Secrets + +This chart will facilitate the creation of TLS secrets for use with kiam. There are three common use cases: + +- Helm auto-generates the certificates. +- User specifies the certificates in the values. +- User generates/manages certificates separately. + +By default the first use case will be applied. In the second case, a certificate and a key are needed. + +- The certificate files should look like the example below. There may be more than one certificate if there is a certificate chain. + + ```console + -----BEGIN CERTIFICATE----- + MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV + ... + jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 + -----END CERTIFICATE----- + ``` + +- The certificate keys should look like this: + + ```console + -----BEGIN RSA PRIVATE KEY----- + MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 + ... + wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= + -----END RSA PRIVATE KEY----- + ``` + +If using the values file to manage the certificates, copy the above values into the `server.tlsFiles.cert`, `server.tlsFiles.ca` and `server.tlsFiles.key` or `agent.tlsFiles.cert`, `agent.tlsFiles.ca` and `agent.tlsFiles.key` parameters respectively. + +If managing TLS secrets outside of Helm, it is possible to create a TLS secret (named `kiam.local-tls`, for example) and set it using the `server.tlsSecret` or `agent.tlsSecret` parameters. ## Parameters @@ -399,117 +500,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/kiam > 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/kiam/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. - -### Add extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `server.extraEnvVars` and `agent.extraEnvVars` property. - -```yaml -server: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `server.extraEnvVarsCM`, `agent.extraEnvVarsCM` or the `server.extraEnvVarsSecret` and `agent.extraEnvVarsSecret` values. - -### Configure Sidecars and Init Containers - -If additional containers are needed in the same pod as Kiam (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Set Pod affinity - -This chart allows you to set your custom affinity using the `server.affinity` and `agent.affinity` parameters. Find more information about Pod 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 `server.podAffinityPreset`, `agent.podAffinityPreset`, `server.podAntiAffinityPreset`, `agent.podAntiAffinityPreset`, or `server.nodeAffinityPreset` and `agent.nodeAffinityPreset` parameters. - -### Configure TLS Secrets - -This chart will facilitate the creation of TLS secrets for use with kiam. There are three common use cases: - -- Helm auto-generates the certificates. -- User specifies the certificates in the values. -- User generates/manages certificates separately. - -By default the first use case will be applied. In the second case, a certificate and a key are needed. - -- The certificate files should look like the example below. There may be more than one certificate if there is a certificate chain. - - ```console - -----BEGIN CERTIFICATE----- - MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV - ... - jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 - -----END CERTIFICATE----- - ``` - -- The certificate keys should look like this: - - ```console - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 - ... - wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= - -----END RSA PRIVATE KEY----- - ``` - -If using the values file to manage the certificates, copy the above values into the `server.tlsFiles.cert`, `server.tlsFiles.ca` and `server.tlsFiles.key` or `agent.tlsFiles.cert`, `agent.tlsFiles.ca` and `agent.tlsFiles.key` parameters respectively. - -If managing TLS secrets outside of Helm, it is possible to create a TLS secret (named `kiam.local-tls`, for example) and set it using the `server.tlsSecret` or `agent.tlsSecret` parameters. - ## 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). diff --git a/bitnami/kibana/README.md b/bitnami/kibana/README.md index 4d17070529..f9327cc201 100644 --- a/bitnami/kibana/README.md +++ b/bitnami/kibana/README.md @@ -45,15 +45,177 @@ This chart requires an Elasticsearch instance to work. You can use an already ex > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` statefulset: +### Resource requests and limits -```console -helm delete my-release +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. + +### Change Kibana version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Use custom configuration + +The Bitnami Kibana chart supports using custom configuration settings. For example, to mount a custom `kibana.yml` you can create a ConfigMap like the following: + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: myconfig +data: + kibana.yml: |- + # Raw text of the file ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +And now you need to pass the ConfigMap name, to the corresponding parameter: `configurationCM=myconfig` + +An alternative is to provide extra configuration settings to the default kibana.yml that the chart deploys. This is done using the `extraConfiguration` value: + +```yaml +extraConfiguration: + "server.maxPayloadBytes": 1048576 + "server.pingTimeout": 1500 +``` + +### Add extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: ELASTICSEARCH_VERSION + value: 6 +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use custom initialization scripts + +For advanced operations, the Bitnami Kibana chart allows using custom initialization scripts that will be mounted in `/docker-entrypoint.init-db`. Mount these extra scripts using a ConfigMap or a Secret (in case of sensitive data) and specify them via the `initScriptsCM` and `initScriptsSecret` chart parameters, as shown below: + +```text +elasticsearch.hosts[0]=elasticsearch-host +elasticsearch.port=9200 +initScriptsCM=special-scripts +initScriptsSecret=special-scripts-sensitive +``` + +### Install plugins + +The Bitnami Kibana chart allows you to install a set of plugins at deployment time using the `plugins` chart parameter, as shown in the example below: + +```text +elasticsearch.hosts[0]=elasticsearch-host +elasticsearch.port=9200 +plugins[0]=https://github.com/fbaligand/kibana-enhanced-table/releases/download/v1.5.0/enhanced-table-1.5.0_7.3.2.zip +``` + +> **NOTE** Make sure that the plugin is available for the Kibana version you are deploying + +### Import saved objects + +If you have visualizations and dashboards (in NDJSON format) to import to Kibana, create a ConfigMap that includes them and then install the chart with the `savedObjects.configmap` chart parameter, as shown below: + +```text +savedObjects.configmap=my-import +``` + +Alternatively, if the saved objects are available at a URL, import them with the `savedObjects.urls` chart parameter, as shown below: + +```text +savedObjects.urls[0]=www.my-site.com/import.ndjson +``` + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +#### Add a sample Elasticsearch container as sidecar + +This chart requires an Elasticsearch instance to work. For production, the options are to use an already existing Elasticsearch instance or deploy the [Elasticsearch chart](https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch) with the [`global.kibanaEnabled=true` parameter](https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch#enable-bundled-kibana). + +For testing purposes, use a sidecar Elasticsearch container setting the following parameters during the Kibana chart installation: + +```text +elasticsearch.hosts[0]=localhost +elasticsearch.port=9200 +sidecars[0].name=elasticsearch +sidecars[0].image=bitnami/elasticsearch:latest +sidecars[0].imagePullPolicy=IfNotPresent +sidecars[0].ports[0].name=http +sidecars[0].ports[0].containerPort=9200 +``` + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use one 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 Kibana](https://github.com/bitnami/containers/tree/main/bitnami/kibana) image can persist data. If enabled, the persisted path is `/bitnami/kibana` by default. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. + +### Add extra volumes + +The Bitnami Kibana chart supports mounting extra volumes (either PVCs, secrets or configmaps) by using the `extraVolumes` and `extraVolumeMounts` property. This can be combined with advanced operations like adding extra init containers and sidecars. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -286,178 +448,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/kiban > 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/kibana/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. - -### Change Kibana version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Use custom configuration - -The Bitnami Kibana chart supports using custom configuration settings. For example, to mount a custom `kibana.yml` you can create a ConfigMap like the following: - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: myconfig -data: - kibana.yml: |- - # Raw text of the file -``` - -And now you need to pass the ConfigMap name, to the corresponding parameter: `configurationCM=myconfig` - -An alternative is to provide extra configuration settings to the default kibana.yml that the chart deploys. This is done using the `extraConfiguration` value: - -```yaml -extraConfiguration: - "server.maxPayloadBytes": 1048576 - "server.pingTimeout": 1500 -``` - -### Add extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: ELASTICSEARCH_VERSION - value: 6 -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use custom initialization scripts - -For advanced operations, the Bitnami Kibana chart allows using custom initialization scripts that will be mounted in `/docker-entrypoint.init-db`. Mount these extra scripts using a ConfigMap or a Secret (in case of sensitive data) and specify them via the `initScriptsCM` and `initScriptsSecret` chart parameters, as shown below: - -```text -elasticsearch.hosts[0]=elasticsearch-host -elasticsearch.port=9200 -initScriptsCM=special-scripts -initScriptsSecret=special-scripts-sensitive -``` - -### Install plugins - -The Bitnami Kibana chart allows you to install a set of plugins at deployment time using the `plugins` chart parameter, as shown in the example below: - -```text -elasticsearch.hosts[0]=elasticsearch-host -elasticsearch.port=9200 -plugins[0]=https://github.com/fbaligand/kibana-enhanced-table/releases/download/v1.5.0/enhanced-table-1.5.0_7.3.2.zip -``` - -> **NOTE** Make sure that the plugin is available for the Kibana version you are deploying - -### Import saved objects - -If you have visualizations and dashboards (in NDJSON format) to import to Kibana, create a ConfigMap that includes them and then install the chart with the `savedObjects.configmap` chart parameter, as shown below: - -```text -savedObjects.configmap=my-import -``` - -Alternatively, if the saved objects are available at a URL, import them with the `savedObjects.urls` chart parameter, as shown below: - -```text -savedObjects.urls[0]=www.my-site.com/import.ndjson -``` - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -#### Add a sample Elasticsearch container as sidecar - -This chart requires an Elasticsearch instance to work. For production, the options are to use an already existing Elasticsearch instance or deploy the [Elasticsearch chart](https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch) with the [`global.kibanaEnabled=true` parameter](https://github.com/bitnami/charts/tree/main/bitnami/elasticsearch#enable-bundled-kibana). - -For testing purposes, use a sidecar Elasticsearch container setting the following parameters during the Kibana chart installation: - -```text -elasticsearch.hosts[0]=localhost -elasticsearch.port=9200 -sidecars[0].name=elasticsearch -sidecars[0].image=bitnami/elasticsearch:latest -sidecars[0].imagePullPolicy=IfNotPresent -sidecars[0].ports[0].name=http -sidecars[0].ports[0].containerPort=9200 -``` - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use one 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 Kibana](https://github.com/bitnami/containers/tree/main/bitnami/kibana) image can persist data. If enabled, the persisted path is `/bitnami/kibana` by default. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. - -### Add extra volumes - -The Bitnami Kibana chart supports mounting extra volumes (either PVCs, secrets or configmaps) by using the `extraVolumes` and `extraVolumeMounts` property. This can be combined with advanced operations like adding extra init containers and sidecars. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/kong/README.md b/bitnami/kong/README.md index 33f73198ae..b0feb0684d 100644 --- a/bitnami/kong/README.md +++ b/bitnami/kong/README.md @@ -44,14 +44,165 @@ These commands deploy kong on the Kubernetes cluster in the default configuratio > **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. + +### Database backend + +The Bitnami Kong chart allows setting two database backends: PostgreSQL or Cassandra. For each option, there are two extra possibilities: deploy a sub-chart with the database installation or use an existing one. The list below details the different options (replace the placeholders specified between _UNDERSCORES_): + +- Deploy the PostgreSQL sub-chart (default) ```console -helm delete my-release +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong ``` +> 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`. + +- Use an external PostgreSQL database + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong \ + --set postgresql.enabled=false \ + --set postgresql.external.host=_HOST_OF_YOUR_POSTGRESQL_INSTALLATION_ \ + --set postgresql.external.password=_PASSWORD_OF_YOUR_POSTGRESQL_INSTALLATION_ \ + --set postgresql.external.user=_USER_OF_YOUR_POSTGRESQL_INSTALLATION_ +``` + +> 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`. + +- Deploy the Cassandra sub-chart + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong \ + --set database=cassandra \ + --set postgresql.enabled=false \ + --set cassandra.enabled=true +``` + +> 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`. + +- Use an existing Cassandra installation + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong \ + --set database=cassandra \ + --set postgresql.enabled=false \ + --set cassandra.enabled=false \ + --set cassandra.external.hosts[0]=_CONTACT_POINT_0_OF_YOUR_CASSANDRA_CLUSTER_ \ + --set cassandra.external.hosts[1]=_CONTACT_POINT_1_OF_YOUR_CASSANDRA_CLUSTER_ \ + ... + --set cassandra.external.user=_USER_OF_YOUR_CASSANDRA_INSTALLATION_ \ + --set cassandra.external.password=_PASSWORD_OF_YOUR_CASSANDRA_INSTALLATION_ +``` + +> 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`. + +### DB-less + +Kong 1.1 added the capability to run Kong without a database, using only in-memory storage for entities: we call this DB-less mode. When running Kong DB-less, the configuration of entities is done in a second configuration file, in YAML or JSON, using declarative configuration (ref. [Link](https://legacy-gateway--kongdocs.netlify.app/gateway-oss/1.1.x/db-less-and-declarative-config/)). +As is said in step 4 of [kong official docker installation](https://docs.konghq.com/gateway/latest/production/deployment-topologies/db-less-and-declarative-config/#declarative-configuration), just add the env variable "KONG_DATABASE=off". + +#### How to enable it + +1. Set `database` value with any value other than "postgresql" or "cassandra". For example `database: "off"` +2. Use `kong.extraEnvVars` value to set the `KONG_DATABASE` environment variable: + +```yaml +kong.extraEnvVars: +- name: KONG_DATABASE + value: "off" +``` + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Kong (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `kong.extraEnvVars` property. + +```yaml +kong: + extraEnvVars: + - name: KONG_LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `kong.extraEnvVarsCM` or the `kong.extraEnvVarsSecret` values. + +The Kong Ingress Controller and the Kong Migration job also allow this kind of configuration via the `ingressController.extraEnvVars`, `ingressController.extraEnvVarsCM`, `ingressController.extraEnvVarsSecret`, `migration.extraEnvVars`, `migration.extraEnvVarsCM` and `migration.extraEnvVarsSecret` values. + +### Using custom init scripts + +For advanced operations, the Bitnami Kong charts allows using custom init scripts that will be mounted in `/docker-entrypoint.init-db`. You can use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. Then use the `kong.initScriptsCM` and `kong.initScriptsSecret` values. + +```console +elasticsearch.hosts[0]=elasticsearch-host +elasticsearch.port=9200 +initScriptsCM=special-scripts +initScriptsSecret=special-scripts-sensitive +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such as KongPlugins, KongConsumers, amongst others. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would activate a plugin at deployment time. + +```yaml +## Extra objects to deploy (value evaluated as a template) +## +extraDeploy: + - | + apiVersion: configuration.konghq.com/v1 + kind: KongPlugin + metadata: + name: {{ include "common.names.fullname" . }}-plugin-correlation + namespace: {{ .Release.Namespace }} + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} + config: + header_name: my-request-id + plugin: correlation-id +``` + +### 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. + ## Parameters ### Global parameters @@ -380,165 +531,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/kong > 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/kong/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. - -### Database backend - -The Bitnami Kong chart allows setting two database backends: PostgreSQL or Cassandra. For each option, there are two extra possibilities: deploy a sub-chart with the database installation or use an existing one. The list below details the different options (replace the placeholders specified between _UNDERSCORES_): - -- Deploy the PostgreSQL sub-chart (default) - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong -``` - -> 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`. - -- Use an external PostgreSQL database - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong \ - --set postgresql.enabled=false \ - --set postgresql.external.host=_HOST_OF_YOUR_POSTGRESQL_INSTALLATION_ \ - --set postgresql.external.password=_PASSWORD_OF_YOUR_POSTGRESQL_INSTALLATION_ \ - --set postgresql.external.user=_USER_OF_YOUR_POSTGRESQL_INSTALLATION_ -``` - -> 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`. - -- Deploy the Cassandra sub-chart - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong \ - --set database=cassandra \ - --set postgresql.enabled=false \ - --set cassandra.enabled=true -``` - -> 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`. - -- Use an existing Cassandra installation - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kong \ - --set database=cassandra \ - --set postgresql.enabled=false \ - --set cassandra.enabled=false \ - --set cassandra.external.hosts[0]=_CONTACT_POINT_0_OF_YOUR_CASSANDRA_CLUSTER_ \ - --set cassandra.external.hosts[1]=_CONTACT_POINT_1_OF_YOUR_CASSANDRA_CLUSTER_ \ - ... - --set cassandra.external.user=_USER_OF_YOUR_CASSANDRA_INSTALLATION_ \ - --set cassandra.external.password=_PASSWORD_OF_YOUR_CASSANDRA_INSTALLATION_ -``` - -> 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`. - -### DB-less - -Kong 1.1 added the capability to run Kong without a database, using only in-memory storage for entities: we call this DB-less mode. When running Kong DB-less, the configuration of entities is done in a second configuration file, in YAML or JSON, using declarative configuration (ref. [Link](https://legacy-gateway--kongdocs.netlify.app/gateway-oss/1.1.x/db-less-and-declarative-config/)). -As is said in step 4 of [kong official docker installation](https://docs.konghq.com/gateway/latest/production/deployment-topologies/db-less-and-declarative-config/#declarative-configuration), just add the env variable "KONG_DATABASE=off". - -#### How to enable it - -1. Set `database` value with any value other than "postgresql" or "cassandra". For example `database: "off"` -2. Use `kong.extraEnvVars` value to set the `KONG_DATABASE` environment variable: - -```yaml -kong.extraEnvVars: -- name: KONG_DATABASE - value: "off" -``` - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Kong (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `kong.extraEnvVars` property. - -```yaml -kong: - extraEnvVars: - - name: KONG_LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `kong.extraEnvVarsCM` or the `kong.extraEnvVarsSecret` values. - -The Kong Ingress Controller and the Kong Migration job also allow this kind of configuration via the `ingressController.extraEnvVars`, `ingressController.extraEnvVarsCM`, `ingressController.extraEnvVarsSecret`, `migration.extraEnvVars`, `migration.extraEnvVarsCM` and `migration.extraEnvVarsSecret` values. - -### Using custom init scripts - -For advanced operations, the Bitnami Kong charts allows using custom init scripts that will be mounted in `/docker-entrypoint.init-db`. You can use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. Then use the `kong.initScriptsCM` and `kong.initScriptsSecret` values. - -```console -elasticsearch.hosts[0]=elasticsearch-host -elasticsearch.port=9200 -initScriptsCM=special-scripts -initScriptsSecret=special-scripts-sensitive -``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such as KongPlugins, KongConsumers, amongst others. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would activate a plugin at deployment time. - -```yaml -## Extra objects to deploy (value evaluated as a template) -## -extraDeploy: - - | - apiVersion: configuration.konghq.com/v1 - kind: KongPlugin - metadata: - name: {{ include "common.names.fullname" . }}-plugin-correlation - namespace: {{ .Release.Namespace }} - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} - config: - header_name: my-request-id - plugin: correlation-id -``` - -### 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. - ## 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). diff --git a/bitnami/kube-prometheus/README.md b/bitnami/kube-prometheus/README.md index ac57daed3f..f0cd3d53a2 100644 --- a/bitnami/kube-prometheus/README.md +++ b/bitnami/kube-prometheus/README.md @@ -51,15 +51,71 @@ The command deploys kube-prometheus on the Kubernetes cluster in the default con > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` release: +### 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. + +### Additional scrape configurations + +The following values have been deprecated. See [Upgrading](#upgrading) below. ```console -helm delete my-release +prometheus.additionalScrapeConfigsExternal.enabled +prometheus.additionalScrapeConfigsExternal.name +prometheus.additionalScrapeConfigsExternal.key ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the flag `--purge` to delete all history too. +It is possible to inject externally managed scrape configurations via a Secret by setting `prometheus.additionalScrapeConfigs.enabled` to `true` and `prometheus.additionalScrapeConfigs.type` to `external`. The secret must exist in the same namespace as the chart deployment. Set the secret name using the parameter `prometheus.additionalScrapeConfigs.external.name`, and the key containing the additional scrape configuration using the `prometheus.additionalScrapeConfigs.external.key`. + +```text +prometheus.additionalScrapeConfigs.enabled=true +prometheus.additionalScrapeConfigs.type=external +prometheus.additionalScrapeConfigs.external.name=kube-prometheus-prometheus-scrape-config +prometheus.additionalScrapeConfigs.external.key=additional-scrape-configs.yaml +``` + +It is also possible to define scrape configuratios to be managed by the Helm chart by setting `prometheus.additionalScrapeConfigs.enabled` to `true` and `prometheus.additionalScrapeConfigs.type` to `internal`. You can then use `prometheus.additionalScrapeConfigs.internal.jobList` to define a list of additional scrape jobs for Prometheus. + +```text +prometheus.additionalScrapeConfigs.enabled=true +prometheus.additionalScrapeConfigs.type=internal +prometheus.additionalScrapeConfigs.internal.jobList= + - job_name: 'opentelemetry-collector' + # metrics_path defaults to '/metrics' + # scheme defaults to 'http'. + static_configs: + - targets: ['opentelemetry-collector:8889'] +``` + +For more information, see the [additional scrape configuration documentation](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/additional-scrape-config.md). + +### Additional alert relabel configurations + +It is possible to inject externally managed Prometheus alert relabel configurations via a Secret by setting `prometheus.additionalAlertRelabelConfigsExternal.enabled` to `true`. The secret must exist in the same namespace as the chart deployment. + +Set the secret name using the parameter `prometheus.additionalAlertRelabelConfigsExternal.name`, and the key containing the additional alert relabel configuration using the `prometheus.additionalAlertRelabelConfigsExternal.key`. For instance, if you created a secret named `kube-prometheus-prometheus-alert-relabel-config` and it contains a file named `additional-alert-relabel-configs.yaml`, use the parameters below: + +```text +prometheus.additionalAlertRelabelConfigsExternal.enabled=true +prometheus.additionalAlertRelabelConfigsExternal.name=kube-prometheus-prometheus-alert-relabel-config +prometheus.additionalAlertRelabelConfigsExternal.key=additional-alert-relabel-configs.yaml +``` + +### Set Pod affinity + +This chart allows setting custom Pod affinity using the `XXX.affinity` parameter(s). 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, use one 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. ## Parameters @@ -855,72 +911,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/kube- > 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/kube-prometheus/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. - -### Additional scrape configurations - -The following values have been deprecated. See [Upgrading](#upgrading) below. - -```console -prometheus.additionalScrapeConfigsExternal.enabled -prometheus.additionalScrapeConfigsExternal.name -prometheus.additionalScrapeConfigsExternal.key -``` - -It is possible to inject externally managed scrape configurations via a Secret by setting `prometheus.additionalScrapeConfigs.enabled` to `true` and `prometheus.additionalScrapeConfigs.type` to `external`. The secret must exist in the same namespace as the chart deployment. Set the secret name using the parameter `prometheus.additionalScrapeConfigs.external.name`, and the key containing the additional scrape configuration using the `prometheus.additionalScrapeConfigs.external.key`. - -```text -prometheus.additionalScrapeConfigs.enabled=true -prometheus.additionalScrapeConfigs.type=external -prometheus.additionalScrapeConfigs.external.name=kube-prometheus-prometheus-scrape-config -prometheus.additionalScrapeConfigs.external.key=additional-scrape-configs.yaml -``` - -It is also possible to define scrape configuratios to be managed by the Helm chart by setting `prometheus.additionalScrapeConfigs.enabled` to `true` and `prometheus.additionalScrapeConfigs.type` to `internal`. You can then use `prometheus.additionalScrapeConfigs.internal.jobList` to define a list of additional scrape jobs for Prometheus. - -```text -prometheus.additionalScrapeConfigs.enabled=true -prometheus.additionalScrapeConfigs.type=internal -prometheus.additionalScrapeConfigs.internal.jobList= - - job_name: 'opentelemetry-collector' - # metrics_path defaults to '/metrics' - # scheme defaults to 'http'. - static_configs: - - targets: ['opentelemetry-collector:8889'] -``` - -For more information, see the [additional scrape configuration documentation](https://github.com/prometheus-operator/prometheus-operator/blob/master/Documentation/additional-scrape-config.md). - -### Additional alert relabel configurations - -It is possible to inject externally managed Prometheus alert relabel configurations via a Secret by setting `prometheus.additionalAlertRelabelConfigsExternal.enabled` to `true`. The secret must exist in the same namespace as the chart deployment. - -Set the secret name using the parameter `prometheus.additionalAlertRelabelConfigsExternal.name`, and the key containing the additional alert relabel configuration using the `prometheus.additionalAlertRelabelConfigsExternal.key`. For instance, if you created a secret named `kube-prometheus-prometheus-alert-relabel-config` and it contains a file named `additional-alert-relabel-configs.yaml`, use the parameters below: - -```text -prometheus.additionalAlertRelabelConfigsExternal.enabled=true -prometheus.additionalAlertRelabelConfigsExternal.name=kube-prometheus-prometheus-alert-relabel-config -prometheus.additionalAlertRelabelConfigsExternal.key=additional-alert-relabel-configs.yaml -``` - -### Set Pod affinity - -This chart allows setting custom Pod affinity using the `XXX.affinity` parameter(s). 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, use one 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/kube-state-metrics/README.md b/bitnami/kube-state-metrics/README.md index 9821cb2066..57cedbd9a6 100644 --- a/bitnami/kube-state-metrics/README.md +++ b/bitnami/kube-state-metrics/README.md @@ -39,15 +39,65 @@ helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/kube-state-metrics The command deploys kube-state-metrics on the Kubernetes cluster in the default configuration. The [configuration](#configuration-and-installation-details) section lists the parameters that can be configured during installation. -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` release: +### Resource requests and limits -```console -helm delete my-release +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. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```yaml +sidecars: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +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/). + +### Set Pod affinity + +This chart allows you to set custom Pod 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, use one 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. ## Parameters @@ -243,66 +293,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/kube- > 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/kube-state-metrics/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. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set custom Pod 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, use one 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. - ## 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). diff --git a/bitnami/kubeapps/README.md b/bitnami/kubeapps/README.md index 9491e8197a..db201ea394 100644 --- a/bitnami/kubeapps/README.md +++ b/bitnami/kubeapps/README.md @@ -57,6 +57,86 @@ The command deploys Kubeapps on the Kubernetes cluster in the `kubeapps` namespa Once you have installed Kubeapps follow the [Getting Started Guide](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/getting-started.md) for additional information on how to access and use Kubeapps. +## 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/). + +### Configuring Initial Repositories + +By default, Kubeapps will track the [Bitnami Application Catalog](https://github.com/bitnami/charts). To change these defaults, override with your desired parameters the `apprepository.initialRepos` object present in the [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/kubeapps/values.yaml) file. + +### Enabling Operators + +Since v1.9.0 (and by default since v2.0), Kubeapps supports deploying and managing Operators within its dashboard. More information about how to enable and use this feature can be found in [this guide](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/operators.md). + +### Exposing Externally + +> **Note**: The Kubeapps frontend sets up a proxy to the Kubernetes API service which means that when exposing the Kubeapps service to a network external to the Kubernetes cluster (perhaps on an internal or public network), the Kubernetes API will also be exposed for authenticated requests from that network. It is highly recommended that you [use an OAuth2/OIDC provider with Kubeapps](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/using-an-OIDC-provider.md) to ensure that your authentication proxy is exposed rather than the Kubeapps frontend. This ensures that only the configured users trusted by your Identity Provider will be able to reach the Kubeapps frontend and therefore the Kubernetes API. Kubernetes service token authentication should only be used for users for demonstration purposes only, not production environments. + +#### LoadBalancer Service + +The simplest way to expose the Kubeapps Dashboard is to assign a LoadBalancer type to the Kubeapps frontend Service. For example, you can use the following parameter: `frontend.service.type=LoadBalancer` + +Wait for your cluster to assign a LoadBalancer IP or Hostname to the `kubeapps` Service and access it on that address: + +```console +kubectl get services --namespace kubeapps --watch +``` + +#### 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. + +To enable ingress integration, please set `ingress.enabled` to `true` + +##### Hosts + +Most likely you will only want to have one hostname that maps to this Kubeapps installation (use the `ingress.hostname` parameter to set the hostname), however, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object is an array. + +##### Annotations + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. Annotations can be set using `ingress.annotations`. + +##### TLS + +This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are four common use cases: + +- Helm generates/manages certificate secrets based on the parameters. +- The user generates/manages certificates separately. +- Helm creates self-signed certificates and generates/manages certificate secrets. +- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. + +In the first two cases, it is needed a certificate and a key. We would expect them to look like this: + +- certificate files should look like (and there can be more than one certificate if there is a certificate chain) + + ```console + -----BEGIN CERTIFICATE----- + MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV + ... + jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 + -----END CERTIFICATE----- + ``` + +- keys should look like: + + ```console + -----BEGIN RSA PRIVATE KEY----- + MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 + ... + wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= + -----END RSA PRIVATE KEY----- + ``` + +- If you are going to use Helm to manage the certificates based on the parameters, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. +- In case you are going to manage TLS secrets separately, please know that you must use 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). +- To use self-signed certificates created by Helm, set both `ingress.tls` and `ingress.selfSigned` to `true`. +- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, set `ingress.certManager` boolean to true to enable the corresponding annotations for cert-manager. + ## Parameters ### Global parameters @@ -689,122 +769,22 @@ helm install kubeapps --namespace kubeapps -f custom-values.yaml oci://REGISTRY_ > 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`. -## Configuration and installation details +## Troubleshooting -### Resource requests and limits +### How to install Kubeapps for demo purposes? -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. +Install Kubeapps for exclusively **demo purposes** by simply following the [getting started](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/getting-started.md) docs. -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/). +### How to install Kubeapps in production scenarios? -### Configuring Initial Repositories +For any user-facing installation, you should [configure an OAuth2/OIDC provider](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/using-an-OIDC-provider.md) to enable secure user authentication with Kubeapps and the cluster. +Please also refer to the [Access Control](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/howto/access-control.md) documentation to configure fine-grained access control for users. -By default, Kubeapps will track the [Bitnami Application Catalog](https://github.com/bitnami/charts). To change these defaults, override with your desired parameters the `apprepository.initialRepos` object present in the [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/kubeapps/values.yaml) file. +### How to use Kubeapps? -### Enabling Operators +Have a look at the [dashboard documentation](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/howto/dashboard.md) for knowing how to use the Kubeapps dashboard: deploying applications, listing and removing the applications running in your cluster and adding new repositories. -Since v1.9.0 (and by default since v2.0), Kubeapps supports deploying and managing Operators within its dashboard. More information about how to enable and use this feature can be found in [this guide](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/operators.md). - -### Exposing Externally - -> **Note**: The Kubeapps frontend sets up a proxy to the Kubernetes API service which means that when exposing the Kubeapps service to a network external to the Kubernetes cluster (perhaps on an internal or public network), the Kubernetes API will also be exposed for authenticated requests from that network. It is highly recommended that you [use an OAuth2/OIDC provider with Kubeapps](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/using-an-OIDC-provider.md) to ensure that your authentication proxy is exposed rather than the Kubeapps frontend. This ensures that only the configured users trusted by your Identity Provider will be able to reach the Kubeapps frontend and therefore the Kubernetes API. Kubernetes service token authentication should only be used for users for demonstration purposes only, not production environments. - -#### LoadBalancer Service - -The simplest way to expose the Kubeapps Dashboard is to assign a LoadBalancer type to the Kubeapps frontend Service. For example, you can use the following parameter: `frontend.service.type=LoadBalancer` - -Wait for your cluster to assign a LoadBalancer IP or Hostname to the `kubeapps` Service and access it on that address: - -```console -kubectl get services --namespace kubeapps --watch -``` - -#### 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. - -To enable ingress integration, please set `ingress.enabled` to `true` - -##### Hosts - -Most likely you will only want to have one hostname that maps to this Kubeapps installation (use the `ingress.hostname` parameter to set the hostname), however, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object is an array. - -##### Annotations - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. Annotations can be set using `ingress.annotations`. - -##### TLS - -This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are four common use cases: - -- Helm generates/manages certificate secrets based on the parameters. -- The user generates/manages certificates separately. -- Helm creates self-signed certificates and generates/manages certificate secrets. -- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. - -In the first two cases, it is needed a certificate and a key. We would expect them to look like this: - -- certificate files should look like (and there can be more than one certificate if there is a certificate chain) - - ```console - -----BEGIN CERTIFICATE----- - MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV - ... - jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 - -----END CERTIFICATE----- - ``` - -- keys should look like: - - ```console - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 - ... - wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= - -----END RSA PRIVATE KEY----- - ``` - -- If you are going to use Helm to manage the certificates based on the parameters, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. -- In case you are going to manage TLS secrets separately, please know that you must use 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). -- To use self-signed certificates created by Helm, set both `ingress.tls` and `ingress.selfSigned` to `true`. -- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, set `ingress.certManager` boolean to true to enable the corresponding annotations for cert-manager. - -## Upgrading Kubeapps - -You can upgrade Kubeapps from the Kubeapps web interface. Select the namespace in which Kubeapps is installed (`kubeapps` if you followed the instructions in this guide) and click on the "Upgrade" button. Select the new version and confirm. - -You can also use the Helm CLI to upgrade Kubeapps, first ensure you have updated your local chart repository cache: - -```console -helm repo update -``` - -Now upgrade Kubeapps: - -```console -export RELEASE_NAME=kubeapps -helm upgrade $RELEASE_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/kubeapps -``` - -> 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`. - -If you find issues upgrading Kubeapps, check the [troubleshooting](#error-while-upgrading-the-chart) section. - -### To 14.0.0 - -This major updates the PostgreSQL subchart to its newest major, 13.0.0. [Here](https://github.com/bitnami/charts/tree/master/bitnami/postgresql#to-1300) you can find more information about the changes introduced in that version. - -### To 13.0.0 - -This major updates the Redis® subchart to its newest major, 18.0.0. [Here](https://github.com/bitnami/charts/tree/main/bitnami/redis#to-1800) you can find more information about the changes introduced in that version. - -NOTE: Due to an error in our release process, Redis®' chart versions higher or equal than 17.15.4 already use Redis® 7.2 by default. - -### To 12.0.0 - -This major updates the PostgreSQL subchart to its newest major, 12.0.0. [Here](https://github.com/bitnami/charts/tree/master/bitnami/postgresql#to-1200) you can find more information about the changes introduced in that version. - -## Uninstalling the Chart +### How to uninstall Kubeapps To uninstall/delete the `kubeapps` deployment: @@ -825,35 +805,6 @@ If you have dedicated a namespace only for Kubeapps you can completely clean the kubectl delete namespace kubeapps ``` -## FAQ - -- [How to install Kubeapps for demo purposes?](#how-to-install-kubeapps-for-demo-purposes) -- [How to install Kubeapps in production scenarios?](#how-to-install-kubeapps-in-production-scenarios) -- [How to use Kubeapps?](#how-to-use-kubeapps) -- [How to configure Kubeapps with Ingress](#how-to-configure-kubeapps-with-ingress) - - [Serving Kubeapps in a subpath](#serving-kubeapps-in-a-subpath) -- [Can Kubeapps install apps into more than one cluster?](#can-kubeapps-install-apps-into-more-than-one-cluster) -- [Can Kubeapps be installed without Internet connection?](#can-kubeapps-be-installed-without-internet-connection) -- [Does Kubeapps support private repositories?](#does-kubeapps-support-private-repositories) -- [Is there any API documentation?](#is-there-any-api-documentation) -- [Why can't I configure global private repositories?](#why-cant-i-configure-global-private-repositories) -- [Does Kubeapps support Operators?](#does-kubeapps-support-operators) -- [Slow response when listing namespaces?](#slow-response-when-listing-namespaces) -- [More questions?](#more-questions) - -### How to install Kubeapps for demo purposes? - -Install Kubeapps for exclusively **demo purposes** by simply following the [getting started](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/getting-started.md) docs. - -### How to install Kubeapps in production scenarios? - -For any user-facing installation, you should [configure an OAuth2/OIDC provider](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/tutorials/using-an-OIDC-provider.md) to enable secure user authentication with Kubeapps and the cluster. -Please also refer to the [Access Control](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/howto/access-control.md) documentation to configure fine-grained access control for users. - -### How to use Kubeapps? - -Have a look at the [dashboard documentation](https://github.com/vmware-tanzu/kubeapps/blob/main/site/content/docs/latest/howto/dashboard.md) for knowing how to use the Kubeapps dashboard: deploying applications, listing and removing the applications running in your cluster and adding new repositories. - ### How to configure Kubeapps with Ingress The example below will match the URL `http://example.com` to the Kubeapps dashboard. For further configuration, please refer to your specific Ingress configuration docs (e.g., [NGINX](https://github.com/kubernetes/ingress-nginx) or [HAProxy](https://github.com/haproxytech/kubernetes-ingress)). @@ -943,45 +894,6 @@ This can lead to a slow response if the number of namespaces on the cluster is l To reduce this response time, you can increase the number of checks that Kubeapps will perform in parallel (per connection) setting the value: `kubeappsapis.burst=` and `kubeappsapis.QPS=`. -### More questions? - -Feel free to [open an issue](https://github.com/vmware-tanzu/kubeapps/issues/new) if you have any questions! - -## Troubleshooting - -### Upgrading to chart version 8.0.0 - -This major release renames several values in this chart and adds missing features, in order to get aligned with the rest of the assets in the Bitnami charts repository. - -Additionally, it updates both the [PostgreSQL](https://github.com/bitnami/charts/tree/main/bitnami/postgresql) and the [Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis) subcharts to their latest major versions, 11.0.0 and 16.0.0 respectively, where similar changes have been also performed. -Check [PostgreSQL Upgrading Notes](https://github.com/bitnami/charts/tree/master/bitnami/postgresql#to-1100) and [Redis Upgrading Notes](https://github.com/bitnami/charts/tree/main/bitnami/redis#to-1600) for more information. - -The following values have been renamed: - -- `frontend.service.port` renamed as `frontend.service.ports.http`. -- `frontend.service.nodePort` renamed as `frontend.service.nodePorts.http`. -- `frontend.containerPort` renamed as `frontend.containerPorts.http`. -- `dashboard.service.port` renamed as `dashboard.service.ports.http`. -- `dashboard.containerPort` renamed as `dashboard.containerPorts.http`. -- `apprepository.service.port` renamed as `apprepository.service.ports.http`. -- `apprepository.containerPort` renamed as `apprepository.containerPorts.http`. -- `kubeops.service.port` renamed as `kubeops.service.ports.http`. -- `kubeops.containerPort` renamed as `kubeops.containerPorts.http`. -- `assetsvc.service.port` renamed as `assetsvc.service.ports.http`. -- `assetsvc.containerPort` renamed as `assetsvc.containerPorts.http`. -- `authProxy.containerPort` renamed as `authProxy.containerPorts.proxy`. -- `authProxy.additionalFlags` renamed as `authProxy.extraFlags`, -- Pinniped Proxy service no longer uses `pinnipedProxy.containerPort`. Use `pinnipedProxy.service.ports.pinnipedProxy` to change the service port. -- `pinnipedProxy.containerPort` renamed as `pinnipedProxy.containerPorts.pinnipedProxy`. -- `postgresql.replication.enabled` has been removed. Use `postgresql.architecture` instead. -- `postgresql.postgresqlDatabase` renamed as `postgresql.auth.database`. -- `postgresql.postgresqlPassword` renamed as `postgresql.auth.password`. -- `postgresql.existingSecret` renamed as `postgresql.auth.existingSecret`. -- `redis.redisPassword` renamed as `redis.auth.password`. -- `redis.existingSecret` renamed as `redis.auth.existingSecret`. - -Note also that if you have an existing Postgresql secret that is used for Kubeapps, you will need to update the key from `postgresql-password` to `postgres-password`. - ### Nginx Ipv6 error When starting the application with the `--set enableIPv6=true` option, the Nginx server present in the services `kubeapps` and `kubeapps-internal-dashboard` may fail with the following: @@ -1025,8 +937,8 @@ helm install --name kubeapps --namespace kubeapps oci://REGISTRY_NAME/REPOSITORY It is possible that when upgrading Kubeapps an error appears. That can be caused by a breaking change in the new chart or because the current chart installation is in an inconsistent state. If you find issues upgrading Kubeapps you can follow these steps: > Note: These steps assume that you have installed Kubeapps in the namespace `kubeapps` using the name `kubeapps`. If that is not the case replace the command with your namespace and/or name. -> Note: If you are upgrading from 2.3.1 see the [following section](#upgrading-to-231). -> Note: If you are upgrading from 1.X to 2.X see the [following section](#upgrading-to-20). +> Note: If you are upgrading from 2.3.1 see the [following section](#to-600). +> Note: If you are upgrading from 1.X to 2.X see the [following section](#to-400). 1. (Optional) Backup your personal repositories (if you have any): @@ -1073,7 +985,79 @@ It is possible that when upgrading Kubeapps an error appears. That can be caused After that you should be able to access the new version of Kubeapps. If the above doesn't work for you or you run into any other issues please open an [issue](https://github.com/vmware-tanzu/kubeapps/issues/new). -### Upgrading to chart version 7.0.0 +### More questions? + +Feel free to [open an issue](https://github.com/vmware-tanzu/kubeapps/issues/new) if you have any questions! + +## Upgrading Kubeapps + +You can upgrade Kubeapps from the Kubeapps web interface. Select the namespace in which Kubeapps is installed (`kubeapps` if you followed the instructions in this guide) and click on the "Upgrade" button. Select the new version and confirm. + +You can also use the Helm CLI to upgrade Kubeapps, first ensure you have updated your local chart repository cache: + +```console +helm repo update +``` + +Now upgrade Kubeapps: + +```console +export RELEASE_NAME=kubeapps +helm upgrade $RELEASE_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/kubeapps +``` + +> 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`. + +If you find issues upgrading Kubeapps, check the [troubleshooting](#error-while-upgrading-the-chart) section. + +### To 14.0.0 + +This major updates the PostgreSQL subchart to its newest major, 13.0.0. [Here](https://github.com/bitnami/charts/tree/master/bitnami/postgresql#to-1300) you can find more information about the changes introduced in that version. + +### To 13.0.0 + +This major updates the Redis® subchart to its newest major, 18.0.0. [Here](https://github.com/bitnami/charts/tree/main/bitnami/redis#to-1800) you can find more information about the changes introduced in that version. + +NOTE: Due to an error in our release process, Redis®' chart versions higher or equal than 17.15.4 already use Redis® 7.2 by default. + +### To 12.0.0 + +This major updates the PostgreSQL subchart to its newest major, 12.0.0. [Here](https://github.com/bitnami/charts/tree/master/bitnami/postgresql#to-1200) you can find more information about the changes introduced in that version. + +### To 8.0.0 + +This major release renames several values in this chart and adds missing features, in order to get aligned with the rest of the assets in the Bitnami charts repository. + +Additionally, it updates both the [PostgreSQL](https://github.com/bitnami/charts/tree/main/bitnami/postgresql) and the [Redis](https://github.com/bitnami/charts/tree/main/bitnami/redis) subcharts to their latest major versions, 11.0.0 and 16.0.0 respectively, where similar changes have been also performed. +Check [PostgreSQL Upgrading Notes](https://github.com/bitnami/charts/tree/master/bitnami/postgresql#to-1100) and [Redis Upgrading Notes](https://github.com/bitnami/charts/tree/main/bitnami/redis#to-1600) for more information. + +The following values have been renamed: + +- `frontend.service.port` renamed as `frontend.service.ports.http`. +- `frontend.service.nodePort` renamed as `frontend.service.nodePorts.http`. +- `frontend.containerPort` renamed as `frontend.containerPorts.http`. +- `dashboard.service.port` renamed as `dashboard.service.ports.http`. +- `dashboard.containerPort` renamed as `dashboard.containerPorts.http`. +- `apprepository.service.port` renamed as `apprepository.service.ports.http`. +- `apprepository.containerPort` renamed as `apprepository.containerPorts.http`. +- `kubeops.service.port` renamed as `kubeops.service.ports.http`. +- `kubeops.containerPort` renamed as `kubeops.containerPorts.http`. +- `assetsvc.service.port` renamed as `assetsvc.service.ports.http`. +- `assetsvc.containerPort` renamed as `assetsvc.containerPorts.http`. +- `authProxy.containerPort` renamed as `authProxy.containerPorts.proxy`. +- `authProxy.additionalFlags` renamed as `authProxy.extraFlags`, +- Pinniped Proxy service no longer uses `pinnipedProxy.containerPort`. Use `pinnipedProxy.service.ports.pinnipedProxy` to change the service port. +- `pinnipedProxy.containerPort` renamed as `pinnipedProxy.containerPorts.pinnipedProxy`. +- `postgresql.replication.enabled` has been removed. Use `postgresql.architecture` instead. +- `postgresql.postgresqlDatabase` renamed as `postgresql.auth.database`. +- `postgresql.postgresqlPassword` renamed as `postgresql.auth.password`. +- `postgresql.existingSecret` renamed as `postgresql.auth.existingSecret`. +- `redis.redisPassword` renamed as `redis.auth.password`. +- `redis.existingSecret` renamed as `redis.auth.existingSecret`. + +Note also that if you have an existing Postgresql secret that is used for Kubeapps, you will need to update the key from `postgresql-password` to `postgres-password`. + +### To 7.0.0 In this release, no breaking changes were included in Kubeapps (version 2.3.2). However, the chart adopted the standardizations included in the rest of the charts in the Bitnami catalog. @@ -1082,7 +1066,7 @@ Most of these standardizations simply add new parameters that allow to add more - Chart labels were adapted to follow the [Helm charts standard labels](https://helm.sh/docs/chart_best_practices/labels/#standard-labels). - `securityContext.*` parameters are deprecated in favor of `XXX.podSecurityContext.*` and `XXX.containerSecurityContext.*`, where _XXX_ is placeholder you need to replace with the actual component(s). For instance, to modify the container security context for "kubeops" use `kubeops.podSecurityContext` and `kubeops.containerSecurityContext` parameters. -### Upgrading to 2.3.1 +### To 6.0.0 Kubeapps 2.3.1 (Chart version 6.0.0) introduces some breaking changes. Helm-specific functionality has been removed in order to support other installation methods (like using YAML manifests, [`kapp`](https://carvel.dev/kapp) or [`kustomize`](https://kustomize.io/)). Because of that, there are some steps required before upgrading from a previous version: @@ -1128,7 +1112,7 @@ helm upgrade kubeapps oci://REGISTRY_NAME/REPOSITORY_NAME/kubeapps -n kubeapps - > 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`. -### Upgrading to 2.0.1 (Chart 5.0.0) +### To 5.0.0 [On November 13, 2020, Helm 2 support was formally finished](https://github.com/helm/charts#status-of-the-project), this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm 3 and to be consistent with the Helm project itself regarding the Helm 2 EOL. @@ -1158,7 +1142,7 @@ kubectl delete statefulset -n kubeapps kubeapps-postgresql-master kubeapps-postg - - -### Upgrading to 2.0 +### To 4.0.0 Kubeapps 2.0 (Chart version 4.0.0) introduces some breaking changes: @@ -1190,4 +1174,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. \ No newline at end of file +limitations under the License. diff --git a/bitnami/kuberay/README.md b/bitnami/kuberay/README.md index 6aa8797f83..42614b4c46 100644 --- a/bitnami/kuberay/README.md +++ b/bitnami/kuberay/README.md @@ -41,15 +41,82 @@ The command deploys kuberay on the Kubernetes cluster in the default configurati > **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 -```console -helm delete my-release +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. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `operator`, `apiserver` and `cluster` sections. + +```yaml +operator: + extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `operator`, `apiserver` and `cluster` sections. + +### Sidecars + +If additional containers are needed in the same pod as KubeRay (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `operator`, `apiserver` and `cluster` 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/). + +### Deploying Ray Cluster + +The Bitnami KubeRay chart allows deploying a RayCluster object. It is possible to define the head parameters under the `cluster.head` section, as well as the properties of the workers using the `cluster.worker` section. It is possible to describe different groupspecs under the `cluster.worker.groupSpecs` section (any parameter not defined will be taken from the `cluster.worker.common` section). + +### Pod affinity + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the `operator`, `apiserver` and `cluster` sections. ## Parameters @@ -553,83 +620,6 @@ helm install my-release -f values.yaml REGISTRY_NAME/REPOSITORY_NAME/kuberay > 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/kuberay/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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `operator`, `apiserver` and `cluster` sections. - -```yaml -operator: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `operator`, `apiserver` and `cluster` sections. - -### Sidecars - -If additional containers are needed in the same pod as KubeRay (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `operator`, `apiserver` and `cluster` 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/). - -### Deploying Ray Cluster - -The Bitnami KubeRay chart allows deploying a RayCluster object. It is possible to define the head parameters under the `cluster.head` section, as well as the properties of the workers using the `cluster.worker` section. It is possible to describe different groupspecs under the `cluster.worker.groupSpecs` section (any parameter not defined will be taken from the `cluster.worker.common` section). - -### Pod affinity - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the `operator`, `apiserver` and `cluster` sections. - ## 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). diff --git a/bitnami/kubernetes-event-exporter/README.md b/bitnami/kubernetes-event-exporter/README.md index 78e41dcce5..021994a2ac 100644 --- a/bitnami/kubernetes-event-exporter/README.md +++ b/bitnami/kubernetes-event-exporter/README.md @@ -41,15 +41,29 @@ These commands deploy Kubernetes Event Exporter on the Kubernetes cluster in the > **Tip**: List all releases using `helm list` or `helm ls --all-namespaces` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` deployment: +### Resource requests and limits -```console -helm delete my-release -``` +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. -The command removes all the Kubernetes components associated with the chart and deletes the release. +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. + +### Use a different version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Set Pod affinity + +This chart allows you to set custom Pod 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, use one 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. ## Parameters @@ -209,30 +223,6 @@ The command removes all the Kubernetes components associated with the chart and | `autoscaling.vpa.updatePolicy.minReplicas` | Specifies minimal number of replicas which need to be alive for VPA Updater to attempt pod eviction | `1` | | `autoscaling.vpa.updatePolicy.updateMode` | Autoscaling update policy Specifies whether recommended updates are applied when a Pod is started and whether recommended updates are applied during the life of a Pod | `Auto` | -## 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. - -### Use a different version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Set Pod affinity - -This chart allows you to set custom Pod 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, use one 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. - ## 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). diff --git a/bitnami/logstash/README.md b/bitnami/logstash/README.md index 0d81bab76c..871d38f185 100644 --- a/bitnami/logstash/README.md +++ b/bitnami/logstash/README.md @@ -41,15 +41,120 @@ These commands deploy logstash on the Kubernetes cluster in the default configur > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` statefulset: +### Resource requests and limits -```console -helm delete my-release +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. + +### Expose the Logstash service + +The service(s) created by the deployment can be exposed within or outside the cluster using any of the following approaches: + +- **Ingress**: This requires an Ingress controller to be installed in the Kubernetes cluster. Set `ingress.enabled=true` to expose the corresponding service(s) through Ingress. +- **ClusterIP**: This exposes the service(s) on a cluster-internal IP address. This approach makes the corresponding service(s) reachable only from within the cluster. Set `service.type=ClusterIP` to choose this approach. +- **NodePort**: This exposes the service() on each node's IP address at a static port (the NodePort). This approach makes the corresponding service(s) reachable from outside the cluster by requesting the static port using the node's IP address, such as *NODE-IP:NODE-PORT*. Set `service.type=NodePort` to choose this approach. +- **LoadBalancer**: This exposes the service(s) externally using a cloud provider's load balancer. Set `service.type=LoadBalancer` to choose this approach. + +### Use custom configuration + +By default, this Helm chart provides a basic configuration for Logstash: listening to HTTP requests on port 8080 and writing them to the standard output. + +This Logstash configuration can be adjusted using the *input*, *filter*, and *output* parameters, which allow specification of the input, filter and output plugins configuration respectively. In addition to these options, the chart also supports reading configuration from an external ConfigMap via the *existingConfiguration* parameter. Note that this will override the parameters discussed previously. + +### Create and use multiple pipelines + +The chart supports the use of [multiple pipelines](https://www.elastic.co/guide/en/logstash/master/multiple-pipelines.html) by setting the `enableMultiplePipelines` parameter to `true`. + +To do this, place the `pipelines.yml` file in the `files/conf` directory, together with the rest of the desired configuration files. If the `enableMultiplePipelines` parameter is set to `true` but the `pipelines.yml` file does not exist in the mounted volume, a dummy file is created using the default configuration (a single pipeline). + +The chart also supports setting an external ConfigMap with all the configuration filesvia the `existingConfiguration` parameter. + +Here is an example of creating multiple pipelines using a ConfigMap: + +- Create a ConfigMap with the configuration files: + + ```bash + $ cat bye.conf + input { + file { + path => "/tmp/bye" + } + } + output { + stdout { } + } + + $ cat hello.conf + input { + file { + path => "/tmp/hello" + } + } + output { + stdout { } + } + + $ cat pipelines.yml + - pipeline.id: hello + path.config: "/opt/bitnami/logstash/config/hello.conf" + - pipeline.id: bye + path.config: "/opt/bitnami/logstash/config/bye.conf" + + $ kubectl create cm multipleconfig --from-file=pipelines.yml --from-file=hello.conf --from-file=bye.conf + ``` + +- Deploy the Helm chart with the `enableMultiplePipelines` parameter: + + ```bash + helm install logstash . --set enableMultiplePipelines=true --set existingConfiguration=multipleconfig + ``` + +- Create dummy events in the tracked files and check the result in the Logstash output: + + ```bash + kubectl exec -ti logstash-0 -- bash -c 'echo hi >> /tmp/hello' + kubectl exec -ti logstash-0 -- bash -c 'echo bye >> /tmp/bye' + ``` + +### Add extra environment variables + +To add extra environment variables, use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: ELASTICSEARCH_HOST + value: "x.y.z" ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +To add extra environment variables from an external ConfigMap or secret, use the `extraEnvVarsCM` and `extraEnvVarsSecret` properties. Note that the secret and ConfigMap should be already available in the namespace. + +```yaml +extraEnvVarsSecret: logstash-secrets +extraEnvVarsCM: logstash-configmap +``` + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 Logstash](https://github.com/bitnami/containers/tree/main/bitnami/logstash) image stores the Logstash data at the `/bitnami/logstash/data` path of the container. + +Persistent Volume Claims (PVCs) 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. ## Parameters @@ -241,121 +346,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/logst > 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/logstash/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. - -### Expose the Logstash service - -The service(s) created by the deployment can be exposed within or outside the cluster using any of the following approaches: - -- **Ingress**: This requires an Ingress controller to be installed in the Kubernetes cluster. Set `ingress.enabled=true` to expose the corresponding service(s) through Ingress. -- **ClusterIP**: This exposes the service(s) on a cluster-internal IP address. This approach makes the corresponding service(s) reachable only from within the cluster. Set `service.type=ClusterIP` to choose this approach. -- **NodePort**: This exposes the service() on each node's IP address at a static port (the NodePort). This approach makes the corresponding service(s) reachable from outside the cluster by requesting the static port using the node's IP address, such as *NODE-IP:NODE-PORT*. Set `service.type=NodePort` to choose this approach. -- **LoadBalancer**: This exposes the service(s) externally using a cloud provider's load balancer. Set `service.type=LoadBalancer` to choose this approach. - -### Use custom configuration - -By default, this Helm chart provides a basic configuration for Logstash: listening to HTTP requests on port 8080 and writing them to the standard output. - -This Logstash configuration can be adjusted using the *input*, *filter*, and *output* parameters, which allow specification of the input, filter and output plugins configuration respectively. In addition to these options, the chart also supports reading configuration from an external ConfigMap via the *existingConfiguration* parameter. Note that this will override the parameters discussed previously. - -### Create and use multiple pipelines - -The chart supports the use of [multiple pipelines](https://www.elastic.co/guide/en/logstash/master/multiple-pipelines.html) by setting the `enableMultiplePipelines` parameter to `true`. - -To do this, place the `pipelines.yml` file in the `files/conf` directory, together with the rest of the desired configuration files. If the `enableMultiplePipelines` parameter is set to `true` but the `pipelines.yml` file does not exist in the mounted volume, a dummy file is created using the default configuration (a single pipeline). - -The chart also supports setting an external ConfigMap with all the configuration filesvia the `existingConfiguration` parameter. - -Here is an example of creating multiple pipelines using a ConfigMap: - -- Create a ConfigMap with the configuration files: - - ```bash - $ cat bye.conf - input { - file { - path => "/tmp/bye" - } - } - output { - stdout { } - } - - $ cat hello.conf - input { - file { - path => "/tmp/hello" - } - } - output { - stdout { } - } - - $ cat pipelines.yml - - pipeline.id: hello - path.config: "/opt/bitnami/logstash/config/hello.conf" - - pipeline.id: bye - path.config: "/opt/bitnami/logstash/config/bye.conf" - - $ kubectl create cm multipleconfig --from-file=pipelines.yml --from-file=hello.conf --from-file=bye.conf - ``` - -- Deploy the Helm chart with the `enableMultiplePipelines` parameter: - - ```bash - helm install logstash . --set enableMultiplePipelines=true --set existingConfiguration=multipleconfig - ``` - -- Create dummy events in the tracked files and check the result in the Logstash output: - - ```bash - kubectl exec -ti logstash-0 -- bash -c 'echo hi >> /tmp/hello' - kubectl exec -ti logstash-0 -- bash -c 'echo bye >> /tmp/bye' - ``` - -### Add extra environment variables - -To add extra environment variables, use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: ELASTICSEARCH_HOST - value: "x.y.z" -``` - -To add extra environment variables from an external ConfigMap or secret, use the `extraEnvVarsCM` and `extraEnvVarsSecret` properties. Note that the secret and ConfigMap should be already available in the namespace. - -```yaml -extraEnvVarsSecret: logstash-secrets -extraEnvVarsCM: logstash-configmap -``` - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 Logstash](https://github.com/bitnami/containers/tree/main/bitnami/logstash) image stores the Logstash data at the `/bitnami/logstash/data` path of the container. - -Persistent Volume Claims (PVCs) 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. - ## 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). diff --git a/bitnami/magento/README.md b/bitnami/magento/README.md index 3adba55328..abf22a8277 100644 --- a/bitnami/magento/README.md +++ b/bitnami/magento/README.md @@ -45,15 +45,221 @@ The command deploys Magento on the Kubernetes cluster in the default configurati > **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 -```console -helm delete my-release +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 + +### 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. + +To enable ingress integration, please set `ingress.enabled` to `true`. + +#### Hosts + +Most likely you will only want to have one hostname that maps to this Magento installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. + +### Certificates + +#### TLS Secrets + +This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are three common use cases: + +- Helm generates/manages certificate secrets. +- User generates/manages certificates separately. +- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. + +In the first two cases, it's needed a certificate and a key. We would expect them to look like this: + +- certificate files should look like (and there can be more than one certificate if there is a certificate chain) + + ```console + -----BEGIN CERTIFICATE----- + MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV + ... + jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 + -----END CERTIFICATE----- + ``` + +- keys should look like: + + ```console + -----BEGIN RSA PRIVATE KEY----- + MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 + ... + wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= + -----END RSA PRIVATE KEY----- + ``` + +If you are going to use Helm to manage the certificates, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. + +If you are going to manage TLS secrets outside of Helm, please know that you can create a TLS secret (named `magento.local-tls` for example). + +#### CA Certificates + +Custom CA certificates not included in the base docker image can be added by means of existing secrets. The secret must exist in the same namespace and contain the desired CA certificates to import. By default, all found certificate files will be loaded. + +```yaml +certificates: + customCAs: + - secret: my-ca-1 + - secret: my-ca-2 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +> Tip! You can create a secret containing your CA certificates using the following command: + +```console +kubectl create secret generic my-ca-1 --from-file my-ca-1.crt +``` + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Magento (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +If these sidecars export extra ports, you can add extra port definitions using the `service.extraPorts` value: + +```yaml +service: +... + extraPorts: + - name: extraPort + port: 11311 + targetPort: 11311 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Using an external database + +Sometimes you may want to have Magento connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use run a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#parameters). You should also disable the MariaDB installation with the `mariadb.enabled` option. For example with the following parameters: + +```console +mariadb.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=3306 +``` + +Note also if you disable MariaDB per above you MUST supply values for the `externalDatabase` connection. + +In case the database already contains data from a previous Magento installation, you need to set the `magentoSkipInstall` parameter to _true_. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. This parameter force the container to not execute the Magento installation wizard. This is necessary in case you use a database that already has Magento data [+info](https://github.com/bitnami/containers/tree/main/bitnami/magento#connect-magento-docker-container-to-an-existing-database). + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more infomation 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 Magento](https://github.com/bitnami/containers/tree/main/bitnami/magento) image stores the Magento data and configurations at the `/bitnami/magento` and `/bitnami/apache` paths of the container. + +Persistent Volume Claims are used to keep the data across deployments. There is a [known issue](https://github.com/kubernetes/kubernetes/issues/39178) in Kubernetes Clusters with EBS in different availability zones. Ensure your cluster is configured properly to create Volumes in the same availability zone where the nodes are running. Kuberentes 1.12 solved this issue with the [Volume Binding Mode](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode). + +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/magento + ``` + + > 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/magento + ``` + + > 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 `magento-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 Magento file directory permissions yourself and disable or clear Magento cache. ## Parameters @@ -388,220 +594,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/magen > 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/magento/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 - -### 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. - -To enable ingress integration, please set `ingress.enabled` to `true`. - -#### Hosts - -Most likely you will only want to have one hostname that maps to this Magento installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. - -### TLS Secrets - -This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are three common use cases: - -- Helm generates/manages certificate secrets. -- User generates/manages certificates separately. -- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. - -In the first two cases, it's needed a certificate and a key. We would expect them to look like this: - -- certificate files should look like (and there can be more than one certificate if there is a certificate chain) - - ```console - -----BEGIN CERTIFICATE----- - MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV - ... - jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 - -----END CERTIFICATE----- - ``` - -- keys should look like: - - ```console - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 - ... - wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= - -----END RSA PRIVATE KEY----- - ``` - -If you are going to use Helm to manage the certificates, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. - -If you are going to manage TLS secrets outside of Helm, please know that you can create a TLS secret (named `magento.local-tls` for example). - -## Persistence - -The [Bitnami Magento](https://github.com/bitnami/containers/tree/main/bitnami/magento) image stores the Magento data and configurations at the `/bitnami/magento` and `/bitnami/apache` paths of the container. - -Persistent Volume Claims are used to keep the data across deployments. There is a [known issue](https://github.com/kubernetes/kubernetes/issues/39178) in Kubernetes Clusters with EBS in different availability zones. Ensure your cluster is configured properly to create Volumes in the same availability zone where the nodes are running. Kuberentes 1.12 solved this issue with the [Volume Binding Mode](https://kubernetes.io/docs/concepts/storage/storage-classes/#volume-binding-mode). - -See the [Parameters](#parameters) section to configure the PVC or to disable persistence. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Magento (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -If these sidecars export extra ports, you can add extra port definitions using the `service.extraPorts` value: - -```yaml -service: -... - extraPorts: - - name: extraPort - port: 11311 - targetPort: 11311 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Using an external database - -Sometimes you may want to have Magento connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use run a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#parameters). You should also disable the MariaDB installation with the `mariadb.enabled` option. For example with the following parameters: - -```console -mariadb.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=3306 -``` - -Note also if you disable MariaDB per above you MUST supply values for the `externalDatabase` connection. - -In case the database already contains data from a previous Magento installation, you need to set the `magentoSkipInstall` parameter to _true_. Otherwise, the container would execute the installation wizard and could modify the existing data in the database. This parameter force the container to not execute the Magento installation wizard. This is necessary in case you use a database that already has Magento data [+info](https://github.com/bitnami/containers/tree/main/bitnami/magento#connect-magento-docker-container-to-an-existing-database). - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more infomation 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. - -### 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/magento - ``` - - > 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/magento - ``` - - > 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 `magento-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 Magento file directory permissions yourself and disable or clear Magento cache. - -## CA Certificates - -Custom CA certificates not included in the base docker image can be added by means of existing secrets. The secret must exist in the same namespace and contain the desired CA certificates to import. By default, all found certificate files will be loaded. - -```yaml -certificates: - customCAs: - - secret: my-ca-1 - - secret: my-ca-2 -``` - -> Tip! You can create a secret containing your CA certificates using the following command: - -```console -kubectl create secret generic my-ca-1 --from-file my-ca-1.crt -``` - ## 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). diff --git a/bitnami/mariadb-galera/README.md b/bitnami/mariadb-galera/README.md index d71ad0eacf..205e3d64b4 100644 --- a/bitnami/mariadb-galera/README.md +++ b/bitnami/mariadb-galera/README.md @@ -22,6 +22,19 @@ This chart bootstraps a [MariaDB Galera](https://github.com/bitnami/containers/t Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters. +## Differences between the the Bitnami MariaDB Galera and Bitnami MariaDB Helm charts + +There are two different ways to deploy a MariaDB cluster, using the MariaDB Helm chart or the MariaDB Galera Helm chart. Both solutions provide a simply and reliable way to run MariaDB in a production environment. Keep reading to discover the differences between them and check which one better suits your needs. + +- The MariaDB Galera Helm chart configures a cluster with three nodes by default, all of them acting as master nodes with writing / reading permissions. The MariaDB Helm chart deploys one node that you can use as a single-node application database. +- The MariaDB Galera Helm chart provides a cluster with both read and write scalability since all nodes acts as master nodes (multi-master topology) while a cluster comprised of several MariaDB nodes will establish the master-slave topology. +- The MariaDB Galera Helm chart deploys a cluster with synchronous replication, avoiding data loss if any node fails. +- The MariaDB Galera Helm chart cluster ensures high-availability thanks to automatic membership control, failed nodes are drop from the cluster. + +The following diagram shows you the options you have for using Bitnami's MariaDB solutions in your deployments: either as a single-node database (MariaDB) or as a multi-master cluster (MariaDB Galera). + +![A diagram comparing a single node MariaDB solution versus a multi-master node distributed database with MariaDB Galera](img/mariadb-galera-topology.png) + ## Prerequisites - Kubernetes 1.23+ @@ -58,285 +71,6 @@ helm delete --purge my-release The command removes all the Kubernetes components associated with the chart and deletes the release. -## Differences between the the Bitnami MariaDB Galera and Bitnami MariaDB Helm charts - -There are two different ways to deploy a MariaDB cluster, using the MariaDB Helm chart or the MariaDB Galera Helm chart. Both solutions provide a simply and reliable way to run MariaDB in a production environment. Keep reading to discover the differences between them and check which one better suits your needs. - -- The MariaDB Galera Helm chart configures a cluster with three nodes by default, all of them acting as master nodes with writing / reading permissions. The MariaDB Helm chart deploys one node that you can use as a single-node application database. -- The MariaDB Galera Helm chart provides a cluster with both read and write scalability since all nodes acts as master nodes (multi-master topology) while a cluster comprised of several MariaDB nodes will establish the master-slave topology. -- The MariaDB Galera Helm chart deploys a cluster with synchronous replication, avoiding data loss if any node fails. -- The MariaDB Galera Helm chart cluster ensures high-availability thanks to automatic membership control, failed nodes are drop from the cluster. - -The following diagram shows you the options you have for using Bitnami's MariaDB solutions in your deployments: either as a single-node database (MariaDB) or as a multi-master cluster (MariaDB Galera). - -![A diagram comparing a single node MariaDB solution versus a multi-master node distributed database with MariaDB Galera](img/mariadb-galera-topology.png) - -## Parameters - -### Global parameters - -| Name | Description | Value | -| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | -| `global.imageRegistry` | Global Docker image registry | `""` | -| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` | -| `global.storageClass` | Global StorageClass for Persistent Volume(s) | `""` | -| `global.compatibility.openshift.adaptSecurityContext` | Adapt the securityContext sections of the deployment to make them compatible with Openshift restricted-v2 SCC: remove runAsUser, runAsGroup and fsGroup and let the platform use their allowed default IDs. Possible values: auto (apply if the detected running cluster is Openshift), force (perform the adaptation always), disabled (do not perform adaptation) | `disabled` | - -### Common parameters - -| Name | Description | Value | -| ------------------------ | --------------------------------------------------------------------------------------------------------- | --------------- | -| `kubeVersion` | Force target Kubernetes version (using Helm capabilities if not set) | `""` | -| `nameOverride` | String to partially override common.names.fullname template with a string (will prepend the release name) | `""` | -| `fullnameOverride` | String to fully override common.names.fullname template with a string | `""` | -| `namespaceOverride` | String to fully override common.names.namespace | `""` | -| `commonAnnotations` | Annotations to add to all deployed objects | `{}` | -| `commonLabels` | Labels to add to all deployed objects | `{}` | -| `schedulerName` | Name of the Kubernetes scheduler (other than default) | `""` | -| `clusterDomain` | Kubernetes DNS Domain name to use | `cluster.local` | -| `extraDeploy` | Array of extra objects to deploy with the release (evaluated as a template) | `[]` | -| `diagnosticMode.enabled` | Enable diagnostic mode (all probes will be disabled and the command will be overridden) | `false` | -| `diagnosticMode.command` | Command to override all containers in the deployment | `[]` | -| `diagnosticMode.args` | Args to override all containers in the deployment | `[]` | - -### MariaDB Galera parameters - -| Name | Description | Value | -| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | -| `image.registry` | MariaDB Galera image registry | `REGISTRY_NAME` | -| `image.repository` | MariaDB Galera image repository | `REPOSITORY_NAME/mariadb-galera` | -| `image.digest` | MariaDB Galera image digest in the way sha256:aa.... Please note this parameter, if set, will override the tag | `""` | -| `image.pullPolicy` | MariaDB Galera image pull policy | `IfNotPresent` | -| `image.pullSecrets` | Specify docker-registry secret names as an array | `[]` | -| `image.debug` | Specify if debug logs should be enabled | `false` | -| `podManagementPolicy` | StatefulSet controller supports relax its ordering guarantees while preserving its uniqueness and identity guarantees. There are two valid pod management policies: OrderedReady and Parallel | `OrderedReady` | -| `automountServiceAccountToken` | Mount Service Account token in pod | `false` | -| `hostAliases` | Add deployment host aliases | `[]` | -| `service.type` | Kubernetes service type | `ClusterIP` | -| `service.clusterIP` | Specific cluster IP when service type is cluster IP. Use `None` for headless service | `""` | -| `service.ports.mysql` | MariaDB service port | `3306` | -| `service.nodePorts.mysql` | Specify the nodePort value for the LoadBalancer and NodePort service types. | `""` | -| `service.extraPorts` | Extra ports to expose (normally used with the `sidecar` value) | `[]` | -| `service.externalIPs` | External IP list to use with ClusterIP service type | `[]` | -| `service.loadBalancerIP` | `loadBalancerIP` if service type is `LoadBalancer` | `""` | -| `service.loadBalancerSourceRanges` | Addresses that are allowed when svc is `LoadBalancer` | `[]` | -| `service.externalTrafficPolicy` | %%MAIN_CONTAINER_NAME%% service external traffic policy | `Cluster` | -| `service.annotations` | Additional annotations for MariaDB Galera service | `{}` | -| `service.sessionAffinity` | Session Affinity for Kubernetes service, can be "None" or "ClientIP" | `None` | -| `service.sessionAffinityConfig` | Additional settings for the sessionAffinity | `{}` | -| `service.headless.annotations` | Annotations for the headless service. | `{}` | -| `service.headless.publishNotReadyAddresses` | Publish not Ready MariaDB Galera pods' IPs in the headless service. | `true` | -| `networkPolicy.enabled` | Enable creation of NetworkPolicy resources | `true` | -| `networkPolicy.allowExternal` | The Policy model to apply | `true` | -| `networkPolicy.allowExternalEgress` | Allow the pod to access any range of port and all destinations. | `true` | -| `networkPolicy.extraIngress` | Add extra ingress rules to the NetworkPolicy | `[]` | -| `networkPolicy.extraEgress` | Add extra ingress rules to the NetworkPolicy | `[]` | -| `networkPolicy.ingressNSMatchLabels` | Labels to match to allow traffic from other namespaces | `{}` | -| `networkPolicy.ingressNSPodMatchLabels` | Pod labels to match to allow traffic from other namespaces | `{}` | -| `serviceAccount.create` | Specify whether a ServiceAccount should be created | `true` | -| `serviceAccount.name` | Name of the service account to use. If not set and create is true, a name is generated using the fullname template. | `""` | -| `serviceAccount.automountServiceAccountToken` | Automount service account token for the server service account | `false` | -| `serviceAccount.annotations` | Annotations for service account. Evaluated as a template. Only used if `create` is `true`. | `{}` | -| `command` | Override default container command (useful when using custom images) | `[]` | -| `args` | Override default container args (useful when using custom images) | `[]` | -| `extraEnvVars` | Array containing extra env vars to configure MariaDB Galera replicas | `[]` | -| `extraEnvVarsCM` | ConfigMap containing extra env vars to configure MariaDB Galera replicas | `""` | -| `extraEnvVarsSecret` | Secret containing extra env vars to configure MariaDB Galera replicas | `""` | -| `rbac.create` | Specify whether RBAC resources should be created and used | `false` | -| `podSecurityContext.enabled` | Enable security context | `true` | -| `podSecurityContext.fsGroupChangePolicy` | Set filesystem group change policy | `Always` | -| `podSecurityContext.sysctls` | Set kernel settings using the sysctl interface | `[]` | -| `podSecurityContext.supplementalGroups` | Set filesystem extra groups | `[]` | -| `podSecurityContext.fsGroup` | Group ID for the container filesystem | `1001` | -| `containerSecurityContext.enabled` | Enabled containers' Security Context | `true` | -| `containerSecurityContext.seLinuxOptions` | Set SELinux options in container | `nil` | -| `containerSecurityContext.runAsUser` | Set containers' Security Context runAsUser | `1001` | -| `containerSecurityContext.runAsGroup` | Set containers' Security Context runAsGroup | `0` | -| `containerSecurityContext.runAsNonRoot` | Set container's Security Context runAsNonRoot | `true` | -| `containerSecurityContext.privileged` | Set container's Security Context privileged | `false` | -| `containerSecurityContext.readOnlyRootFilesystem` | Set container's Security Context readOnlyRootFilesystem | `false` | -| `containerSecurityContext.allowPrivilegeEscalation` | Set container's Security Context allowPrivilegeEscalation | `false` | -| `containerSecurityContext.capabilities.drop` | List of capabilities to be dropped | `["ALL"]` | -| `containerSecurityContext.seccompProfile.type` | Set container's Security Context seccomp profile | `RuntimeDefault` | -| `rootUser.user` | Username for the admin user. | `root` | -| `rootUser.password` | Password for the admin user. Ignored if existing secret is provided. | `""` | -| `rootUser.forcePassword` | Option to force users to specify a password. That is required for 'helm upgrade' to work properly. | `false` | -| `existingSecret` | Use existing secret for password details (`rootUser.password`, `db.password`, `galera.mariabackup.password` will be ignored and picked up from this secret) | `""` | -| `usePasswordFiles` | Mount credentials as a files instead of using an environment variable. | `false` | -| `customPasswordFiles` | Use custom password files when `usePasswordFiles` is set to `true`. Define path for keys `root`, `user`, and `mariabackup`. | `{}` | -| `db.user` | Username of new user to create | `""` | -| `db.password` | Password for the new user. Ignored if existing secret is provided. | `""` | -| `db.name` | Name for new database to create | `my_database` | -| `db.forcePassword` | Option to force users to specify a password. That is required for 'helm upgrade' to work properly. | `false` | -| `galera.name` | Galera cluster name | `galera` | -| `galera.bootstrap.forceBootstrap` | Option to force the boostraping from the indicated node in `galera.bootstarp.bootstrapFromNode` | `false` | -| `galera.bootstrap.bootstrapFromNode` | Node to bootstrap from, you will need to change this parameter in case you want to bootstrap from other node | `0` | -| `galera.bootstrap.forceSafeToBootstrap` | Force `safe_to_bootstrap: 1` in `grastate.date` file | `false` | -| `galera.mariabackup.user` | MariaBackup username | `mariabackup` | -| `galera.mariabackup.password` | MariaBackup password. Password is ignored if existingSecret is specified. | `""` | -| `galera.mariabackup.forcePassword` | Option to force users to specify a password. That is required for 'helm upgrade' to work properly. | `false` | -| `ldap.enabled` | Enable LDAP support | `false` | -| `ldap.uri` | LDAP URL beginning in the form `ldap` | `""` | -| `ldap.base` | LDAP base DN | `""` | -| `ldap.binddn` | LDAP bind DN | `""` | -| `ldap.bindpw` | LDAP bind password | `""` | -| `ldap.bslookup` | LDAP base lookup | `""` | -| `ldap.filter` | LDAP custom filter | `""` | -| `ldap.map` | LDAP custom map | `""` | -| `ldap.nss_initgroups_ignoreusers` | LDAP ignored users | `root,nslcd` | -| `ldap.scope` | LDAP search scope | `""` | -| `ldap.tls_reqcert` | LDAP TLS check on server certificates | `""` | -| `tls.enabled` | Enable TLS support for replication traffic | `false` | -| `tls.autoGenerated` | Generate automatically self-signed TLS certificates | `false` | -| `tls.certificatesSecret` | Name of the secret that contains the certificates | `""` | -| `tls.certFilename` | Certificate filename | `""` | -| `tls.certKeyFilename` | Certificate key filename | `""` | -| `tls.certCAFilename` | CA Certificate filename | `""` | -| `mariadbConfiguration` | Configuration for the MariaDB server | `""` | -| `configurationConfigMap` | ConfigMap with the MariaDB configuration files (Note: Overrides `mariadbConfiguration`). The value is evaluated as a template. | `""` | -| `initdbScripts` | Specify dictionary of scripts to be run at first boot | `{}` | -| `initdbScriptsConfigMap` | ConfigMap with the initdb scripts (Note: Overrides `initdbScripts`) | `""` | -| `extraFlags` | MariaDB additional command line flags | `""` | -| `replicaCount` | Desired number of cluster nodes | `3` | -| `updateStrategy.type` | updateStrategy for MariaDB Master StatefulSet | `RollingUpdate` | -| `podLabels` | Extra labels for MariaDB Galera pods | `{}` | -| `podAnnotations` | Annotations for MariaDB Galera pods | `{}` | -| `podAffinityPreset` | Pod affinity preset. Ignored if `affinity` is set. Allowed values: `soft` or `hard` | `""` | -| `podAntiAffinityPreset` | Pod anti-affinity preset. Ignored if `affinity` is set. Allowed values: `soft` or `hard` | `soft` | -| `nodeAffinityPreset.type` | Node affinity preset type. Ignored if `affinity` is set. Allowed values: `soft` or `hard` | `""` | -| `nodeAffinityPreset.key` | Node label key to match. Ignored if `affinity` is set. | `""` | -| `nodeAffinityPreset.values` | Node label values to match. Ignored if `affinity` is set. | `[]` | -| `affinity` | Affinity for pod assignment | `{}` | -| `nodeSelector` | Node labels for pod assignment | `{}` | -| `tolerations` | Tolerations for pod assignment | `[]` | -| `topologySpreadConstraints` | Topology Spread Constraints for pods assignment | `[]` | -| `lifecycleHooks` | for the galera container(s) to automate configuration before or after startup | `{}` | -| `containerPorts.mysql` | mariadb database container port | `3306` | -| `containerPorts.galera` | galera cluster container port | `4567` | -| `containerPorts.ist` | galera IST container port | `4568` | -| `containerPorts.sst` | galera SST container port | `4444` | -| `persistence.enabled` | Enable persistence using PVC | `true` | -| `persistence.existingClaim` | Provide an existing `PersistentVolumeClaim` | `""` | -| `persistence.subPath` | Subdirectory of the volume to mount | `""` | -| `persistence.mountPath` | Path to mount the volume at | `/bitnami/mariadb` | -| `persistence.selector` | Selector to match an existing Persistent Volume (this value is evaluated as a template) | `{}` | -| `persistence.storageClass` | Persistent Volume Storage Class | `""` | -| `persistence.annotations` | Persistent Volume Claim annotations | `{}` | -| `persistence.labels` | Persistent Volume Claim Labels | `{}` | -| `persistence.accessModes` | Persistent Volume Access Modes | `["ReadWriteOnce"]` | -| `persistence.size` | Persistent Volume Size | `8Gi` | -| `priorityClassName` | Priority Class Name for Statefulset | `""` | -| `initContainers` | Additional init containers (this value is evaluated as a template) | `[]` | -| `sidecars` | Add additional sidecar containers (this value is evaluated as a template) | `[]` | -| `extraVolumes` | Extra volumes | `[]` | -| `extraVolumeMounts` | Mount extra volume(s) | `[]` | -| `resourcesPreset` | Set container resources according to one common preset (allowed values: none, nano, small, medium, large, xlarge, 2xlarge). This is ignored if resources is set (resources is recommended for production). | `none` | -| `resources` | Set container requests and limits for different resources like CPU or memory (essential for production workloads) | `{}` | -| `livenessProbe.enabled` | Turn on and off liveness probe | `true` | -| `livenessProbe.initialDelaySeconds` | Delay before liveness probe is initiated | `120` | -| `livenessProbe.periodSeconds` | How often to perform the probe | `10` | -| `livenessProbe.timeoutSeconds` | When the probe times out | `1` | -| `livenessProbe.failureThreshold` | Minimum consecutive failures for the probe | `3` | -| `livenessProbe.successThreshold` | Minimum consecutive successes for the probe | `1` | -| `readinessProbe.enabled` | Turn on and off readiness probe | `true` | -| `readinessProbe.initialDelaySeconds` | Delay before readiness probe is initiated | `30` | -| `readinessProbe.periodSeconds` | How often to perform the probe | `10` | -| `readinessProbe.timeoutSeconds` | When the probe times out | `1` | -| `readinessProbe.failureThreshold` | Minimum consecutive failures for the probe | `3` | -| `readinessProbe.successThreshold` | Minimum consecutive successes for the probe | `1` | -| `startupProbe.enabled` | Turn on and off startup probe | `false` | -| `startupProbe.initialDelaySeconds` | Delay before startup probe is initiated | `120` | -| `startupProbe.periodSeconds` | How often to perform the probe | `10` | -| `startupProbe.timeoutSeconds` | When the probe times out | `1` | -| `startupProbe.failureThreshold` | Minimum consecutive failures for the probe | `48` | -| `startupProbe.successThreshold` | Minimum consecutive successes for the probe | `1` | -| `customStartupProbe` | Custom liveness probe for the Web component | `{}` | -| `customLivenessProbe` | Custom liveness probe for the Web component | `{}` | -| `customReadinessProbe` | Custom rediness probe for the Web component | `{}` | -| `podDisruptionBudget.create` | Specifies whether a Pod disruption budget should be created | `false` | -| `podDisruptionBudget.minAvailable` | Minimum number / percentage of pods that should remain scheduled | `1` | -| `podDisruptionBudget.maxUnavailable` | Maximum number / percentage of pods that may be made unavailable | `""` | -| `metrics.enabled` | Start a side-car prometheus exporter | `false` | -| `metrics.image.registry` | MariaDB Prometheus exporter image registry | `REGISTRY_NAME` | -| `metrics.image.repository` | MariaDB Prometheus exporter image repository | `REPOSITORY_NAME/mysqld-exporter` | -| `metrics.image.digest` | MariaDB Prometheus exporter image digest in the way sha256:aa.... Please note this parameter, if set, will override the tag | `""` | -| `metrics.image.pullPolicy` | MariaDB Prometheus exporter image pull policy | `IfNotPresent` | -| `metrics.image.pullSecrets` | MariaDB Prometheus exporter image pull secrets | `[]` | -| `metrics.extraFlags` | MariaDB Prometheus exporter additional command line flags | `[]` | -| `metrics.resourcesPreset` | Set container resources according to one common preset (allowed values: none, nano, small, medium, large, xlarge, 2xlarge). This is ignored if metrics.resources is set (metrics.resources is recommended for production). | `none` | -| `metrics.resources` | Set container requests and limits for different resources like CPU or memory (essential for production workloads) | `{}` | -| `metrics.containerSecurityContext.enabled` | Enabled containers' Security Context | `true` | -| `metrics.containerSecurityContext.seLinuxOptions` | Set SELinux options in container | `nil` | -| `metrics.containerSecurityContext.runAsUser` | Set containers' Security Context runAsUser | `1001` | -| `metrics.containerSecurityContext.runAsGroup` | Set containers' Security Context runAsGroup | `0` | -| `metrics.containerSecurityContext.runAsNonRoot` | Set container's Security Context runAsNonRoot | `true` | -| `metrics.containerSecurityContext.privileged` | Set container's Security Context privileged | `false` | -| `metrics.containerSecurityContext.readOnlyRootFilesystem` | Set container's Security Context readOnlyRootFilesystem | `false` | -| `metrics.containerSecurityContext.allowPrivilegeEscalation` | Set container's Security Context allowPrivilegeEscalation | `false` | -| `metrics.containerSecurityContext.capabilities.drop` | List of capabilities to be dropped | `["ALL"]` | -| `metrics.containerSecurityContext.seccompProfile.type` | Set container's Security Context seccomp profile | `RuntimeDefault` | -| `metrics.containerPorts.http` | Container port for http | `9104` | -| `metrics.service.type` | Prometheus exporter service type | `ClusterIP` | -| `metrics.service.port` | Prometheus exporter service port | `9104` | -| `metrics.service.annotations` | Prometheus exporter service annotations | `{}` | -| `metrics.service.loadBalancerIP` | Load Balancer IP if the Prometheus metrics server type is `LoadBalancer` | `""` | -| `metrics.service.clusterIP` | Prometheus metrics service Cluster IP | `""` | -| `metrics.service.loadBalancerSourceRanges` | Prometheus metrics service Load Balancer sources | `[]` | -| `metrics.service.externalTrafficPolicy` | Prometheus metrics service external traffic policy | `Cluster` | -| `metrics.serviceMonitor.enabled` | if `true`, creates a Prometheus Operator ServiceMonitor (also requires `metrics.enabled` to be `true`) | `false` | -| `metrics.serviceMonitor.namespace` | Optional namespace which Prometheus is running in | `""` | -| `metrics.serviceMonitor.jobLabel` | The name of the label on the target service to use as the job name in prometheus. | `""` | -| `metrics.serviceMonitor.interval` | How frequently to scrape metrics (use by default, falling back to Prometheus' default) | `""` | -| `metrics.serviceMonitor.scrapeTimeout` | Timeout after which the scrape is ended | `""` | -| `metrics.serviceMonitor.selector` | ServiceMonitor selector labels | `{}` | -| `metrics.serviceMonitor.relabelings` | RelabelConfigs to apply to samples before scraping | `[]` | -| `metrics.serviceMonitor.metricRelabelings` | MetricRelabelConfigs to apply to samples before ingestion | `[]` | -| `metrics.serviceMonitor.honorLabels` | honorLabels chooses the metric's labels on collisions with target labels | `false` | -| `metrics.serviceMonitor.labels` | ServiceMonitor extra labels | `{}` | -| `metrics.prometheusRules.enabled` | if `true`, creates a Prometheus Operator PrometheusRule (also requires `metrics.enabled` to be `true`, and makes little sense without ServiceMonitor) | `false` | -| `metrics.prometheusRules.additionalLabels` | Additional labels to add to the PrometheusRule so it is picked up by the operator | `{}` | -| `metrics.prometheusRules.rules` | PrometheusRule rules to configure | `{}` | - -The above parameters map to the env variables defined in [bitnami/mariadb-galera](https://github.com/bitnami/containers/tree/main/bitnami/mariadb-galera). For more information please refer to the [bitnami/mariadb-galera](https://github.com/bitnami/containers/tree/main/bitnami/mariadb-galera) image documentation. - -Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example, - -```console -helm install my-release \ - --set rootUser.password=secretpassword, - --set db.user=app_database \ - oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera -``` - -> 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`. - -The above command sets the MariaDB `root` account password to `secretpassword`. Additionally it creates a database named `my_database`. - -> NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available. - -Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example, - -```console -helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera -``` - -> 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/mariadb-galera/values.yaml) - -## Passing extra command-line flags to mysqld startup - -While the chart allows you to specify the server configuration using the `.mariadbConfiguration` chart parameter, some options for the MariaDB server can only be specified via command line flags. For such cases, the chart exposes the `.extraFlags` parameter. - -For example, if you want to enable the PAM cleartext plugin, specify the command line parameter while deploying the chart like so: - -```console -helm install my-release \ - --set extraFlags="--pam-use-cleartext-plugin=ON" \ - oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera -``` - -> 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`. - ## Configuration and installation details ### Resource requests and limits @@ -603,12 +337,6 @@ helm upgrade my-release oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera \ > 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`. -### Persistence - -The [Bitnami MariaDB Galera](https://github.com/bitnami/containers/tree/main/bitnami/mariadb-galera) image stores the MariaDB data and configurations at the `/bitnami/mariadb` path of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can be defined. - ### Backup and restore MariaDB Galera deployments Two different approaches are available to back up and restore Bitnami MariaDB Galera Helm chart deployments on Kubernetes: @@ -650,6 +378,278 @@ This chart allows you to set your custom affinity using the `affinity` parameter 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 MariaDB Galera](https://github.com/bitnami/containers/tree/main/bitnami/mariadb-galera) image stores the MariaDB data and configurations at the `/bitnami/mariadb` path of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can be defined. + +## Parameters + +### Global parameters + +| Name | Description | Value | +| ----------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------- | +| `global.imageRegistry` | Global Docker image registry | `""` | +| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` | +| `global.storageClass` | Global StorageClass for Persistent Volume(s) | `""` | +| `global.compatibility.openshift.adaptSecurityContext` | Adapt the securityContext sections of the deployment to make them compatible with Openshift restricted-v2 SCC: remove runAsUser, runAsGroup and fsGroup and let the platform use their allowed default IDs. Possible values: auto (apply if the detected running cluster is Openshift), force (perform the adaptation always), disabled (do not perform adaptation) | `disabled` | + +### Common parameters + +| Name | Description | Value | +| ------------------------ | --------------------------------------------------------------------------------------------------------- | --------------- | +| `kubeVersion` | Force target Kubernetes version (using Helm capabilities if not set) | `""` | +| `nameOverride` | String to partially override common.names.fullname template with a string (will prepend the release name) | `""` | +| `fullnameOverride` | String to fully override common.names.fullname template with a string | `""` | +| `namespaceOverride` | String to fully override common.names.namespace | `""` | +| `commonAnnotations` | Annotations to add to all deployed objects | `{}` | +| `commonLabels` | Labels to add to all deployed objects | `{}` | +| `schedulerName` | Name of the Kubernetes scheduler (other than default) | `""` | +| `clusterDomain` | Kubernetes DNS Domain name to use | `cluster.local` | +| `extraDeploy` | Array of extra objects to deploy with the release (evaluated as a template) | `[]` | +| `diagnosticMode.enabled` | Enable diagnostic mode (all probes will be disabled and the command will be overridden) | `false` | +| `diagnosticMode.command` | Command to override all containers in the deployment | `[]` | +| `diagnosticMode.args` | Args to override all containers in the deployment | `[]` | + +### MariaDB Galera parameters + +| Name | Description | Value | +| ----------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------- | +| `image.registry` | MariaDB Galera image registry | `REGISTRY_NAME` | +| `image.repository` | MariaDB Galera image repository | `REPOSITORY_NAME/mariadb-galera` | +| `image.digest` | MariaDB Galera image digest in the way sha256:aa.... Please note this parameter, if set, will override the tag | `""` | +| `image.pullPolicy` | MariaDB Galera image pull policy | `IfNotPresent` | +| `image.pullSecrets` | Specify docker-registry secret names as an array | `[]` | +| `image.debug` | Specify if debug logs should be enabled | `false` | +| `podManagementPolicy` | StatefulSet controller supports relax its ordering guarantees while preserving its uniqueness and identity guarantees. There are two valid pod management policies: OrderedReady and Parallel | `OrderedReady` | +| `automountServiceAccountToken` | Mount Service Account token in pod | `false` | +| `hostAliases` | Add deployment host aliases | `[]` | +| `service.type` | Kubernetes service type | `ClusterIP` | +| `service.clusterIP` | Specific cluster IP when service type is cluster IP. Use `None` for headless service | `""` | +| `service.ports.mysql` | MariaDB service port | `3306` | +| `service.nodePorts.mysql` | Specify the nodePort value for the LoadBalancer and NodePort service types. | `""` | +| `service.extraPorts` | Extra ports to expose (normally used with the `sidecar` value) | `[]` | +| `service.externalIPs` | External IP list to use with ClusterIP service type | `[]` | +| `service.loadBalancerIP` | `loadBalancerIP` if service type is `LoadBalancer` | `""` | +| `service.loadBalancerSourceRanges` | Addresses that are allowed when svc is `LoadBalancer` | `[]` | +| `service.externalTrafficPolicy` | %%MAIN_CONTAINER_NAME%% service external traffic policy | `Cluster` | +| `service.annotations` | Additional annotations for MariaDB Galera service | `{}` | +| `service.sessionAffinity` | Session Affinity for Kubernetes service, can be "None" or "ClientIP" | `None` | +| `service.sessionAffinityConfig` | Additional settings for the sessionAffinity | `{}` | +| `service.headless.annotations` | Annotations for the headless service. | `{}` | +| `service.headless.publishNotReadyAddresses` | Publish not Ready MariaDB Galera pods' IPs in the headless service. | `true` | +| `networkPolicy.enabled` | Enable creation of NetworkPolicy resources | `true` | +| `networkPolicy.allowExternal` | The Policy model to apply | `true` | +| `networkPolicy.allowExternalEgress` | Allow the pod to access any range of port and all destinations. | `true` | +| `networkPolicy.extraIngress` | Add extra ingress rules to the NetworkPolicy | `[]` | +| `networkPolicy.extraEgress` | Add extra ingress rules to the NetworkPolicy | `[]` | +| `networkPolicy.ingressNSMatchLabels` | Labels to match to allow traffic from other namespaces | `{}` | +| `networkPolicy.ingressNSPodMatchLabels` | Pod labels to match to allow traffic from other namespaces | `{}` | +| `serviceAccount.create` | Specify whether a ServiceAccount should be created | `true` | +| `serviceAccount.name` | Name of the service account to use. If not set and create is true, a name is generated using the fullname template. | `""` | +| `serviceAccount.automountServiceAccountToken` | Automount service account token for the server service account | `false` | +| `serviceAccount.annotations` | Annotations for service account. Evaluated as a template. Only used if `create` is `true`. | `{}` | +| `command` | Override default container command (useful when using custom images) | `[]` | +| `args` | Override default container args (useful when using custom images) | `[]` | +| `extraEnvVars` | Array containing extra env vars to configure MariaDB Galera replicas | `[]` | +| `extraEnvVarsCM` | ConfigMap containing extra env vars to configure MariaDB Galera replicas | `""` | +| `extraEnvVarsSecret` | Secret containing extra env vars to configure MariaDB Galera replicas | `""` | +| `rbac.create` | Specify whether RBAC resources should be created and used | `false` | +| `podSecurityContext.enabled` | Enable security context | `true` | +| `podSecurityContext.fsGroupChangePolicy` | Set filesystem group change policy | `Always` | +| `podSecurityContext.sysctls` | Set kernel settings using the sysctl interface | `[]` | +| `podSecurityContext.supplementalGroups` | Set filesystem extra groups | `[]` | +| `podSecurityContext.fsGroup` | Group ID for the container filesystem | `1001` | +| `containerSecurityContext.enabled` | Enabled containers' Security Context | `true` | +| `containerSecurityContext.seLinuxOptions` | Set SELinux options in container | `nil` | +| `containerSecurityContext.runAsUser` | Set containers' Security Context runAsUser | `1001` | +| `containerSecurityContext.runAsGroup` | Set containers' Security Context runAsGroup | `0` | +| `containerSecurityContext.runAsNonRoot` | Set container's Security Context runAsNonRoot | `true` | +| `containerSecurityContext.privileged` | Set container's Security Context privileged | `false` | +| `containerSecurityContext.readOnlyRootFilesystem` | Set container's Security Context readOnlyRootFilesystem | `false` | +| `containerSecurityContext.allowPrivilegeEscalation` | Set container's Security Context allowPrivilegeEscalation | `false` | +| `containerSecurityContext.capabilities.drop` | List of capabilities to be dropped | `["ALL"]` | +| `containerSecurityContext.seccompProfile.type` | Set container's Security Context seccomp profile | `RuntimeDefault` | +| `rootUser.user` | Username for the admin user. | `root` | +| `rootUser.password` | Password for the admin user. Ignored if existing secret is provided. | `""` | +| `rootUser.forcePassword` | Option to force users to specify a password. That is required for 'helm upgrade' to work properly. | `false` | +| `existingSecret` | Use existing secret for password details (`rootUser.password`, `db.password`, `galera.mariabackup.password` will be ignored and picked up from this secret) | `""` | +| `usePasswordFiles` | Mount credentials as a files instead of using an environment variable. | `false` | +| `customPasswordFiles` | Use custom password files when `usePasswordFiles` is set to `true`. Define path for keys `root`, `user`, and `mariabackup`. | `{}` | +| `db.user` | Username of new user to create | `""` | +| `db.password` | Password for the new user. Ignored if existing secret is provided. | `""` | +| `db.name` | Name for new database to create | `my_database` | +| `db.forcePassword` | Option to force users to specify a password. That is required for 'helm upgrade' to work properly. | `false` | +| `galera.name` | Galera cluster name | `galera` | +| `galera.bootstrap.forceBootstrap` | Option to force the boostraping from the indicated node in `galera.bootstarp.bootstrapFromNode` | `false` | +| `galera.bootstrap.bootstrapFromNode` | Node to bootstrap from, you will need to change this parameter in case you want to bootstrap from other node | `0` | +| `galera.bootstrap.forceSafeToBootstrap` | Force `safe_to_bootstrap: 1` in `grastate.date` file | `false` | +| `galera.mariabackup.user` | MariaBackup username | `mariabackup` | +| `galera.mariabackup.password` | MariaBackup password. Password is ignored if existingSecret is specified. | `""` | +| `galera.mariabackup.forcePassword` | Option to force users to specify a password. That is required for 'helm upgrade' to work properly. | `false` | +| `ldap.enabled` | Enable LDAP support | `false` | +| `ldap.uri` | LDAP URL beginning in the form `ldap` | `""` | +| `ldap.base` | LDAP base DN | `""` | +| `ldap.binddn` | LDAP bind DN | `""` | +| `ldap.bindpw` | LDAP bind password | `""` | +| `ldap.bslookup` | LDAP base lookup | `""` | +| `ldap.filter` | LDAP custom filter | `""` | +| `ldap.map` | LDAP custom map | `""` | +| `ldap.nss_initgroups_ignoreusers` | LDAP ignored users | `root,nslcd` | +| `ldap.scope` | LDAP search scope | `""` | +| `ldap.tls_reqcert` | LDAP TLS check on server certificates | `""` | +| `tls.enabled` | Enable TLS support for replication traffic | `false` | +| `tls.autoGenerated` | Generate automatically self-signed TLS certificates | `false` | +| `tls.certificatesSecret` | Name of the secret that contains the certificates | `""` | +| `tls.certFilename` | Certificate filename | `""` | +| `tls.certKeyFilename` | Certificate key filename | `""` | +| `tls.certCAFilename` | CA Certificate filename | `""` | +| `mariadbConfiguration` | Configuration for the MariaDB server | `""` | +| `configurationConfigMap` | ConfigMap with the MariaDB configuration files (Note: Overrides `mariadbConfiguration`). The value is evaluated as a template. | `""` | +| `initdbScripts` | Specify dictionary of scripts to be run at first boot | `{}` | +| `initdbScriptsConfigMap` | ConfigMap with the initdb scripts (Note: Overrides `initdbScripts`) | `""` | +| `extraFlags` | MariaDB additional command line flags | `""` | +| `replicaCount` | Desired number of cluster nodes | `3` | +| `updateStrategy.type` | updateStrategy for MariaDB Master StatefulSet | `RollingUpdate` | +| `podLabels` | Extra labels for MariaDB Galera pods | `{}` | +| `podAnnotations` | Annotations for MariaDB Galera pods | `{}` | +| `podAffinityPreset` | Pod affinity preset. Ignored if `affinity` is set. Allowed values: `soft` or `hard` | `""` | +| `podAntiAffinityPreset` | Pod anti-affinity preset. Ignored if `affinity` is set. Allowed values: `soft` or `hard` | `soft` | +| `nodeAffinityPreset.type` | Node affinity preset type. Ignored if `affinity` is set. Allowed values: `soft` or `hard` | `""` | +| `nodeAffinityPreset.key` | Node label key to match. Ignored if `affinity` is set. | `""` | +| `nodeAffinityPreset.values` | Node label values to match. Ignored if `affinity` is set. | `[]` | +| `affinity` | Affinity for pod assignment | `{}` | +| `nodeSelector` | Node labels for pod assignment | `{}` | +| `tolerations` | Tolerations for pod assignment | `[]` | +| `topologySpreadConstraints` | Topology Spread Constraints for pods assignment | `[]` | +| `lifecycleHooks` | for the galera container(s) to automate configuration before or after startup | `{}` | +| `containerPorts.mysql` | mariadb database container port | `3306` | +| `containerPorts.galera` | galera cluster container port | `4567` | +| `containerPorts.ist` | galera IST container port | `4568` | +| `containerPorts.sst` | galera SST container port | `4444` | +| `persistence.enabled` | Enable persistence using PVC | `true` | +| `persistence.existingClaim` | Provide an existing `PersistentVolumeClaim` | `""` | +| `persistence.subPath` | Subdirectory of the volume to mount | `""` | +| `persistence.mountPath` | Path to mount the volume at | `/bitnami/mariadb` | +| `persistence.selector` | Selector to match an existing Persistent Volume (this value is evaluated as a template) | `{}` | +| `persistence.storageClass` | Persistent Volume Storage Class | `""` | +| `persistence.annotations` | Persistent Volume Claim annotations | `{}` | +| `persistence.labels` | Persistent Volume Claim Labels | `{}` | +| `persistence.accessModes` | Persistent Volume Access Modes | `["ReadWriteOnce"]` | +| `persistence.size` | Persistent Volume Size | `8Gi` | +| `priorityClassName` | Priority Class Name for Statefulset | `""` | +| `initContainers` | Additional init containers (this value is evaluated as a template) | `[]` | +| `sidecars` | Add additional sidecar containers (this value is evaluated as a template) | `[]` | +| `extraVolumes` | Extra volumes | `[]` | +| `extraVolumeMounts` | Mount extra volume(s) | `[]` | +| `resourcesPreset` | Set container resources according to one common preset (allowed values: none, nano, small, medium, large, xlarge, 2xlarge). This is ignored if resources is set (resources is recommended for production). | `none` | +| `resources` | Set container requests and limits for different resources like CPU or memory (essential for production workloads) | `{}` | +| `livenessProbe.enabled` | Turn on and off liveness probe | `true` | +| `livenessProbe.initialDelaySeconds` | Delay before liveness probe is initiated | `120` | +| `livenessProbe.periodSeconds` | How often to perform the probe | `10` | +| `livenessProbe.timeoutSeconds` | When the probe times out | `1` | +| `livenessProbe.failureThreshold` | Minimum consecutive failures for the probe | `3` | +| `livenessProbe.successThreshold` | Minimum consecutive successes for the probe | `1` | +| `readinessProbe.enabled` | Turn on and off readiness probe | `true` | +| `readinessProbe.initialDelaySeconds` | Delay before readiness probe is initiated | `30` | +| `readinessProbe.periodSeconds` | How often to perform the probe | `10` | +| `readinessProbe.timeoutSeconds` | When the probe times out | `1` | +| `readinessProbe.failureThreshold` | Minimum consecutive failures for the probe | `3` | +| `readinessProbe.successThreshold` | Minimum consecutive successes for the probe | `1` | +| `startupProbe.enabled` | Turn on and off startup probe | `false` | +| `startupProbe.initialDelaySeconds` | Delay before startup probe is initiated | `120` | +| `startupProbe.periodSeconds` | How often to perform the probe | `10` | +| `startupProbe.timeoutSeconds` | When the probe times out | `1` | +| `startupProbe.failureThreshold` | Minimum consecutive failures for the probe | `48` | +| `startupProbe.successThreshold` | Minimum consecutive successes for the probe | `1` | +| `customStartupProbe` | Custom liveness probe for the Web component | `{}` | +| `customLivenessProbe` | Custom liveness probe for the Web component | `{}` | +| `customReadinessProbe` | Custom rediness probe for the Web component | `{}` | +| `podDisruptionBudget.create` | Specifies whether a Pod disruption budget should be created | `false` | +| `podDisruptionBudget.minAvailable` | Minimum number / percentage of pods that should remain scheduled | `1` | +| `podDisruptionBudget.maxUnavailable` | Maximum number / percentage of pods that may be made unavailable | `""` | +| `metrics.enabled` | Start a side-car prometheus exporter | `false` | +| `metrics.image.registry` | MariaDB Prometheus exporter image registry | `REGISTRY_NAME` | +| `metrics.image.repository` | MariaDB Prometheus exporter image repository | `REPOSITORY_NAME/mysqld-exporter` | +| `metrics.image.digest` | MariaDB Prometheus exporter image digest in the way sha256:aa.... Please note this parameter, if set, will override the tag | `""` | +| `metrics.image.pullPolicy` | MariaDB Prometheus exporter image pull policy | `IfNotPresent` | +| `metrics.image.pullSecrets` | MariaDB Prometheus exporter image pull secrets | `[]` | +| `metrics.extraFlags` | MariaDB Prometheus exporter additional command line flags | `[]` | +| `metrics.resourcesPreset` | Set container resources according to one common preset (allowed values: none, nano, small, medium, large, xlarge, 2xlarge). This is ignored if metrics.resources is set (metrics.resources is recommended for production). | `none` | +| `metrics.resources` | Set container requests and limits for different resources like CPU or memory (essential for production workloads) | `{}` | +| `metrics.containerSecurityContext.enabled` | Enabled containers' Security Context | `true` | +| `metrics.containerSecurityContext.seLinuxOptions` | Set SELinux options in container | `nil` | +| `metrics.containerSecurityContext.runAsUser` | Set containers' Security Context runAsUser | `1001` | +| `metrics.containerSecurityContext.runAsGroup` | Set containers' Security Context runAsGroup | `0` | +| `metrics.containerSecurityContext.runAsNonRoot` | Set container's Security Context runAsNonRoot | `true` | +| `metrics.containerSecurityContext.privileged` | Set container's Security Context privileged | `false` | +| `metrics.containerSecurityContext.readOnlyRootFilesystem` | Set container's Security Context readOnlyRootFilesystem | `false` | +| `metrics.containerSecurityContext.allowPrivilegeEscalation` | Set container's Security Context allowPrivilegeEscalation | `false` | +| `metrics.containerSecurityContext.capabilities.drop` | List of capabilities to be dropped | `["ALL"]` | +| `metrics.containerSecurityContext.seccompProfile.type` | Set container's Security Context seccomp profile | `RuntimeDefault` | +| `metrics.containerPorts.http` | Container port for http | `9104` | +| `metrics.service.type` | Prometheus exporter service type | `ClusterIP` | +| `metrics.service.port` | Prometheus exporter service port | `9104` | +| `metrics.service.annotations` | Prometheus exporter service annotations | `{}` | +| `metrics.service.loadBalancerIP` | Load Balancer IP if the Prometheus metrics server type is `LoadBalancer` | `""` | +| `metrics.service.clusterIP` | Prometheus metrics service Cluster IP | `""` | +| `metrics.service.loadBalancerSourceRanges` | Prometheus metrics service Load Balancer sources | `[]` | +| `metrics.service.externalTrafficPolicy` | Prometheus metrics service external traffic policy | `Cluster` | +| `metrics.serviceMonitor.enabled` | if `true`, creates a Prometheus Operator ServiceMonitor (also requires `metrics.enabled` to be `true`) | `false` | +| `metrics.serviceMonitor.namespace` | Optional namespace which Prometheus is running in | `""` | +| `metrics.serviceMonitor.jobLabel` | The name of the label on the target service to use as the job name in prometheus. | `""` | +| `metrics.serviceMonitor.interval` | How frequently to scrape metrics (use by default, falling back to Prometheus' default) | `""` | +| `metrics.serviceMonitor.scrapeTimeout` | Timeout after which the scrape is ended | `""` | +| `metrics.serviceMonitor.selector` | ServiceMonitor selector labels | `{}` | +| `metrics.serviceMonitor.relabelings` | RelabelConfigs to apply to samples before scraping | `[]` | +| `metrics.serviceMonitor.metricRelabelings` | MetricRelabelConfigs to apply to samples before ingestion | `[]` | +| `metrics.serviceMonitor.honorLabels` | honorLabels chooses the metric's labels on collisions with target labels | `false` | +| `metrics.serviceMonitor.labels` | ServiceMonitor extra labels | `{}` | +| `metrics.prometheusRules.enabled` | if `true`, creates a Prometheus Operator PrometheusRule (also requires `metrics.enabled` to be `true`, and makes little sense without ServiceMonitor) | `false` | +| `metrics.prometheusRules.additionalLabels` | Additional labels to add to the PrometheusRule so it is picked up by the operator | `{}` | +| `metrics.prometheusRules.rules` | PrometheusRule rules to configure | `{}` | + +The above parameters map to the env variables defined in [bitnami/mariadb-galera](https://github.com/bitnami/containers/tree/main/bitnami/mariadb-galera). For more information please refer to the [bitnami/mariadb-galera](https://github.com/bitnami/containers/tree/main/bitnami/mariadb-galera) image documentation. + +Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example, + +```console +helm install my-release \ + --set rootUser.password=secretpassword, + --set db.user=app_database \ + oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera +``` + +> 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`. + +The above command sets the MariaDB `root` account password to `secretpassword`. Additionally it creates a database named `my_database`. + +> NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available. + +Alternatively, a YAML file that specifies the values for the parameters can be provided while installing the chart. For example, + +```console +helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera +``` + +> 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/mariadb-galera/values.yaml) + +## Passing extra command-line flags to mysqld startup + +While the chart allows you to specify the server configuration using the `.mariadbConfiguration` chart parameter, some options for the MariaDB server can only be specified via command line flags. For such cases, the chart exposes the `.extraFlags` parameter. + +For example, if you want to enable the PAM cleartext plugin, specify the command line parameter while deploying the chart like so: + +```console +helm install my-release \ + --set extraFlags="--pam-use-cleartext-plugin=ON" \ + oci://REGISTRY_NAME/REPOSITORY_NAME/mariadb-galera +``` + +> 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`. + ## 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). diff --git a/bitnami/mariadb/README.md b/bitnami/mariadb/README.md index e8f307c604..f3444d43f0 100644 --- a/bitnami/mariadb/README.md +++ b/bitnami/mariadb/README.md @@ -44,15 +44,101 @@ The command deploys MariaDB on the Kubernetes cluster in the default configurati > **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 -```console -helm delete my-release +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. + +### Change MariaDB version + +To modify the MariaDB version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/mariadb/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. + +### Initialize a fresh instance + +The [Bitnami MariaDB](https://github.com/bitnami/containers/tree/main/bitnami/mariadb) image allows you to use your custom scripts to initialize a fresh instance. Custom scripts may be specified using the `initdbScripts` parameter. Alternatively, an external ConfigMap may be created with all the initialization scripts and the ConfigMap passed to the chart via the `initdbScriptsConfigMap` parameter. Note that this will override the `initdbScripts` parameter. + +The allowed extensions are `.sh`, `.sql` and `.sql.gz`. + +These scripts are treated differently depending on their extension. While `.sh` scripts are executed on all the nodes, `.sql` and `.sql.gz` scripts are only executed on the primary nodes. This is because `.sh` scripts support conditional tests to identify the type of node they are running on, while such tests are not supported in `.sql` or `.sql.gz` files. + +When using a `.sh` script, you may wish to perform a "one-time" action like creating a database. This can be achieved by adding a condition in the script to ensure that it is executed only on one node, as shown in the example below: + +```yaml +initdbScripts: + my_init_script.sh: | + #!/bin/sh + if [[ $(hostname) == *primary* ]]; then + echo "Primary node" + mysql -P 3306 -uroot -prandompassword -e "create database new_database"; + else + echo "No primary node" + fi ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Sidecars and Init Containers + +If additional containers are needed in the same pod as MariaDB (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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/). + +## Persistence + +The [Bitnami MariaDB](https://github.com/bitnami/containers/tree/main/bitnami/mariadb) image stores the MariaDB data and configurations at the `/bitnami/mariadb` path of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can also be defined. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. + +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -426,102 +512,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/maria > 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/mariadb/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. - -### Change MariaDB version - -To modify the MariaDB version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/mariadb/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. - -### Initialize a fresh instance - -The [Bitnami MariaDB](https://github.com/bitnami/containers/tree/main/bitnami/mariadb) image allows you to use your custom scripts to initialize a fresh instance. Custom scripts may be specified using the `initdbScripts` parameter. Alternatively, an external ConfigMap may be created with all the initialization scripts and the ConfigMap passed to the chart via the `initdbScriptsConfigMap` parameter. Note that this will override the `initdbScripts` parameter. - -The allowed extensions are `.sh`, `.sql` and `.sql.gz`. - -These scripts are treated differently depending on their extension. While `.sh` scripts are executed on all the nodes, `.sql` and `.sql.gz` scripts are only executed on the primary nodes. This is because `.sh` scripts support conditional tests to identify the type of node they are running on, while such tests are not supported in `.sql` or `.sql.gz` files. - -When using a `.sh` script, you may wish to perform a "one-time" action like creating a database. This can be achieved by adding a condition in the script to ensure that it is executed only on one node, as shown in the example below: - -```yaml -initdbScripts: - my_init_script.sh: | - #!/bin/sh - if [[ $(hostname) == *primary* ]]; then - echo "Primary node" - mysql -P 3306 -uroot -prandompassword -e "create database new_database"; - else - echo "No primary node" - fi -``` - -### Sidecars and Init Containers - -If additional containers are needed in the same pod as MariaDB (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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/). - -## Persistence - -The [Bitnami MariaDB](https://github.com/bitnami/containers/tree/main/bitnami/mariadb) image stores the MariaDB data and configurations at the `/bitnami/mariadb` path of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can also be defined. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. - -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/mastodon/README.md b/bitnami/mastodon/README.md index c4135dae12..291f107fb9 100644 --- a/bitnami/mastodon/README.md +++ b/bitnami/mastodon/README.md @@ -44,15 +44,180 @@ The command deploys Mastodon on the Kubernetes cluster in the default configurat > **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. + +### External database support + +You may want to have Mastodon connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the MongoDB installation with the `postgresql.enabled` option. Here is an example: ```console -helm delete my-release +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=5432 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### External redis support + +You may want to have mastodon connect to an external redis rather than installing one inside your cluster. Typical reasons for this are to use a managed redis service, or to share a common redis server for all your applications. To achieve this, the chart allows you to specify credentials for an external redis with the [`externalRedis` parameter](#parameters). You should also disable the Redis installation with the `redis.enabled` option. Here is an example: + +```console +redis.enabled=false +externalRedis.host=myexternalhost +externalRedis.password=mypassword +externalRedis.port=6379 +``` + +### External elasticsearch support + +You may want to have mastodon connect to an external elasticsearch rather than installing one inside your cluster. Typical reasons for this are to use a managed elasticsearch service, or to share a common elasticsearch server for all your applications. To achieve this, the chart allows you to specify credentials for an external elasticsearch with the [`externalElasticsearch` parameter](#parameters). You should also disable the Redis installation with the `elasticsearch.enabled` option. Here is an example: + +```console +elasticsearch.enabled=false +externalElasticsearch.host=myexternalhost +externalElasticsearch.password=mypassword +externalElasticsearch.port=9200 +``` + +### External S3 support + +You may want to have mastodon connect to an external storage streaming rather than installing MiniIO(TM) inside your cluster. To achieve this, the chart allows you to specify credentials for an external storage streaming with the [`externalS3` parameter](#parameters). You should also disable the MinIO(TM) installation with the `minio.enabled` option. Here is an example: + +```console +minio.enabled=false +externalS3.host=myexternalhost +exterernalS3.accessKeyID=accesskey +externalS3.accessKeySecret=secret +``` + +### 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.To enable Ingress integration, set `apache.ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `apache.ingress.hostname` property can be used to set the host name. The `apache.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 `apache.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `apache.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `apache.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 + +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `web`, `streaming` and `sidekiq` sections. + +```yaml +streaming: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `web`, `streaming` and `sidekiq` sections. + +### Sidecars + +If additional containers are needed in the same pod as mastodon (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `web`, `streaming` and `sidekiq` 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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the `web`, `streaming` and `sidekiq` sections. + +## Persistence + +The [Bitnami mastodon](https://github.com/bitnami/containers/tree/main/bitnami/mastodon) image stores the mastodon data and configurations at the `/bitnami` 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. ## Parameters @@ -648,181 +813,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/masto > 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/mastodon/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. - -### External database support - -You may want to have Mastodon connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the MongoDB installation with the `postgresql.enabled` option. Here is an example: - -```console -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=5432 -``` - -### External redis support - -You may want to have mastodon connect to an external redis rather than installing one inside your cluster. Typical reasons for this are to use a managed redis service, or to share a common redis server for all your applications. To achieve this, the chart allows you to specify credentials for an external redis with the [`externalRedis` parameter](#parameters). You should also disable the Redis installation with the `redis.enabled` option. Here is an example: - -```console -redis.enabled=false -externalRedis.host=myexternalhost -externalRedis.password=mypassword -externalRedis.port=6379 -``` - -### External elasticsearch support - -You may want to have mastodon connect to an external elasticsearch rather than installing one inside your cluster. Typical reasons for this are to use a managed elasticsearch service, or to share a common elasticsearch server for all your applications. To achieve this, the chart allows you to specify credentials for an external elasticsearch with the [`externalElasticsearch` parameter](#parameters). You should also disable the Redis installation with the `elasticsearch.enabled` option. Here is an example: - -```console -elasticsearch.enabled=false -externalElasticsearch.host=myexternalhost -externalElasticsearch.password=mypassword -externalElasticsearch.port=9200 -``` - -### External S3 support - -You may want to have mastodon connect to an external storage streaming rather than installing MiniIO(TM) inside your cluster. To achieve this, the chart allows you to specify credentials for an external storage streaming with the [`externalS3` parameter](#parameters). You should also disable the MinIO(TM) installation with the `minio.enabled` option. Here is an example: - -```console -minio.enabled=false -externalS3.host=myexternalhost -exterernalS3.accessKeyID=accesskey -externalS3.accessKeySecret=secret -``` - -### 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.To enable Ingress integration, set `apache.ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `apache.ingress.hostname` property can be used to set the host name. The `apache.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 `apache.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `apache.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `apache.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 - -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 - -The [Bitnami mastodon](https://github.com/bitnami/containers/tree/main/bitnami/mastodon) image stores the mastodon data and configurations at the `/bitnami` 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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `web`, `streaming` and `sidekiq` sections. - -```yaml -streaming: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `web`, `streaming` and `sidekiq` sections. - -### Sidecars - -If additional containers are needed in the same pod as mastodon (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `web`, `streaming` and `sidekiq` 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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the `web`, `streaming` and `sidekiq` sections. - ## 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). diff --git a/bitnami/matomo/README.md b/bitnami/matomo/README.md index 93ba86e52f..7a7840c30d 100644 --- a/bitnami/matomo/README.md +++ b/bitnami/matomo/README.md @@ -45,15 +45,83 @@ The command deploys Matomo on the Kubernetes cluster in the default configuratio > **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 Matomo](https://github.com/bitnami/containers/tree/main/bitnami/matomo) image stores the Matomo data and configurations at the `/bitnami/matomo` 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/matomo ``` -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/matomo + ``` + + > 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 `matomo-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 Matomo file directory permissions yourself ## Parameters @@ -372,84 +440,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/matom > 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/matomo/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 Matomo](https://github.com/bitnami/containers/tree/main/bitnami/matomo) image stores the Matomo data and configurations at the `/bitnami/matomo` 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/matomo -``` - -> 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/matomo - ``` - - > 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 `matomo-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 Matomo 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). diff --git a/bitnami/mediawiki/README.md b/bitnami/mediawiki/README.md index 5781f6e2a6..3f8cf264df 100644 --- a/bitnami/mediawiki/README.md +++ b/bitnami/mediawiki/README.md @@ -45,15 +45,74 @@ The command deploys MediaWiki on the Kubernetes cluster in the default configura > **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 -```console -helm delete my-release +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. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the Mediawki app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### 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 MediaWiki](https://github.com/bitnami/containers/tree/main/bitnami/mediawiki) image stores the MediaWiki data and configurations at the `/bitnami/mediawiki` 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. ## Parameters @@ -317,75 +376,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/media > 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/mediawiki/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. - -## Persistence - -The [Bitnami MediaWiki](https://github.com/bitnami/containers/tree/main/bitnami/mediawiki) image stores the MediaWiki data and configurations at the `/bitnami/mediawiki` 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. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the Mediawki app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### 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. - ## 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). diff --git a/bitnami/memcached/README.md b/bitnami/memcached/README.md index a8ed875814..7c0b8d0814 100644 --- a/bitnami/memcached/README.md +++ b/bitnami/memcached/README.md @@ -41,15 +41,75 @@ These commands deploy Memcached on the Kubernetes cluster in the default configu > **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 -```console -helm delete my-release +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. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```yaml +sidecars: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +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/). + +### Set Pod affinity + +This chart allows you to set your custom affinity using the `affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 + +When using `architecture: "high-availability"` the [Bitnami Memcached](https://github.com/bitnami/containers/tree/main/bitnami/memcached) image stores the cache-state at the `/cache-state` path of the container if enabled. + +Persistent Volume Claims (PVCs) 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. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). ## Parameters @@ -312,76 +372,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/memca > 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/memcached/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. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set your custom affinity using the `affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 - -When using `architecture: "high-availability"` the [Bitnami Memcached](https://github.com/bitnami/containers/tree/main/bitnami/memcached) image stores the cache-state at the `/cache-state` path of the container if enabled. - -Persistent Volume Claims (PVCs) 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. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - ## 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). diff --git a/bitnami/metallb/README.md b/bitnami/metallb/README.md index a3c6f5913a..eff65c248e 100644 --- a/bitnami/metallb/README.md +++ b/bitnami/metallb/README.md @@ -44,16 +44,46 @@ These commands deploy metallb on the Kubernetes cluster in the default configura > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` helm release: +### Resource requests and limits -```console -helm uninstall my-release +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. + +To configure [MetalLB](https://metallb.universe.tf) please look into the configuration section [MetalLB Configuration](https://metallb.universe.tf/configuration/). + +### Example IP addresses to assing to the LoadBalancer configuration + +```yaml +# The address-pools lists the IP addresses that MetalLB is +# allowed to allocate. You can have as many +# address pools as you want. +apiVersion: metallb.io/v1beta1 +kind: IPAddressPool +metadata: + # A name for the address pool. Services can request allocation + # from a specific address pool using this name. + name: first-pool + namespace: metallb-system +spec: + # A list of IP address ranges over which MetalLB has + # authority. You can list multiple ranges in a single pool, they + # will all share the same settings. Each range can be either a + # CIDR prefix, or an explicit start-end range of IPs. + addresses: + - 192.168.10.0/24 + - 192.168.9.1-192.168.9.5 + - fc00:f853:0ccd:e799::/124 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Parameters ### Global parameters @@ -322,46 +352,6 @@ helm install my-release \ The above command sets the `readinessProbe.successThreshold` to `5`. -## 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. - -To configure [MetalLB](https://metallb.universe.tf) please look into the configuration section [MetalLB Configuration](https://metallb.universe.tf/configuration/). - -### Example IP addresses to assing to the LoadBalancer configuration - -```yaml -# The address-pools lists the IP addresses that MetalLB is -# allowed to allocate. You can have as many -# address pools as you want. -apiVersion: metallb.io/v1beta1 -kind: IPAddressPool -metadata: - # A name for the address pool. Services can request allocation - # from a specific address pool using this name. - name: first-pool - namespace: metallb-system -spec: - # A list of IP address ranges over which MetalLB has - # authority. You can list multiple ranges in a single pool, they - # will all share the same settings. Each range can be either a - # CIDR prefix, or an explicit start-end range of IPs. - addresses: - - 192.168.10.0/24 - - 192.168.9.1-192.168.9.5 - - fc00:f853:0ccd:e799::/124 -``` - ## 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). diff --git a/bitnami/metrics-server/README.md b/bitnami/metrics-server/README.md index f68954e663..5c794893b9 100644 --- a/bitnami/metrics-server/README.md +++ b/bitnami/metrics-server/README.md @@ -41,15 +41,33 @@ These commands deploy Metrics Server on the Kubernetes cluster in the default co > **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 -```console -helm delete my-release -``` +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. -The command removes all the Kubernetes components associated with the chart and deletes the release. +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. + +### Enable RBAC security + +In order to enable Role-Based Access Control (RBAC) for Metrics Server, use the following parameter: `rbac.create=true`. + +### Configure certificates + +If you are providing your own certificates for the API Service, set `insecureSkipTLSVerify` to `"false"`, and provide a `caBundle` consisting of the base64-encoded certificate chain. + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use one 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. ## Parameters @@ -207,34 +225,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/metri > 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/metrics-server/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. - -### Enable RBAC security - -In order to enable Role-Based Access Control (RBAC) for Metrics Server, use the following parameter: `rbac.create=true`. - -### Configure certificates - -If you are providing your own certificates for the API Service, set `insecureSkipTLSVerify` to `"false"`, and provide a `caBundle` consisting of the base64-encoded certificate chain. - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use one 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. - ## 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). diff --git a/bitnami/milvus/README.md b/bitnami/milvus/README.md index 6f6b3fa1b2..a11ccf3db0 100644 --- a/bitnami/milvus/README.md +++ b/bitnami/milvus/README.md @@ -44,15 +44,194 @@ The command deploys milvus on the Kubernetes cluster in the default configuratio > **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 -```console -helm delete my-release +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. + +### Milvus configuration + +The Milvus configuration file `milvus.yaml` is shared across the different components: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode` and `indexNode`. This is set in the `milvus.defaultConfig` value. This configuration can be extended with extra settings using the `milvus.extraConfig` value. For specific component configuration edit the `extraConfig` section inside each of the previously mentioned components. Check the official [Milvis documentation](https://milvus.io/docs) for the list of possible configurations. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode`, `indexNode`, `attu` and `queryNode`. + +```yaml +dataCoord: + extraEnvVars: + - name: LOG_LEVEL + value: error + +rootCoord: + extraEnvVars: + - name: LOG_LEVEL + value: error + +indexCoord: + extraEnvVars: + - name: LOG_LEVEL + value: error + +dataNode: + extraEnvVars: + - name: LOG_LEVEL + value: error + +indexNode: + extraEnvVars: + - name: LOG_LEVEL + value: error + +queryNode: + extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as milvus (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode`, `indexNode`, `attu` and `queryNode` . + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside each of the subsections: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode`, `indexNode`, `attu` and `queryNode`. + +### External kafka support + +You may want to have Milvus connect to an external kafka rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalKafka` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example: + +```yaml +kafka: + enabled: false +externalKafka: + hosts: + - externalhost +``` + +### External etcd support + +You may want to have Milvus connect to an external etcd rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalEtcd` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example: + +```yaml +etcd: + enabled: false +externalEtcd: + hosts: + - externalhost +``` + +### External S3 support + +You may want to have mastodon connect to an external storage streaming rather than installing MiniIO(TM) inside your cluster. To achieve this, the chart allows you to specify credentials for an external storage streaming with the [`externalS3` parameter](#parameters). You should also disable the MinIO(TM) installation with the `minio.enabled` option. Here is an example: + +```console +minio.enabled=false +externalS3.host=myexternalhost +exterernalS3.accessKeyID=accesskey +externalS3.accessKeySecret=secret +``` + +### 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.To enable Ingress integration, set `attu.ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `attu.ingress.hostname` property can be used to set the host name. The `attu.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 `attu.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `attu.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `attu.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 + +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`. ## Parameters @@ -1604,194 +1783,9 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/milvu > 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/milvus/values.yaml) -## Configuration and installation details +## Troubleshooting -### 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. - -### Milvus configuration - -The Milvus configuration file `milvus.yaml` is shared across the different components: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode` and `indexNode`. This is set in the `milvus.defaultConfig` value. This configuration can be extended with extra settings using the `milvus.extraConfig` value. For specific component configuration edit the `extraConfig` section inside each of the previously mentioned components. Check the official [Milvis documentation](https://milvus.io/docs) for the list of possible configurations. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside each of the subsections: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode`, `indexNode`, `attu` and `queryNode`. - -```yaml -dataCoord: - extraEnvVars: - - name: LOG_LEVEL - value: error - -rootCoord: - extraEnvVars: - - name: LOG_LEVEL - value: error - -indexCoord: - extraEnvVars: - - name: LOG_LEVEL - value: error - -dataNode: - extraEnvVars: - - name: LOG_LEVEL - value: error - -indexNode: - extraEnvVars: - - name: LOG_LEVEL - value: error - -queryNode: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as milvus (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside each of the subsections: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode`, `indexNode`, `attu` and `queryNode` . - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside each of the subsections: `rootCoord`, `dataCoord`, `indexCoord`, `dataNode`, `indexNode`, `attu` and `queryNode`. - -### External kafka support - -You may want to have Milvus connect to an external kafka rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalKafka` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example: - -```yaml -kafka: - enabled: false -externalKafka: - hosts: - - externalhost -``` - -### External etcd support - -You may want to have Milvus connect to an external etcd rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalEtcd` parameter](#parameters). You should also disable the etcd installation with the `etcd.enabled` option. Here is an example: - -```yaml -etcd: - enabled: false -externalEtcd: - hosts: - - externalhost -``` - -### External S3 support - -You may want to have mastodon connect to an external storage streaming rather than installing MiniIO(TM) inside your cluster. To achieve this, the chart allows you to specify credentials for an external storage streaming with the [`externalS3` parameter](#parameters). You should also disable the MinIO(TM) installation with the `minio.enabled` option. Here is an example: - -```console -minio.enabled=false -externalS3.host=myexternalhost -exterernalS3.accessKeyID=accesskey -externalS3.accessKeySecret=secret -``` - -### 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.To enable Ingress integration, set `attu.ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `attu.ingress.hostname` property can be used to set the host name. The `attu.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 `attu.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `attu.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `attu.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 - -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`. +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). ## Upgrading @@ -1824,10 +1818,6 @@ Additionally, the following values have been modified: This major updates the Kafka subchart to its newest major, 23.0.0. For more information on this subchart's major, please refer to [Kafka upgrade notes](https://github.com/bitnami/charts/tree/main/bitnami/kafka#to-2300). -## 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). - ## License Copyright © 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. diff --git a/bitnami/minio/README.md b/bitnami/minio/README.md index a2c1ac67a0..ef18209d8d 100644 --- a/bitnami/minio/README.md +++ b/bitnami/minio/README.md @@ -42,15 +42,171 @@ These commands deploy MinIO® on the Kubernetes cluster in the default config > **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. + +### Distributed mode + +By default, this chart provisions a MinIO® server in standalone mode. You can start MinIO® server in [distributed mode](https://docs.minio.io/docs/distributed-minio-quickstart-guide) with the following parameter: `mode=distributed` + +This chart bootstrap MinIO® server in distributed mode with 4 nodes by default. You can change the number of nodes using the `statefulset.replicaCount` parameter. For instance, you can deploy the chart with 8 nodes using the following parameters: ```console -helm delete my-release +mode=distributed +statefulset.replicaCount=8 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +You can also bootstrap MinIO® server in distributed mode in several zones, and using multiple drives per node. For instance, you can deploy the chart with 2 nodes per zone on 2 zones, using 2 drives per node: + +```console +mode=distributed +statefulset.replicaCount=2 +statefulset.zones=2 +statefulset.drivesPerNode=2 +``` + +> Note: The total number of drives should be greater than 4 to guarantee erasure coding. Please set a combination of nodes, and drives per node that match this condition. + +### Prometheus exporter + +MinIO® exports Prometheus metrics at `/minio/v2/metrics/cluster`. To allow Prometheus collecting your MinIO® metrics, modify the `values.yaml` adding the corresponding annotations: + +```diff +- podAnnotations: {} ++ podAnnotations: ++ prometheus.io/scrape: "true" ++ prometheus.io/path: "/minio/v2/metrics/cluster" ++ prometheus.io/port: "9000" +``` + +> Find more information about MinIO® metrics at + +### 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: MINIO_LOG_LEVEL + value: DEBUG +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the MinIO® app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### 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 Object Storage based on MinIO(®)](https://github.com/bitnami/containers/tree/main/bitnami/minio) image stores data at the `/bitnami/minio/data` path of the container by default. +This can be modified with the `persistence.mountPath` value which modifies the `MINIO_DATA_DIR` environment variable of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location so that data within MinIO is persistent. The volume is created using dynamic volume provisioning. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -362,172 +518,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/minio > 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/minio/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. - -### Distributed mode - -By default, this chart provisions a MinIO® server in standalone mode. You can start MinIO® server in [distributed mode](https://docs.minio.io/docs/distributed-minio-quickstart-guide) with the following parameter: `mode=distributed` - -This chart bootstrap MinIO® server in distributed mode with 4 nodes by default. You can change the number of nodes using the `statefulset.replicaCount` parameter. For instance, you can deploy the chart with 8 nodes using the following parameters: - -```console -mode=distributed -statefulset.replicaCount=8 -``` - -You can also bootstrap MinIO® server in distributed mode in several zones, and using multiple drives per node. For instance, you can deploy the chart with 2 nodes per zone on 2 zones, using 2 drives per node: - -```console -mode=distributed -statefulset.replicaCount=2 -statefulset.zones=2 -statefulset.drivesPerNode=2 -``` - -> Note: The total number of drives should be greater than 4 to guarantee erasure coding. Please set a combination of nodes, and drives per node that match this condition. - -### Prometheus exporter - -MinIO® exports Prometheus metrics at `/minio/v2/metrics/cluster`. To allow Prometheus collecting your MinIO® metrics, modify the `values.yaml` adding the corresponding annotations: - -```diff -- podAnnotations: {} -+ podAnnotations: -+ prometheus.io/scrape: "true" -+ prometheus.io/path: "/minio/v2/metrics/cluster" -+ prometheus.io/port: "9000" -``` - -> Find more information about MinIO® metrics at - -## Persistence - -The [Bitnami Object Storage based on MinIO(®)](https://github.com/bitnami/containers/tree/main/bitnami/minio) image stores data at the `/bitnami/minio/data` path of the container by default. -This can be modified with the `persistence.mountPath` value which modifies the `MINIO_DATA_DIR` environment variable of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location so that data within MinIO is persistent. The volume is created using dynamic volume provisioning. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: MINIO_LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the MinIO® app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### 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. - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - ## 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). diff --git a/bitnami/mlflow/README.md b/bitnami/mlflow/README.md index f0385a0ca2..a8584ff923 100644 --- a/bitnami/mlflow/README.md +++ b/bitnami/mlflow/README.md @@ -45,18 +45,6 @@ The command deploys mlflow on the Kubernetes cluster in the default configuratio > **Tip**: List all releases using `helm list` -## Uninstalling the Chart - -> Note: [PVCs are not removed](https://github.com/helm/helm/issues/5156) and we still don't have created a remove hook. You need to remove PVCs manually. - -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Parameters ### Global parameters diff --git a/bitnami/mongodb-sharded/README.md b/bitnami/mongodb-sharded/README.md index a1b4768227..3b49e50bed 100644 --- a/bitnami/mongodb-sharded/README.md +++ b/bitnami/mongodb-sharded/README.md @@ -47,15 +47,103 @@ The command deploys MongoDB® on the Kubernetes cluster in the default config > **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 -```console -helm delete my-release +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. + +### Change MongoDB® version + +To modify the MongoDB® version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/mongodb-sharded/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. + +### Sharding + +This chart deploys a sharded cluster by default. Some characteristics of this chart are: + +- It allows HA by enabling replication on the shards and the config servers. The mongos instances can be scaled horizontally as well. +- The number of secondary and arbiter nodes can be scaled out independently. + +### Initialize a fresh instance + +The [Bitnami MongoDB®](https://github.com/bitnami/containers/tree/main/bitnami/mongodb-sharded) image allows you to use your custom scripts to initialize a fresh instance. You can create a custom config map and give it via `initScriptsCM`(check options for more details). + +The allowed extensions are `.sh`, and `.js`. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Kibana (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter (available in the `mongos`, `shardsvr.dataNode`, `shardsvr.arbiter`, `configsvr` and `common` sections). Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: +- name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` (available in the `mongos`, `shardsvr.dataNode`, `shardsvr.arbiter`, `configsvr` and `common` sections) property. + +```yaml +extraEnvVars: + - name: MONGODB_VERSION + value: 4.0 +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Using an external config server + +It is possible to not deploy any shards or a config server. For example, it is possible to simply deploy `mongos` instances that point to an external MongoDB® sharded database. If that is the case, set the `configsvr.external.host` and `configsvr.external.replicasetName` for the mongos instances to connect. For authentication, set the `configsvr.external.rootPassword` and `configsvr.external.replicasetKey` values. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami MongoDB®](https://github.com/bitnami/containers/tree/main/bitnami/mongodb-sharded) image stores the MongoDB® data and configurations at the `/bitnami/mongodb` path of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + +### Adding extra volumes + +The Bitnami Kibana chart supports mounting extra volumes (either PVCs, secrets or configmaps) by using the `extraVolumes` and `extraVolumeMounts` properties (available in the `mongos`, `shardsvr.dataNode`, `shardsvr.arbiter`, `configsvr` and `common` sections). This can be combined with advanced operations like adding extra init containers and sidecars. ## Parameters @@ -593,104 +681,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/mongo > 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/mongodb-sharded/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. - -### Change MongoDB® version - -To modify the MongoDB® version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/mongodb-sharded/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. - -### Sharding - -This chart deploys a sharded cluster by default. Some characteristics of this chart are: - -- It allows HA by enabling replication on the shards and the config servers. The mongos instances can be scaled horizontally as well. -- The number of secondary and arbiter nodes can be scaled out independently. - -### Initialize a fresh instance - -The [Bitnami MongoDB®](https://github.com/bitnami/containers/tree/main/bitnami/mongodb-sharded) image allows you to use your custom scripts to initialize a fresh instance. You can create a custom config map and give it via `initScriptsCM`(check options for more details). - -The allowed extensions are `.sh`, and `.js`. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Kibana (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter (available in the `mongos`, `shardsvr.dataNode`, `shardsvr.arbiter`, `configsvr` and `common` sections). Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: -- name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: -- name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` (available in the `mongos`, `shardsvr.dataNode`, `shardsvr.arbiter`, `configsvr` and `common` sections) property. - -```yaml -extraEnvVars: - - name: MONGODB_VERSION - value: 4.0 -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Using an external config server - -It is possible to not deploy any shards or a config server. For example, it is possible to simply deploy `mongos` instances that point to an external MongoDB® sharded database. If that is the case, set the `configsvr.external.host` and `configsvr.external.replicasetName` for the mongos instances to connect. For authentication, set the `configsvr.external.rootPassword` and `configsvr.external.replicasetKey` values. - -## Persistence - -The [Bitnami MongoDB®](https://github.com/bitnami/containers/tree/main/bitnami/mongodb-sharded) image stores the MongoDB® data and configurations at the `/bitnami/mongodb` path of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### Adding extra volumes - -The Bitnami Kibana chart supports mounting extra volumes (either PVCs, secrets or configmaps) by using the `extraVolumes` and `extraVolumeMounts` properties (available in the `mongos`, `shardsvr.dataNode`, `shardsvr.arbiter`, `configsvr` and `common` sections). This can be combined with advanced operations like adding extra init containers and sidecars. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/mongodb/README.md b/bitnami/mongodb/README.md index b5c5da8d1d..55067b6574 100644 --- a/bitnami/mongodb/README.md +++ b/bitnami/mongodb/README.md @@ -22,36 +22,6 @@ This chart bootstraps a [MongoDB(®)](https://github.com/bitnami/containers/t Bitnami charts can be used with [Kubeapps](https://kubeapps.dev/) for deployment and management of Helm Charts in clusters. -## Prerequisites - -- Kubernetes 1.23+ -- Helm 3.8.0+ -- PV provisioner support in the underlying infrastructure - -## Installing the Chart - -To install the chart with the release name `my-release`: - -```console -helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/mongodb -``` - -> 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`. - -The command deploys MongoDB(®) on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. - -> **Tip**: List all releases using `helm list` - -## Uninstalling the Chart - -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Architecture This chart allows installing MongoDB(®) using two different architecture setups: `standalone` or `replicaset`. Use the `architecture` parameter to choose the one to use: @@ -125,6 +95,268 @@ There are no services load balancing requests between MongoDB(®) nodes; inst > NOTE: Although the first replica is initially assigned the primary role, any of the secondary nodes can become the primary if it is down, or during upgrades. Do not make any assumption about what replica has the primary role. Instead, configure your MongoDB(®) client with the list of MongoDB(®) hostnames so it can dynamically choose the node to send requests. +## Prerequisites + +- Kubernetes 1.23+ +- Helm 3.8.0+ +- PV provisioner support in the underlying infrastructure + +## Installing the Chart + +To install the chart with the release name `my-release`: + +```console +helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/mongodb +``` + +> 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`. + +The command deploys MongoDB(®) on the Kubernetes cluster in the default configuration. The [Parameters](#parameters) section lists the parameters that can be configured during installation. + +> **Tip**: List all releases using `helm list` + +## 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. + +### Customize a new MongoDB instance + +The [Bitnami MongoDB(®) image](https://github.com/bitnami/containers/tree/main/bitnami/mongodb) supports the use of custom scripts to initialize a fresh instance. In order to execute the scripts, two options are available: + +- Specify them using the `initdbScripts` parameter as dict. +- Define an external Kubernetes ConfigMap with all the initialization scripts by setting the `initdbScriptsConfigMap` parameter. Note that this will override the previous option. + +The allowed script extensions are `.sh` and `.js`. + +### Replicaset: Access MongoDB(®) nodes from outside the cluster + +In order to access MongoDB(®) nodes from outside the cluster when using a replicaset architecture, a specific service per MongoDB(®) pod will be created. There are two ways of configuring external access: + +- Using LoadBalancer services +- Using NodePort services. + +#### Use LoadBalancer services + +Two alternatives are available to use *LoadBalancer* services: + +- Use random load balancer IP addresses using an *initContainer* that waits for the IP addresses to be ready and discovers them automatically. An example deployment configuration is shown below: + + ```text + architecture=replicaset + replicaCount=2 + externalAccess.enabled=true + externalAccess.service.type=LoadBalancer + externalAccess.service.port=27017 + externalAccess.autoDiscovery.enabled=true + serviceAccount.create=true + rbac.create=true + ``` + + > NOTE: This option requires creating RBAC rules on clusters where RBAC policies are enabled. + +- Manually specify the load balancer IP addresses. An example deployment configuration is shown below, with the placeholder EXTERNAL-IP-ADDRESS-X used in place of the load balancer IP addresses: + + ```text + architecture=replicaset + replicaCount=2 + externalAccess.enabled=true + externalAccess.service.type=LoadBalancer + externalAccess.service.port=27017 + externalAccess.service.loadBalancerIPs[0]='EXTERNAL-IP-ADDRESS-1' + externalAccess.service.loadBalancerIPs[1]='EXTERNAL-IP-ADDRESS-2' + ``` + + > NOTE: This option requires knowing the load balancer IP addresses, so that each MongoDB® node's advertised hostname is configured with it. + +#### Use NodePort services + +Manually specify the node ports to use. An example deployment configuration is shown below, with the placeholder NODE-PORT-X used in place of the node ports: + +```text +architecture=replicaset +replicaCount=2 +externalAccess.enabled=true +externalAccess.service.type=NodePort +externalAccess.service.nodePorts[0]='NODE-PORT-1' +externalAccess.service.nodePorts[1]='NODE-PORT-2' +``` + +> NOTE: This option requires knowing the node ports that will be exposed, so each MongoDB® node's advertised hostname is configured with it. + +The pod will try to get the external IP address of the node using the command `curl -s https://ipinfo.io/IP-ADDRESS` unless the `externalAccess.service.domain` parameter is set. + +### Bootstrapping with an External Cluster + +This chart is equipped with the ability to bring online a set of Pods that connect to an existing MongoDB(®) deployment that lies outside of Kubernetes. This effectively creates a hybrid MongoDB(®) Deployment where both Pods in Kubernetes and Instances such as Virtual Machines can partake in a single MongoDB(®) Deployment. This is helpful in situations where one may be migrating MongoDB(®) from Virtual Machines into Kubernetes, for example. To take advantage of this, use the following as an example configuration: + +```yaml +externalAccess: + externalMaster: + enabled: true + host: external-mongodb-0.internal +``` + +:warning: To bootstrap MongoDB(®) with an external master that lies outside of Kubernetes, be sure to set up external access using any of the suggested methods in this chart to have connectivity between the MongoDB(®) members. :warning: + +### Add extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` properties. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Backup and restore MongoDB(R) deployments + +Two different approaches are available to back up and restore Bitnami MongoDB® Helm chart deployments on Kubernetes: + +- Back up the data from the source deployment and restore it in a new deployment using MongoDB® built-in backup/restore tools. +- Back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool. + +#### Method 1: Backup and restore data using MongoDB® built-in tools + +This method involves the following steps: + +- Use the *mongodump* tool to create a snapshot of the data in the source cluster. +- Create a new MongoDB® Cluster deployment and forward the MongoDB® Cluster service port for the new deployment. +- Restore the data using the *mongorestore* tool to import the backup to the new cluster. + +> NOTE: Under this approach, it is important to create the new deployment on the destination cluster using the same credentials as the original deployment on the source cluster. + +#### Method 2: Back up and restore persistent data volumes + +This method involves copying the persistent data volumes for the MongoDB® nodes and reusing them in a new deployment with [Velero](https://velero.io/), an open source Kubernetes backup/restore tool. This method is only suitable when: + +- The Kubernetes provider is [supported by Velero](https://velero.io/docs/latest/supported-providers/). +- Both clusters are on the same Kubernetes provider, as this is a requirement of [Velero's native support for migrating persistent volumes](https://velero.io/docs/latest/migration-case/). +- The restored deployment on the destination cluster will have the same name, namespace, topology and credentials as the original deployment on the source cluster. + +This method involves the following steps: + +- Install Velero on the source and destination clusters. +- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster. +- Use Velero to restore the backed-up PVs on the destination cluster. +- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. + +Refer to our detailed [tutorial on backing up and restoring MongoDB® chart deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-mongodb-kubernetes/), which covers both these approaches, for more information. + +### Use custom Prometheus rules + +Custom Prometheus rules can be defined for the Prometheus Operator by using the `prometheusRule` parameter. A basic configuration example is shown below: + +```text + metrics: + enabled: true + prometheusRule: + enabled: true + rules: + - name: rule1 + rules: + - alert: HighRequestLatency + expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5 + for: 10m + labels: + severity: page + annotations: + summary: High request latency +``` + +### Enable SSL/TLS + +This chart supports enabling SSL/TLS between nodes in the cluster, as well as between MongoDB(®) clients and nodes, by setting the `MONGODB_EXTRA_FLAGS` and `MONGODB_CLIENT_EXTRA_FLAGS` container environment variables, together with the correct `MONGODB_ADVERTISED_HOSTNAME`. To enable full TLS encryption, set the `tls.enabled` parameter to `true`. + +#### Generate the self-signed certificates via pre-install Helm hooks + +The `secrets-ca.yaml` file utilizes the Helm "pre-install" hook to ensure that the certificates will only be generated on chart install. + +The `genCA()` function will create a new self-signed x509 certificate authority. The `genSignedCert()` function creates an object with the certificate and key, which are base64-encoded and used in a YAML-like object. The `genSignedCert()` function is passed the CN, an empty IP list (the nil part), the validity and the CA created previously. + +A Kubernetes Secret is used to hold the signed certificate created above, and the `initContainer` sets up the rest. Using Helm's hook annotations ensures that the certificates will only be generated on chart install. This will prevent overriding the certificates if the chart is upgraded. + +#### Use your own CA + +To use your own CA, set `tls.caCert` and `tls.caKey` with appropriate base64 encoded data. The `secrets-ca.yaml` file will utilize this data to create the Secret. + +> NOTE: Currently, only RSA private keys are supported. + +#### Access the cluster + +To access the cluster, enable the init container which generates the MongoDB(®) server/client PEM key needed to access the cluster. Please be sure to include the `$my_hostname` section with your actual hostname, and the alternative hostnames section should contain the hostnames that should be allowed access to the MongoDB(®) replicaset. Additionally, if external access is enabled, the load balancer IP addresses are added to the alternative names list. + +> NOTE: You will be generating self-signed certificates for the MongoDB(®) deployment. The init container generates a new MongoDB(®) private key which will be used to create a Certificate Authority (CA) and the public certificate for the CA. The Certificate Signing Request will be created as well and signed using the private key of the CA previously created. Finally, the PEM bundle will be created using the private key and public certificate. This process will be repeated for each node in the cluster. + +#### Start the cluster + +After the certificates have been generated and made available to the containers at the correct mount points, the MongoDB(®) server will be started with TLS enabled. The options for the TLS mode will be one of `disabled`, `allowTLS`, `preferTLS`, or `requireTLS`. This value can be changed via the `MONGODB_EXTRA_FLAGS` field using the `tlsMode` parameter. The client should now be able to connect to the TLS-enabled cluster with the provided certificates. + +### Set Pod affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami MongoDB(®)](https://github.com/bitnami/containers/tree/main/bitnami/mongodb) image stores the MongoDB(®) data and configurations at the `/bitnami/mongodb` path of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). + ## Parameters ### Global parameters @@ -736,248 +968,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/mongo > 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/mongodb/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. - -### Customize a new MongoDB instance - -The [Bitnami MongoDB(®) image](https://github.com/bitnami/containers/tree/main/bitnami/mongodb) supports the use of custom scripts to initialize a fresh instance. In order to execute the scripts, two options are available: - -- Specify them using the `initdbScripts` parameter as dict. -- Define an external Kubernetes ConfigMap with all the initialization scripts by setting the `initdbScriptsConfigMap` parameter. Note that this will override the previous option. - -The allowed script extensions are `.sh` and `.js`. - -### Replicaset: Access MongoDB(®) nodes from outside the cluster - -In order to access MongoDB(®) nodes from outside the cluster when using a replicaset architecture, a specific service per MongoDB(®) pod will be created. There are two ways of configuring external access: - -- Using LoadBalancer services -- Using NodePort services. - -#### Use LoadBalancer services - -Two alternatives are available to use *LoadBalancer* services: - -- Use random load balancer IP addresses using an *initContainer* that waits for the IP addresses to be ready and discovers them automatically. An example deployment configuration is shown below: - - ```text - architecture=replicaset - replicaCount=2 - externalAccess.enabled=true - externalAccess.service.type=LoadBalancer - externalAccess.service.port=27017 - externalAccess.autoDiscovery.enabled=true - serviceAccount.create=true - rbac.create=true - ``` - - > NOTE: This option requires creating RBAC rules on clusters where RBAC policies are enabled. - -- Manually specify the load balancer IP addresses. An example deployment configuration is shown below, with the placeholder EXTERNAL-IP-ADDRESS-X used in place of the load balancer IP addresses: - - ```text - architecture=replicaset - replicaCount=2 - externalAccess.enabled=true - externalAccess.service.type=LoadBalancer - externalAccess.service.port=27017 - externalAccess.service.loadBalancerIPs[0]='EXTERNAL-IP-ADDRESS-1' - externalAccess.service.loadBalancerIPs[1]='EXTERNAL-IP-ADDRESS-2' - ``` - - > NOTE: This option requires knowing the load balancer IP addresses, so that each MongoDB® node's advertised hostname is configured with it. - -#### Use NodePort services - -Manually specify the node ports to use. An example deployment configuration is shown below, with the placeholder NODE-PORT-X used in place of the node ports: - -```text -architecture=replicaset -replicaCount=2 -externalAccess.enabled=true -externalAccess.service.type=NodePort -externalAccess.service.nodePorts[0]='NODE-PORT-1' -externalAccess.service.nodePorts[1]='NODE-PORT-2' -``` - -> NOTE: This option requires knowing the node ports that will be exposed, so each MongoDB® node's advertised hostname is configured with it. - -The pod will try to get the external IP address of the node using the command `curl -s https://ipinfo.io/IP-ADDRESS` unless the `externalAccess.service.domain` parameter is set. - -### Bootstrapping with an External Cluster - -This chart is equipped with the ability to bring online a set of Pods that connect to an existing MongoDB(®) deployment that lies outside of Kubernetes. This effectively creates a hybrid MongoDB(®) Deployment where both Pods in Kubernetes and Instances such as Virtual Machines can partake in a single MongoDB(®) Deployment. This is helpful in situations where one may be migrating MongoDB(®) from Virtual Machines into Kubernetes, for example. To take advantage of this, use the following as an example configuration: - -```yaml -externalAccess: - externalMaster: - enabled: true - host: external-mongodb-0.internal -``` - -:warning: To bootstrap MongoDB(®) with an external master that lies outside of Kubernetes, be sure to set up external access using any of the suggested methods in this chart to have connectivity between the MongoDB(®) members. :warning: - -### Add extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` properties. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Persistence - -The [Bitnami MongoDB(®)](https://github.com/bitnami/containers/tree/main/bitnami/mongodb) image stores the MongoDB(®) data and configurations at the `/bitnami/mongodb` path of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Backup and restore MongoDB(R) deployments - -Two different approaches are available to back up and restore Bitnami MongoDB® Helm chart deployments on Kubernetes: - -- Back up the data from the source deployment and restore it in a new deployment using MongoDB® built-in backup/restore tools. -- Back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool. - -#### Method 1: Backup and restore data using MongoDB® built-in tools - -This method involves the following steps: - -- Use the *mongodump* tool to create a snapshot of the data in the source cluster. -- Create a new MongoDB® Cluster deployment and forward the MongoDB® Cluster service port for the new deployment. -- Restore the data using the *mongorestore* tool to import the backup to the new cluster. - -> NOTE: Under this approach, it is important to create the new deployment on the destination cluster using the same credentials as the original deployment on the source cluster. - -#### Method 2: Back up and restore persistent data volumes - -This method involves copying the persistent data volumes for the MongoDB® nodes and reusing them in a new deployment with [Velero](https://velero.io/), an open source Kubernetes backup/restore tool. This method is only suitable when: - -- The Kubernetes provider is [supported by Velero](https://velero.io/docs/latest/supported-providers/). -- Both clusters are on the same Kubernetes provider, as this is a requirement of [Velero's native support for migrating persistent volumes](https://velero.io/docs/latest/migration-case/). -- The restored deployment on the destination cluster will have the same name, namespace, topology and credentials as the original deployment on the source cluster. - -This method involves the following steps: - -- Install Velero on the source and destination clusters. -- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster. -- Use Velero to restore the backed-up PVs on the destination cluster. -- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. - -Refer to our detailed [tutorial on backing up and restoring MongoDB® chart deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-mongodb-kubernetes/), which covers both these approaches, for more information. - -### Use custom Prometheus rules - -Custom Prometheus rules can be defined for the Prometheus Operator by using the `prometheusRule` parameter. A basic configuration example is shown below: - -```text - metrics: - enabled: true - prometheusRule: - enabled: true - rules: - - name: rule1 - rules: - - alert: HighRequestLatency - expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5 - for: 10m - labels: - severity: page - annotations: - summary: High request latency -``` - -### Enable SSL/TLS - -This chart supports enabling SSL/TLS between nodes in the cluster, as well as between MongoDB(®) clients and nodes, by setting the `MONGODB_EXTRA_FLAGS` and `MONGODB_CLIENT_EXTRA_FLAGS` container environment variables, together with the correct `MONGODB_ADVERTISED_HOSTNAME`. To enable full TLS encryption, set the `tls.enabled` parameter to `true`. - -#### Generate the self-signed certificates via pre-install Helm hooks - -The `secrets-ca.yaml` file utilizes the Helm "pre-install" hook to ensure that the certificates will only be generated on chart install. - -The `genCA()` function will create a new self-signed x509 certificate authority. The `genSignedCert()` function creates an object with the certificate and key, which are base64-encoded and used in a YAML-like object. The `genSignedCert()` function is passed the CN, an empty IP list (the nil part), the validity and the CA created previously. - -A Kubernetes Secret is used to hold the signed certificate created above, and the `initContainer` sets up the rest. Using Helm's hook annotations ensures that the certificates will only be generated on chart install. This will prevent overriding the certificates if the chart is upgraded. - -#### Use your own CA - -To use your own CA, set `tls.caCert` and `tls.caKey` with appropriate base64 encoded data. The `secrets-ca.yaml` file will utilize this data to create the Secret. - -> NOTE: Currently, only RSA private keys are supported. - -#### Access the cluster - -To access the cluster, enable the init container which generates the MongoDB(®) server/client PEM key needed to access the cluster. Please be sure to include the `$my_hostname` section with your actual hostname, and the alternative hostnames section should contain the hostnames that should be allowed access to the MongoDB(®) replicaset. Additionally, if external access is enabled, the load balancer IP addresses are added to the alternative names list. - -> NOTE: You will be generating self-signed certificates for the MongoDB(®) deployment. The init container generates a new MongoDB(®) private key which will be used to create a Certificate Authority (CA) and the public certificate for the CA. The Certificate Signing Request will be created as well and signed using the private key of the CA previously created. Finally, the PEM bundle will be created using the private key and public certificate. This process will be repeated for each node in the cluster. - -#### Start the cluster - -After the certificates have been generated and made available to the containers at the correct mount points, the MongoDB(®) server will be started with TLS enabled. The options for the TLS mode will be one of `disabled`, `allowTLS`, `preferTLS`, or `requireTLS`. This value can be changed via the `MONGODB_EXTRA_FLAGS` field using the `tlsMode` parameter. The client should now be able to connect to the TLS-enabled cluster with the provided certificates. - -### Set Pod affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/moodle/README.md b/bitnami/moodle/README.md index 1ff80e4aa3..5ffef02067 100644 --- a/bitnami/moodle/README.md +++ b/bitnami/moodle/README.md @@ -45,15 +45,75 @@ The command deploys Moodle™ on the Kubernetes cluster in the default confi > **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. + +### Ingress without TLS + +For using ingress (example without TLS): ```console -helm delete my-release +ingress.enabled=True +ingress.hosts[0]=moodle.domain.com +serviceType=ClusterIP +moodleUsername=admin +moodlePassword=password +mariadb.mariadbRootPassword=secretpassword ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +These are the *3 mandatory parameters* when *Ingress* is desired: `ingress.enabled=True`, `ingress.hosts[0]=moodle.domain.com` and `serviceType=ClusterIP` + +### Ingress TLS + +If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. + +To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `moodle-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: + +```yaml +ingress: + ## If true, Moodle(TM) server Ingress will be created + ## + enabled: true + + ## Moodle(TM) server Ingress annotations + ## + annotations: {} + # kubernetes.io/ingress.class: nginx + # kubernetes.io/tls-acme: 'true' + + ## Moodle(TM) server Ingress hostnames + ## Must be provided if Ingress is enabled + ## + hosts: + - moodle.domain.com + + ## Moodle(TM) server Ingress TLS configuration + ## Secrets must be manually created in the namespace + ## + tls: + - secretName: moodle-server-tls + hosts: + - moodle.domain.com +``` + +## Persistence + +The [Bitnami Container Image for Moodle™](https://github.com/bitnami/containers/tree/main/bitnami/moodle) stores the Moodle™ data and configurations at the `/bitnami/moodle` and `/bitnami/apache` paths of the container. + +Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, vpshere, and minikube. +See the [Parameters](#parameters) section to configure the PVC or to disable persistence. +You may want to review the [PV reclaim policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) and update as required. By default, it's set to delete, and when Moodle™ is uninstalled, data is also removed. ## Parameters @@ -338,76 +398,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/moodl > 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/moodle/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. - -### Ingress without TLS - -For using ingress (example without TLS): - -```console -ingress.enabled=True -ingress.hosts[0]=moodle.domain.com -serviceType=ClusterIP -moodleUsername=admin -moodlePassword=password -mariadb.mariadbRootPassword=secretpassword -``` - -These are the *3 mandatory parameters* when *Ingress* is desired: `ingress.enabled=True`, `ingress.hosts[0]=moodle.domain.com` and `serviceType=ClusterIP` - -### Ingress TLS - -If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. - -To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `moodle-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: - -```yaml -ingress: - ## If true, Moodle(TM) server Ingress will be created - ## - enabled: true - - ## Moodle(TM) server Ingress annotations - ## - annotations: {} - # kubernetes.io/ingress.class: nginx - # kubernetes.io/tls-acme: 'true' - - ## Moodle(TM) server Ingress hostnames - ## Must be provided if Ingress is enabled - ## - hosts: - - moodle.domain.com - - ## Moodle(TM) server Ingress TLS configuration - ## Secrets must be manually created in the namespace - ## - tls: - - secretName: moodle-server-tls - hosts: - - moodle.domain.com -``` - -## Persistence - -The [Bitnami Container Image for Moodle™](https://github.com/bitnami/containers/tree/main/bitnami/moodle) stores the Moodle™ data and configurations at the `/bitnami/moodle` and `/bitnami/apache` paths of the container. - -Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, vpshere, and minikube. -See the [Parameters](#parameters) section to configure the PVC or to disable persistence. -You may want to review the [PV reclaim policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) and update as required. By default, it's set to delete, and when Moodle™ is uninstalled, data is also removed. - ## 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). diff --git a/bitnami/multus-cni/README.md b/bitnami/multus-cni/README.md index 3437b5b481..b5428ed4bc 100644 --- a/bitnami/multus-cni/README.md +++ b/bitnami/multus-cni/README.md @@ -43,15 +43,51 @@ The command deploys Multus CNI on the Kubernetes cluster in the default configur > **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 -```console -helm delete my-release -``` +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. -The command removes all the Kubernetes components associated with the chart and deletes the release. +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. + +### Host configuration + +Once installed, the helm chart will modify configuration files in the host nodes of the Kubernetes cluster. Ensure that the cluster allows root and privileged deployments. + +Once the multus-cni configuration is installed, check the [upstream Kubernetes documentation](https://kubernetes.io/docs/concepts/cluster-administration/networking/) on how to modify the network settings of the cluster. + +> **Important**: Double check that the host CNI binary and configuration directories are properly configured, or the deployment will fail. This is done using the `hostCNINetDir` and `hostCNIBinDir` values. + +### 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. ## Parameters @@ -197,52 +233,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/multu > 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/multus-cni/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. - -### Host configuration - -Once installed, the helm chart will modify configuration files in the host nodes of the Kubernetes cluster. Ensure that the cluster allows root and privileged deployments. - -Once the multus-cni configuration is installed, check the [upstream Kubernetes documentation](https://kubernetes.io/docs/concepts/cluster-administration/networking/) on how to modify the network settings of the cluster. - -> **Important**: Double check that the host CNI binary and configuration directories are properly configured, or the deployment will fail. This is done using the `hostCNINetDir` and `hostCNIBinDir` values. - -### 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. - ## 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). diff --git a/bitnami/mysql/README.md b/bitnami/mysql/README.md index a02582d6da..05ed06e43e 100644 --- a/bitnami/mysql/README.md +++ b/bitnami/mysql/README.md @@ -42,15 +42,100 @@ These commands deploy MySQL on the Kubernetes cluster in the default configurati > **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 -```console -helm delete my-release +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. + +### Use a different MySQL version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Customize a new MySQL instance + +The [Bitnami MySQL](https://github.com/bitnami/containers/tree/main/bitnami/mysql) image allows you to use your custom scripts to initialize a fresh instance. Custom scripts may be specified using the `initdbScripts` parameter. Alternatively, an external ConfigMap may be created with all the initialization scripts and the ConfigMap passed to the chart via the `initdbScriptsConfigMap` parameter. Note that this will override the `initdbScripts` parameter. + +The allowed extensions are `.sh`, `.sql` and `.sql.gz`. + +These scripts are treated differently depending on their extension. While `.sh` scripts are executed on all the nodes, `.sql` and `.sql.gz` scripts are only executed on the primary nodes. This is because `.sh` scripts support conditional tests to identify the type of node they are running on, while such tests are not supported in `.sql` or `sql.gz` files. + +When using a `.sh` script, you may wish to perform a "one-time" action like creating a database. This can be achieved by adding a condition in the script to ensure that it is executed only on one node, as shown in the example below: + +```yaml +initdbScripts: + my_init_script.sh: | + #!/bin/sh + if [[ $(hostname) == *master* ]]; then + echo "Master node" + mysql -P 3306 -uroot -prandompassword -e "create database new_database"; + else + echo "No master node" + fi ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as MySQL, you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Network Policy config + +To enable network policy for MySQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`. + +For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting the DefaultDeny namespace annotation. Note: this will enforce policy for _all_ pods in the namespace: + +```console +kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}" +``` + +With NetworkPolicy enabled, traffic will be limited to just port 3306. + +For more precise policy, set `networkPolicy.allowExternal=false`. This will only allow pods with the generated client label to connect to MySQL. +This label will be displayed in the output of a successful install. + +### Pod affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami MySQL](https://github.com/bitnami/containers/tree/main/bitnami/mysql) image stores the MySQL data and configurations at the `/bitnami/mysql` path of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning by default. An existing PersistentVolumeClaim can also be defined for this purpose. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). ## Parameters @@ -433,101 +518,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/mysql > 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/mysql/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. - -### Use a different MySQL version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Customize a new MySQL instance - -The [Bitnami MySQL](https://github.com/bitnami/containers/tree/main/bitnami/mysql) image allows you to use your custom scripts to initialize a fresh instance. Custom scripts may be specified using the `initdbScripts` parameter. Alternatively, an external ConfigMap may be created with all the initialization scripts and the ConfigMap passed to the chart via the `initdbScriptsConfigMap` parameter. Note that this will override the `initdbScripts` parameter. - -The allowed extensions are `.sh`, `.sql` and `.sql.gz`. - -These scripts are treated differently depending on their extension. While `.sh` scripts are executed on all the nodes, `.sql` and `.sql.gz` scripts are only executed on the primary nodes. This is because `.sh` scripts support conditional tests to identify the type of node they are running on, while such tests are not supported in `.sql` or `sql.gz` files. - -When using a `.sh` script, you may wish to perform a "one-time" action like creating a database. This can be achieved by adding a condition in the script to ensure that it is executed only on one node, as shown in the example below: - -```yaml -initdbScripts: - my_init_script.sh: | - #!/bin/sh - if [[ $(hostname) == *master* ]]; then - echo "Master node" - mysql -P 3306 -uroot -prandompassword -e "create database new_database"; - else - echo "No master node" - fi -``` - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as MySQL, you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -## Persistence - -The [Bitnami MySQL](https://github.com/bitnami/containers/tree/main/bitnami/mysql) image stores the MySQL data and configurations at the `/bitnami/mysql` path of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning by default. An existing PersistentVolumeClaim can also be defined for this purpose. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -## Network Policy config - -To enable network policy for MySQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`. - -For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting the DefaultDeny namespace annotation. Note: this will enforce policy for _all_ pods in the namespace: - -```console -kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}" -``` - -With NetworkPolicy enabled, traffic will be limited to just port 3306. - -For more precise policy, set `networkPolicy.allowExternal=false`. This will only allow pods with the generated client label to connect to MySQL. -This label will be displayed in the output of a successful install. - -## Pod affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/nats/README.md b/bitnami/nats/README.md index f9919b54c5..3dc70dc455 100644 --- a/bitnami/nats/README.md +++ b/bitnami/nats/README.md @@ -41,15 +41,81 @@ The command deploys NATS 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 -```console -helm delete my-release +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. + +### Add extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod 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. ## Parameters @@ -302,99 +368,12 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/nats > 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/nats/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. - -### Add extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod 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. - ## 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). ## Upgrading -## Deploy chart with NATS version 1.x.x - -NATS version 2.0.0 has renamed the server binary filename from `gnatsd` to `nats-server`. Therefore, the default values has been changed in the chart, -however, it is still possible to use the chart to deploy NATS version 1.x.x using the `natsFilename` property. - -```console -helm install nats-v1 --set natsFilename=gnatsd --set image.tag=1.4.1 oci://REGISTRY_NAME/REPOSITORY_NAME/nats -``` - -> 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`. - ### To 7.0.0 This new version updates the NATS image to a [new version that has support to configure NATS based on bash logic](https://github.com/bitnami/containers/tree/main/bitnami/nats#264-r13), although this chart overwrites the configuration file so that shouldn't affect the functionality. It also adds several standardizations that were missing in the chart: @@ -428,6 +407,17 @@ Consequences: [On November 13, 2020, Helm v2 support formally ended](https://github.com/helm/charts#status-of-the-project). This major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL. +### Deploy chart with NATS version 1.x.x + +NATS version 2.0.0 has renamed the server binary filename from `gnatsd` to `nats-server`. Therefore, the default values has been changed in the chart, +however, it is still possible to use the chart to deploy NATS version 1.x.x using the `natsFilename` property. + +```console +helm install nats-v1 --set natsFilename=gnatsd --set image.tag=1.4.1 oci://REGISTRY_NAME/REPOSITORY_NAME/nats +``` + +> 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`. + ### To 1.0.0 Backwards compatibility is not guaranteed unless you modify the labels used on the chart's deployments. diff --git a/bitnami/nginx-ingress-controller/README.md b/bitnami/nginx-ingress-controller/README.md index 35cd0977e0..a9f309dd26 100644 --- a/bitnami/nginx-ingress-controller/README.md +++ b/bitnami/nginx-ingress-controller/README.md @@ -43,15 +43,55 @@ These commands deploy nginx-ingress-controller on the Kubernetes cluster in the > **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 -```console -helm delete my-release +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. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the NGINX Ingress Controller (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### 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. ## Parameters @@ -385,63 +425,13 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/nginx > 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/nginx-ingress-controller/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. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the NGINX Ingress Controller (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### 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. - ## 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). -## Notable changes +## Upgrading -### 10.0.0 +### To 10.0.0 This major version changes the default parameters so it can be run in Pod Security Admission restricted mode: @@ -454,12 +444,6 @@ In order to restore the configuration from versions < 10.0.0, set the following - `containerPorts.https=443` - `containerSecurityContext.allowPrivilegeEscalation=true` -### 5.3.0 - -In this version you can indicate the key to download the GeoLite2 databases using the [parameter](#parameters) `maxmindLicenseKey`. - -## Upgrading - ### To 9.0.0 - Configuration for routing `Ingress` resources with custom `kubernetes.io/ingress.class` annotation is changed in favor of `IngressClass` resource required in NGINX Ingress Controller 1.x @@ -505,6 +489,10 @@ Consequences: - - +### 5.3.0 + +In this version you can indicate the key to download the GeoLite2 databases using the [parameter](#parameters) `maxmindLicenseKey`. + ### To 1.0.0 Backwards compatibility is not guaranteed unless you modify the labels used on the chart's deployments. diff --git a/bitnami/nginx/README.md b/bitnami/nginx/README.md index a447b7cc72..bb178c47e3 100644 --- a/bitnami/nginx/README.md +++ b/bitnami/nginx/README.md @@ -43,15 +43,95 @@ These commands deploy NGINX Open Source on the Kubernetes cluster in the default > **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. + +### Use a different NGINX version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Deploying your custom web application + +The NGINX chart allows you to deploy a custom web application using one of the following methods: + +- Cloning from a git repository: Set `cloneStaticSiteFromGit.enabled` to `true` and set the repository and branch using the `cloneStaticSiteFromGit.repository` and `cloneStaticSiteFromGit.branch` parameters. A sidecar will also pull the latest changes in an interval set by `cloneStaticSitesFromGit.interval`. +- Providing a ConfigMap: Set the `staticSiteConfigmap` value to mount a ConfigMap in the NGINX html folder. +- Using an existing PVC: Set the `staticSitePVC` value to mount an PersistentVolumeClaim with the static site content. + +You can deploy a example web application using git deploying the chart with the following parameters: ```console -helm delete my-release +cloneStaticSiteFromGit.enabled=true +cloneStaticSiteFromGit.repository=https://github.com/mdn/beginner-html-site-styled.git +cloneStaticSiteFromGit.branch=master ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### Providing a custom server block + +This helm chart supports using custom custom server block for NGINX to use. + +You can use the `serverBlock` value to provide a custom server block for NGINX to use. To do this, create a values files with your server block and install the chart using it: + +```yaml +serverBlock: |- + server { + listen 0.0.0.0:8080; + location / { + return 200 "hello!"; + } + } +``` + +> Warning: The above example is not compatible with enabling Prometheus metrics since it affects the `/status` endpoint. + +In addition, you can also set an external ConfigMap with the configuration file. This is done by setting the `existingServerBlockConfigmap` parameter. Note that this will override the previous option. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### 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#affinity) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters. + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### 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. + +To enable ingress integration, please set `ingress.enabled` to `true`. + +#### Hosts + +Most likely you will only want to have one hostname that maps to this NGINX installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. ## Parameters @@ -319,96 +399,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/nginx > 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/nginx/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. - -### Use a different NGINX version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Deploying your custom web application - -The NGINX chart allows you to deploy a custom web application using one of the following methods: - -- Cloning from a git repository: Set `cloneStaticSiteFromGit.enabled` to `true` and set the repository and branch using the `cloneStaticSiteFromGit.repository` and `cloneStaticSiteFromGit.branch` parameters. A sidecar will also pull the latest changes in an interval set by `cloneStaticSitesFromGit.interval`. -- Providing a ConfigMap: Set the `staticSiteConfigmap` value to mount a ConfigMap in the NGINX html folder. -- Using an existing PVC: Set the `staticSitePVC` value to mount an PersistentVolumeClaim with the static site content. - -You can deploy a example web application using git deploying the chart with the following parameters: - -```console -cloneStaticSiteFromGit.enabled=true -cloneStaticSiteFromGit.repository=https://github.com/mdn/beginner-html-site-styled.git -cloneStaticSiteFromGit.branch=master -``` - -### Providing a custom server block - -This helm chart supports using custom custom server block for NGINX to use. - -You can use the `serverBlock` value to provide a custom server block for NGINX to use. To do this, create a values files with your server block and install the chart using it: - -```yaml -serverBlock: |- - server { - listen 0.0.0.0:8080; - location / { - return 200 "hello!"; - } - } -``` - -> Warning: The above example is not compatible with enabling Prometheus metrics since it affects the `/status` endpoint. - -In addition, you can also set an external ConfigMap with the configuration file. This is done by setting the `existingServerBlockConfigmap` parameter. Note that this will override the previous option. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### 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#affinity) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters. - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### 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. - -To enable ingress integration, please set `ingress.enabled` to `true`. - -#### Hosts - -Most likely you will only want to have one hostname that maps to this NGINX installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. - ## 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). @@ -491,15 +481,6 @@ Use the workaround below to upgrade from versions previous to 1.0.0. The followi kubectl patch deployment nginx --type=json -p='[{"op": "remove", "path": "/spec/selector/matchLabels/chart"}]' ``` -## Bitnami Kubernetes Documentation - -Bitnami Kubernetes documentation is available at [https://docs.bitnami.com/](https://docs.bitnami.com/). You can find there the following resources: - -- [Documentation for NGINX Helm chart](https://github.com/bitnami/charts/tree/main/bitnami/nginx) -- [Get Started with Kubernetes guides](https://docs.bitnami.com/kubernetes/) -- [Kubernetes FAQs](https://docs.bitnami.com/kubernetes/faq/) -- [Kubernetes Developer guides](https://docs.bitnami.com/tutorials/) - ## License Copyright © 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. diff --git a/bitnami/node-exporter/README.md b/bitnami/node-exporter/README.md index c2a5709fb9..70ee153de5 100644 --- a/bitnami/node-exporter/README.md +++ b/bitnami/node-exporter/README.md @@ -39,15 +39,25 @@ helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/node-exporter The command deploys Node Exporter on the Kubernetes cluster in the default configuration. The [configuration](#configuration-and-installation-details) section lists the parameters that can be configured during installation. -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` release: +### Resource requests and limits -```console -helm delete my-release -``` +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. -The command removes all the Kubernetes components associated with the chart and deletes the release. +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. + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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. ## Parameters @@ -211,26 +221,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/node- > 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/node-exporter/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. - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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. - ## 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). diff --git a/bitnami/oauth2-proxy/README.md b/bitnami/oauth2-proxy/README.md index a4784dbfb8..2724db8d13 100644 --- a/bitnami/oauth2-proxy/README.md +++ b/bitnami/oauth2-proxy/README.md @@ -45,15 +45,91 @@ The command deploys OAuth2 Proxy on the Kubernetes cluster in the default config > **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 -```console -helm delete my-release +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. + +### 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. + +To enable Ingress integration, set `ingress.enabled` to `true`. The `ingress.hostname` property can be used to set the host name. The `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. + +### TLS secrets + +The chart also facilitates the creation of TLS secrets for use with the Ingress controller, with different options for certificate management. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as OAuth2 Proxy (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 OAuth2 Proxy](https://github.com/bitnami/containers/tree/main/bitnami/oauth2-proxy) image stores the OAuth2 Proxy data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. ## Parameters @@ -291,92 +367,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/oauth > 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/oauth2-proxy/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. - -### 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. - -To enable Ingress integration, set `ingress.enabled` to `true`. The `ingress.hostname` property can be used to set the host name. The `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. - -### TLS secrets - -The chart also facilitates the creation of TLS secrets for use with the Ingress controller, with different options for certificate management. - -## Persistence - -The [Bitnami OAuth2 Proxy](https://github.com/bitnami/containers/tree/main/bitnami/oauth2-proxy) image stores the OAuth2 Proxy data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as OAuth2 Proxy (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/odoo/README.md b/bitnami/odoo/README.md index d549866d16..26c409bdd6 100644 --- a/bitnami/odoo/README.md +++ b/bitnami/odoo/README.md @@ -45,16 +45,66 @@ The command deploys Odoo 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. + +### Use a different Odoo version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Using an external database + +Sometimes you may want to have Odoo connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#parameters). You should also disable the PostgreSQL installation with the `postgresql.enabled` option. For example using the following parameters: ```console -helm delete my-release +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.port=3306 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. -> If persistence.resourcePolicy is set to keep, you should manually delete the PVCs. +Note also if you disable PostgreSQL per above you MUST supply values for the `externalDatabase` connection. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Odoo, you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +### 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 Odoo](https://github.com/bitnami/containers/tree/main/bitnami/odoo) image stores the Odoo data and configurations at the `/bitnami/odoo` 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. ## Parameters @@ -316,67 +366,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/odoo > 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/odoo/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. - -### Use a different Odoo version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Using an external database - -Sometimes you may want to have Odoo connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#parameters). You should also disable the PostgreSQL installation with the `postgresql.enabled` option. For example using the following parameters: - -```console -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.port=3306 -``` - -Note also if you disable PostgreSQL per above you MUST supply values for the `externalDatabase` connection. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Odoo, you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -### 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 Odoo](https://github.com/bitnami/containers/tree/main/bitnami/odoo) image stores the Odoo data and configurations at the `/bitnami/odoo` 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. - ## 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). diff --git a/bitnami/opencart/README.md b/bitnami/opencart/README.md index 782a379110..791d2e0803 100644 --- a/bitnami/opencart/README.md +++ b/bitnami/opencart/README.md @@ -45,15 +45,83 @@ The command deploys OpenCart on the Kubernetes cluster in the default configurat > **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 OpenCart](https://github.com/bitnami/containers/tree/main/bitnami/opencart) image stores the OpenCart data and configurations at the `/bitnami/opencart` 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/prestashop ``` -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/prestashop + ``` + + > 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 `prestashop-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 PrestaShop file directory permissions yourself and disable or clear PrestaShop cache. ## Parameters @@ -343,84 +411,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/openc > 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/opencart/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 OpenCart](https://github.com/bitnami/containers/tree/main/bitnami/opencart) image stores the OpenCart data and configurations at the `/bitnami/opencart` 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/prestashop -``` - -> 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/prestashop - ``` - - > 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 `prestashop-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 PrestaShop file directory permissions yourself and disable or clear PrestaShop cache. - ## 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). diff --git a/bitnami/opensearch/README.md b/bitnami/opensearch/README.md index d5a2b58dba..a9b1a85272 100644 --- a/bitnami/opensearch/README.md +++ b/bitnami/opensearch/README.md @@ -42,20 +42,119 @@ These commands deploy OpenSearch on the Kubernetes cluster in the default config > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` release: +### Resource requests and limits -```console -helm delete my-release +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. + +### Change OpenSearch version + +To modify the OpenSearch version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/opensearch/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. + +### Default kernel settings + +Currently, OpenSearch requires some changes in the kernel of the host machine to work as expected. If those values are not set in the underlying operating system, the OS containers fail to boot with ERROR messages. More information about these requirements can be found in the links below: + +- [File Descriptor requirements](https://www.open.co/guide/en/opensearch/reference/current/file-descriptors.html) +- [Virtual memory requirements](https://www.open.co/guide/en/opensearch/reference/current/vm-max-map-count.html) + +This chart uses a **privileged** initContainer to change those settings in the Kernel by running: `sysctl -w vm.max_map_count=262144 && sysctl -w fs.file-max=65536`. +You can disable the initContainer using the `sysctlImage.enabled=false` parameter. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: OPENSEARCH_VERSION + value: 7.0 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Remove also the chart using `--purge` option: +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Using custom init scripts + +For advanced operations, the Bitnami OpenSearch charts allows using custom init scripts that will be mounted inside `/docker-entrypoint.init-db`. You can include the file directly in your `values.yaml` with `initScripts`, or use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. In this case you use the `initScriptsCM` and `initScriptsSecret` values. ```console -helm delete --purge my-release +initScriptsCM=special-scripts +initScriptsSecret=special-scripts-sensitive ``` +### Snapshot and restore operations + +As it's described in the [official documentation](https://www.open.co/guide/en/opensearch/reference/current/snapshots-register-repository.html#snapshots-filesystem-repository), it's necessary to register a snapshot repository before you can perform snapshot and restore operations. + +This chart allows you to configure OpenSearch to use a shared file system to store snapshots. To do so, you need to mount a RWX volume on every OpenSearch node, and set the parameter `snapshotRepoPath` with the path where the volume is mounted. In the example below, you can find the values to set when using a NFS Persistent Volume: + +```yaml +extraVolumes: + - name: snapshot-repository + nfs: + server: nfs.example.com # Please change this to your NFS server + path: /share1 +extraVolumeMounts: + - name: snapshot-repository + mountPath: /snapshots +snapshotRepoPath: "/snapshots" +``` + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as OpenSearch components (e.g. an additional metrics or logging exporter), you can do so via the `XXX.sidecars` parameter(s), where XXX is placeholder you need to replace with the actual component(s). Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname +``` + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami OpenSearch](https://github.com/bitnami/containers/tree/main/bitnami/opensearch) image stores the OpenSearch data at the `/bitnami/opensearch/data` path of the container. + +By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. See the [Parameters](#parameters) section to configure the PVC. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + ## Parameters ### Global parameters @@ -836,119 +935,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/opens > 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/opensearch/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. - -### Change OpenSearch version - -To modify the OpenSearch version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/opensearch/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters. - -### Default kernel settings - -Currently, OpenSearch requires some changes in the kernel of the host machine to work as expected. If those values are not set in the underlying operating system, the OS containers fail to boot with ERROR messages. More information about these requirements can be found in the links below: - -- [File Descriptor requirements](https://www.open.co/guide/en/opensearch/reference/current/file-descriptors.html) -- [Virtual memory requirements](https://www.open.co/guide/en/opensearch/reference/current/vm-max-map-count.html) - -This chart uses a **privileged** initContainer to change those settings in the Kernel by running: `sysctl -w vm.max_map_count=262144 && sysctl -w fs.file-max=65536`. -You can disable the initContainer using the `sysctlImage.enabled=false` parameter. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: OPENSEARCH_VERSION - value: 7.0 -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Using custom init scripts - -For advanced operations, the Bitnami OpenSearch charts allows using custom init scripts that will be mounted inside `/docker-entrypoint.init-db`. You can include the file directly in your `values.yaml` with `initScripts`, or use a ConfigMap or a Secret (in case of sensitive data) for mounting these extra scripts. In this case you use the `initScriptsCM` and `initScriptsSecret` values. - -```console -initScriptsCM=special-scripts -initScriptsSecret=special-scripts-sensitive -``` - -### Snapshot and restore operations - -As it's described in the [official documentation](https://www.open.co/guide/en/opensearch/reference/current/snapshots-register-repository.html#snapshots-filesystem-repository), it's necessary to register a snapshot repository before you can perform snapshot and restore operations. - -This chart allows you to configure OpenSearch to use a shared file system to store snapshots. To do so, you need to mount a RWX volume on every OpenSearch node, and set the parameter `snapshotRepoPath` with the path where the volume is mounted. In the example below, you can find the values to set when using a NFS Persistent Volume: - -```yaml -extraVolumes: - - name: snapshot-repository - nfs: - server: nfs.example.com # Please change this to your NFS server - path: /share1 -extraVolumeMounts: - - name: snapshot-repository - mountPath: /snapshots -snapshotRepoPath: "/snapshots" -``` - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as OpenSearch components (e.g. an additional metrics or logging exporter), you can do so via the `XXX.sidecars` parameter(s), where XXX is placeholder you need to replace with the actual component(s). Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname -``` - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -## Persistence - -The [Bitnami OpenSearch](https://github.com/bitnami/containers/tree/main/bitnami/opensearch) image stores the OpenSearch data at the `/bitnami/opensearch/data` path of the container. - -By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. See the [Parameters](#parameters) section to configure the PVC. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/parse/README.md b/bitnami/parse/README.md index d3feba13e3..67c49bff73 100644 --- a/bitnami/parse/README.md +++ b/bitnami/parse/README.md @@ -43,15 +43,85 @@ The command deploys Parse 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 -```console -helm delete my-release +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. + +### Deploy your Cloud functions with Parse Cloud Code + +The [Bitnami Parse](https://github.com/bitnami/containers/tree/main/bitnami/parse) image allows you to deploy your Cloud functions with Parse Cloud Code (a feature which allows running a piece of code in your Parse Server instead of the user's mobile devices). In order to add your custom scripts, they must be located inside the chart folder `files/cloud` so they can be consumed as a ConfigMap. + +Alternatively, you can specify custom scripts using the `cloudCodeScripts` parameter as dict. + +In addition to these options, you can also set an external ConfigMap with all the Cloud Code scripts. This is done by setting the `existingCloudCodeScriptsCM` parameter. Note that this will override the two previous options. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` (available in the `server` and `dashboard` sections) property. + +```yaml +extraEnvVars: + - name: PARSE_SERVER_ALLOW_CLIENT_CLASS_CREATION + value: true ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such as KongPlugins, KongConsumers, amongst others. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would activate a plugin at deployment time. + +```yaml +## Extra objects to deploy (value evaluated as a template) +## +extraDeploy: |- + - apiVersion: rbac.authorization.k8s.io/v1 + kind: RoleBinding + metadata: + name: {{ include "common.names.fullname" . }}-privileged + namespace: {{ .Release.Namespace }} + labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} + roleRef: + apiGroup: rbac.authorization.k8s.io + kind: ClusterRole + name: cluster-admin + subjects: + - kind: ServiceAccount + name: default + namespace: {{ .Release.Namespace }} +``` + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` paremeter(s). Find more infomation 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami Parse](https://github.com/bitnami/containers/tree/main/bitnami/parse) image stores the Parse data and configurations at the `/bitnami/parse` 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. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -384,86 +454,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/parse > 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/parse/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. - -### Deploy your Cloud functions with Parse Cloud Code - -The [Bitnami Parse](https://github.com/bitnami/containers/tree/main/bitnami/parse) image allows you to deploy your Cloud functions with Parse Cloud Code (a feature which allows running a piece of code in your Parse Server instead of the user's mobile devices). In order to add your custom scripts, they must be located inside the chart folder `files/cloud` so they can be consumed as a ConfigMap. - -Alternatively, you can specify custom scripts using the `cloudCodeScripts` parameter as dict. - -In addition to these options, you can also set an external ConfigMap with all the Cloud Code scripts. This is done by setting the `existingCloudCodeScriptsCM` parameter. Note that this will override the two previous options. - -## Persistence - -The [Bitnami Parse](https://github.com/bitnami/containers/tree/main/bitnami/parse) image stores the Parse data and configurations at the `/bitnami/parse` 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. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` (available in the `server` and `dashboard` sections) property. - -```yaml -extraEnvVars: - - name: PARSE_SERVER_ALLOW_CLIENT_CLASS_CREATION - value: true -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such as KongPlugins, KongConsumers, amongst others. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. The following example would activate a plugin at deployment time. - -```yaml -## Extra objects to deploy (value evaluated as a template) -## -extraDeploy: |- - - apiVersion: rbac.authorization.k8s.io/v1 - kind: RoleBinding - metadata: - name: {{ include "common.names.fullname" . }}-privileged - namespace: {{ .Release.Namespace }} - labels: {{- include "common.labels.standard" ( dict "customLabels" .Values.commonLabels "context" $ ) | nindent 6 }} - roleRef: - apiGroup: rbac.authorization.k8s.io - kind: ClusterRole - name: cluster-admin - subjects: - - kind: ServiceAccount - name: default - namespace: {{ .Release.Namespace }} -``` - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` paremeter(s). Find more infomation 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/phpbb/README.md b/bitnami/phpbb/README.md index 1a205215f0..fa0a4c0881 100644 --- a/bitnami/phpbb/README.md +++ b/bitnami/phpbb/README.md @@ -45,15 +45,75 @@ The command deploys phpBB 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. + +### Ingress without TLS + +For using ingress (example without TLS): ```console -helm delete my-release +ingress.enabled=True +ingress.hosts[0]=phpbb.domain.com +serviceType=ClusterIP +phpbbUsername=admin +phpbbPassword=password +mariadb.mariadbRootPassword=secretpassword ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +These are the *3 mandatory parameters* when *Ingress* is desired: `ingress.enabled=True`, `ingress.hosts[0]=phpbb.domain.com` and `serviceType=ClusterIP` + +### Ingress TLS + +If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. + +To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `phpbb-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: + +```yaml +ingress: + ## If true, phpBB server Ingress will be created + ## + enabled: true + + ## phpBB server Ingress annotations + ## + annotations: {} + # kubernetes.io/ingress.class: nginx + # kubernetes.io/tls-acme: 'true' + + ## phpBB server Ingress hostnames + ## Must be provided if Ingress is enabled + ## + hosts: + - phpbb.domain.com + + ## phpBB server Ingress TLS configuration + ## Secrets must be manually created in the namespace + ## + tls: + - secretName: phpbb-server-tls + hosts: + - phpbb.domain.com +``` + +## Persistence + +The [Bitnami phpBB](https://github.com/bitnami/containers/tree/main/bitnami/phpbb) image stores the phpBB data and configurations at the `/bitnami/phpbb` and `/bitnami/apache` paths of the container. + +Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, vpshere, and minikube. +See the [Parameters](#parameters) section to configure the PVC or to disable persistence. +You may want to review the [PV reclaim policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) and update as required. By default, it's set to delete, and when phpBB is uninstalled, data is also removed. ## Parameters @@ -298,76 +358,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/phpbb > 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/phpbb/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. - -### Ingress without TLS - -For using ingress (example without TLS): - -```console -ingress.enabled=True -ingress.hosts[0]=phpbb.domain.com -serviceType=ClusterIP -phpbbUsername=admin -phpbbPassword=password -mariadb.mariadbRootPassword=secretpassword -``` - -These are the *3 mandatory parameters* when *Ingress* is desired: `ingress.enabled=True`, `ingress.hosts[0]=phpbb.domain.com` and `serviceType=ClusterIP` - -### Ingress TLS - -If your cluster allows automatic creation/retrieval of TLS certificates (e.g. [kube-lego](https://github.com/jetstack/kube-lego)), please refer to the documentation for that mechanism. - -To manually configure TLS, first create/retrieve a key & certificate pair for the address(es) you wish to protect. Then create a TLS secret (named `phpbb-server-tls` in this example) in the namespace. Include the secret's name, along with the desired hostnames, in the Ingress TLS section of your custom `values.yaml` file: - -```yaml -ingress: - ## If true, phpBB server Ingress will be created - ## - enabled: true - - ## phpBB server Ingress annotations - ## - annotations: {} - # kubernetes.io/ingress.class: nginx - # kubernetes.io/tls-acme: 'true' - - ## phpBB server Ingress hostnames - ## Must be provided if Ingress is enabled - ## - hosts: - - phpbb.domain.com - - ## phpBB server Ingress TLS configuration - ## Secrets must be manually created in the namespace - ## - tls: - - secretName: phpbb-server-tls - hosts: - - phpbb.domain.com -``` - -## Persistence - -The [Bitnami phpBB](https://github.com/bitnami/containers/tree/main/bitnami/phpbb) image stores the phpBB data and configurations at the `/bitnami/phpbb` and `/bitnami/apache` paths of the container. - -Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, vpshere, and minikube. -See the [Parameters](#parameters) section to configure the PVC or to disable persistence. -You may want to review the [PV reclaim policy](https://kubernetes.io/docs/tasks/administer-cluster/change-pv-reclaim-policy/) and update as required. By default, it's set to delete, and when phpBB is uninstalled, data is also removed. - ## 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). diff --git a/bitnami/phpmyadmin/README.md b/bitnami/phpmyadmin/README.md index 66c2155462..90542581ea 100644 --- a/bitnami/phpmyadmin/README.md +++ b/bitnami/phpmyadmin/README.md @@ -43,15 +43,118 @@ The command deploys phpMyAdmin on the Kubernetes cluster in the default configur > **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 -```console -helm delete my-release +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. + +### 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. + +To enable ingress integration, please set `ingress.enabled` to `true`. + +#### Hosts + +Most likely you will only want to have one hostname that maps to this phpMyAdmin installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. + +### TLS Secrets + +This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are some common use cases: + +- Helm generates and manages certificate secrets (default). +- User generates certificates and helm manages secrets. +- User generates and manages certificates separately. +- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. + +In the second case, a certificate and a key are needed. We would expect them to look like this: + +- certificate files should look like (and there can be more than one certificate if there is a certificate chain) + + ```console + -----BEGIN CERTIFICATE----- + MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV + ... + jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 + -----END CERTIFICATE----- + ``` + +- keys should look like: + + ```console + -----BEGIN RSA PRIVATE KEY----- + MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 + ... + wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= + -----END RSA PRIVATE KEY----- + ``` + +If you are going to generate certificates yourself and want helm to manage the secret, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. + +If you want to manage TLS secrets outside of Helm, please know that you can create a TLS secret and pass its name via the parameter `ingress.existingSecretName`. + +To make use of cert-manager, you need to add the the `cert-manager.io/cluster-issuer:` annotation to the ingress object via `ingress.annotations`. + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as the PhpMyAdmin app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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`, `XpodAntiAffinityPreset`, or `nodeAffinityPreset` parameters. ## Parameters @@ -295,119 +398,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/phpmy > 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/phpmyadmin/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. - -### 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. - -To enable ingress integration, please set `ingress.enabled` to `true`. - -#### Hosts - -Most likely you will only want to have one hostname that maps to this phpMyAdmin installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. - -### TLS Secrets - -This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are some common use cases: - -- Helm generates and manages certificate secrets (default). -- User generates certificates and helm manages secrets. -- User generates and manages certificates separately. -- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. - -In the second case, a certificate and a key are needed. We would expect them to look like this: - -- certificate files should look like (and there can be more than one certificate if there is a certificate chain) - - ```console - -----BEGIN CERTIFICATE----- - MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV - ... - jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 - -----END CERTIFICATE----- - ``` - -- keys should look like: - - ```console - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 - ... - wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= - -----END RSA PRIVATE KEY----- - ``` - -If you are going to generate certificates yourself and want helm to manage the secret, please copy these values into the `certificate` and `key` values for a given `ingress.secrets` entry. - -If you want to manage TLS secrets outside of Helm, please know that you can create a TLS secret and pass its name via the parameter `ingress.existingSecretName`. - -To make use of cert-manager, you need to add the the `cert-manager.io/cluster-issuer:` annotation to the ingress object via `ingress.annotations`. - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as the PhpMyAdmin app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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`, `XpodAntiAffinityPreset`, or `nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/pinniped/README.md b/bitnami/pinniped/README.md index 8f982349e8..a061d7b57a 100644 --- a/bitnami/pinniped/README.md +++ b/bitnami/pinniped/README.md @@ -43,15 +43,82 @@ The command deploys pinniped on the Kubernetes cluster in the default configurat > **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 -```console -helm delete my-release +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. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +pinniped: + extraEnvVars: + - name: LOG_LEVEL + value: error ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as pinniped (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 pinniped](https://github.com/bitnami/containers/tree/main/bitnami/pinniped) image stores the pinniped data and configurations at the `/bitnami` 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. ## Parameters @@ -370,83 +437,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/pinni > 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/pinniped/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. - -## Persistence - -The [Bitnami pinniped](https://github.com/bitnami/containers/tree/main/bitnami/pinniped) image stores the pinniped data and configurations at the `/bitnami` 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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -pinniped: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as pinniped (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/postgresql-ha/README.md b/bitnami/postgresql-ha/README.md index 76f9c35959..4483dc0c27 100644 --- a/bitnami/postgresql-ha/README.md +++ b/bitnami/postgresql-ha/README.md @@ -55,15 +55,255 @@ helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/postgresql-ha > 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`. -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` deployment: +### Resource requests and limits -```console -helm delete --purge my-release +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. + +### Use a different PostgreSQL version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Use a volume for /dev/shm + +When working with huge databeses, `/dev/shm` can run out of space. A way to fix this is to use the `postgresql.extraVolumes` and `postgresql.extraVolumeMounts` values. In the example below, we set an `emptyDir` volume with 512Mb: + +```yaml +postgresql: + extraVolumes: + - name: dshm + emptyDir: + medium: Memory + sizeLimit: 512Mi + extraVolumeMounts: + - name: dshm + mountPath: /dev/shm ``` -Additionally, if `persistence.resourcePolicy` is set to `keep`, you should manually delete the PVCs. +### Configure the way how to expose PostgreSQL + +- **ClusterIP**: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. Set `service.type=ClusterIP` to choose this service type. +- **NodePort**: Exposes the service on each Node's IP at a static port (the NodePort). You will be able to contact the NodePort service, from outside the cluster, by requesting `NodeIP:NodePort`. Set `service.type=NodePort` to choose this service type. +- **LoadBalancer**: Exposes the service externally using a cloud provider's load balancer. Set `service.type=LoadBalancer` to choose this service type. + +### Adjust permissions of persistent volume mountpoint + +As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + +### LDAP + +LDAP support can be enabled in the chart by specifying the `ldap.` parameters while creating a release. The following parameters should be configured to properly enable the LDAP support in the chart. + +- **ldap.enabled**: Enable LDAP support. Defaults to `false`. +- **ldap.uri**: LDAP URL beginning in the form `ldap[s]://:`. No defaults. +- **ldap.base**: LDAP base DN. No defaults. +- **ldap.binddn**: LDAP bind DN. No defaults. +- **ldap.bindpw**: LDAP bind password. No defaults. +- **ldap.bslookup**: LDAP base lookup. No defaults. +- **ldap.nss_initgroups_ignoreusers**: LDAP ignored users. `root,nslcd`. +- **ldap.scope**: LDAP search scope. No defaults. +- **ldap.tls_reqcert**: LDAP TLS check on server certificates. No defaults. + +For example: + +```text +ldap.enabled="true" +ldap.uri="ldap://my_ldap_server" +ldap.base="dc=example\,dc=org" +ldap.binddn="cn=admin\,dc=example\,dc=org" +ldap.bindpw="admin" +ldap.bslookup="ou=group-ok\,dc=example\,dc=org" +ldap.nss_initgroups_ignoreusers="root\,nslcd" +ldap.scope="sub" +ldap.tls_reqcert="demand" +``` + +Next, login to the PostgreSQL server using the `psql` client and add the PAM authenticated LDAP users. + +> Note: Parameters including commas must be escaped as shown in the above example. + +### Securing traffic using TLS + +The chart handles two main flows of traffic information: + +- Connections between end-clients and PgPool (sometimes referred to as *frontend* connections). +- Internal connections between PgPool and PostgreSQL nodes (sometimes referred to as *backend* connections). + +The Bitnami postgresql-ha chart allows configuring the securitization of both types of traffic using TLS. + +#### Encrypt traffic between clients and Pgpool (frontend) + +TLS for end-client connections can be enabled in the chart by specifying the `pgpool.tls.*` parameters when installing a release. Below you can find detailed information about these parameters: + +- `pgpool.tls.enabled`: Enable TLS support. Defaults to `false`. +- `pgpool.tls.certificatesSecret`: Name of an existing secret that contains the certificates. No defaults. +- `pgpool.tls.certFilename`: Certificate filename. No defaults. +- `pgpool.tls.certKeyFilename`: Certificate key filename. No defaults. + +For example: + +- First, create a secret with the certificates files. You will need to generate previously the certificate files: + + ```console + kubectl create secret generic pgpool-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt + ``` + +> Note: Although certificate generation is out of the scope of this guide, bear in mind that PostgreSQL requires that server TLS certificates specify the actual DNS server name in the CN (Common Name) field. + +- Then, install the chart using the following parameters: + + ```console + pgpool.tls.enabled=true + pgpool.tls.certificatesSecret="pgpool-tls-secret" + pgpool.tls.certFilename="cert.crt" + pgpool.tls.certKeyFilename="cert.key" + ``` + +> Note: Certificates permissions: PgPool requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going [issue](https://github.com/kubernetes/kubernetes/issues/57923) regarding K8s permissions and the use of `containerSecurityContext.runAsUser`, an init container will adapt the permissions to ensure everything works as expected. + +##### Enable client certificate authentication + +When TLS is configured for *frontend* connections, the server can be configured to authenticate clients by verifying their provided TLS certificate is valid and trusted. Hence, the client will not be sent a password prompt. + +You can enable this authentication feature additionally specifying the following parameter: + +- `postgresql.tls.certCAFilename`: CA Certificate filename. No defaults. + + ```console + $ psql --host postgresql-ha-pgpool -d "dbname=XXXXX user=YYYYYY sslcert=client.crt sslkey=client.key sslmode=require" + psql (14.4) + SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) + Type "help" for help. + + postgres=> + ``` + +Clients using this method to authenticate will be required to provide a certificate with the CN (Common Name) field matching the requested database user name. Please, refer to [the official documentation](https://www.postgresql.org/docs/current/auth-cert.html) for further information. + +> Note: As with traditional password-based authentication, database users must exist in both PgPool and PostgreSQL nodes and have the correct privileges to connect to a database. You may use the `postgresql.initdbScripts` and `pgpool.customUsers` properties to create them in advance. + +#### Encrypt traffic between Pgpool and PostgreSQL nodes (backend) + +TLS for backend connections can be enabled in the chart by specifying the `postgresql.tls.*` parameters while creating a release. Below you can find detailed information about these parameters: + +- `postgresql.tls.enabled`: Enable TLS support. Defaults to `false` +- `postgresql.tls.certificatesSecret`: Name of an existing secret that contains the certificates. No defaults. +- `postgresql.tls.certFilename`: Certificate filename. No defaults. +- `postgresql.tls.certKeyFilename`: Certificate key filename. No defaults. + +For example: + +- First, create a secret with the certificates files. You will need to generate previously the certificate files: + + ```console + kubectl create secret generic postgresql-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt + ``` + +- Then, install the chart using the following parameters: + + ```console + postgresql.tls.enabled=true + postgresql.tls.certificatesSecret="postgresql-tls-secret" + postgresql.tls.certFilename="cert.crt" + postgresql.tls.certKeyFilename="cert.key" + ``` + +> Note: Certificates permissions: PostgreSQL requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going [issue](https://github.com/kubernetes/kubernetes/issues/57923) regarding K8s permissions and the use of `containerSecurityContext.runAsUser`, an init container will adapt the permissions to ensure everything works as expected. + +If you want to encrypt both *frontend* and *backend* traffics, you may use the same secret for Pgpool and PostgreSQL TLS configuration. + +### repmgr.conf / postgresql.conf / pg_hba.conf / pgpool.conf files as configMap + +This helm chart also supports to customize the whole configuration file. + +You can specify the Pgpool, PostgreSQL and Repmgr configuration using the `pgpool.configuration`, `postgresql.configuration`, `postgresql.pgHbaConfiguration`, and `postgresql.repmgrConfiguration` parameters. The corresponding files will be mounted as ConfigMap to the containers and it will be used for configuring Pgpool, Repmgr and the PostgreSQL server. + +In addition to this option, you can also set an external ConfigMap(s) with all the configuration files. This is done by setting the `postgresql.configurationCM` and `pgpool.configurationCM` parameters. Note that this will override the previous options. + +### Allow settings to be loaded from files other than the default `postgresql.conf` + +If you don't want to provide the whole PostgreSQL configuration file and only specify certain parameters, you can specify the extended configuration using the `postgresql.extendedConf` parameter. A file will be mounted as configMap to the containers adding/overwriting the default configuration using the `include_dir` directive that allows settings to be loaded from files other than the default `postgresql.conf`. + +In addition to this option, you can also set an external ConfigMap with all the extra configuration files. This is done by setting the `postgresql.extendedConfCM` parameter. Note that this will override the previous option. + +### Initialize a fresh instance + +The [Bitnami PostgreSQL with Repmgr](https://github.com/bitnami/containers/tree/main/bitnami/postgresql-repmgr) image allows you to use your custom scripts to initialize a fresh instance. You can specify custom scripts using the `initdbScripts` parameter as dict so they can be consumed as a ConfigMap. + +In addition to this option, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `initdbScriptsCM` parameter. Note that this will override the two previous options. If your initialization scripts contain sensitive information such as credentials or passwords, you can use the `initdbScriptsSecret` parameter. + +The above parameters (`initdbScripts`, `initdbScriptsCM`, and `initdbScriptsSecret`) are supported in both StatefulSet by prepending `postgresql` or `pgpool` to the parameter, depending on the use case (see above parameters table). + +The allowed extensions are `.sh`, `.sql` and `.sql.gz` in the **postgresql** container while only `.sh` in the case of the **pgpool** one. + ++info: and + +### Use of global variables + +In more complex scenarios, we may have the following tree of dependencies + +```text + +--------------+ + | | + +------------+ Chart 1 +-----------+ + | | | | + | --------+------+ | + | | | + | | | + | | | + | | | + v v v ++-------+------+ +--------+------+ +--------+------+ +| | | | | | +| PostgreSQL HA | | Sub-chart 1 | | Sub-chart 2 | +|---------------|--|-------------|--|-------------| ++--------------+ +---------------+ +---------------+ +``` + +The three charts below depend on the parent chart Chart 1. However, subcharts 1 and 2 may need to connect to PostgreSQL HA as well. In order to do so, subcharts 1 and 2 need to know the PostgreSQL HA credentials, so one option for deploying could be deploy Chart 1 with the following parameters: + +```text +postgresql.postgresqlPassword=testtest +subchart1.postgresql.postgresqlPassword=testtest +subchart2.postgresql.postgresqlPassword=testtest +postgresql.postgresqlDatabase=db1 +subchart1.postgresql.postgresqlDatabase=db1 +subchart2.postgresql.postgresqlDatabase=db1 +``` + +If the number of dependent sub-charts increases, installing the chart with parameters can become increasingly difficult. An alternative would be to set the credentials using global variables as follows: + +```text +global.postgresql.postgresqlPassword=testtest +global.postgresql.postgresqlDatabase=db1 +``` + +This way, the credentials will be available in all of the subcharts. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` paremeter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The data is persisted by default using PVC templates in the PostgreSQL statefulset. You can disable the persistence setting the `persistence.enabled` parameter to `false`. +A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `persistence.storageClass` or set `persistence.existingClaim` if you have already existing persistent volumes to use. ## Parameters @@ -699,256 +939,6 @@ helm install my-release \ bitnami/postgresql-ha ``` -## 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. - -### Use a different PostgreSQL version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Use a volume for /dev/shm - -When working with huge databeses, `/dev/shm` can run out of space. A way to fix this is to use the `postgresql.extraVolumes` and `postgresql.extraVolumeMounts` values. In the example below, we set an `emptyDir` volume with 512Mb: - -```yaml -postgresql: - extraVolumes: - - name: dshm - emptyDir: - medium: Memory - sizeLimit: 512Mi - extraVolumeMounts: - - name: dshm - mountPath: /dev/shm -``` - -### Configure the way how to expose PostgreSQL - -- **ClusterIP**: Exposes the service on a cluster-internal IP. Choosing this value makes the service only reachable from within the cluster. Set `service.type=ClusterIP` to choose this service type. -- **NodePort**: Exposes the service on each Node's IP at a static port (the NodePort). You will be able to contact the NodePort service, from outside the cluster, by requesting `NodeIP:NodePort`. Set `service.type=NodePort` to choose this service type. -- **LoadBalancer**: Exposes the service externally using a cloud provider's load balancer. Set `service.type=LoadBalancer` to choose this service type. - -### Adjust permissions of persistent volume mountpoint - -As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### LDAP - -LDAP support can be enabled in the chart by specifying the `ldap.` parameters while creating a release. The following parameters should be configured to properly enable the LDAP support in the chart. - -- **ldap.enabled**: Enable LDAP support. Defaults to `false`. -- **ldap.uri**: LDAP URL beginning in the form `ldap[s]://:`. No defaults. -- **ldap.base**: LDAP base DN. No defaults. -- **ldap.binddn**: LDAP bind DN. No defaults. -- **ldap.bindpw**: LDAP bind password. No defaults. -- **ldap.bslookup**: LDAP base lookup. No defaults. -- **ldap.nss_initgroups_ignoreusers**: LDAP ignored users. `root,nslcd`. -- **ldap.scope**: LDAP search scope. No defaults. -- **ldap.tls_reqcert**: LDAP TLS check on server certificates. No defaults. - -For example: - -```text -ldap.enabled="true" -ldap.uri="ldap://my_ldap_server" -ldap.base="dc=example\,dc=org" -ldap.binddn="cn=admin\,dc=example\,dc=org" -ldap.bindpw="admin" -ldap.bslookup="ou=group-ok\,dc=example\,dc=org" -ldap.nss_initgroups_ignoreusers="root\,nslcd" -ldap.scope="sub" -ldap.tls_reqcert="demand" -``` - -Next, login to the PostgreSQL server using the `psql` client and add the PAM authenticated LDAP users. - -> Note: Parameters including commas must be escaped as shown in the above example. - -### Securing traffic using TLS - -The chart handles two main flows of traffic information: - -- Connections between end-clients and PgPool (sometimes referred to as *frontend* connections). -- Internal connections between PgPool and PostgreSQL nodes (sometimes referred to as *backend* connections). - -The Bitnami postgresql-ha chart allows configuring the securitization of both types of traffic using TLS. - -#### Encrypt traffic between clients and Pgpool (frontend) - -TLS for end-client connections can be enabled in the chart by specifying the `pgpool.tls.*` parameters when installing a release. Below you can find detailed information about these parameters: - -- `pgpool.tls.enabled`: Enable TLS support. Defaults to `false`. -- `pgpool.tls.certificatesSecret`: Name of an existing secret that contains the certificates. No defaults. -- `pgpool.tls.certFilename`: Certificate filename. No defaults. -- `pgpool.tls.certKeyFilename`: Certificate key filename. No defaults. - -For example: - -- First, create a secret with the certificates files. You will need to generate previously the certificate files: - - ```console - kubectl create secret generic pgpool-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt - ``` - -> Note: Although certificate generation is out of the scope of this guide, bear in mind that PostgreSQL requires that server TLS certificates specify the actual DNS server name in the CN (Common Name) field. - -- Then, install the chart using the following parameters: - - ```console - pgpool.tls.enabled=true - pgpool.tls.certificatesSecret="pgpool-tls-secret" - pgpool.tls.certFilename="cert.crt" - pgpool.tls.certKeyFilename="cert.key" - ``` - -> Note: Certificates permissions: PgPool requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going [issue](https://github.com/kubernetes/kubernetes/issues/57923) regarding K8s permissions and the use of `containerSecurityContext.runAsUser`, an init container will adapt the permissions to ensure everything works as expected. - -##### Enable client certificate authentication - -When TLS is configured for *frontend* connections, the server can be configured to authenticate clients by verifying their provided TLS certificate is valid and trusted. Hence, the client will not be sent a password prompt. - -You can enable this authentication feature additionally specifying the following parameter: - -- `postgresql.tls.certCAFilename`: CA Certificate filename. No defaults. - - ```console - $ psql --host postgresql-ha-pgpool -d "dbname=XXXXX user=YYYYYY sslcert=client.crt sslkey=client.key sslmode=require" - psql (14.4) - SSL connection (protocol: TLSv1.3, cipher: TLS_AES_256_GCM_SHA384, bits: 256, compression: off) - Type "help" for help. - - postgres=> - ``` - -Clients using this method to authenticate will be required to provide a certificate with the CN (Common Name) field matching the requested database user name. Please, refer to [the official documentation](https://www.postgresql.org/docs/current/auth-cert.html) for further information. - -> Note: As with traditional password-based authentication, database users must exist in both PgPool and PostgreSQL nodes and have the correct privileges to connect to a database. You may use the `postgresql.initdbScripts` and `pgpool.customUsers` properties to create them in advance. - -#### Encrypt traffic between Pgpool and PostgreSQL nodes (backend) - -TLS for backend connections can be enabled in the chart by specifying the `postgresql.tls.*` parameters while creating a release. Below you can find detailed information about these parameters: - -- `postgresql.tls.enabled`: Enable TLS support. Defaults to `false` -- `postgresql.tls.certificatesSecret`: Name of an existing secret that contains the certificates. No defaults. -- `postgresql.tls.certFilename`: Certificate filename. No defaults. -- `postgresql.tls.certKeyFilename`: Certificate key filename. No defaults. - -For example: - -- First, create a secret with the certificates files. You will need to generate previously the certificate files: - - ```console - kubectl create secret generic postgresql-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt - ``` - -- Then, install the chart using the following parameters: - - ```console - postgresql.tls.enabled=true - postgresql.tls.certificatesSecret="postgresql-tls-secret" - postgresql.tls.certFilename="cert.crt" - postgresql.tls.certKeyFilename="cert.key" - ``` - -> Note: Certificates permissions: PostgreSQL requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going [issue](https://github.com/kubernetes/kubernetes/issues/57923) regarding K8s permissions and the use of `containerSecurityContext.runAsUser`, an init container will adapt the permissions to ensure everything works as expected. - -If you want to encrypt both *frontend* and *backend* traffics, you may use the same secret for Pgpool and PostgreSQL TLS configuration. - -### repmgr.conf / postgresql.conf / pg_hba.conf / pgpool.conf files as configMap - -This helm chart also supports to customize the whole configuration file. - -You can specify the Pgpool, PostgreSQL and Repmgr configuration using the `pgpool.configuration`, `postgresql.configuration`, `postgresql.pgHbaConfiguration`, and `postgresql.repmgrConfiguration` parameters. The corresponding files will be mounted as ConfigMap to the containers and it will be used for configuring Pgpool, Repmgr and the PostgreSQL server. - -In addition to this option, you can also set an external ConfigMap(s) with all the configuration files. This is done by setting the `postgresql.configurationCM` and `pgpool.configurationCM` parameters. Note that this will override the previous options. - -### Allow settings to be loaded from files other than the default `postgresql.conf` - -If you don't want to provide the whole PostgreSQL configuration file and only specify certain parameters, you can specify the extended configuration using the `postgresql.extendedConf` parameter. A file will be mounted as configMap to the containers adding/overwriting the default configuration using the `include_dir` directive that allows settings to be loaded from files other than the default `postgresql.conf`. - -In addition to this option, you can also set an external ConfigMap with all the extra configuration files. This is done by setting the `postgresql.extendedConfCM` parameter. Note that this will override the previous option. - -### Initialize a fresh instance - -The [Bitnami PostgreSQL with Repmgr](https://github.com/bitnami/containers/tree/main/bitnami/postgresql-repmgr) image allows you to use your custom scripts to initialize a fresh instance. You can specify custom scripts using the `initdbScripts` parameter as dict so they can be consumed as a ConfigMap. - -In addition to this option, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `initdbScriptsCM` parameter. Note that this will override the two previous options. If your initialization scripts contain sensitive information such as credentials or passwords, you can use the `initdbScriptsSecret` parameter. - -The above parameters (`initdbScripts`, `initdbScriptsCM`, and `initdbScriptsSecret`) are supported in both StatefulSet by prepending `postgresql` or `pgpool` to the parameter, depending on the use case (see above parameters table). - -The allowed extensions are `.sh`, `.sql` and `.sql.gz` in the **postgresql** container while only `.sh` in the case of the **pgpool** one. - -+info: and - -### Use of global variables - -In more complex scenarios, we may have the following tree of dependencies - -```text - +--------------+ - | | - +------------+ Chart 1 +-----------+ - | | | | - | --------+------+ | - | | | - | | | - | | | - | | | - v v v -+-------+------+ +--------+------+ +--------+------+ -| | | | | | -| PostgreSQL HA | | Sub-chart 1 | | Sub-chart 2 | -|---------------|--|-------------|--|-------------| -+--------------+ +---------------+ +---------------+ -``` - -The three charts below depend on the parent chart Chart 1. However, subcharts 1 and 2 may need to connect to PostgreSQL HA as well. In order to do so, subcharts 1 and 2 need to know the PostgreSQL HA credentials, so one option for deploying could be deploy Chart 1 with the following parameters: - -```text -postgresql.postgresqlPassword=testtest -subchart1.postgresql.postgresqlPassword=testtest -subchart2.postgresql.postgresqlPassword=testtest -postgresql.postgresqlDatabase=db1 -subchart1.postgresql.postgresqlDatabase=db1 -subchart2.postgresql.postgresqlDatabase=db1 -``` - -If the number of dependent sub-charts increases, installing the chart with parameters can become increasingly difficult. An alternative would be to set the credentials using global variables as follows: - -```text -global.postgresql.postgresqlPassword=testtest -global.postgresql.postgresqlDatabase=db1 -``` - -This way, the credentials will be available in all of the subcharts. - -### Persistence - -The data is persisted by default using PVC templates in the PostgreSQL statefulset. You can disable the persistence setting the `persistence.enabled` parameter to `false`. -A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `persistence.storageClass` or set `persistence.existingClaim` if you have already existing persistent volumes to use. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` paremeter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/postgresql/README.md b/bitnami/postgresql/README.md index e05a3dfb7d..ef8b9d4adb 100644 --- a/bitnami/postgresql/README.md +++ b/bitnami/postgresql/README.md @@ -44,23 +44,232 @@ The command deploys PostgreSQL on the Kubernetes cluster in the default configur > **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 -```console -helm delete my-release +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. + +### Customizing primary and read replica services in a replicated configuration + +At the top level, there is a service object which defines the services for both primary and readReplicas. For deeper customization, there are service objects for both the primary and read types individually. This allows you to override the values in the top level service object so that the primary and read can be of different service types and with different clusterIPs / nodePorts. Also in the case you want the primary and read to be of type nodePort, you will need to set the nodePorts to different values to prevent a collision. The values that are deeper in the primary.service or readReplicas.service objects will take precedence over the top level service object. + +### Use a different PostgreSQL version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### LDAP + +LDAP support can be enabled in the chart by specifying the `ldap.` parameters while creating a release. The following parameters should be configured to properly enable the LDAP support in the chart. + +- **ldap.enabled**: Enable LDAP support. Defaults to `false`. +- **ldap.uri**: LDAP URL beginning in the form `ldap[s]://:`. No defaults. +- **ldap.base**: LDAP base DN. No defaults. +- **ldap.binddn**: LDAP bind DN. No defaults. +- **ldap.bindpw**: LDAP bind password. No defaults. +- **ldap.bslookup**: LDAP base lookup. No defaults. +- **ldap.nss_initgroups_ignoreusers**: LDAP ignored users. `root,nslcd`. +- **ldap.scope**: LDAP search scope. No defaults. +- **ldap.tls_reqcert**: LDAP TLS check on server certificates. No defaults. + +For example: + +```text +ldap.enabled="true" +ldap.uri="ldap://my_ldap_server" +ldap.base="dc=example\,dc=org" +ldap.binddn="cn=admin\,dc=example\,dc=org" +ldap.bindpw="admin" +ldap.bslookup="ou=group-ok\,dc=example\,dc=org" +ldap.nss_initgroups_ignoreusers="root\,nslcd" +ldap.scope="sub" +ldap.tls_reqcert="demand" ``` -The command removes all the Kubernetes components but PVC's associated with the chart and deletes the release. +Next, login to the PostgreSQL server using the `psql` client and add the PAM authenticated LDAP users. -To delete the PVC's associated with `my-release`: +> Note: Parameters including commas must be escaped as shown in the above example. -```console -kubectl delete pvc -l release=my-release +### postgresql.conf / pg_hba.conf files as configMap + +This helm chart also supports to customize the PostgreSQL configuration file. You can add additional PostgreSQL configuration parameters using the `primary.extendedConfiguration`/`readReplicas.extendedConfiguration` parameters as a string. Alternatively, to replace the entire default configuration use `primary.configuration`. + +You can also add a custom pg_hba.conf using the `primary.pgHbaConfiguration` parameter. + +In addition to these options, you can also set an external ConfigMap with all the configuration files. This is done by setting the `primary.existingConfigmap` parameter. Note that this will override the two previous options. + +### Initialize a fresh instance + +The [Bitnami PostgreSQL](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, you can specify custom scripts using the `primary.initdb.scripts` parameter as a string. + +In addition, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `primary.initdb.scriptsConfigMap` parameter. Note that this will override the two previous options. If your initialization scripts contain sensitive information such as credentials or passwords, you can use the `primary.initdb.scriptsSecret` parameter. + +The allowed extensions are `.sh`, `.sql` and `.sql.gz`. + +### Securing traffic using TLS + +TLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the chart: + +- `tls.enabled`: Enable TLS support. Defaults to `false` +- `tls.certificatesSecret`: Name of an existing secret that contains the certificates. No defaults. +- `tls.certFilename`: Certificate filename. No defaults. +- `tls.certKeyFilename`: Certificate key filename. No defaults. + +For example: + +- First, create the secret with the cetificates files: + + ```console + kubectl create secret generic certificates-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt + ``` + +- Then, use the following parameters: + + ```console + volumePermissions.enabled=true + tls.enabled=true + tls.certificatesSecret="certificates-tls-secret" + tls.certFilename="cert.crt" + tls.certKeyFilename="cert.key" + ``` + + > Note TLS and VolumePermissions: PostgreSQL requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going [issue](https://github.com/kubernetes/kubernetes/issues/57923) regarding kubernetes permissions and the use of `containerSecurityContext.runAsUser`, you must enable `volumePermissions` to ensure everything works as expected. + +### Sidecars + +If you need additional containers to run within the same pod as PostgreSQL (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +# For the PostgreSQL primary +primary: + sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +# For the PostgreSQL replicas +readReplicas: + sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 ``` -> **Note**: Deleting the PVC's will delete postgresql data as well. Please be cautious before doing it. +### Metrics + +The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9187) is not exposed and it is expected that the metrics are collected from inside the k8s cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). + +The exporter allows to create custom metrics from additional SQL queries. See the Chart's `values.yaml` for an example and consult the [exporters documentation](https://github.com/wrouesnel/postgres_exporter#adding-new-metrics-via-a-config-file) for more details. + +### Use of global variables + +In more complex scenarios, we may have the following tree of dependencies + +```text + +--------------+ + | | + +------------+ Chart 1 +-----------+ + | | | | + | --------+------+ | + | | | + | | | + | | | + | | | + v v v ++-------+------+ +--------+------+ +--------+------+ +| | | | | | +| PostgreSQL | | Sub-chart 1 | | Sub-chart 2 | +| | | | | | ++--------------+ +---------------+ +---------------+ +``` + +The three charts below depend on the parent chart Chart 1. However, subcharts 1 and 2 may need to connect to PostgreSQL as well. In order to do so, subcharts 1 and 2 need to know the PostgreSQL credentials, so one option for deploying could be deploy Chart 1 with the following parameters: + +```text +postgresql.auth.username=testuser +subchart1.postgresql.auth.username=testuser +subchart2.postgresql.auth.username=testuser +postgresql.auth.password=testpass +subchart1.postgresql.auth.password=testpass +subchart2.postgresql.auth.password=testpass +postgresql.auth.database=testdb +subchart1.postgresql.auth.database=testdb +subchart2.postgresql.auth.database=testdb +``` + +If the number of dependent sub-charts increases, installing the chart with parameters can become increasingly difficult. An alternative would be to set the credentials using global variables as follows: + +```text +global.postgresql.auth.username=testuser +global.postgresql.auth.password=testpass +global.postgresql.auth.database=testdb +``` + +This way, the credentials will be available in all of the subcharts. + +### Backup and restore PostgreSQL deployments + +To back up and restore Bitnami PostgreSQL Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using [Velero](https://velero.io/), a Kubernetes backup/restore tool. + +These are the steps you will usually follow to back up and restore your PostgreSQL cluster data: + +- Install Velero on the source and destination clusters. +- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster. +- Use Velero to restore the backed-up PVs on the destination cluster. +- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. + +Refer to our detailed [tutorial on backing up and restoring PostgreSQL deployments on Kubernetes](https://docs.bitnami.com/tutorials/migrate-data-bitnami-velero/) for more information. + +### NetworkPolicy + +To enable network policy for PostgreSQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`. + +For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting the DefaultDeny namespace annotation. Note: this will enforce policy for _all_ pods in the namespace: + +```console +kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}" +``` + +With NetworkPolicy enabled, traffic will be limited to just port 5432. + +For more precise policy, set `networkPolicy.allowExternal=false`. This will only allow pods with the generated client label to connect to PostgreSQL. +This label will be displayed in the output of a successful install. + +### Differences between Bitnami PostgreSQL image and [Docker Official](https://hub.docker.com/_/postgres) image + +- The Docker Official PostgreSQL image does not support replication. If you pass any replication environment variable, this would be ignored. The only environment variables supported by the Docker Official image are POSTGRES_USER, POSTGRES_DB, POSTGRES_PASSWORD, POSTGRES_INITDB_ARGS, POSTGRES_INITDB_WALDIR and PGDATA. All the remaining environment variables are specific to the Bitnami PostgreSQL image. +- The Bitnami PostgreSQL image is non-root by default. This requires that you run the pod with `securityContext` and updates the permissions of the volume with an `initContainer`. A key benefit of this configuration is that the pod follows security best practices and is prepared to run on Kubernetes distributions with hard security constraints like OpenShift. +- For OpenShift up to 4.10, let set the volume permissions, security context, runAsUser and fsGroup automatically by OpenShift and disable the predefined settings of the helm chart: primary.securityContext.enabled=false,primary.containerSecurityContext.enabled=false,volumePermissions.enabled=false,shmVolume.enabled=false +- For OpenShift 4.11 and higher, let set OpenShift the runAsUser and fsGroup automatically. Configure the pod and container security context to restrictive defaults and disable the volume permissions setup: primary. + podSecurityContext.fsGroup=null,primary.podSecurityContext.seccompProfile.type=RuntimeDefault,primary.containerSecurityContext.runAsUser=null,primary.containerSecurityContext.allowPrivilegeEscalation=false,primary.containerSecurityContext.runAsNonRoot=true,primary.containerSecurityContext.seccompProfile.type=RuntimeDefault,primary.containerSecurityContext.capabilities.drop=['ALL'],volumePermissions.enabled=false,shmVolume.enabled=false + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami PostgreSQL](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) image stores the PostgreSQL data and configurations at the `/bitnami/postgresql` 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. + +If you already have data in it, you will fail to sync to standby nodes for all commits, details can refer to the [code present in the container repository](https://github.com/bitnami/containers/tree/main/bitnami/postgresql). If you need to use those data, please covert them to sql and import after `helm install` finished. ## Parameters @@ -560,233 +769,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/postg > 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/postgresql/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. - -### Customizing primary and read replica services in a replicated configuration - -At the top level, there is a service object which defines the services for both primary and readReplicas. For deeper customization, there are service objects for both the primary and read types individually. This allows you to override the values in the top level service object so that the primary and read can be of different service types and with different clusterIPs / nodePorts. Also in the case you want the primary and read to be of type nodePort, you will need to set the nodePorts to different values to prevent a collision. The values that are deeper in the primary.service or readReplicas.service objects will take precedence over the top level service object. - -### Use a different PostgreSQL version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### LDAP - -LDAP support can be enabled in the chart by specifying the `ldap.` parameters while creating a release. The following parameters should be configured to properly enable the LDAP support in the chart. - -- **ldap.enabled**: Enable LDAP support. Defaults to `false`. -- **ldap.uri**: LDAP URL beginning in the form `ldap[s]://:`. No defaults. -- **ldap.base**: LDAP base DN. No defaults. -- **ldap.binddn**: LDAP bind DN. No defaults. -- **ldap.bindpw**: LDAP bind password. No defaults. -- **ldap.bslookup**: LDAP base lookup. No defaults. -- **ldap.nss_initgroups_ignoreusers**: LDAP ignored users. `root,nslcd`. -- **ldap.scope**: LDAP search scope. No defaults. -- **ldap.tls_reqcert**: LDAP TLS check on server certificates. No defaults. - -For example: - -```text -ldap.enabled="true" -ldap.uri="ldap://my_ldap_server" -ldap.base="dc=example\,dc=org" -ldap.binddn="cn=admin\,dc=example\,dc=org" -ldap.bindpw="admin" -ldap.bslookup="ou=group-ok\,dc=example\,dc=org" -ldap.nss_initgroups_ignoreusers="root\,nslcd" -ldap.scope="sub" -ldap.tls_reqcert="demand" -``` - -Next, login to the PostgreSQL server using the `psql` client and add the PAM authenticated LDAP users. - -> Note: Parameters including commas must be escaped as shown in the above example. - -### postgresql.conf / pg_hba.conf files as configMap - -This helm chart also supports to customize the PostgreSQL configuration file. You can add additional PostgreSQL configuration parameters using the `primary.extendedConfiguration`/`readReplicas.extendedConfiguration` parameters as a string. Alternatively, to replace the entire default configuration use `primary.configuration`. - -You can also add a custom pg_hba.conf using the `primary.pgHbaConfiguration` parameter. - -In addition to these options, you can also set an external ConfigMap with all the configuration files. This is done by setting the `primary.existingConfigmap` parameter. Note that this will override the two previous options. - -### Initialize a fresh instance - -The [Bitnami PostgreSQL](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) image allows you to use your custom scripts to initialize a fresh instance. In order to execute the scripts, you can specify custom scripts using the `primary.initdb.scripts` parameter as a string. - -In addition, you can also set an external ConfigMap with all the initialization scripts. This is done by setting the `primary.initdb.scriptsConfigMap` parameter. Note that this will override the two previous options. If your initialization scripts contain sensitive information such as credentials or passwords, you can use the `primary.initdb.scriptsSecret` parameter. - -The allowed extensions are `.sh`, `.sql` and `.sql.gz`. - -### Securing traffic using TLS - -TLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the chart: - -- `tls.enabled`: Enable TLS support. Defaults to `false` -- `tls.certificatesSecret`: Name of an existing secret that contains the certificates. No defaults. -- `tls.certFilename`: Certificate filename. No defaults. -- `tls.certKeyFilename`: Certificate key filename. No defaults. - -For example: - -- First, create the secret with the cetificates files: - - ```console - kubectl create secret generic certificates-tls-secret --from-file=./cert.crt --from-file=./cert.key --from-file=./ca.crt - ``` - -- Then, use the following parameters: - - ```console - volumePermissions.enabled=true - tls.enabled=true - tls.certificatesSecret="certificates-tls-secret" - tls.certFilename="cert.crt" - tls.certKeyFilename="cert.key" - ``` - - > Note TLS and VolumePermissions: PostgreSQL requires certain permissions on sensitive files (such as certificate keys) to start up. Due to an on-going [issue](https://github.com/kubernetes/kubernetes/issues/57923) regarding kubernetes permissions and the use of `containerSecurityContext.runAsUser`, you must enable `volumePermissions` to ensure everything works as expected. - -### Sidecars - -If you need additional containers to run within the same pod as PostgreSQL (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -# For the PostgreSQL primary -primary: - sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -# For the PostgreSQL replicas -readReplicas: - sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Metrics - -The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9187) is not exposed and it is expected that the metrics are collected from inside the k8s cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). - -The exporter allows to create custom metrics from additional SQL queries. See the Chart's `values.yaml` for an example and consult the [exporters documentation](https://github.com/wrouesnel/postgres_exporter#adding-new-metrics-via-a-config-file) for more details. - -### Use of global variables - -In more complex scenarios, we may have the following tree of dependencies - -```text - +--------------+ - | | - +------------+ Chart 1 +-----------+ - | | | | - | --------+------+ | - | | | - | | | - | | | - | | | - v v v -+-------+------+ +--------+------+ +--------+------+ -| | | | | | -| PostgreSQL | | Sub-chart 1 | | Sub-chart 2 | -| | | | | | -+--------------+ +---------------+ +---------------+ -``` - -The three charts below depend on the parent chart Chart 1. However, subcharts 1 and 2 may need to connect to PostgreSQL as well. In order to do so, subcharts 1 and 2 need to know the PostgreSQL credentials, so one option for deploying could be deploy Chart 1 with the following parameters: - -```text -postgresql.auth.username=testuser -subchart1.postgresql.auth.username=testuser -subchart2.postgresql.auth.username=testuser -postgresql.auth.password=testpass -subchart1.postgresql.auth.password=testpass -subchart2.postgresql.auth.password=testpass -postgresql.auth.database=testdb -subchart1.postgresql.auth.database=testdb -subchart2.postgresql.auth.database=testdb -``` - -If the number of dependent sub-charts increases, installing the chart with parameters can become increasingly difficult. An alternative would be to set the credentials using global variables as follows: - -```text -global.postgresql.auth.username=testuser -global.postgresql.auth.password=testpass -global.postgresql.auth.database=testdb -``` - -This way, the credentials will be available in all of the subcharts. - -### Persistence - -The [Bitnami PostgreSQL](https://github.com/bitnami/containers/tree/main/bitnami/postgresql) image stores the PostgreSQL data and configurations at the `/bitnami/postgresql` 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. - -If you already have data in it, you will fail to sync to standby nodes for all commits, details can refer to the [code present in the container repository](https://github.com/bitnami/containers/tree/main/bitnami/postgresql). If you need to use those data, please covert them to sql and import after `helm install` finished. - -### Backup and restore PostgreSQL deployments - -To back up and restore Bitnami PostgreSQL Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using [Velero](https://velero.io/), a Kubernetes backup/restore tool. - -These are the steps you will usually follow to back up and restore your PostgreSQL cluster data: - -- Install Velero on the source and destination clusters. -- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster. -- Use Velero to restore the backed-up PVs on the destination cluster. -- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. - -Refer to our detailed [tutorial on backing up and restoring PostgreSQL deployments on Kubernetes](https://docs.bitnami.com/tutorials/migrate-data-bitnami-velero/) for more information. - -### NetworkPolicy - -To enable network policy for PostgreSQL, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`. - -For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting the DefaultDeny namespace annotation. Note: this will enforce policy for _all_ pods in the namespace: - -```console -kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}" -``` - -With NetworkPolicy enabled, traffic will be limited to just port 5432. - -For more precise policy, set `networkPolicy.allowExternal=false`. This will only allow pods with the generated client label to connect to PostgreSQL. -This label will be displayed in the output of a successful install. - -### Differences between Bitnami PostgreSQL image and [Docker Official](https://hub.docker.com/_/postgres) image - -- The Docker Official PostgreSQL image does not support replication. If you pass any replication environment variable, this would be ignored. The only environment variables supported by the Docker Official image are POSTGRES_USER, POSTGRES_DB, POSTGRES_PASSWORD, POSTGRES_INITDB_ARGS, POSTGRES_INITDB_WALDIR and PGDATA. All the remaining environment variables are specific to the Bitnami PostgreSQL image. -- The Bitnami PostgreSQL image is non-root by default. This requires that you run the pod with `securityContext` and updates the permissions of the volume with an `initContainer`. A key benefit of this configuration is that the pod follows security best practices and is prepared to run on Kubernetes distributions with hard security constraints like OpenShift. -- For OpenShift up to 4.10, let set the volume permissions, security context, runAsUser and fsGroup automatically by OpenShift and disable the predefined settings of the helm chart: primary.securityContext.enabled=false,primary.containerSecurityContext.enabled=false,volumePermissions.enabled=false,shmVolume.enabled=false -- For OpenShift 4.11 and higher, let set OpenShift the runAsUser and fsGroup automatically. Configure the pod and container security context to restrictive defaults and disable the volume permissions setup: primary. - podSecurityContext.fsGroup=null,primary.podSecurityContext.seccompProfile.type=RuntimeDefault,primary.containerSecurityContext.runAsUser=null,primary.containerSecurityContext.allowPrivilegeEscalation=false,primary.containerSecurityContext.runAsNonRoot=true,primary.containerSecurityContext.seccompProfile.type=RuntimeDefault,primary.containerSecurityContext.capabilities.drop=['ALL'],volumePermissions.enabled=false,shmVolume.enabled=false - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/prestashop/README.md b/bitnami/prestashop/README.md index 22534c7209..a1efcb442e 100644 --- a/bitnami/prestashop/README.md +++ b/bitnami/prestashop/README.md @@ -45,15 +45,97 @@ The command deploys PrestaShop on the Kubernetes cluster in the default configur > **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. + +### 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/prestashop + ``` + + > 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 `prestashop-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 PrestaShop file directory permissions yourself and disable or clear PrestaShop cache. + +### SSL + +One needs to explicitly turn on SSL in the Prestashop administration panel, else a `302` redirect to `http` scheme is returned on any page of the site by default. + +To enable SSL on all pages, follow these steps: + +- Browse to the administration panel and log in. +- Click "Shop Parameters" in the left navigation panel. +- Set the option "Enable SSL" to "Yes". +- Click the "Save" button. +- Set the (now enabled) option "Enable SSL on all pages" to "Yes". +- Click the "Save" button. + +## Persistence + +The [Bitnami PrestaShop](https://github.com/bitnami/containers/tree/main/bitnami/prestashop) image stores the PrestaShop data and configurations at the `/bitnami/prestashop` 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/prestashop ``` -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`. ## Parameters @@ -349,98 +431,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/prest > 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/prestashop/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 PrestaShop](https://github.com/bitnami/containers/tree/main/bitnami/prestashop) image stores the PrestaShop data and configurations at the `/bitnami/prestashop` 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/prestashop -``` - -> 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/prestashop - ``` - - > 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 `prestashop-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 PrestaShop file directory permissions yourself and disable or clear PrestaShop cache. - -### SSL - -One needs to explicitly turn on SSL in the Prestashop administration panel, else a `302` redirect to `http` scheme is returned on any page of the site by default. - -To enable SSL on all pages, follow these steps: - -- Browse to the administration panel and log in. -- Click "Shop Parameters" in the left navigation panel. -- Set the option "Enable SSL" to "Yes". -- Click the "Save" button. -- Set the (now enabled) option "Enable SSL on all pages" to "Yes". -- Click the "Save" button. - ## 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). diff --git a/bitnami/prometheus/README.md b/bitnami/prometheus/README.md index 3b6559c79a..b2bc1ae4f7 100644 --- a/bitnami/prometheus/README.md +++ b/bitnami/prometheus/README.md @@ -45,15 +45,259 @@ The command deploys Prometheus on the Kubernetes cluster in the default configur > **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 -```console -helm delete my-release +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. + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +### Integrate Prometheus and Alertmanager with Thanos + +You can integrate Prometheus & Alertmanager with Thanos using this chart and the [Bitnami Thanos chart](https://github.com/bitnami/charts/tree/main/bitnami/thanos) following the steps below: + +> Note: in this example we will use MinIO® (subchart) as the Objstore. Every component will be deployed in the "monitoring" namespace. + +- Create a **values.yaml** like the one below for Thanos: + +```yaml +objstoreConfig: |- + type: s3 + config: + bucket: thanos + endpoint: {{ include "thanos.minio.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local:9000 + access_key: minio + secret_key: minio123 + insecure: true +query: + dnsDiscovery: + sidecarsService: prometheus-thanos + sidecarsNamespace: monitoring +bucketweb: + enabled: true +compactor: + enabled: true +storegateway: + enabled: true +ruler: + enabled: true + alertmanagers: + - http://prometheus-alertmanager.monitoring.svc.cluster.local:9093 + config: |- + groups: + - name: "metamonitoring" + rules: + - alert: "PrometheusDown" + expr: absent(up{prometheus="monitoring/prometheus"}) +metrics: + enabled: true + serviceMonitor: + enabled: true +minio: + enabled: true + auth: + rootPassword: minio123 + rootUser: minio + monitoringBuckets: thanos + accessKey: + password: minio + secretKey: + password: minio123 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +- Install Prometheus and Thanos charts: + +For Helm 3: + +```console +kubectl create namespace monitoring +helm install prometheus \ + --set prometheus.thanos.create=true \ + --namespace monitoring \ + oci://REGISTRY_NAME/REPOSITORY_NAME/prometheus +helm install thanos \ + --values values.yaml \ + --namespace monitoring \ + oci://REGISTRY_NAME/REPOSITORY_NAME/thanos +``` + +> 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`. + +That's all! Now you have Thanos fully integrated with Prometheus and Alertmanager. + +### Integrate Prometheus with Grafana Mimir + +You can integrate Prometheus with Grafana Mimir using this chart and the [Bitnami Grafana Mimir chart](https://github.com/bitnami/charts/tree/main/bitnami/grafana-mimir) adding a `remoteWrite` entry: + +- Create a **values.yaml** like the one below for Prometheus: + +```yaml +server: + remoteWrite: + - url: http://grafana-mimir-gateway.svc.cluster.local/api/v1/push + headers: + X-Scope-OrgID: demo +``` + +- Install Prometheus and Grafana Mimir charts: + +For Helm 3: + +```console +kubectl create namespace monitoring +helm install prometheus \ + --values values.yaml \ + --namespace monitoring \ + oci://REGISTRY_NAME/REPOSITORY_NAME/prometheus +helm install grafana-mimir \ + oci://REGISTRY_NAME/REPOSITORY_NAME/grafana-mimir +``` + +> 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`. + +That's all! Now you have Prometheus integrated with Grafana Mimir. + +### Integrate Prometheus with Grafana + +You can integrate Prometheus with Grafana Dashboard using this chart and the [Bitnami Grafana chart](https://github.com/bitnami/charts/tree/main/bitnami/grafana) just adding the prometheus datasources: + +- Create a **values.yaml** like the one below for Grafana: + +```yaml +datasources: + secretDefinition: + apiVersion: 1 + datasources: + - name: Prometheus + type: prometheus + access: proxy + orgId: 1 + url: http://prometheus.monitoring.svc.cluster.local + version: 1 + editable: true + isDefault: true + - name: Alertmanager + uid: alertmanager + type: alertmanager + access: proxy + orgId: 1 + url: http://prometheus-alertmanager.monitoring.svc.cluster.local:9093 + version: 1 + editable: true +``` + +- Install Prometheus and Grafana charts: + +For Helm 3: + +```console +kubectl create namespace monitoring +helm install prometheus \ + --namespace monitoring \ + oci://REGISTRY_NAME/REPOSITORY_NAME/prometheus +helm install grafana-mimir \ + --values values.yaml \ + --namespace monitoring \ + oci://REGISTRY_NAME/REPOSITORY_NAME/grafana +``` + +> 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`. + +### How to add new targets + +By default this helm chart will monitor its own targets: prometheus and alertmanager. Additional ones can be added setting a list with the [scrape_configs](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) in the value `server.extraScrapeConfigs`. Here there is a simple example for wordpress (deployed in the default namespace): + +```yaml +server: + extraScrapeConfigs: + - job_name: wordpress + kubernetes_sd_configs: + - role: endpoints + namespaces: + names: + - default + metrics_path: /metrics + relabel_configs: + - source_labels: + - job + target_label: __tmp_wordpress_job_name + - action: keep + source_labels: + - __meta_kubernetes_service_label_app_kubernetes_io_instance + - __meta_kubernetes_service_labelpresent_app_kubernetes_io_instance + regex: (wordpress);true + - action: keep + source_labels: + - __meta_kubernetes_service_label_app_kubernetes_io_name + - __meta_kubernetes_service_labelpresent_app_kubernetes_io_name + regex: (wordpress);true + - action: keep + source_labels: + - __meta_kubernetes_endpoint_port_name + regex: metrics + - source_labels: + - __meta_kubernetes_endpoint_address_target_kind + - __meta_kubernetes_endpoint_address_target_name + separator: ; + regex: Node;(.*) + replacement: ${1} + target_label: node + - source_labels: + - __meta_kubernetes_endpoint_address_target_kind + - __meta_kubernetes_endpoint_address_target_name + separator: ; + regex: Pod;(.*) + replacement: ${1} + target_label: pod + - source_labels: + - __meta_kubernetes_namespace + target_label: namespace + - source_labels: + - __meta_kubernetes_service_name + target_label: service + - source_labels: + - __meta_kubernetes_pod_name + target_label: pod + - source_labels: + - __meta_kubernetes_pod_container_name + target_label: container + - action: drop + source_labels: + - __meta_kubernetes_pod_phase + regex: (Failed|Succeeded) + - source_labels: + - __meta_kubernetes_service_name + target_label: job + replacement: ${1} + - target_label: endpoint + replacement: metrics + - source_labels: + - __address__ + target_label: __tmp_hash + modulus: 1 + action: hashmod + - source_labels: + - __tmp_hash + regex: 0 + action: keep +``` ## Parameters @@ -459,260 +703,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/prome > 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/prometheus/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. - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -### Integrate Prometheus and Alertmanager with Thanos - -You can integrate Prometheus & Alertmanager with Thanos using this chart and the [Bitnami Thanos chart](https://github.com/bitnami/charts/tree/main/bitnami/thanos) following the steps below: - -> Note: in this example we will use MinIO® (subchart) as the Objstore. Every component will be deployed in the "monitoring" namespace. - -- Create a **values.yaml** like the one below for Thanos: - -```yaml -objstoreConfig: |- - type: s3 - config: - bucket: thanos - endpoint: {{ include "thanos.minio.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local:9000 - access_key: minio - secret_key: minio123 - insecure: true -query: - dnsDiscovery: - sidecarsService: prometheus-thanos - sidecarsNamespace: monitoring -bucketweb: - enabled: true -compactor: - enabled: true -storegateway: - enabled: true -ruler: - enabled: true - alertmanagers: - - http://prometheus-alertmanager.monitoring.svc.cluster.local:9093 - config: |- - groups: - - name: "metamonitoring" - rules: - - alert: "PrometheusDown" - expr: absent(up{prometheus="monitoring/prometheus"}) -metrics: - enabled: true - serviceMonitor: - enabled: true -minio: - enabled: true - auth: - rootPassword: minio123 - rootUser: minio - monitoringBuckets: thanos - accessKey: - password: minio - secretKey: - password: minio123 -``` - -- Install Prometheus and Thanos charts: - -For Helm 3: - -```console -kubectl create namespace monitoring -helm install prometheus \ - --set prometheus.thanos.create=true \ - --namespace monitoring \ - oci://REGISTRY_NAME/REPOSITORY_NAME/prometheus -helm install thanos \ - --values values.yaml \ - --namespace monitoring \ - oci://REGISTRY_NAME/REPOSITORY_NAME/thanos -``` - -> 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`. - -That's all! Now you have Thanos fully integrated with Prometheus and Alertmanager. - -### Integrate Prometheus with Grafana Mimir - -You can integrate Prometheus with Grafana Mimir using this chart and the [Bitnami Grafana Mimir chart](https://github.com/bitnami/charts/tree/main/bitnami/grafana-mimir) adding a `remoteWrite` entry: - -- Create a **values.yaml** like the one below for Prometheus: - -```yaml -server: - remoteWrite: - - url: http://grafana-mimir-gateway.svc.cluster.local/api/v1/push - headers: - X-Scope-OrgID: demo -``` - -- Install Prometheus and Grafana Mimir charts: - -For Helm 3: - -```console -kubectl create namespace monitoring -helm install prometheus \ - --values values.yaml \ - --namespace monitoring \ - oci://REGISTRY_NAME/REPOSITORY_NAME/prometheus -helm install grafana-mimir \ - oci://REGISTRY_NAME/REPOSITORY_NAME/grafana-mimir -``` - -> 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`. - -That's all! Now you have Prometheus integrated with Grafana Mimir. - -### Integrate Prometheus with Grafana - -You can integrate Prometheus with Grafana Dashboard using this chart and the [Bitnami Grafana chart](https://github.com/bitnami/charts/tree/main/bitnami/grafana) just adding the prometheus datasources: - -- Create a **values.yaml** like the one below for Grafana: - -```yaml -datasources: - secretDefinition: - apiVersion: 1 - datasources: - - name: Prometheus - type: prometheus - access: proxy - orgId: 1 - url: http://prometheus.monitoring.svc.cluster.local - version: 1 - editable: true - isDefault: true - - name: Alertmanager - uid: alertmanager - type: alertmanager - access: proxy - orgId: 1 - url: http://prometheus-alertmanager.monitoring.svc.cluster.local:9093 - version: 1 - editable: true -``` - -- Install Prometheus and Grafana charts: - -For Helm 3: - -```console -kubectl create namespace monitoring -helm install prometheus \ - --namespace monitoring \ - oci://REGISTRY_NAME/REPOSITORY_NAME/prometheus -helm install grafana-mimir \ - --values values.yaml \ - --namespace monitoring \ - oci://REGISTRY_NAME/REPOSITORY_NAME/grafana -``` - -> 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`. - -### How to add new targets - -By default this helm chart will monitor its own targets: prometheus and alertmanager. Additional ones can be added setting a list with the [scrape_configs](https://prometheus.io/docs/prometheus/latest/configuration/configuration/#scrape_config) in the value `server.extraScrapeConfigs`. Here there is a simple example for wordpress (deployed in the default namespace): - -```yaml -server: - extraScrapeConfigs: - - job_name: wordpress - kubernetes_sd_configs: - - role: endpoints - namespaces: - names: - - default - metrics_path: /metrics - relabel_configs: - - source_labels: - - job - target_label: __tmp_wordpress_job_name - - action: keep - source_labels: - - __meta_kubernetes_service_label_app_kubernetes_io_instance - - __meta_kubernetes_service_labelpresent_app_kubernetes_io_instance - regex: (wordpress);true - - action: keep - source_labels: - - __meta_kubernetes_service_label_app_kubernetes_io_name - - __meta_kubernetes_service_labelpresent_app_kubernetes_io_name - regex: (wordpress);true - - action: keep - source_labels: - - __meta_kubernetes_endpoint_port_name - regex: metrics - - source_labels: - - __meta_kubernetes_endpoint_address_target_kind - - __meta_kubernetes_endpoint_address_target_name - separator: ; - regex: Node;(.*) - replacement: ${1} - target_label: node - - source_labels: - - __meta_kubernetes_endpoint_address_target_kind - - __meta_kubernetes_endpoint_address_target_name - separator: ; - regex: Pod;(.*) - replacement: ${1} - target_label: pod - - source_labels: - - __meta_kubernetes_namespace - target_label: namespace - - source_labels: - - __meta_kubernetes_service_name - target_label: service - - source_labels: - - __meta_kubernetes_pod_name - target_label: pod - - source_labels: - - __meta_kubernetes_pod_container_name - target_label: container - - action: drop - source_labels: - - __meta_kubernetes_pod_phase - regex: (Failed|Succeeded) - - source_labels: - - __meta_kubernetes_service_name - target_label: job - replacement: ${1} - - target_label: endpoint - replacement: metrics - - source_labels: - - __address__ - target_label: __tmp_hash - modulus: 1 - action: hashmod - - source_labels: - - __tmp_hash - regex: 0 - action: keep -``` - ## 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). diff --git a/bitnami/pytorch/README.md b/bitnami/pytorch/README.md index 138b03c991..d503e656ae 100644 --- a/bitnami/pytorch/README.md +++ b/bitnami/pytorch/README.md @@ -45,15 +45,62 @@ These commands deploy PyTorch on the Kubernetes cluster in the default configura > **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. + +### Loading your files + +The PyTorch chart supports three different ways to load your files. In order of priority, they are: + + 1. Existing config map + 2. Files under the `files` directory + 3. Cloning a git repository + +This means that if you specify a config map with your files, it won't look for the `files/` directory nor the git repository. + +In order to use use an existing config map, set the `configMap=my-config-map` parameter. + +To load your files from the `files/` directory you don't have to set any option. Just copy your files inside and don't specify a `ConfigMap`. + +Finally, if you want to clone a git repository you can use those parameters: ```console -helm delete my-release +cloneFilesFromGit.enabled=true +cloneFilesFromGit.repository=https://github.com/my-user/my-repo +cloneFilesFromGit.revision=master ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### 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 PyTorch](https://github.com/bitnami/containers/tree/main/bitnami/pytorch) image can persist data. If enabled, the persisted path is `/bitnami/pytorch` by default. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -249,63 +296,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/pytor > 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/pytorch/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. - -### Loading your files - -The PyTorch chart supports three different ways to load your files. In order of priority, they are: - - 1. Existing config map - 2. Files under the `files` directory - 3. Cloning a git repository - -This means that if you specify a config map with your files, it won't look for the `files/` directory nor the git repository. - -In order to use use an existing config map, set the `configMap=my-config-map` parameter. - -To load your files from the `files/` directory you don't have to set any option. Just copy your files inside and don't specify a `ConfigMap`. - -Finally, if you want to clone a git repository you can use those parameters: - -```console -cloneFilesFromGit.enabled=true -cloneFilesFromGit.repository=https://github.com/my-user/my-repo -cloneFilesFromGit.revision=master -``` - -## Persistence - -The [Bitnami PyTorch](https://github.com/bitnami/containers/tree/main/bitnami/pytorch) image can persist data. If enabled, the persisted path is `/bitnami/pytorch` by default. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### 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. - ## 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). diff --git a/bitnami/rabbitmq-cluster-operator/README.md b/bitnami/rabbitmq-cluster-operator/README.md index 53e949504d..84f126e8c3 100644 --- a/bitnami/rabbitmq-cluster-operator/README.md +++ b/bitnami/rabbitmq-cluster-operator/README.md @@ -44,16 +44,6 @@ The command deploy the RabbitMQ Cluster Kubernetes Operator on the Kubernetes cl > **Tip**: List all releases using `helm list` -## Uninstalling the Chart - -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - ## Differences between the Bitnami RabbitMQ chart and the Bitnami RabbitMQ Operator chart In the Bitnami catalog we offer both the *bitnami/rabbitmq* and *bitnami/rabbitmq-operator* charts. Each solution covers different needs and use cases. @@ -132,6 +122,98 @@ The operator will extend the Kubernetes API with the following object: *Rabbitmq This solution allows to easily deploy multiple RabbitMQ instances compared to the *bitnami/rabbitmq* chart. As the operator automatically deploys RabbitMQ installations, the RabbitMQ Operator pods will require a ServiceAccount with privileges to create and destroy multiple Kubernetes objects. This may be problematic for Kubernetes clusters with strict role-based access policies. +## 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. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +rabbitmq-cluster-operator: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as rabbitmq-cluster-operator (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. + +### Deploying extra resources + +There are cases where you may want to deploy extra objects, such your custom *RabbitmqCluster* objects. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +For instance, to deploy your custom *RabbitmqCluster* definition, you can install the RabbitMQ Cluster Operator using the values below: + +```yaml +extraDeploy: + - apiVersion: rabbitmq.com/v1beta1 + kind: RabbitmqCluster + metadata: + name: rabbitmq-custom-configuration + spec: + replicas: 1 + rabbitmq: + additionalConfig: | + log.console.level = debug +``` + ## Parameters ### Global parameters @@ -476,98 +558,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/rabbi > 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/rabbitmq-cluster-operator/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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -rabbitmq-cluster-operator: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as rabbitmq-cluster-operator (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - -### Deploying extra resources - -There are cases where you may want to deploy extra objects, such your custom *RabbitmqCluster* objects. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -For instance, to deploy your custom *RabbitmqCluster* definition, you can install the RabbitMQ Cluster Operator using the values below: - -```yaml -extraDeploy: - - apiVersion: rabbitmq.com/v1beta1 - kind: RabbitmqCluster - metadata: - name: rabbitmq-custom-configuration - spec: - replicas: 1 - rabbitmq: - additionalConfig: | - log.console.level = debug -``` - ## 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). diff --git a/bitnami/rabbitmq/README.md b/bitnami/rabbitmq/README.md index f47ce9d9f0..67c9f42e66 100644 --- a/bitnami/rabbitmq/README.md +++ b/bitnami/rabbitmq/README.md @@ -42,15 +42,293 @@ The command deploys RabbitMQ on the Kubernetes cluster in the default configurat > **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 -```console -helm delete my-release +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. + +### Set pod 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. + +### Scale horizontally + +To horizontally scale this chart once it has been deployed, two options are available: + +- Use the `kubectl scale` command. +- Upgrade the chart modifying the `replicaCount` parameter. + +```text + replicaCount=3 + auth.password="$RABBITMQ_PASSWORD" + auth.erlangCookie="$RABBITMQ_ERLANG_COOKIE" ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +> NOTE: It is mandatory to specify the password and Erlang cookie that was set the first time the chart was installed when upgrading the chart. Otherwise, new pods won't be able to join the cluster. + +When scaling down the solution, unnecessary RabbitMQ nodes are automatically stopped, but they are not removed from the cluster. These nodes must be manually removed via the `rabbitmqctl forget_cluster_node` command. + +For instance, if RabbitMQ was initially installed with three replicas and then scaled down to two replicas, run the commands below (assuming that the release name is `rabbitmq` and the clustering type is `hostname`): + +```console + kubectl exec rabbitmq-0 --container rabbitmq -- rabbitmqctl forget_cluster_node rabbit@rabbitmq-2.rabbitmq-headless.default.svc.cluster.local + kubectl delete pvc data-rabbitmq-2 +``` + +> NOTE: It is mandatory to specify the password and Erlang cookie that was set the first time the chart was installed when upgrading the chart. + +### Enable TLS support + +To enable TLS support, first generate the certificates as described in the [RabbitMQ documentation for SSL certificate generation](https://www.rabbitmq.com/ssl.html#automated-certificate-generation). + +Once the certificates are generated, you have two alternatives: + +- Create a secret with the certificates and associate the secret when deploying the chart +- Include the certificates in the *values.yaml* file when deploying the chart + +Set the *auth.tls.failIfNoPeerCert* parameter to *false* to allow a TLS connection if the client fails to provide a certificate. + +Set the *auth.tls.sslOptionsVerify* to *verify_peer* to force a node to perform peer verification. When set to *verify_none*, peer verification will be disabled and certificate exchange won't be performed. + +This chart also 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`. + +### Load custom definitions + +It is possible to [load a RabbitMQ definitions file to configure RabbitMQ](https://www.rabbitmq.com/management.html#load-definitions). Follow the steps below: + +Because definitions may contain RabbitMQ credentials, [store the JSON as a Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod). Within the secret's data, choose a key name that corresponds with the desired load definitions filename (i.e. `load_definition.json`) and use the JSON object as the value. + +Next, specify the `load_definitions` property as an `extraConfiguration` pointing to the load definition file path within the container (i.e. `/app/load_definition.json`) and set `loadDefinition.enable` to `true`. Any load definitions specified will be available within in the container at `/app`. + +> NOTE: Loading a definition will take precedence over any configuration done through [Helm values](#parameters). + +If needed, you can use `extraSecrets` to let the chart create the secret for you. This way, you don't need to manually create it before deploying a release. These secrets can also be templated to use supplied chart values. Here is an example: + +```yaml +auth: + password: CHANGEME +extraSecrets: + load-definition: + load_definition.json: | + { + "users": [ + { + "name": "{{ .Values.auth.username }}", + "password": "{{ .Values.auth.password }}", + "tags": "administrator" + } + ], + "vhosts": [ + { + "name": "/" + } + ] + } +loadDefinition: + enabled: true + existingSecret: load-definition +extraConfiguration: | + load_definitions = /app/load_definition.json +``` + +### Configure LDAP support + +LDAP support can be enabled in the chart by specifying the `ldap.*` parameters while creating a release. For example: + +```text +ldap.enabled="true" +ldap.server="my-ldap-server" +ldap.port="389" +ldap.user_dn_pattern="cn=${username},dc=example,dc=org" +``` + +If `ldap.tls.enabled` is set to true, consider using `ldap.port=636` and checking the settings in the `advancedConfiguration` chart parameters. + +### Configure memory high watermark + +It is possible to configure a memory high watermark on RabbitMQ to define [memory thresholds](https://www.rabbitmq.com/memory.html#threshold) using the `memoryHighWatermark.*` parameters. To do so, you have two alternatives: + +- Set an absolute limit of RAM to be used on each RabbitMQ node, as shown in the configuration example below: + +```text +memoryHighWatermark.enabled="true" +memoryHighWatermark.type="absolute" +memoryHighWatermark.value="512MB" +``` + +- Set a relative limit of RAM to be used on each RabbitMQ node. To enable this feature, define the memory limits at pod level too. An example configuration is shown below: + +```text +memoryHighWatermark.enabled="true" +memoryHighWatermark.type="relative" +memoryHighWatermark.value="0.4" +resources.limits.memory="2Gi" +``` + +### Add extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `.extraEnvVarsCM` or the `extraEnvVarsSecret` properties. + +### Configure the default user/vhost + +If you want to create default user/vhost and set the default permission. you can use `extraConfiguration`: + +```yaml +auth: + username: default-user +extraConfiguration: |- + default_vhost = default-vhost + default_permissions.configure = .* + default_permissions.read = .* + default_permissions.write = .* +``` + +### Use plugins + +The Bitnami Docker RabbitMQ image ships a set of plugins by default. By default, this chart enables `rabbitmq_management` and `rabbitmq_peer_discovery_k8s` since they are required for RabbitMQ to work on K8s. + +To enable extra plugins, set the `extraPlugins` parameter with the list of plugins you want to enable. In addition to this, the `communityPlugins` parameter can be used to specify a list of URLs (separated by spaces) for custom plugins for RabbitMQ. + +```text +communityPlugins="http://URL-TO-PLUGIN/" +extraPlugins="my-custom-plugin" +``` + +### Advanced logging + +In case you want to configure RabbitMQ logging set `logs` value to false and set the log config in extraConfiguration following the [official documentation](https://www.rabbitmq.com/logging.html#log-file-location). + +An example: + +```yaml +logs: false # custom logging +extraConfiguration: | + log.default.level = warning + log.file = false + log.console = true + log.console.level = warning + log.console.formatter = json +``` + +### Recover the cluster from complete shutdown + +> IMPORTANT: Some of these procedures can lead to data loss. Always make a backup beforehand. + +The RabbitMQ cluster is able to support multiple node failures but, in a situation in which all the nodes are brought down at the same time, the cluster might not be able to self-recover. + +This happens if the pod management policy of the statefulset is not `Parallel` and the last pod to be running wasn't the first pod of the statefulset. If that happens, update the pod management policy to recover a healthy state: + +```console +$ kubectl delete statefulset STATEFULSET_NAME --cascade=false +helm upgrade RELEASE_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq \ + --set podManagementPolicy=Parallel \ + --set replicaCount=NUMBER_OF_REPLICAS \ + --set auth.password=PASSWORD \ + --set auth.erlangCookie=ERLANG_COOKIE +``` + +> 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`. + +For a faster resyncronization of the nodes, you can temporarily disable the readiness probe by setting `readinessProbe.enabled=false`. Bear in mind that the pods will be exposed before they are actually ready to process requests. + +If the steps above don't bring the cluster to a healthy state, it could be possible that none of the RabbitMQ nodes think they were the last node to be up during the shutdown. In those cases, you can force the boot of the nodes by specifying the `clustering.forceBoot=true` parameter (which will execute [`rabbitmqctl force_boot`](https://www.rabbitmq.com/rabbitmqctl.8.html#force_boot) in each pod): + +```console +helm upgrade RELEASE_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq \ + --set podManagementPolicy=Parallel \ + --set clustering.forceBoot=true \ + --set replicaCount=NUMBER_OF_REPLICAS \ + --set auth.password=PASSWORD \ + --set auth.erlangCookie=ERLANG_COOKIE +``` + +> 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`. + +More information: [Clustering Guide: Restarting](https://www.rabbitmq.com/clustering.html#restarting). + +### Known issues + +- Changing the password through RabbitMQ's UI can make the pod fail due to the default liveness probes. If you do so, remember to make the chart aware of the new password. Updating the default secret with the password you set through RabbitMQ's UI will automatically recreate the pods. If you are using your own secret, you may have to manually recreate the pods. + +## Persistence + +The [Bitnami RabbitMQ](https://github.com/bitnami/containers/tree/main/bitnami/rabbitmq) image stores the RabbitMQ data and configurations at the `/opt/bitnami/rabbitmq/var/lib/rabbitmq/` path of the container. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. By default, the volume is created using dynamic volume provisioning. An existing PersistentVolumeClaim can also be defined. + +### Use existing PersistentVolumeClaims + +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/rabbitmq +``` + +> 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`. + +### Adjust permissions of the persistence volume mountpoint + +As the image runs as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an `initContainer` to change the ownership of the volume before mounting it in the final destination. + +You can enable this `initContainer` by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -416,294 +694,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/rabbi > 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/rabbitmq/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. - -### Set pod 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. - -### Scale horizontally - -To horizontally scale this chart once it has been deployed, two options are available: - -- Use the `kubectl scale` command. -- Upgrade the chart modifying the `replicaCount` parameter. - -```text - replicaCount=3 - auth.password="$RABBITMQ_PASSWORD" - auth.erlangCookie="$RABBITMQ_ERLANG_COOKIE" -``` - -> NOTE: It is mandatory to specify the password and Erlang cookie that was set the first time the chart was installed when upgrading the chart. Otherwise, new pods won't be able to join the cluster. - -When scaling down the solution, unnecessary RabbitMQ nodes are automatically stopped, but they are not removed from the cluster. These nodes must be manually removed via the `rabbitmqctl forget_cluster_node` command. - -For instance, if RabbitMQ was initially installed with three replicas and then scaled down to two replicas, run the commands below (assuming that the release name is `rabbitmq` and the clustering type is `hostname`): - -```console - kubectl exec rabbitmq-0 --container rabbitmq -- rabbitmqctl forget_cluster_node rabbit@rabbitmq-2.rabbitmq-headless.default.svc.cluster.local - kubectl delete pvc data-rabbitmq-2 -``` - -> NOTE: It is mandatory to specify the password and Erlang cookie that was set the first time the chart was installed when upgrading the chart. - -### Enable TLS support - -To enable TLS support, first generate the certificates as described in the [RabbitMQ documentation for SSL certificate generation](https://www.rabbitmq.com/ssl.html#automated-certificate-generation). - -Once the certificates are generated, you have two alternatives: - -- Create a secret with the certificates and associate the secret when deploying the chart -- Include the certificates in the *values.yaml* file when deploying the chart - -Set the *auth.tls.failIfNoPeerCert* parameter to *false* to allow a TLS connection if the client fails to provide a certificate. - -Set the *auth.tls.sslOptionsVerify* to *verify_peer* to force a node to perform peer verification. When set to *verify_none*, peer verification will be disabled and certificate exchange won't be performed. - -This chart also 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`. - -### Load custom definitions - -It is possible to [load a RabbitMQ definitions file to configure RabbitMQ](https://www.rabbitmq.com/management.html#load-definitions). Follow the steps below: - -Because definitions may contain RabbitMQ credentials, [store the JSON as a Kubernetes secret](https://kubernetes.io/docs/concepts/configuration/secret/#using-secrets-as-files-from-a-pod). Within the secret's data, choose a key name that corresponds with the desired load definitions filename (i.e. `load_definition.json`) and use the JSON object as the value. - -Next, specify the `load_definitions` property as an `extraConfiguration` pointing to the load definition file path within the container (i.e. `/app/load_definition.json`) and set `loadDefinition.enable` to `true`. Any load definitions specified will be available within in the container at `/app`. - -> NOTE: Loading a definition will take precedence over any configuration done through [Helm values](#parameters). - -If needed, you can use `extraSecrets` to let the chart create the secret for you. This way, you don't need to manually create it before deploying a release. These secrets can also be templated to use supplied chart values. Here is an example: - -```yaml -auth: - password: CHANGEME -extraSecrets: - load-definition: - load_definition.json: | - { - "users": [ - { - "name": "{{ .Values.auth.username }}", - "password": "{{ .Values.auth.password }}", - "tags": "administrator" - } - ], - "vhosts": [ - { - "name": "/" - } - ] - } -loadDefinition: - enabled: true - existingSecret: load-definition -extraConfiguration: | - load_definitions = /app/load_definition.json -``` - -### Configure LDAP support - -LDAP support can be enabled in the chart by specifying the `ldap.*` parameters while creating a release. For example: - -```text -ldap.enabled="true" -ldap.server="my-ldap-server" -ldap.port="389" -ldap.user_dn_pattern="cn=${username},dc=example,dc=org" -``` - -If `ldap.tls.enabled` is set to true, consider using `ldap.port=636` and checking the settings in the `advancedConfiguration` chart parameters. - -### Configure memory high watermark - -It is possible to configure a memory high watermark on RabbitMQ to define [memory thresholds](https://www.rabbitmq.com/memory.html#threshold) using the `memoryHighWatermark.*` parameters. To do so, you have two alternatives: - -- Set an absolute limit of RAM to be used on each RabbitMQ node, as shown in the configuration example below: - -```text -memoryHighWatermark.enabled="true" -memoryHighWatermark.type="absolute" -memoryHighWatermark.value="512MB" -``` - -- Set a relative limit of RAM to be used on each RabbitMQ node. To enable this feature, define the memory limits at pod level too. An example configuration is shown below: - -```text -memoryHighWatermark.enabled="true" -memoryHighWatermark.type="relative" -memoryHighWatermark.value="0.4" -resources.limits.memory="2Gi" -``` - -### Add extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `.extraEnvVarsCM` or the `extraEnvVarsSecret` properties. - -### Use plugins - -The Bitnami Docker RabbitMQ image ships a set of plugins by default. By default, this chart enables `rabbitmq_management` and `rabbitmq_peer_discovery_k8s` since they are required for RabbitMQ to work on K8s. - -To enable extra plugins, set the `extraPlugins` parameter with the list of plugins you want to enable. In addition to this, the `communityPlugins` parameter can be used to specify a list of URLs (separated by spaces) for custom plugins for RabbitMQ. - -```text -communityPlugins="http://URL-TO-PLUGIN/" -extraPlugins="my-custom-plugin" -``` - -### Advanced logging - -In case you want to configure RabbitMQ logging set `logs` value to false and set the log config in extraConfiguration following the [official documentation](https://www.rabbitmq.com/logging.html#log-file-location). - -An example: - -```yaml -logs: false # custom logging -extraConfiguration: | - log.default.level = warning - log.file = false - log.console = true - log.console.level = warning - log.console.formatter = json -``` - -### Recover the cluster from complete shutdown - -> IMPORTANT: Some of these procedures can lead to data loss. Always make a backup beforehand. - -The RabbitMQ cluster is able to support multiple node failures but, in a situation in which all the nodes are brought down at the same time, the cluster might not be able to self-recover. - -This happens if the pod management policy of the statefulset is not `Parallel` and the last pod to be running wasn't the first pod of the statefulset. If that happens, update the pod management policy to recover a healthy state: - -```console -$ kubectl delete statefulset STATEFULSET_NAME --cascade=false -helm upgrade RELEASE_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq \ - --set podManagementPolicy=Parallel \ - --set replicaCount=NUMBER_OF_REPLICAS \ - --set auth.password=PASSWORD \ - --set auth.erlangCookie=ERLANG_COOKIE -``` - -> 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`. - -For a faster resyncronization of the nodes, you can temporarily disable the readiness probe by setting `readinessProbe.enabled=false`. Bear in mind that the pods will be exposed before they are actually ready to process requests. - -If the steps above don't bring the cluster to a healthy state, it could be possible that none of the RabbitMQ nodes think they were the last node to be up during the shutdown. In those cases, you can force the boot of the nodes by specifying the `clustering.forceBoot=true` parameter (which will execute [`rabbitmqctl force_boot`](https://www.rabbitmq.com/rabbitmqctl.8.html#force_boot) in each pod): - -```console -helm upgrade RELEASE_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/rabbitmq \ - --set podManagementPolicy=Parallel \ - --set clustering.forceBoot=true \ - --set replicaCount=NUMBER_OF_REPLICAS \ - --set auth.password=PASSWORD \ - --set auth.erlangCookie=ERLANG_COOKIE -``` - -> 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`. - -More information: [Clustering Guide: Restarting](https://www.rabbitmq.com/clustering.html#restarting). - -### Known issues - -- Changing the password through RabbitMQ's UI can make the pod fail due to the default liveness probes. If you do so, remember to make the chart aware of the new password. Updating the default secret with the password you set through RabbitMQ's UI will automatically recreate the pods. If you are using your own secret, you may have to manually recreate the pods. - -## Persistence - -The [Bitnami RabbitMQ](https://github.com/bitnami/containers/tree/main/bitnami/rabbitmq) image stores the RabbitMQ data and configurations at the `/opt/bitnami/rabbitmq/var/lib/rabbitmq/` path of the container. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. By default, the volume is created using dynamic volume provisioning. An existing PersistentVolumeClaim can also be defined. - -### Use existing PersistentVolumeClaims - -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/rabbitmq -``` - -> 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`. - -### Adjust permissions of the persistence volume mountpoint - -As the image runs as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an `initContainer` to change the ownership of the volume before mounting it in the final destination. - -You can enable this `initContainer` by setting `volumePermissions.enabled` to `true`. - -### Configure the default user/vhost - -If you want to create default user/vhost and set the default permission. you can use `extraConfiguration`: - -```yaml -auth: - username: default-user -extraConfiguration: |- - default_vhost = default-vhost - default_permissions.configure = .* - default_permissions.read = .* - default_permissions.write = .* -``` - ## 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). diff --git a/bitnami/redis-cluster/README.md b/bitnami/redis-cluster/README.md index d478ad4f5e..e878b3dc8a 100644 --- a/bitnami/redis-cluster/README.md +++ b/bitnami/redis-cluster/README.md @@ -61,15 +61,313 @@ helm install --timeout 600s myrelease oci://REGISTRY_NAME/REPOSITORY_NAME/redis- > 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**: 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. + +### Use a different Redis® version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Cluster topology + +To successfully set the cluster up, it will need to have at least 3 master nodes. The total number of nodes is calculated like- `nodes = numOfMasterNodes + numOfMasterNodes * replicas`. Hence, the defaults `cluster.nodes = 6` and `cluster.replicas = 1` means, 3 master and 3 replica nodes will be deployed by the chart. + +By default the Redis® Cluster is not accessible from outside the Kubernetes cluster, to access the Redis® Cluster from outside you have to set `cluster.externalAccess.enabled=true` at deployment time. It will create in the first installation only 6 LoadBalancer services, one for each Redis® node, once you have the external IPs of each service you will need to perform an upgrade passing those IPs to the `cluster.externalAccess.service.loadbalancerIP` array. + +The replicas will be read-only replicas of the masters. By default only one service is exposed (when not using the external access mode). You will connect your client to the exposed service, regardless you need to read or write. When a write operation arrives to a replica it will redirect the client to the proper master node. For example, using `redis-cli` you will need to provide the `-c` flag for `redis-cli` to follow the redirection automatically. + +Using the external access mode, you can connect to any of the pods and the slaves will redirect the client in the same way as explained before, but the all the IPs will be public. + +In case the master crashes, one of his slaves will be promoted to master. The slots stored by the crashed master will be unavailable until the slave finish the promotion. If a master and all his slaves crash, the cluster will be down until one of them is up again. To avoid downtime, it is possible to configure the number of Redis® nodes with `cluster.nodes` and the number of replicas that will be assigned to each master with `cluster.replicas`. For example: + +- `cluster.nodes=9` ( 3 master plus 2 replicas for each master) +- `cluster.replicas=2` + +Providing the values above, the cluster will have 3 masters and, each master, will have 2 replicas. + +> NOTE: By default `cluster.init` will be set to `true` in order to initialize the Redis® Cluster in the first installation. If for testing purposes you only want to deploy or upgrade the nodes but avoiding the creation of the cluster you can set `cluster.init` to `false`. + +#### Adding a new node to the cluster + +There is a job that will be executed using a `post-upgrade` hook that will allow you to add a new node. To use it, you should provide some parameters to the upgrade: + +- Pass as `password` the password used in the installation time. If you did not provide a password follow the instructions from the NOTES.txt to get the generated password. +- Set the desired number of nodes at `cluster.nodes`. +- Set the number of current nodes at `cluster.update.currentNumberOfNodes`. +- Set to true `cluster.update.addNodes`. + +The following will be an example to add one more node: ```console -helm delete my-release +helm upgrade --timeout 600s --set "password=${REDIS_PASSWORD},cluster.nodes=7,cluster.update.addNodes=true,cluster.update.currentNumberOfNodes=6" oci://REGISTRY_NAME/REPOSITORY_NAME/redis-cluster ``` -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`. + +Where `REDIS_PASSWORD` is the password obtained with the command that appears after the first installation of the Helm Chart. +The cluster will continue up while restarting pods one by one as the quorum is not lost. + +##### External Access + +If you are using external access, to add a new node you will need to perform two upgrades. First upgrade the release to add a new Redis® node and to get a LoadBalancerIP service. For example: + +```console +helm upgrade --set "password=${REDIS_PASSWORD},cluster.externalAccess.enabled=true,cluster.externalAccess.service.type=LoadBalancer,cluster.externalAccess.service.loadBalancerIP[0]=,cluster.externalAccess.service.loadBalancerIP[1]=,cluster.externalAccess.service.loadBalancerIP[2]=,cluster.externalAccess.service.loadBalancerIP[3]=,cluster.externalAccess.service.loadBalancerIP[4]=,cluster.externalAccess.service.loadBalancerIP[5]=,cluster.externalAccess.service.loadBalancerIP[6]=,cluster.nodes=7,cluster.init=false oci://REGISTRY_NAME/REPOSITORY_NAME/redis-cluster +``` + +> 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`. +> Important here to provide the loadBalancerIP parameters for the new nodes empty to not get an index error. + +As we want to add a new node, we are setting `cluster.nodes=7` and we leave empty the LoadBalancerIP for the new node, so the cluster will provide the correct one. +`REDIS_PASSWORD` is the password obtained with the command that appears after the first installation of the Helm Chart. +At this point, you will have a new Redis® Pod that will remain in `crashLoopBackOff` state until we provide the LoadBalancerIP for the new service. +Now, wait until the cluster provides the new LoadBalancerIP for the new service and perform the second upgrade: + +```console +helm upgrade --set "password=${REDIS_PASSWORD},cluster.externalAccess.enabled=true,cluster.externalAccess.service.type=LoadBalancer,cluster.externalAccess.service.loadBalancerIP[0]=,cluster.externalAccess.service.loadBalancerIP[1]=,cluster.externalAccess.service.loadBalancerIP[2]=,cluster.externalAccess.service.loadBalancerIP[3]=,cluster.externalAccess.service.loadBalancerIP[4]=,cluster.externalAccess.service.loadBalancerIP[5]=,cluster.externalAccess.service.loadBalancerIP[6]=,cluster.nodes=7,cluster.init=false,cluster.update.addNodes=true,cluster.update.newExternalIPs[0]=" oci://REGISTRY_NAME/REPOSITORY_NAME/redis-cluster +``` + +> 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`. + +Note we are providing the new IPs at `cluster.update.newExternalIPs`, the flag `cluster.update.addNodes=true` to enable the creation of the Job that adds a new node and now we are setting the LoadBalancerIP of the new service instead of leave it empty. + +> NOTE: To avoid the creation of the Job that initializes the Redis® Cluster again, you will need to provide `cluster.init=false`. + +#### Scale down the cluster + +To scale down the Redis® Cluster, follow these steps: + +First perform a normal upgrade setting the `cluster.nodes` value to the desired number of nodes. It should not be less than `6` and the difference between current number of nodes and the desired should be less or equal to `cluster.replicas` to avoid removing master node an its slaves at the same time. Also it is needed to provide the password using the `password`. For example, having more than 6 nodes, to scale down the cluster to 6 nodes: + +```console +helm upgrade --timeout 600s --set "password=${REDIS_PASSWORD},cluster.nodes=6" . +``` + +The cluster will continue working during the update as long as the quorum is not lost. + +> NOTE: To avoid the creation of the Job that initializes the Redis® Cluster again, you will need to provide `cluster.init=false`. + +Once all the nodes are ready, get the list of nodes in the cluster using the `CLUSTER NODES` command. You will see references to the ones that were removed. Write down the node IDs of the nodes that show `fail`. In the following example the cluster scaled down from 7 to 6 nodes. + +```console +redis-cli -a $REDIS_PASSWORD CLUSTER NODES + +... +b23bcffa1fd64368d445c1d9bd9aeb92641105f7 10.0.0.70:6379@16379 slave,fail - 1645633139060 0 0 connected +... +``` + +In each cluster node, execute the following command. Replace the NODE_ID placeholder. + +```console +redis-cli -a $REDIS_PASSWORD CLUSTER FORGET NODE_ID +``` + +In the previous example the commands would look like this in each cluster node: + +```console +redis-cli -a $REDIS_PASSWORD CLUSTER FORGET b23bcffa1fd64368d445c1d9bd9aeb92641105f7 +``` + +### Using password file + +To use a password file for Redis® you need to create a secret containing the password. + +> *NOTE*: It is important that the file with the password must be called `redis-password` + +And then deploy the Helm Chart using the secret name as parameter: + +```text +usePassword=true +usePasswordFile=true +existingSecret=redis-password-secret +metrics.enabled=true +``` + +### Securing traffic using TLS + +TLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the cluster: + +- `tls.enabled`: Enable TLS support. Defaults to `false` +- `tls.existingSecret`: Name of the secret that contains the certificates. No defaults. +- `tls.certFilename`: Certificate filename. No defaults. +- `tls.certKeyFilename`: Certificate key filename. No defaults. +- `tls.certCAFilename`: CA Certificate filename. No defaults. + +For example: + +First, create the secret with the certificates files: + +```console +kubectl create secret generic certificates-tls-secret --from-file=./cert.pem --from-file=./cert.key --from-file=./ca.pem +``` + +Then, use the following parameters: + +```console +tls.enabled="true" +tls.existingSecret="certificates-tls-secret" +tls.certFilename="cert.pem" +tls.certKeyFilename="cert.key" +tls.certCAFilename="ca.pem" +``` + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Redis® (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Adding extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: REDIS_WHATEVER + value: value +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Metrics + +The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9121) is exposed in the service. Metrics can be scraped from within the cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. + +### Host Kernel Settings + +Redis® may require some changes in the kernel of the host machine to work as expected, in particular increasing the `somaxconn` value and disabling transparent huge pages. +To do so, you can set up a privileged initContainer with the `sysctlImage` config values, for example: + +```yaml +sysctlImage: + enabled: true + mountHostSys: true + command: + - /bin/sh + - -c + - |- + sysctl -w net.core.somaxconn=10000 + echo never > /host-sys/kernel/mm/transparent_hugepage/enabled +``` + +Alternatively, for Kubernetes 1.12+ you can set `podSecurityContext.sysctls` which will configure sysctls for master and slave pods. Example: + +```yaml +podSecurityContext: + sysctls: + - name: net.core.somaxconn + value: "10000" +``` + +Note that this will not disable transparent huge tables. + +### Helm Upgrade + +By default `cluster.init` will be set to `true` in order to initialize the Redis® Cluster in the first installation. If for testing purposes you only want to deploy or upgrade the nodes but avoiding the creation of the cluster you can set `cluster.init` to `false`. + +### Backup and restore + +To back up and restore Redis Cluster Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using [Velero](https://velero.io/), a Kubernetes backup/restore tool. + +These are the steps you will usually follow to back up and restore your Redis Cluster database cluster data: + +- Install Velero on the source and destination clusters. +- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster. +- Use Velero to restore the backed-up PVs on the destination cluster. +- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. + +Refer to our detailed [tutorial on backing up and restoring Redis Cluster deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-redis-cluster-kubernetes/) for more information. + +### NetworkPolicy + +To enable network policy for Redis®, install +[a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), +and set `networkPolicy.enabled` to `true`. + +For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting +the DefaultDeny namespace annotation. Note: this will enforce policy for *all* pods in the namespace: + +```console +kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}" +``` + +With NetworkPolicy enabled, only pods with the generated client label will be +able to connect to Redis®. This label will be displayed in the output +after a successful install. + +With `networkPolicy.ingressNSMatchLabels` pods from other namespaces can connect to redis. Set `networkPolicy.ingressNSPodMatchLabels` to match pod labels in matched namespace. For example, for a namespace labeled `redis=external` and pods in that namespace labeled `redis-client=true` the fields should be set: + +```yaml +networkPolicy: + enabled: true + ingressNSMatchLabels: + redis: external + ingressNSPodMatchLabels: + redis-client: true +``` + +#### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` paremeter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at the `/bitnami` path. The volume is created using dynamic volume provisioning. + +If persistence is disabled, an emptyDir volume is used. **This is only recommended for testing environments** because the required information included in the nodes.conf file is missing. This file contains the relationship between the nodes and the cluster. For example, if any node is down or faulty, when it starts again, it is a self-proclaimed master and also acts as an independent node outside the main cluster as it doesn't have the necessary information to connect to it. + +To reconnect the failed node, run the following: + +See nodes.sh + +```console +$ cat /bitnami/redis/data/nodes.sh +declare -A host_2_ip_array=([redis-node-0]="192.168.192.6" [redis-node-1]="192.168.192.2" [redis-node-2]="192.168.192.4" [redis-node-3]="192.168.192.5" [redis-node-4]="192.168.192.3" [redis-node-5]="192.168.192.7" ) +``` + +Run redis-cli and run [CLUSTER MEET](https://redis.io/commands/cluster-meet/) to any other node in the cluster. Now the node has connected to the main cluster. + +```console +$ REDISCLI_AUTH=bitnami redis-cli +127.0.0.1:6379> cluster meet 192.168.192.7 6379 +OK +``` + +See [#15075](https://github.com/bitnami/charts/issues/15075) ## Parameters @@ -394,314 +692,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/redis > **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/redis-cluster/values.yaml) > **Note for minikube users**: Current versions of minikube (v0.24.1 at the time of writing) provision `hostPath` persistent volumes that are only writable by root. Using chart defaults cause pod failure for the Redis® pod as it attempts to write to the `/bitnami` directory. See minikube issue [1990](https://github.com/kubernetes/minikube/issues/1990) for more information. -## 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. - -### Use a different Redis® version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Cluster topology - -To successfully set the cluster up, it will need to have at least 3 master nodes. The total number of nodes is calculated like- `nodes = numOfMasterNodes + numOfMasterNodes * replicas`. Hence, the defaults `cluster.nodes = 6` and `cluster.replicas = 1` means, 3 master and 3 replica nodes will be deployed by the chart. - -By default the Redis® Cluster is not accessible from outside the Kubernetes cluster, to access the Redis® Cluster from outside you have to set `cluster.externalAccess.enabled=true` at deployment time. It will create in the first installation only 6 LoadBalancer services, one for each Redis® node, once you have the external IPs of each service you will need to perform an upgrade passing those IPs to the `cluster.externalAccess.service.loadbalancerIP` array. - -The replicas will be read-only replicas of the masters. By default only one service is exposed (when not using the external access mode). You will connect your client to the exposed service, regardless you need to read or write. When a write operation arrives to a replica it will redirect the client to the proper master node. For example, using `redis-cli` you will need to provide the `-c` flag for `redis-cli` to follow the redirection automatically. - -Using the external access mode, you can connect to any of the pods and the slaves will redirect the client in the same way as explained before, but the all the IPs will be public. - -In case the master crashes, one of his slaves will be promoted to master. The slots stored by the crashed master will be unavailable until the slave finish the promotion. If a master and all his slaves crash, the cluster will be down until one of them is up again. To avoid downtime, it is possible to configure the number of Redis® nodes with `cluster.nodes` and the number of replicas that will be assigned to each master with `cluster.replicas`. For example: - -- `cluster.nodes=9` ( 3 master plus 2 replicas for each master) -- `cluster.replicas=2` - -Providing the values above, the cluster will have 3 masters and, each master, will have 2 replicas. - -> NOTE: By default `cluster.init` will be set to `true` in order to initialize the Redis® Cluster in the first installation. If for testing purposes you only want to deploy or upgrade the nodes but avoiding the creation of the cluster you can set `cluster.init` to `false`. - -#### Adding a new node to the cluster - -There is a job that will be executed using a `post-upgrade` hook that will allow you to add a new node. To use it, you should provide some parameters to the upgrade: - -- Pass as `password` the password used in the installation time. If you did not provide a password follow the instructions from the NOTES.txt to get the generated password. -- Set the desired number of nodes at `cluster.nodes`. -- Set the number of current nodes at `cluster.update.currentNumberOfNodes`. -- Set to true `cluster.update.addNodes`. - -The following will be an example to add one more node: - -```console -helm upgrade --timeout 600s --set "password=${REDIS_PASSWORD},cluster.nodes=7,cluster.update.addNodes=true,cluster.update.currentNumberOfNodes=6" oci://REGISTRY_NAME/REPOSITORY_NAME/redis-cluster -``` - -> 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`. - -Where `REDIS_PASSWORD` is the password obtained with the command that appears after the first installation of the Helm Chart. -The cluster will continue up while restarting pods one by one as the quorum is not lost. - -##### External Access - -If you are using external access, to add a new node you will need to perform two upgrades. First upgrade the release to add a new Redis® node and to get a LoadBalancerIP service. For example: - -```console -helm upgrade --set "password=${REDIS_PASSWORD},cluster.externalAccess.enabled=true,cluster.externalAccess.service.type=LoadBalancer,cluster.externalAccess.service.loadBalancerIP[0]=,cluster.externalAccess.service.loadBalancerIP[1]=,cluster.externalAccess.service.loadBalancerIP[2]=,cluster.externalAccess.service.loadBalancerIP[3]=,cluster.externalAccess.service.loadBalancerIP[4]=,cluster.externalAccess.service.loadBalancerIP[5]=,cluster.externalAccess.service.loadBalancerIP[6]=,cluster.nodes=7,cluster.init=false oci://REGISTRY_NAME/REPOSITORY_NAME/redis-cluster -``` - -> 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`. -> Important here to provide the loadBalancerIP parameters for the new nodes empty to not get an index error. - -As we want to add a new node, we are setting `cluster.nodes=7` and we leave empty the LoadBalancerIP for the new node, so the cluster will provide the correct one. -`REDIS_PASSWORD` is the password obtained with the command that appears after the first installation of the Helm Chart. -At this point, you will have a new Redis® Pod that will remain in `crashLoopBackOff` state until we provide the LoadBalancerIP for the new service. -Now, wait until the cluster provides the new LoadBalancerIP for the new service and perform the second upgrade: - -```console -helm upgrade --set "password=${REDIS_PASSWORD},cluster.externalAccess.enabled=true,cluster.externalAccess.service.type=LoadBalancer,cluster.externalAccess.service.loadBalancerIP[0]=,cluster.externalAccess.service.loadBalancerIP[1]=,cluster.externalAccess.service.loadBalancerIP[2]=,cluster.externalAccess.service.loadBalancerIP[3]=,cluster.externalAccess.service.loadBalancerIP[4]=,cluster.externalAccess.service.loadBalancerIP[5]=,cluster.externalAccess.service.loadBalancerIP[6]=,cluster.nodes=7,cluster.init=false,cluster.update.addNodes=true,cluster.update.newExternalIPs[0]=" oci://REGISTRY_NAME/REPOSITORY_NAME/redis-cluster -``` - -> 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`. - -Note we are providing the new IPs at `cluster.update.newExternalIPs`, the flag `cluster.update.addNodes=true` to enable the creation of the Job that adds a new node and now we are setting the LoadBalancerIP of the new service instead of leave it empty. - -> NOTE: To avoid the creation of the Job that initializes the Redis® Cluster again, you will need to provide `cluster.init=false`. - -#### Scale down the cluster - -To scale down the Redis® Cluster, follow these steps: - -First perform a normal upgrade setting the `cluster.nodes` value to the desired number of nodes. It should not be less than `6` and the difference between current number of nodes and the desired should be less or equal to `cluster.replicas` to avoid removing master node an its slaves at the same time. Also it is needed to provide the password using the `password`. For example, having more than 6 nodes, to scale down the cluster to 6 nodes: - -```console -helm upgrade --timeout 600s --set "password=${REDIS_PASSWORD},cluster.nodes=6" . -``` - -The cluster will continue working during the update as long as the quorum is not lost. - -> NOTE: To avoid the creation of the Job that initializes the Redis® Cluster again, you will need to provide `cluster.init=false`. - -Once all the nodes are ready, get the list of nodes in the cluster using the `CLUSTER NODES` command. You will see references to the ones that were removed. Write down the node IDs of the nodes that show `fail`. In the following example the cluster scaled down from 7 to 6 nodes. - -```console -redis-cli -a $REDIS_PASSWORD CLUSTER NODES - -... -b23bcffa1fd64368d445c1d9bd9aeb92641105f7 10.0.0.70:6379@16379 slave,fail - 1645633139060 0 0 connected -... -``` - -In each cluster node, execute the following command. Replace the NODE_ID placeholder. - -```console -redis-cli -a $REDIS_PASSWORD CLUSTER FORGET NODE_ID -``` - -In the previous example the commands would look like this in each cluster node: - -```console -redis-cli -a $REDIS_PASSWORD CLUSTER FORGET b23bcffa1fd64368d445c1d9bd9aeb92641105f7 -``` - -### Using password file - -To use a password file for Redis® you need to create a secret containing the password. - -> *NOTE*: It is important that the file with the password must be called `redis-password` - -And then deploy the Helm Chart using the secret name as parameter: - -```text -usePassword=true -usePasswordFile=true -existingSecret=redis-password-secret -metrics.enabled=true -``` - -### Securing traffic using TLS - -TLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the cluster: - -- `tls.enabled`: Enable TLS support. Defaults to `false` -- `tls.existingSecret`: Name of the secret that contains the certificates. No defaults. -- `tls.certFilename`: Certificate filename. No defaults. -- `tls.certKeyFilename`: Certificate key filename. No defaults. -- `tls.certCAFilename`: CA Certificate filename. No defaults. - -For example: - -First, create the secret with the certificates files: - -```console -kubectl create secret generic certificates-tls-secret --from-file=./cert.pem --from-file=./cert.key --from-file=./ca.pem -``` - -Then, use the following parameters: - -```console -tls.enabled="true" -tls.existingSecret="certificates-tls-secret" -tls.certFilename="cert.pem" -tls.certKeyFilename="cert.key" -tls.certCAFilename="ca.pem" -``` - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Redis® (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Adding extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: REDIS_WHATEVER - value: value -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Metrics - -The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9121) is exposed in the service. Metrics can be scraped from within the cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. - -### Host Kernel Settings - -Redis® may require some changes in the kernel of the host machine to work as expected, in particular increasing the `somaxconn` value and disabling transparent huge pages. -To do so, you can set up a privileged initContainer with the `sysctlImage` config values, for example: - -```yaml -sysctlImage: - enabled: true - mountHostSys: true - command: - - /bin/sh - - -c - - |- - sysctl -w net.core.somaxconn=10000 - echo never > /host-sys/kernel/mm/transparent_hugepage/enabled -``` - -Alternatively, for Kubernetes 1.12+ you can set `podSecurityContext.sysctls` which will configure sysctls for master and slave pods. Example: - -```yaml -podSecurityContext: - sysctls: - - name: net.core.somaxconn - value: "10000" -``` - -Note that this will not disable transparent huge tables. - -## Helm Upgrade - -By default `cluster.init` will be set to `true` in order to initialize the Redis® Cluster in the first installation. If for testing purposes you only want to deploy or upgrade the nodes but avoiding the creation of the cluster you can set `cluster.init` to `false`. - -## Persistence - -By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at the `/bitnami` path. The volume is created using dynamic volume provisioning. - -If persistence is disabled, an emptyDir volume is used. **This is only recommended for testing environments** because the required information included in the nodes.conf file is missing. This file contains the relationship between the nodes and the cluster. For example, if any node is down or faulty, when it starts again, it is a self-proclaimed master and also acts as an independent node outside the main cluster as it doesn't have the necessary information to connect to it. - -To reconnect the failed node, run the following: - -See nodes.sh - -```console -$ cat /bitnami/redis/data/nodes.sh -declare -A host_2_ip_array=([redis-node-0]="192.168.192.6" [redis-node-1]="192.168.192.2" [redis-node-2]="192.168.192.4" [redis-node-3]="192.168.192.5" [redis-node-4]="192.168.192.3" [redis-node-5]="192.168.192.7" ) -``` - -Run redis-cli and run [CLUSTER MEET](https://redis.io/commands/cluster-meet/) to any other node in the cluster. Now the node has connected to the main cluster. - -```console -$ REDISCLI_AUTH=bitnami redis-cli -127.0.0.1:6379> cluster meet 192.168.192.7 6379 -OK -``` - -See [#15075](https://github.com/bitnami/charts/issues/15075) - -## Backup and restore - -To back up and restore Redis Cluster Helm chart deployments on Kubernetes, you need to back up the persistent volumes from the source deployment and attach them to a new deployment using [Velero](https://velero.io/), a Kubernetes backup/restore tool. - -These are the steps you will usually follow to back up and restore your Redis Cluster database cluster data: - -- Install Velero on the source and destination clusters. -- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster. -- Use Velero to restore the backed-up PVs on the destination cluster. -- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data. - -Refer to our detailed [tutorial on backing up and restoring Redis Cluster deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-redis-cluster-kubernetes/) for more information. - -## NetworkPolicy - -To enable network policy for Redis®, install -[a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), -and set `networkPolicy.enabled` to `true`. - -For Kubernetes v1.5 & v1.6, you must also turn on NetworkPolicy by setting -the DefaultDeny namespace annotation. Note: this will enforce policy for *all* pods in the namespace: - -```console -kubectl annotate namespace default "net.beta.kubernetes.io/network-policy={\"ingress\":{\"isolation\":\"DefaultDeny\"}}" -``` - -With NetworkPolicy enabled, only pods with the generated client label will be -able to connect to Redis®. This label will be displayed in the output -after a successful install. - -With `networkPolicy.ingressNSMatchLabels` pods from other namespaces can connect to redis. Set `networkPolicy.ingressNSPodMatchLabels` to match pod labels in matched namespace. For example, for a namespace labeled `redis=external` and pods in that namespace labeled `redis-client=true` the fields should be set: - -```yaml -networkPolicy: - enabled: true - ingressNSMatchLabels: - redis: external - ingressNSPodMatchLabels: - redis-client: true -``` - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` paremeter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/redis/README.md b/bitnami/redis/README.md index 6d529356f3..0290136e16 100644 --- a/bitnami/redis/README.md +++ b/bitnami/redis/README.md @@ -57,15 +57,377 @@ The command deploys Redis® on the Kubernetes cluster in the default configur > **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 -```console -helm delete my-release +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. + +### Use a different Redis® version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Bootstrapping with an External Cluster + +This chart is equipped with the ability to bring online a set of Pods that connect to an existing Redis deployment that lies outside of Kubernetes. This effectively creates a hybrid Redis Deployment where both Pods in Kubernetes and Instances such as Virtual Machines can partake in a single Redis Deployment. This is helpful in situations where one may be migrating Redis from Virtual Machines into Kubernetes, for example. To take advantage of this, use the following as an example configuration: + +```yaml +replica: + externalMaster: + enabled: true + host: external-redis-0.internal +sentinel: + externalMaster: + enabled: true + host: external-redis-0.internal ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +:warning: This is currently limited to clusters in which Sentinel and Redis run on the same node! :warning: + +Please also note that the external sentinel must be listening on port `26379`, and this is currently not configurable. + +Once the Kubernetes Redis Deployment is online and confirmed to be working with the existing cluster, the configuration can then be removed and the cluster will remain connected. + +### External DNS + +This chart is equipped to allow leveraging the ExternalDNS project. Doing so will enable ExternalDNS to publish the FQDN for each instance, in the format of `..`. +Example, when using the following configuration: + +```yaml +useExternalDNS: + enabled: true + suffix: prod.example.org + additionalAnnotations: + ttl: 10 +``` + +On a cluster where the name of the Helm release is `a`, the hostname of a Pod is generated as: `a-redis-node-0.a-redis.prod.example.org`. The IP of that FQDN will match that of the associated Pod. This modifies the following parameters of the Redis/Sentinel configuration using this new FQDN: + +- `replica-announce-ip` +- `known-sentinel` +- `known-replica` +- `announce-ip` + +:warning: This requires a working installation of `external-dns` to be fully functional. :warning: + +See the [official ExternalDNS documentation](https://github.com/kubernetes-sigs/external-dns) for additional configuration options. + +### Cluster topologies + +#### Default: Master-Replicas + +When installing the chart with `architecture=replication`, it will deploy a Redis® master StatefulSet and a Redis® replicas StatefulSet. The replicas will be read-replicas of the master. Two services will be exposed: + +- Redis® Master service: Points to the master, where read-write operations can be performed +- Redis® Replicas service: Points to the replicas, where only read operations are allowed by default. + +In case the master crashes, the replicas will wait until the master node is respawned again by the Kubernetes Controller Manager. + +#### Standalone + +When installing the chart with `architecture=standalone`, it will deploy a standalone Redis® StatefulSet. A single service will be exposed: + +- Redis® Master service: Points to the master, where read-write operations can be performed + +#### Master-Replicas with Sentinel + +When installing the chart with `architecture=replication` and `sentinel.enabled=true`, it will deploy a Redis® master StatefulSet (only one master allowed) and a Redis® replicas StatefulSet. In this case, the pods will contain an extra container with Redis® Sentinel. This container will form a cluster of Redis® Sentinel nodes, which will promote a new master in case the actual one fails. + +On graceful termination of the Redis® master pod, a failover of the master is initiated to promote a new master. The Redis® Sentinel container in this pod will wait for the failover to occur before terminating. If `sentinel.redisShutdownWaitFailover=true` is set (the default), the Redis® container will wait for the failover as well before terminating. This increases availability for reads during failover, but may cause stale reads until all clients have switched to the new master. + +In addition to this, only one service is exposed: + +- Redis® service: Exposes port 6379 for Redis® read-only operations and port 26379 for accessing Redis® Sentinel. + +For read-only operations, access the service using port 6379. For write operations, it's necessary to access the Redis® Sentinel cluster and query the current master using the command below (using redis-cli or similar): + +```console +SENTINEL get-master-addr-by-name +``` + +This command will return the address of the current master, which can be accessed from inside the cluster. + +In case the current master crashes, the Sentinel containers will elect a new master node. + +`master.count` greater than `1` is not designed for use when `sentinel.enabled=true`. + +### Multiple masters (experimental) + +When `master.count` is greater than `1`, special care must be taken to create a consistent setup. + +An example of use case is the creation of a redundant set of standalone masters or master-replicas per Kubernetes node where you must ensure: + +- No more than `1` master can be deployed per Kubernetes node +- Replicas and writers can only see the single master of their own Kubernetes node + +One way of achieving this is by setting `master.service.internalTrafficPolicy=Local` in combination with a `master.affinity.podAntiAffinity` spec to never schedule more than one master per Kubernetes node. + +It's recommended to only change `master.count` if you know what you are doing. +`master.count` greater than `1` is not designed for use when `sentinel.enabled=true`. + +### Using a password file + +To use a password file for Redis® you need to create a secret containing the password and then deploy the chart using that secret. Follow these instructions: + +- Create the secret with the password. It is important that the file with the password must be called `redis-password`. + +```console +kubectl create secret generic redis-password-secret --from-file=redis-password.yaml +``` + +- Deploy the Helm Chart using the secret name as parameter: + +```text +usePassword=true +usePasswordFile=true +existingSecret=redis-password-secret +sentinels.enabled=true +metrics.enabled=true +``` + +### Securing traffic using TLS + +TLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the cluster: + +- `tls.enabled`: Enable TLS support. Defaults to `false` +- `tls.existingSecret`: Name of the secret that contains the certificates. No defaults. +- `tls.certFilename`: Certificate filename. No defaults. +- `tls.certKeyFilename`: Certificate key filename. No defaults. +- `tls.certCAFilename`: CA Certificate filename. No defaults. + +For example: + +First, create the secret with the certificates files: + +```console +kubectl create secret generic certificates-tls-secret --from-file=./cert.pem --from-file=./cert.key --from-file=./ca.pem +``` + +Then, use the following parameters: + +```console +tls.enabled="true" +tls.existingSecret="certificates-tls-secret" +tls.certFilename="cert.pem" +tls.certKeyFilename="cert.key" +tls.certCAFilename="ca.pem" +``` + +### Metrics + +The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9121) is exposed in the service. Metrics can be scraped from within the cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. + +If you have enabled TLS by specifying `tls.enabled=true` you also need to specify TLS option to the metrics exporter. You can do that via `metrics.extraArgs`. You can find the metrics exporter CLI flags for TLS [here](https://github.com/oliver006/redis_exporter#command-line-flags). For example: + +You can either specify `metrics.extraArgs.skip-tls-verification=true` to skip TLS verification or providing the following values under `metrics.extraArgs` for TLS client authentication: + +```console +tls-client-key-file +tls-client-cert-file +tls-ca-cert-file +``` + +### Deploy a custom metrics script in the sidecar + +A custom Lua script can be added to the `redis-exporter` sidecar by way of the `metrics.extraArgs.script` parameter. The pathname of the script must exist on the container, or the `redis_exporter` process (and therefore the whole pod) will refuse to start. The script can be provided to the sidecar containers via the `metrics.extraVolumes` and `metrics.extraVolumeMounts` parameters: + +```yaml +metrics: + extraVolumeMounts: + - name: '{{ printf "%s-metrics-script-file" (include "common.names.fullname" .) }}' + mountPath: '{{ printf "/mnt/%s/" (include "common.names.name" .) }}' + readOnly: true + extraVolumes: + - name: '{{ printf "%s-metrics-script-file" (include "common.names.fullname" .) }}' + configMap: + name: '{{ printf "%s-metrics-script" (include "common.names.fullname" .) }}' + extraArgs: + script: '{{ printf "/mnt/%s/my_custom_metrics.lua" (include "common.names.name" .) }}' +``` + +Then deploy the script into the correct location via `extraDeploy`: + +```yaml +extraDeploy: + - apiVersion: v1 + kind: ConfigMap + metadata: + name: '{{ printf "%s-metrics-script" (include "common.names.fullname" .) }}' + data: + my_custom_metrics.lua: | + -- LUA SCRIPT CODE HERE, e.g., + return {'bitnami_makes_the_best_charts', '1'} +``` + +### Host Kernel Settings + +Redis® may require some changes in the kernel of the host machine to work as expected, in particular increasing the `somaxconn` value and disabling transparent huge pages. To do so, you can set up a privileged `initContainer` with the `sysctlImage` config values, for example: + +```yaml +sysctlImage: + enabled: true + mountHostSys: true + command: + - /bin/sh + - -c + - |- + install_packages procps + sysctl -w net.core.somaxconn=10000 + echo never > /host-sys/kernel/mm/transparent_hugepage/enabled +``` + +Alternatively, for Kubernetes 1.12+ you can set `securityContext.sysctls` which will configure `sysctls` for master and slave pods. Example: + +```yaml +securityContext: + sysctls: + - name: net.core.somaxconn + value: "10000" +``` + +Note that this will not disable transparent huge tables. + +### Backup and restore + +To backup and restore Redis deployments on Kubernetes, you will need to create a snapshot of the data in the source cluster, and later restore it in a new cluster with the new parameters. Follow the instructions below: + +#### Step 1: Backup the deployment + +- Connect to one of the nodes and start the Redis CLI tool. Then, run the commands below: + + ```text + $ kubectl exec -it my-release-master-0 bash + $ redis-cli + 127.0.0.1:6379> auth your_current_redis_password + OK + 127.0.0.1:6379> save + OK + ``` + +- Copy the dump file from the Redis node: + + ```console + kubectl cp my-release-master-0:/data/dump.rdb dump.rdb -c redis + ``` + +#### Step 2: Restore the data on the destination cluster + +To restore the data in a new cluster, you will need to create a PVC and then upload the *dump.rdb* file to the new volume. + +Follow the following steps: + +- In the [*values.yaml*](https://github.com/bitnami/charts/blob/main/bitnami/redis/values.yaml) file set the *appendonly* parameter to *no*. You can skip this step if it is already configured as *no* + + ```yaml + commonConfiguration: |- + # Enable AOF https://redis.io/topics/persistence#append-only-file + appendonly no + # Disable RDB persistence, AOF persistence already enabled. + save "" + ``` + + > *Note that the `Enable AOF` comment belongs to the original config file and what you're actually doing is disabling it. This change will only be neccessary for the temporal cluster you're creating to upload the dump.* + +- Start the new cluster to create the PVCs. Use the command below as an example: + + ```console + helm install new-redis -f values.yaml . --set cluster.enabled=true --set cluster.slaveCount=3 + ``` + +- Now that the PVC were created, stop it and copy the *dump.rdp* file on the persisted data by using a helping pod. + + ```text + $ helm delete new-redis + + $ kubectl run --generator=run-pod/v1 -i --rm --tty volpod --overrides=' + { + "apiVersion": "v1", + "kind": "Pod", + "metadata": { + "name": "redisvolpod" + }, + "spec": { + "containers": [{ + "command": [ + "tail", + "-f", + "/dev/null" + ], + "image": "bitnami/minideb", + "name": "mycontainer", + "volumeMounts": [{ + "mountPath": "/mnt", + "name": "redisdata" + }] + }], + "restartPolicy": "Never", + "volumes": [{ + "name": "redisdata", + "persistentVolumeClaim": { + "claimName": "redis-data-new-redis-master-0" + } + }] + } + }' --image="bitnami/minideb" + + $ kubectl cp dump.rdb redisvolpod:/mnt/dump.rdb + $ kubectl delete pod volpod + ``` + +- Restart the cluster: + + > **INFO:** The *appendonly* parameter can be safely restored to your desired value. + + ```console + helm install new-redis -f values.yaml . --set cluster.enabled=true --set cluster.slaveCount=3 + ``` + +### NetworkPolicy + +To enable network policy for Redis®, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`. + +With NetworkPolicy enabled, only pods with the generated client label will be able to connect to Redis. This label will be displayed in the output after a successful install. + +With `networkPolicy.ingressNSMatchLabels` pods from other namespaces can connect to Redis. Set `networkPolicy.ingressNSPodMatchLabels` to match pod labels in matched namespace. For example, for a namespace labeled `redis=external` and pods in that namespace labeled `redis-client=true` the fields should be set: + +```yaml +networkPolicy: + enabled: true + ingressNSMatchLabels: + redis: external + ingressNSPodMatchLabels: + redis-client: true +``` + +#### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at the `/data` path. The volume is created using dynamic volume provisioning. If a Persistent Volume Claim already exists, specify it during installation. + +### Existing PersistentVolumeClaim + +1. Create the PersistentVolume +2. Create the PersistentVolumeClaim +3. Install the chart + +```console +helm install my-release --set master.persistence.existingClaim=PVC_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/redis +``` + +> 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`. ## Parameters @@ -656,378 +1018,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/redis > 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/redis/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. - -### Use a different Redis® version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Bootstrapping with an External Cluster - -This chart is equipped with the ability to bring online a set of Pods that connect to an existing Redis deployment that lies outside of Kubernetes. This effectively creates a hybrid Redis Deployment where both Pods in Kubernetes and Instances such as Virtual Machines can partake in a single Redis Deployment. This is helpful in situations where one may be migrating Redis from Virtual Machines into Kubernetes, for example. To take advantage of this, use the following as an example configuration: - -```yaml -replica: - externalMaster: - enabled: true - host: external-redis-0.internal -sentinel: - externalMaster: - enabled: true - host: external-redis-0.internal -``` - -:warning: This is currently limited to clusters in which Sentinel and Redis run on the same node! :warning: - -Please also note that the external sentinel must be listening on port `26379`, and this is currently not configurable. - -Once the Kubernetes Redis Deployment is online and confirmed to be working with the existing cluster, the configuration can then be removed and the cluster will remain connected. - -### External DNS - -This chart is equipped to allow leveraging the ExternalDNS project. Doing so will enable ExternalDNS to publish the FQDN for each instance, in the format of `..`. -Example, when using the following configuration: - -```yaml -useExternalDNS: - enabled: true - suffix: prod.example.org - additionalAnnotations: - ttl: 10 -``` - -On a cluster where the name of the Helm release is `a`, the hostname of a Pod is generated as: `a-redis-node-0.a-redis.prod.example.org`. The IP of that FQDN will match that of the associated Pod. This modifies the following parameters of the Redis/Sentinel configuration using this new FQDN: - -- `replica-announce-ip` -- `known-sentinel` -- `known-replica` -- `announce-ip` - -:warning: This requires a working installation of `external-dns` to be fully functional. :warning: - -See the [official ExternalDNS documentation](https://github.com/kubernetes-sigs/external-dns) for additional configuration options. - -### Cluster topologies - -#### Default: Master-Replicas - -When installing the chart with `architecture=replication`, it will deploy a Redis® master StatefulSet and a Redis® replicas StatefulSet. The replicas will be read-replicas of the master. Two services will be exposed: - -- Redis® Master service: Points to the master, where read-write operations can be performed -- Redis® Replicas service: Points to the replicas, where only read operations are allowed by default. - -In case the master crashes, the replicas will wait until the master node is respawned again by the Kubernetes Controller Manager. - -#### Standalone - -When installing the chart with `architecture=standalone`, it will deploy a standalone Redis® StatefulSet. A single service will be exposed: - -- Redis® Master service: Points to the master, where read-write operations can be performed - -#### Master-Replicas with Sentinel - -When installing the chart with `architecture=replication` and `sentinel.enabled=true`, it will deploy a Redis® master StatefulSet (only one master allowed) and a Redis® replicas StatefulSet. In this case, the pods will contain an extra container with Redis® Sentinel. This container will form a cluster of Redis® Sentinel nodes, which will promote a new master in case the actual one fails. - -On graceful termination of the Redis® master pod, a failover of the master is initiated to promote a new master. The Redis® Sentinel container in this pod will wait for the failover to occur before terminating. If `sentinel.redisShutdownWaitFailover=true` is set (the default), the Redis® container will wait for the failover as well before terminating. This increases availability for reads during failover, but may cause stale reads until all clients have switched to the new master. - -In addition to this, only one service is exposed: - -- Redis® service: Exposes port 6379 for Redis® read-only operations and port 26379 for accessing Redis® Sentinel. - -For read-only operations, access the service using port 6379. For write operations, it's necessary to access the Redis® Sentinel cluster and query the current master using the command below (using redis-cli or similar): - -```console -SENTINEL get-master-addr-by-name -``` - -This command will return the address of the current master, which can be accessed from inside the cluster. - -In case the current master crashes, the Sentinel containers will elect a new master node. - -`master.count` greater than `1` is not designed for use when `sentinel.enabled=true`. - -### Multiple masters (experimental) - -When `master.count` is greater than `1`, special care must be taken to create a consistent setup. - -An example of use case is the creation of a redundant set of standalone masters or master-replicas per Kubernetes node where you must ensure: - -- No more than `1` master can be deployed per Kubernetes node -- Replicas and writers can only see the single master of their own Kubernetes node - -One way of achieving this is by setting `master.service.internalTrafficPolicy=Local` in combination with a `master.affinity.podAntiAffinity` spec to never schedule more than one master per Kubernetes node. - -It's recommended to only change `master.count` if you know what you are doing. -`master.count` greater than `1` is not designed for use when `sentinel.enabled=true`. - -### Using a password file - -To use a password file for Redis® you need to create a secret containing the password and then deploy the chart using that secret. Follow these instructions: - -- Create the secret with the password. It is important that the file with the password must be called `redis-password`. - -```console -kubectl create secret generic redis-password-secret --from-file=redis-password.yaml -``` - -- Deploy the Helm Chart using the secret name as parameter: - -```text -usePassword=true -usePasswordFile=true -existingSecret=redis-password-secret -sentinels.enabled=true -metrics.enabled=true -``` - -### Securing traffic using TLS - -TLS support can be enabled in the chart by specifying the `tls.` parameters while creating a release. The following parameters should be configured to properly enable the TLS support in the cluster: - -- `tls.enabled`: Enable TLS support. Defaults to `false` -- `tls.existingSecret`: Name of the secret that contains the certificates. No defaults. -- `tls.certFilename`: Certificate filename. No defaults. -- `tls.certKeyFilename`: Certificate key filename. No defaults. -- `tls.certCAFilename`: CA Certificate filename. No defaults. - -For example: - -First, create the secret with the certificates files: - -```console -kubectl create secret generic certificates-tls-secret --from-file=./cert.pem --from-file=./cert.key --from-file=./ca.pem -``` - -Then, use the following parameters: - -```console -tls.enabled="true" -tls.existingSecret="certificates-tls-secret" -tls.certFilename="cert.pem" -tls.certKeyFilename="cert.key" -tls.certCAFilename="ca.pem" -``` - -### Metrics - -The chart optionally can start a metrics exporter for [prometheus](https://prometheus.io). The metrics endpoint (port 9121) is exposed in the service. Metrics can be scraped from within the cluster using something similar as the described in the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. - -If you have enabled TLS by specifying `tls.enabled=true` you also need to specify TLS option to the metrics exporter. You can do that via `metrics.extraArgs`. You can find the metrics exporter CLI flags for TLS [here](https://github.com/oliver006/redis_exporter#command-line-flags). For example: - -You can either specify `metrics.extraArgs.skip-tls-verification=true` to skip TLS verification or providing the following values under `metrics.extraArgs` for TLS client authentication: - -```console -tls-client-key-file -tls-client-cert-file -tls-ca-cert-file -``` - -### Deploy a custom metrics script in the sidecar - -A custom Lua script can be added to the `redis-exporter` sidecar by way of the `metrics.extraArgs.script` parameter. The pathname of the script must exist on the container, or the `redis_exporter` process (and therefore the whole pod) will refuse to start. The script can be provided to the sidecar containers via the `metrics.extraVolumes` and `metrics.extraVolumeMounts` parameters: - -```yaml -metrics: - extraVolumeMounts: - - name: '{{ printf "%s-metrics-script-file" (include "common.names.fullname" .) }}' - mountPath: '{{ printf "/mnt/%s/" (include "common.names.name" .) }}' - readOnly: true - extraVolumes: - - name: '{{ printf "%s-metrics-script-file" (include "common.names.fullname" .) }}' - configMap: - name: '{{ printf "%s-metrics-script" (include "common.names.fullname" .) }}' - extraArgs: - script: '{{ printf "/mnt/%s/my_custom_metrics.lua" (include "common.names.name" .) }}' -``` - -Then deploy the script into the correct location via `extraDeploy`: - -```yaml -extraDeploy: - - apiVersion: v1 - kind: ConfigMap - metadata: - name: '{{ printf "%s-metrics-script" (include "common.names.fullname" .) }}' - data: - my_custom_metrics.lua: | - -- LUA SCRIPT CODE HERE, e.g., - return {'bitnami_makes_the_best_charts', '1'} -``` - -### Host Kernel Settings - -Redis® may require some changes in the kernel of the host machine to work as expected, in particular increasing the `somaxconn` value and disabling transparent huge pages. To do so, you can set up a privileged `initContainer` with the `sysctlImage` config values, for example: - -```yaml -sysctlImage: - enabled: true - mountHostSys: true - command: - - /bin/sh - - -c - - |- - install_packages procps - sysctl -w net.core.somaxconn=10000 - echo never > /host-sys/kernel/mm/transparent_hugepage/enabled -``` - -Alternatively, for Kubernetes 1.12+ you can set `securityContext.sysctls` which will configure `sysctls` for master and slave pods. Example: - -```yaml -securityContext: - sysctls: - - name: net.core.somaxconn - value: "10000" -``` - -Note that this will not disable transparent huge tables. - -## Persistence - -By default, the chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at the `/data` path. The volume is created using dynamic volume provisioning. If a Persistent Volume Claim already exists, specify it during installation. - -### Existing PersistentVolumeClaim - -1. Create the PersistentVolume -2. Create the PersistentVolumeClaim -3. Install the chart - -```console -helm install my-release --set master.persistence.existingClaim=PVC_NAME oci://REGISTRY_NAME/REPOSITORY_NAME/redis -``` - -> 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`. - -## Backup and restore - -To backup and restore Redis deployments on Kubernetes, you will need to create a snapshot of the data in the source cluster, and later restore it in a new cluster with the new parameters. Follow the instructions below: - -### Step 1: Backup the deployment - -- Connect to one of the nodes and start the Redis CLI tool. Then, run the commands below: - - ```text - $ kubectl exec -it my-release-master-0 bash - $ redis-cli - 127.0.0.1:6379> auth your_current_redis_password - OK - 127.0.0.1:6379> save - OK - ``` - -- Copy the dump file from the Redis node: - - ```console - kubectl cp my-release-master-0:/data/dump.rdb dump.rdb -c redis - ``` - -### Step 2: Restore the data on the destination cluster - -To restore the data in a new cluster, you will need to create a PVC and then upload the *dump.rdb* file to the new volume. - -Follow the following steps: - -- In the [*values.yaml*](https://github.com/bitnami/charts/blob/main/bitnami/redis/values.yaml) file set the *appendonly* parameter to *no*. You can skip this step if it is already configured as *no* - - ```yaml - commonConfiguration: |- - # Enable AOF https://redis.io/topics/persistence#append-only-file - appendonly no - # Disable RDB persistence, AOF persistence already enabled. - save "" - ``` - - > *Note that the `Enable AOF` comment belongs to the original config file and what you're actually doing is disabling it. This change will only be neccessary for the temporal cluster you're creating to upload the dump.* - -- Start the new cluster to create the PVCs. Use the command below as an example: - - ```console - helm install new-redis -f values.yaml . --set cluster.enabled=true --set cluster.slaveCount=3 - ``` - -- Now that the PVC were created, stop it and copy the *dump.rdp* file on the persisted data by using a helping pod. - - ```text - $ helm delete new-redis - - $ kubectl run --generator=run-pod/v1 -i --rm --tty volpod --overrides=' - { - "apiVersion": "v1", - "kind": "Pod", - "metadata": { - "name": "redisvolpod" - }, - "spec": { - "containers": [{ - "command": [ - "tail", - "-f", - "/dev/null" - ], - "image": "bitnami/minideb", - "name": "mycontainer", - "volumeMounts": [{ - "mountPath": "/mnt", - "name": "redisdata" - }] - }], - "restartPolicy": "Never", - "volumes": [{ - "name": "redisdata", - "persistentVolumeClaim": { - "claimName": "redis-data-new-redis-master-0" - } - }] - } - }' --image="bitnami/minideb" - - $ kubectl cp dump.rdb redisvolpod:/mnt/dump.rdb - $ kubectl delete pod volpod - ``` - -- Restart the cluster: - - > **INFO:** The *appendonly* parameter can be safely restored to your desired value. - - ```console - helm install new-redis -f values.yaml . --set cluster.enabled=true --set cluster.slaveCount=3 - ``` - -## NetworkPolicy - -To enable network policy for Redis®, install [a networking plugin that implements the Kubernetes NetworkPolicy spec](https://kubernetes.io/docs/tasks/administer-cluster/declare-network-policy#before-you-begin), and set `networkPolicy.enabled` to `true`. - -With NetworkPolicy enabled, only pods with the generated client label will be able to connect to Redis. This label will be displayed in the output after a successful install. - -With `networkPolicy.ingressNSMatchLabels` pods from other namespaces can connect to Redis. Set `networkPolicy.ingressNSPodMatchLabels` to match pod labels in matched namespace. For example, for a namespace labeled `redis=external` and pods in that namespace labeled `redis-client=true` the fields should be set: - -```yaml -networkPolicy: - enabled: true - ingressNSMatchLabels: - redis: external - ingressNSPodMatchLabels: - redis-client: true -``` - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/redmine/README.md b/bitnami/redmine/README.md index c263b18e90..a7be924f80 100644 --- a/bitnami/redmine/README.md +++ b/bitnami/redmine/README.md @@ -45,17 +45,9 @@ The command deploys Redmine on the Kubernetes cluster in the default configurati > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - -## Using PostgreSQL instead of MariaDB +### Using PostgreSQL instead of MariaDB This chart includes the option to use a PostgreSQL database for Redmine instead of MariaDB. To use this, set the `databaseType` parameter to `postgresql`: @@ -65,6 +57,179 @@ helm install my-release oci://REGISTRY_NAME/REPOSITORY_NAME/redmine --set databa > 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`. +### Certificates + +#### CA Certificates + +Custom CA certificates not included in the base docker image can be added with +the following configuration. The secret must exist in the same namespace as the +deployment. Will load all certificates files it finds in the secret. + +```yaml +certificates: + customCAs: + - secret: my-ca-1 + - secret: my-ca-2 +``` + +##### CA Certificates Secret + +Secret can be created with: + +```console +kubectl create secret generic my-ca-1 --from-file my-ca-1.crt +``` + +#### TLS Certificate + +A web server TLS Certificate can be injected into the container with the +following configuration. The certificate will be stored at the location +specified in the certificateLocation value. + +```yaml +certificates: + customCertificate: + certificateSecret: my-secret + certificateLocation: /ssl/server.pem + keyLocation: /ssl/key.pem + chainSecret: + name: my-cert-chain + key: chain.pem +``` + +##### TLS Certificate Secret + +The certificate tls secret can be created with: + +```console +kubectl create secret tls my-secret --cert tls.crt --key tls.key +``` + +The certificate chain is created with: + +```console +kubectl create secret generic my-cert-chain --from-file chain.pem +``` + +### 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. + +### Replicas + +Redmine writes uploaded files to a persistent volume. By default that volume cannot be shared between pods (RWO). In such a configuration the `replicas` option must be set to `1`. If the persistent volume supports more than one writer (RWX), ie NFS, `replicas` can be greater than `1`. + +> **Important**: When running more than one instance of Redmine they must share the same `secret_key_base` to have sessions working acreoss all instances. +> This can be achieved by setting +> +> ```yaml +> extraEnvVars: +> - name: SECRET_KEY_BASE +> value: someredminesecretkeybase +> ``` + +### Deploying to a sub-URI + +(adapted from ) + +On certain occasions, you may need that Redmine is available under a specific sub-URI path rather than the root. A common scenario to this problem may arise if you plan to set up your Redmine container behind a reverse proxy. To deploy your Redmine container using a certain sub-URI you just need to follow these steps: + +#### Create a configmap containing an altered version of post-init.sh + +```yaml +apiVersion: v1 +kind: ConfigMap +metadata: + name: redmine-init-configmap + namespace: + labels: + ... +data: + + post-init.sh: |- + #!/bin/bash + + # REPLACE WITH YOUR OWN SUB-URI + SUB_URI_PATH='/redmine' + + #Config files where to apply changes + config1=/opt/bitnami/redmine/config.ru + config2=/opt/bitnami/redmine/config/environment.rb + + sed -i '$ d' ${config1} + echo 'map ActionController::Base.config.try(:relative_url_root) || "/" do' >> ${config1} + echo 'run Rails.application' >> ${config1} + echo 'end' >> ${config1} + echo 'Redmine::Utils::relative_url_root = "'${SUB_URI_PATH}'"' >> ${config2} + + SUB_URI_PATH=$(echo ${SUB_URI_PATH} | sed -e 's|/|\\/|g') + sed -i -e "s/\(relative_url_root\ \=\ \"\).*\(\"\)/\1${SUB_URI_PATH}\2/" ${config2} +``` + +#### Add this confimap as a volume/volume mount in the chart values + +```yaml +## Extra volumes to add to the deployment +## +extraVolumes: + - name: redmine-init-volume + configMap: + name: redmine-init-configmap + +## Extra volume mounts to add to the container +## +extraVolumeMounts: + - name: "redmine-init-volume" + mountPath: "/post-init.sh" + subPath: post-init.sh +``` + +#### Change the probes URI + +```yaml +## Configure extra options for liveness and readiness probes +## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes) +## +livenessProbe: + enabled: true + path: /redmine/ +--- +readinessProbe: + enabled: true + path: /redmine/ +``` + +## Persistence + +The [Bitnami Redmine](https://github.com/bitnami/containers/tree/main/bitnami/redmine) image stores the Redmine data and configurations at the `/bitnami/redmine` 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. The volume is created using dynamic volume provisioning. Clusters configured with NFS mounts require manually managed volumes and claims. + +See the [Parameters](#parameters) section to configure the PVC or to disable persistence. + +### Existing PersistentVolumeClaims + +The following example includes two PVCs, one for Redmine and another for MariaDB. + +1. Create the PersistentVolume +2. Create the PersistentVolumeClaim +3. Create the directory, on a worker +4. Install the chart + +```console +helm install test --set persistence.existingClaim=PVC_REDMINE,mariadb.persistence.existingClaim=PVC_MARIADB oci://REGISTRY_NAME/REPOSITORY_NAME/redmine +``` + +> 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`. + ## Parameters ### Global parameters @@ -400,181 +565,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/redmi > 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/redmine/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. - -### Replicas - -Redmine writes uploaded files to a persistent volume. By default that volume cannot be shared between pods (RWO). In such a configuration the `replicas` option must be set to `1`. If the persistent volume supports more than one writer (RWX), ie NFS, `replicas` can be greater than `1`. - -> **Important**: When running more than one instance of Redmine they must share the same `secret_key_base` to have sessions working acreoss all instances. -> This can be achieved by setting -> -> ```yaml -> extraEnvVars: -> - name: SECRET_KEY_BASE -> value: someredminesecretkeybase -> ``` - -### Deploying to a sub-URI - -(adapted from ) - -On certain occasions, you may need that Redmine is available under a specific sub-URI path rather than the root. A common scenario to this problem may arise if you plan to set up your Redmine container behind a reverse proxy. To deploy your Redmine container using a certain sub-URI you just need to follow these steps: - -#### Create a configmap containing an altered version of post-init.sh - -```yaml -apiVersion: v1 -kind: ConfigMap -metadata: - name: redmine-init-configmap - namespace: - labels: - ... -data: - - post-init.sh: |- - #!/bin/bash - - # REPLACE WITH YOUR OWN SUB-URI - SUB_URI_PATH='/redmine' - - #Config files where to apply changes - config1=/opt/bitnami/redmine/config.ru - config2=/opt/bitnami/redmine/config/environment.rb - - sed -i '$ d' ${config1} - echo 'map ActionController::Base.config.try(:relative_url_root) || "/" do' >> ${config1} - echo 'run Rails.application' >> ${config1} - echo 'end' >> ${config1} - echo 'Redmine::Utils::relative_url_root = "'${SUB_URI_PATH}'"' >> ${config2} - - SUB_URI_PATH=$(echo ${SUB_URI_PATH} | sed -e 's|/|\\/|g') - sed -i -e "s/\(relative_url_root\ \=\ \"\).*\(\"\)/\1${SUB_URI_PATH}\2/" ${config2} -``` - -#### Add this confimap as a volume/volume mount in the chart values - -```yaml -## Extra volumes to add to the deployment -## -extraVolumes: - - name: redmine-init-volume - configMap: - name: redmine-init-configmap - -## Extra volume mounts to add to the container -## -extraVolumeMounts: - - name: "redmine-init-volume" - mountPath: "/post-init.sh" - subPath: post-init.sh -``` - -#### Change the probes URI - -```yaml -## Configure extra options for liveness and readiness probes -## ref: https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-readiness-probes/#configure-probes) -## -livenessProbe: - enabled: true - path: /redmine/ ---- -readinessProbe: - enabled: true - path: /redmine/ -``` - -## Persistence - -The [Bitnami Redmine](https://github.com/bitnami/containers/tree/main/bitnami/redmine) image stores the Redmine data and configurations at the `/bitnami/redmine` 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. The volume is created using dynamic volume provisioning. Clusters configured with NFS mounts require manually managed volumes and claims. - -See the [Parameters](#parameters) section to configure the PVC or to disable persistence. - -### Existing PersistentVolumeClaims - -The following example includes two PVCs, one for Redmine and another for MariaDB. - -1. Create the PersistentVolume -2. Create the PersistentVolumeClaim -3. Create the directory, on a worker -4. Install the chart - -```console -helm install test --set persistence.existingClaim=PVC_REDMINE,mariadb.persistence.existingClaim=PVC_MARIADB oci://REGISTRY_NAME/REPOSITORY_NAME/redmine -``` - -> 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`. - -## Certificates - -### CA Certificates - -Custom CA certificates not included in the base docker image can be added with -the following configuration. The secret must exist in the same namespace as the -deployment. Will load all certificates files it finds in the secret. - -```yaml -certificates: - customCAs: - - secret: my-ca-1 - - secret: my-ca-2 -``` - -#### CA Certificates Secret - -Secret can be created with: - -```console -kubectl create secret generic my-ca-1 --from-file my-ca-1.crt -``` - -### TLS Certificate - -A web server TLS Certificate can be injected into the container with the -following configuration. The certificate will be stored at the location -specified in the certificateLocation value. - -```yaml -certificates: - customCertificate: - certificateSecret: my-secret - certificateLocation: /ssl/server.pem - keyLocation: /ssl/key.pem - chainSecret: - name: my-cert-chain - key: chain.pem -``` - -#### TLS Certificate Secret - -The certificate tls secret can be created with: - -```console -kubectl create secret tls my-secret --cert tls.crt --key tls.key -``` - -The certificate chain is created with: - -```console -kubectl create secret generic my-cert-chain --from-file chain.pem -``` - ## 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). diff --git a/bitnami/schema-registry/README.md b/bitnami/schema-registry/README.md index 9060b150a0..a9ca0ccf96 100644 --- a/bitnami/schema-registry/README.md +++ b/bitnami/schema-registry/README.md @@ -41,15 +41,160 @@ These commands deploy Schema Registry on the Kubernetes cluster with the default > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` chart: +### 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. + +### Enable authentication for Kafka + +You can configure different authentication protocols for each listener you configure in Kafka. For instance, you can use `sasl_tls` authentication for client communications, while using `tls` for inter-broker communications. This table shows the available protocols and the security they provide: + +| Method | Authentication | Encryption via TLS | +|-----------|------------------------------|--------------------| +| plaintext | None | No | +| tls | None | Yes | +| mtls | Yes (two-way authentication) | Yes | +| sasl | Yes (via SASL) | No | +| sasl_tls | Yes (via SASL) | Yes | + +Configure the authentication protocols for client and inter-broker communications by setting the *auth.clientProtocol* and *auth.interBrokerProtocol* parameters to the desired ones, respectively. + +If you enabled SASL authentication on any listener, you can set the SASL credentials using the parameters below: + +- `kafka.auth.sasl.jaas.clientUsers`/`kafka.auth.sasl.jaas.clientPasswords`: when enabling SASL authentication for communications with clients. +- `kafka.auth.sasl.jaas.interBrokerUser`/`kafka.auth.sasl.jaas.interBrokerPassword`: when enabling SASL authentication for inter-broker communications. +- `kafka.auth.jaas.zookeeperUser`/`kafka.auth.jaas.zookeeperPassword`: In the case that the Zookeeper chart is deployed with SASL authentication enabled. + +For instance, you can deploy the chart with the following parameters: ```console -helm delete my-release +kafka.auth.clientProtocol=sasl +kafka.auth.jaas.clientUsers[0]=clientUser +kafka.auth.jaas.clientPasswords[0]=clientPassword ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +In order to configure TLS authentication/encryption, you **can** create a secret per Kafka broker you have in the cluster containing the Java Key Stores (JKS) files: the truststore (`kafka.truststore.jks`) and the keystore (`kafka.keystore.jks`). Then, you need pass the secret names with the `kafka.auth.tls.existingSecrets` parameter when deploying the chart. + +> **Note**: If the JKS files are password protected (recommended), you will need to provide the password to get access to the keystores. To do so, use the `kafka.auth.tls.password` parameter to provide your password. + +For instance, to configure TLS authentication on a cluster with 2 Kafka brokers, and 1 Schema Registry replica use the commands below to create the secrets: + +```console +kubectl create secret generic schema-registry-jks --from-file=/schema-registry.truststore.jks --from-file=./schema-registry-0.keystore.jks +kubectl create secret generic kafka-jks-0 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-0.keystore.jks +kubectl create secret generic kafka-jks-1 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-1.keystore.jks +``` + +> **Note**: the command above assumes you already created the truststore and keystores files. This [script](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh) can help you with the JKS files generation. + +Then, deploy the chart with the following parameters: + +```console +auth.kafka.jksSecret=schema-registry-jks +auth.kafka.keystorePassword=some-password +auth.kafka.truststorePassword=some-password +kafka.replicaCount=2 +kafka.auth.clientProtocol=tls +kafka.auth.tls.existingSecrets[0]=kafka-jks-0 +kafka.auth.tls.existingSecrets[1]=kafka-jks-1 +kafka.auth.tls.password=jksPassword +``` + +In case you want to ignore hostname verification on Kafka certificates, set the parameter `auth.kafka.tls.endpointIdentificationAlgorithm` with an empty string `""`. In this case, you can reuse the same truststore and keystore for every Kafka broker and Schema Registry replica. For instance, to configure TLS authentication on a cluster with 2 Kafka brokers, and 1 Schema Registry replica use the commands below to create the secrets: + +```console +kubectl create secret generic schema-registry-jks --from-file=schema-registry.truststore.jks=common.truststore.jks --from-file=schema-registry-0.keystore.jks=common.keystore.jks +kubectl create secret generic kafka-jks --from-file=kafka.truststore.jks=common.truststore.jks --from-file=kafka.keystore.jks=common.keystore.jks +``` + +### Adding extra flags + +In case you want to add extra environment variables to Schema Registry, you can use `extraEnvs` parameter. For instance: + +```yaml +extraEnvs: + - name: FOO + value: BAR +``` + +### Using custom configuration + +This helm chart supports using custom configuration for Schema Registry. + +You can specify the configuration for Schema Registry using the `configuration` paramater. In addition, you can also set an external configmap with the configuration file. This is done by setting the `existingConfigmap` parameter. + +### Sidecars and Init Containers + +If you have a need for additional containers to run within the same pod as Schema Registry (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. + +```yaml +sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `initContainers` parameter. + +```yaml +initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### Using an external Kafka + +Sometimes you may want to have Schema Registry connect to an external Kafka cluster rather than installing one as dependency. To do this, the chart allows you to specify credentials for an existing Kafka cluster under the [`externalKafka` parameter](#kafka-chart-parameters). You should also disable the Kafka installation with the `kafka.enabled` option. + +For example, use the parameters below to connect Schema Registry with an existing Kafka installation using SASL authentication: + +```console +kafka.enabled=false +externalKafka.brokers=SASL_PLAINTEXT://kafka-0.kafka-headless.default.svc.cluster.local:9092 +externalKafka.auth.protocol=sasl +externalKafka.auth.jaas.user=myuser +externalKafka.auth.jaas.password=mypassword +``` + +Alternatively, you can use an existing secret with a key "client-passwords": + +```console +kafka.enabled=false +externalKafka.brokers=SASL_PLAINTEXT://kafka-0.kafka-headless.default.svc.cluster.local:9092 +externalKafka.auth.protocol=sasl +externalKafka.auth.jaas.user=myuser +externalKafka.auth.jaas.existingSecret=my-secret +``` + +### 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. +To enable Ingress integration, set `ingress.enabled` to `true`. The `ingress.hostname` property can be used to set the host name. + +#### Hosts + +Most likely you will only want to have one hostname that maps to this Schema Registry installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object is can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. ## Parameters @@ -276,160 +421,9 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/schem > 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/schema-registry/values.yaml) -## Configuration and installation details +## Troubleshooting -### 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. - -### Enable authentication for Kafka - -You can configure different authentication protocols for each listener you configure in Kafka. For instance, you can use `sasl_tls` authentication for client communications, while using `tls` for inter-broker communications. This table shows the available protocols and the security they provide: - -| Method | Authentication | Encryption via TLS | -|-----------|------------------------------|--------------------| -| plaintext | None | No | -| tls | None | Yes | -| mtls | Yes (two-way authentication) | Yes | -| sasl | Yes (via SASL) | No | -| sasl_tls | Yes (via SASL) | Yes | - -Configure the authentication protocols for client and inter-broker communications by setting the *auth.clientProtocol* and *auth.interBrokerProtocol* parameters to the desired ones, respectively. - -If you enabled SASL authentication on any listener, you can set the SASL credentials using the parameters below: - -- `kafka.auth.sasl.jaas.clientUsers`/`kafka.auth.sasl.jaas.clientPasswords`: when enabling SASL authentication for communications with clients. -- `kafka.auth.sasl.jaas.interBrokerUser`/`kafka.auth.sasl.jaas.interBrokerPassword`: when enabling SASL authentication for inter-broker communications. -- `kafka.auth.jaas.zookeeperUser`/`kafka.auth.jaas.zookeeperPassword`: In the case that the Zookeeper chart is deployed with SASL authentication enabled. - -For instance, you can deploy the chart with the following parameters: - -```console -kafka.auth.clientProtocol=sasl -kafka.auth.jaas.clientUsers[0]=clientUser -kafka.auth.jaas.clientPasswords[0]=clientPassword -``` - -In order to configure TLS authentication/encryption, you **can** create a secret per Kafka broker you have in the cluster containing the Java Key Stores (JKS) files: the truststore (`kafka.truststore.jks`) and the keystore (`kafka.keystore.jks`). Then, you need pass the secret names with the `kafka.auth.tls.existingSecrets` parameter when deploying the chart. - -> **Note**: If the JKS files are password protected (recommended), you will need to provide the password to get access to the keystores. To do so, use the `kafka.auth.tls.password` parameter to provide your password. - -For instance, to configure TLS authentication on a cluster with 2 Kafka brokers, and 1 Schema Registry replica use the commands below to create the secrets: - -```console -kubectl create secret generic schema-registry-jks --from-file=/schema-registry.truststore.jks --from-file=./schema-registry-0.keystore.jks -kubectl create secret generic kafka-jks-0 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-0.keystore.jks -kubectl create secret generic kafka-jks-1 --from-file=kafka.truststore.jks=./kafka.truststore.jks --from-file=kafka.keystore.jks=./kafka-1.keystore.jks -``` - -> **Note**: the command above assumes you already created the truststore and keystores files. This [script](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh) can help you with the JKS files generation. - -Then, deploy the chart with the following parameters: - -```console -auth.kafka.jksSecret=schema-registry-jks -auth.kafka.keystorePassword=some-password -auth.kafka.truststorePassword=some-password -kafka.replicaCount=2 -kafka.auth.clientProtocol=tls -kafka.auth.tls.existingSecrets[0]=kafka-jks-0 -kafka.auth.tls.existingSecrets[1]=kafka-jks-1 -kafka.auth.tls.password=jksPassword -``` - -In case you want to ignore hostname verification on Kafka certificates, set the parameter `auth.kafka.tls.endpointIdentificationAlgorithm` with an empty string `""`. In this case, you can reuse the same truststore and keystore for every Kafka broker and Schema Registry replica. For instance, to configure TLS authentication on a cluster with 2 Kafka brokers, and 1 Schema Registry replica use the commands below to create the secrets: - -```console -kubectl create secret generic schema-registry-jks --from-file=schema-registry.truststore.jks=common.truststore.jks --from-file=schema-registry-0.keystore.jks=common.keystore.jks -kubectl create secret generic kafka-jks --from-file=kafka.truststore.jks=common.truststore.jks --from-file=kafka.keystore.jks=common.keystore.jks -``` - -### Adding extra flags - -In case you want to add extra environment variables to Schema Registry, you can use `extraEnvs` parameter. For instance: - -```yaml -extraEnvs: - - name: FOO - value: BAR -``` - -### Using custom configuration - -This helm chart supports using custom configuration for Schema Registry. - -You can specify the configuration for Schema Registry using the `configuration` paramater. In addition, you can also set an external configmap with the configuration file. This is done by setting the `existingConfigmap` parameter. - -### Sidecars and Init Containers - -If you have a need for additional containers to run within the same pod as Schema Registry (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec. - -```yaml -sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `initContainers` parameter. - -```yaml -initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### Using an external Kafka - -Sometimes you may want to have Schema Registry connect to an external Kafka cluster rather than installing one as dependency. To do this, the chart allows you to specify credentials for an existing Kafka cluster under the [`externalKafka` parameter](#kafka-chart-parameters). You should also disable the Kafka installation with the `kafka.enabled` option. - -For example, use the parameters below to connect Schema Registry with an existing Kafka installation using SASL authentication: - -```console -kafka.enabled=false -externalKafka.brokers=SASL_PLAINTEXT://kafka-0.kafka-headless.default.svc.cluster.local:9092 -externalKafka.auth.protocol=sasl -externalKafka.auth.jaas.user=myuser -externalKafka.auth.jaas.password=mypassword -``` - -Alternatively, you can use an existing secret with a key "client-passwords": - -```console -kafka.enabled=false -externalKafka.brokers=SASL_PLAINTEXT://kafka-0.kafka-headless.default.svc.cluster.local:9092 -externalKafka.auth.protocol=sasl -externalKafka.auth.jaas.user=myuser -externalKafka.auth.jaas.existingSecret=my-secret -``` - -### 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. -To enable Ingress integration, set `ingress.enabled` to `true`. The `ingress.hostname` property can be used to set the host name. - -#### Hosts - -Most likely you will only want to have one hostname that maps to this Schema Registry installation. If that's your case, the property `ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `ingress.extraHosts` object is can be specified as an array. You can also use `ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. +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). ## Upgrading @@ -510,10 +504,6 @@ This version bump the version of charts used as dependency in a major. Kafka fro - - -## 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). - ## License Copyright © 2024 Broadcom. The term "Broadcom" refers to Broadcom Inc. and/or its subsidiaries. diff --git a/bitnami/sealed-secrets/README.md b/bitnami/sealed-secrets/README.md index 882d4751b4..5697a1b8ea 100644 --- a/bitnami/sealed-secrets/README.md +++ b/bitnami/sealed-secrets/README.md @@ -41,15 +41,132 @@ The command deploys the Sealed Secrets controller on the Kubernetes cluster in t > **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/). + +### Using kubeseal + +The easiest way to interact with the Sealed Secrets controller is using the **kubeseal** utility. You can install this CLI by downloading the binary from [sealed-secrets/releases](https://github.com/bitnami-labs/sealed-secrets/releases) page. + +Once installed, you can start using it to encrypt your secrets or fetching the controller public certificate as shown in the example below: ```console -helm delete my-release +$ kubeseal --fetch-cert \ +--controller-name=my-release \ +--controller-namespace=my-release-namespace \ +> pub-cert.pem ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Refer to Sealed Secrets documentation for more information about [kubeseal usage](https://github.com/bitnami-labs/sealed-secrets#usage). + +### [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. + +### 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### Sidecars + +If additional containers are needed in the same pod as Sealed Secrets (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. ## Parameters @@ -256,133 +373,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/seale > 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/sealed-secrets/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/). - -### Using kubeseal - -The easiest way to interact with the Sealed Secrets controller is using the **kubeseal** utility. You can install this CLI by downloading the binary from [sealed-secrets/releases](https://github.com/bitnami-labs/sealed-secrets/releases) page. - -Once installed, you can start using it to encrypt your secrets or fetching the controller public certificate as shown in the example below: - -```console -$ kubeseal --fetch-cert \ ---controller-name=my-release \ ---controller-namespace=my-release-namespace \ -> pub-cert.pem -``` - -Refer to Sealed Secrets documentation for more information about [kubeseal usage](https://github.com/bitnami-labs/sealed-secrets#usage). - -### [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. - -### 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### Sidecars - -If additional containers are needed in the same pod as Sealed Secrets (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/solr/README.md b/bitnami/solr/README.md index 8240250ff1..49479a0e71 100644 --- a/bitnami/solr/README.md +++ b/bitnami/solr/README.md @@ -53,6 +53,101 @@ helm delete my-release The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all history too. +## 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. + +### Use a different Apache Solr version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Add extra environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: ZOOKEEPER_VERSION + value: 6 +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Set Pod affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The [Bitnami Solr](https://github.com/bitnami/containers/tree/main/bitnami/solr) image can persist data. If enabled, the persisted path is `/bitnami/solr` by default. + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. + +### Add extra volumes + +The Bitnami Solr chart supports mounting extra volumes (either PVCs, secrets or configmaps) by using the `extraVolumes` and `extraVolumeMounts` property. This can be combined with advanced operations like adding extra init containers and sidecars. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + ## Parameters ### Global parameters @@ -396,101 +491,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/solr > 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/solr/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. - -### Use a different Apache Solr version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Add extra environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: ZOOKEEPER_VERSION - value: 6 -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - -## Persistence - -The [Bitnami Solr](https://github.com/bitnami/containers/tree/main/bitnami/solr) image can persist data. If enabled, the persisted path is `/bitnami/solr` by default. - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. - -### Add extra volumes - -The Bitnami Solr chart supports mounting extra volumes (either PVCs, secrets or configmaps) by using the `extraVolumes` and `extraVolumeMounts` property. This can be combined with advanced operations like adding extra init containers and sidecars. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/sonarqube/README.md b/bitnami/sonarqube/README.md index 96677689e3..4d01eafd9b 100644 --- a/bitnami/sonarqube/README.md +++ b/bitnami/sonarqube/README.md @@ -41,15 +41,189 @@ The command deploys SonarQube™ on the Kubernetes cluster in the default co > **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 -```console -helm delete my-release +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. + +### Default kernel settings + +Currently, SonarQube™ requires some changes in the kernel of the host machine to work as expected. If those values are not set in the underlying operating system, the SonarQube™ containers fail to boot with ERROR messages. More information about these requirements can be found in the links below: + +- [File Descriptor requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html) +- [Virtual memory requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html) + +This chart uses a **privileged** initContainer to change those settings in the Kernel by running: `sysctl -w vm.max_map_count=262144 && sysctl -w fs.file-max=65536`. You can disable the initContainer using the `sysctl.enabled=false` parameter. + +### External database support + +You may want to have SonarQube™ connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, set the `postgresql.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: + +```text +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=5432 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +sonarqube: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Enable metrics + +The chart can optionally start a sidecar exporter for [Prometheus](https://prometheus.io/) to expose JMX metrics. The metrics endpoint is exposed in a separate service. + +To start the sidecar Prometheus exporter, set the *metrics.jmx.enabled* parameter to *true* when deploying the chart. Refer to the chart parameters for the default port number. + +Metrics can be scraped from within the cluster using any of the following approaches: + +- Adding the required annotations in the service for Prometheus to discover the metrics endpoints, as in the example below: + + ```yaml + metrics: + jmx: + service: + annotations: + prometheus.io/scrape: "true" + prometheus.io/port: "10443" + prometheus.io/path: "/" + ``` + +- Creating a ServiceMonitor (when the Prometheus Operator is available in the cluster). You can do this setting the *metrics.serviceMonitor.enabled* parameter to *true* when deploying the chart. +- Using something similar to the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). + +If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. + +### Sidecars + +If additional containers are needed in the same pod as SonarQube™ (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 SonarQube™](https://github.com/bitnami/containers/tree/main/bitnami/sonarqube) image stores the SonarQube™ data and configurations at the `/bitnami/sonarqube` path of the container. Persistent Volume Claims are used to keep the data across deployments. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. + +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. You can enable this initContainer by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -412,190 +586,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/sonar > 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/sonarqube/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. - -### Default kernel settings - -Currently, SonarQube™ requires some changes in the kernel of the host machine to work as expected. If those values are not set in the underlying operating system, the SonarQube™ containers fail to boot with ERROR messages. More information about these requirements can be found in the links below: - -- [File Descriptor requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/file-descriptors.html) -- [Virtual memory requirements](https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html) - -This chart uses a **privileged** initContainer to change those settings in the Kernel by running: `sysctl -w vm.max_map_count=262144 && sysctl -w fs.file-max=65536`. You can disable the initContainer using the `sysctl.enabled=false` parameter. - -### External database support - -You may want to have SonarQube™ connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, set the `postgresql.enabled` parameter to `false` and specify the credentials for the external database using the `externalDatabase.*` parameters. Here is an example: - -```text -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -sonarqube: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Enable metrics - -The chart can optionally start a sidecar exporter for [Prometheus](https://prometheus.io/) to expose JMX metrics. The metrics endpoint is exposed in a separate service. - -To start the sidecar Prometheus exporter, set the *metrics.jmx.enabled* parameter to *true* when deploying the chart. Refer to the chart parameters for the default port number. - -Metrics can be scraped from within the cluster using any of the following approaches: - -- Adding the required annotations in the service for Prometheus to discover the metrics endpoints, as in the example below: - - ```yaml - metrics: - jmx: - service: - annotations: - prometheus.io/scrape: "true" - prometheus.io/port: "10443" - prometheus.io/path: "/" - ``` - -- Creating a ServiceMonitor (when the Prometheus Operator is available in the cluster). You can do this setting the *metrics.serviceMonitor.enabled* parameter to *true* when deploying the chart. -- Using something similar to the [example Prometheus scrape configuration](https://github.com/prometheus/prometheus/blob/master/documentation/examples/prometheus-kubernetes.yml). - -If metrics are to be scraped from outside the cluster, the Kubernetes API proxy can be utilized to access the endpoint. - -### Sidecars - -If additional containers are needed in the same pod as SonarQube™ (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 SonarQube™](https://github.com/bitnami/containers/tree/main/bitnami/sonarqube) image stores the SonarQube™ data and configurations at the `/bitnami/sonarqube` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. - -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/spark/README.md b/bitnami/spark/README.md index f3b708822e..7ece2099c2 100644 --- a/bitnami/spark/README.md +++ b/bitnami/spark/README.md @@ -43,15 +43,113 @@ These commands deploy Apache Spark on the Kubernetes cluster in the default conf > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` statefulset: +### 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. + +### Define custom configuration + +To use a custom configuration, a ConfigMap should be created with the `spark-env.sh` file inside the ConfigMap. The ConfigMap name must be provided at deployment time. + +To set the configuration on the master use `master.configurationConfigMap=configMapName`. To set the configuration on the worker, use `worker.configurationConfigMap=configMapName`. + +These values can be set at the same time in a single ConfigMap or using two ConfigMaps. An additional `spark-defaults.conf` file can be provided in the ConfigMap. You can use both files or one without the other. + +### Submit an application + +To submit an application to the Apache Spark cluster, use the `spark-submit` script, which is available at [https://github.com/apache/spark/tree/master/bin](https://github.com/apache/spark/tree/master/bin). + +The command below illustrates the process of deploying one of the sample applications included with Apache Spark. Replace the `k8s-apiserver-host`, `k8s-apiserver-port`, `spark-master-svc`, and `spark-master-port` placeholders with the correct master host/IP address and port for your deployment. ```console -helm delete my-release +$ ./bin/spark-submit \ + --class org.apache.spark.examples.SparkPi \ + --conf spark.kubernetes.container.image=bitnami/spark:3 \ + --master k8s://https://k8s-apiserver-host:k8s-apiserver-port \ + --conf spark.kubernetes.driverEnv.SPARK_MASTER_URL=spark://spark-master-svc:spark-master-port \ + --deploy-mode cluster \ + ./examples/jars/spark-examples_2.12-3.2.0.jar 1000 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. Use the option `--purge` to delete all persistent volumes too. +This command example assumes that you have downloaded a Spark binary distribution, which can be found at [Download Apache Spark](https://spark.apache.org/downloads.html). + +For a complete walkthrough of the process using a custom application, refer to Spark's guide to [Running Spark on Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html). + +> Be aware that it is currently not possible to submit an application to a standalone cluster if RPC authentication is configured. [Learn more about the issue](https://issues.apache.org/jira/browse/SPARK-25078). + +### Configuring Spark Master as reverse proxy + +Spark offers configuration to enable running Spark Master as reverse proxy for worker and application UIs. This can be useful as the Spark Master UI may otherwise use private IPv4 addresses for links to Spark workers and Spark apps. + +Coupled with `ingress` configuration, you can set `master.configOptions` and `worker.configOptions` to tell Spark to reverse proxy the worker and application UIs to enable access without requiring direct access to their hosts: + +```yaml +master: + configOptions: + -Dspark.ui.reverseProxy=true + -Dspark.ui.reverseProxyUrl=https://spark.your-domain.com +worker: + configOptions: + -Dspark.ui.reverseProxy=true + -Dspark.ui.reverseProxyUrl=https://spark.your-domain.com +ingress: + enabled: true + hostname: spark.your-domain.com +``` + +See the [Spark Configuration](https://spark.apache.org/docs/latest/configuration.html) docs for detail on the parameters. + +### Configure security for Apache Spark + +### Configure SSL communication + +In order to enable secure transport between workers and master, deploy the Helm chart with the `ssl.enabled=true` chart parameter. + +### Create certificate and password secrets + +It is necessary to create two secrets for the passwords and certificates. The names of the two secrets should be configured using the `security.passwordsSecretName` and `security.ssl.existingSecret` chart parameters. + +#### Create certificates and the certificate secret + +To generate the certificates secret, first generate the two certificates and rename them to `spark-keystore.jks` and `spark-truststore.jks`. Use [this script to generate certificates](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh) for test purposes if required. + +Once the certificates are created, create a secret for them with the file names as keys. The keys must be named `spark-keystore.jks` and `spark-truststore.jks`, and the content must be text in JKS format. + +#### Create the password secret + +The secret for passwords should have three keys: `rpc-authentication-secret`, `ssl-keystore-password` and `ssl-truststore-password`. + +#### Configure the chart + +Once the secrets are created, configure the chart and set the various security-related parameters, including the `security.certificatesSecretName` and `security.passwordsSecretName` parameters referencing the secrets created previously. Here is an example configuration for chart deployment: + +```text +security.certificatesSecretName=my-secret +security.passwordsSecretName=my-passwords-secret +security.rpc.authenticationEnabled=true +security.rpc.encryptionEnabled=true +security.storageEncrytionEnabled=true +security.ssl.enabled=true +security.ssl.needClientAuth=true +``` + +> NOTE: It is currently not possible to submit an application to a standalone cluster if RPC authentication is configured. [Learn more about this issue](https://issues.apache.org/jira/browse/SPARK-25078). + +### Set Pod affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. ## Parameters @@ -378,114 +476,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/spark > 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/spark/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. - -### Define custom configuration - -To use a custom configuration, a ConfigMap should be created with the `spark-env.sh` file inside the ConfigMap. The ConfigMap name must be provided at deployment time. - -To set the configuration on the master use `master.configurationConfigMap=configMapName`. To set the configuration on the worker, use `worker.configurationConfigMap=configMapName`. - -These values can be set at the same time in a single ConfigMap or using two ConfigMaps. An additional `spark-defaults.conf` file can be provided in the ConfigMap. You can use both files or one without the other. - -### Submit an application - -To submit an application to the Apache Spark cluster, use the `spark-submit` script, which is available at [https://github.com/apache/spark/tree/master/bin](https://github.com/apache/spark/tree/master/bin). - -The command below illustrates the process of deploying one of the sample applications included with Apache Spark. Replace the `k8s-apiserver-host`, `k8s-apiserver-port`, `spark-master-svc`, and `spark-master-port` placeholders with the correct master host/IP address and port for your deployment. - -```console -$ ./bin/spark-submit \ - --class org.apache.spark.examples.SparkPi \ - --conf spark.kubernetes.container.image=bitnami/spark:3 \ - --master k8s://https://k8s-apiserver-host:k8s-apiserver-port \ - --conf spark.kubernetes.driverEnv.SPARK_MASTER_URL=spark://spark-master-svc:spark-master-port \ - --deploy-mode cluster \ - ./examples/jars/spark-examples_2.12-3.2.0.jar 1000 -``` - -This command example assumes that you have downloaded a Spark binary distribution, which can be found at [Download Apache Spark](https://spark.apache.org/downloads.html). - -For a complete walkthrough of the process using a custom application, refer to Spark's guide to [Running Spark on Kubernetes](https://spark.apache.org/docs/latest/running-on-kubernetes.html). - -> Be aware that it is currently not possible to submit an application to a standalone cluster if RPC authentication is configured. [Learn more about the issue](https://issues.apache.org/jira/browse/SPARK-25078). - -### Configuring Spark Master as reverse proxy - -Spark offers configuration to enable running Spark Master as reverse proxy for worker and application UIs. This can be useful as the Spark Master UI may otherwise use private IPv4 addresses for links to Spark workers and Spark apps. - -Coupled with `ingress` configuration, you can set `master.configOptions` and `worker.configOptions` to tell Spark to reverse proxy the worker and application UIs to enable access without requiring direct access to their hosts: - -```yaml -master: - configOptions: - -Dspark.ui.reverseProxy=true - -Dspark.ui.reverseProxyUrl=https://spark.your-domain.com -worker: - configOptions: - -Dspark.ui.reverseProxy=true - -Dspark.ui.reverseProxyUrl=https://spark.your-domain.com -ingress: - enabled: true - hostname: spark.your-domain.com -``` - -See the [Spark Configuration](https://spark.apache.org/docs/latest/configuration.html) docs for detail on the parameters. - -### Configure security for Apache Spark - -### Configure SSL communication - -In order to enable secure transport between workers and master, deploy the Helm chart with the `ssl.enabled=true` chart parameter. - -### Create certificate and password secrets - -It is necessary to create two secrets for the passwords and certificates. The names of the two secrets should be configured using the `security.passwordsSecretName` and `security.ssl.existingSecret` chart parameters. - -#### Create certificates and the certificate secret - -To generate the certificates secret, first generate the two certificates and rename them to `spark-keystore.jks` and `spark-truststore.jks`. Use [this script to generate certificates](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh) for test purposes if required. - -Once the certificates are created, create a secret for them with the file names as keys. The keys must be named `spark-keystore.jks` and `spark-truststore.jks`, and the content must be text in JKS format. - -#### Create the password secret - -The secret for passwords should have three keys: `rpc-authentication-secret`, `ssl-keystore-password` and `ssl-truststore-password`. - -#### Configure the chart - -Once the secrets are created, configure the chart and set the various security-related parameters, including the `security.certificatesSecretName` and `security.passwordsSecretName` parameters referencing the secrets created previously. Here is an example configuration for chart deployment: - -```text -security.certificatesSecretName=my-secret -security.passwordsSecretName=my-passwords-secret -security.rpc.authenticationEnabled=true -security.rpc.encryptionEnabled=true -security.storageEncrytionEnabled=true -security.ssl.enabled=true -security.ssl.needClientAuth=true -``` - -> NOTE: It is currently not possible to submit an application to a standalone cluster if RPC authentication is configured. [Learn more about this issue](https://issues.apache.org/jira/browse/SPARK-25078). - -### Set Pod affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/spring-cloud-dataflow/README.md b/bitnami/spring-cloud-dataflow/README.md index 53274f50e7..854fb8b639 100644 --- a/bitnami/spring-cloud-dataflow/README.md +++ b/bitnami/spring-cloud-dataflow/README.md @@ -40,14 +40,195 @@ These commands deploy Spring Cloud Data Flow on the Kubernetes cluster with the > **Tip**: List all releases using `helm list` -## Uninstalling the Chart +## Configuration and installation details -To uninstall/delete the `my-release` chart: +### 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. + +### Features + +If you only need to deploy tasks and schedules, streaming and Skipper can be disabled: ```console -helm uninstall my-release +server.configuration.batchEnabled=true +server.configuration.streamingEnabled=false +skipper.enabled=false +rabbitmq.enabled=false ``` +If you only need to deploy streams, tasks and schedules can be disabled: + +```console +server.configuration.batchEnabled=false +server.configuration.streamingEnabled=true +skipper.enabled=true +rabbitmq.enabled=true +``` + +NOTE: Both `server.configuration.batchEnabled` and `server.configuration.streamingEnabled` should not be set to `false` at the same time. + +### Messaging solutions + +There are two supported messaging solutions in this chart: + +- RabbitMQ (default) +- Kafka + +To change the messaging layer to Kafka, use the following parameters: + +```console +rabbitmq.enabled=false +kafka.enabled=true +``` + +Only one messaging layer can be used at a given time. + +### Using an external database + +Sometimes you may want to have Spring Cloud components connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#database-parameters). You should also disable the MariaDB installation with the `mariadb.enabled` option. For example with the following parameters: + +```console +mariadb.enabled=false +externalDatabase.scheme=mariadb +externalDatabase.host=myexternalhost +externalDatabase.port=3306 +externalDatabase.password=mypassword +externalDatabase.dataflow.user=mydataflowuser +externalDatabase.dataflow.database=mydataflowdatabase +externalDatabase.skipper.user=myskipperuser +externalDatabase.skipper.database=myskipperdatabase +``` + +NOTE: When using the individual properties (scheme, host, port, database, an optional jdbcParameters) this chart will format the JDBC URL as `jdbc:{scheme}://{host}:{port}/{database}{jdbcParameters}`. The URL format follows that of the MariaDB database drive but may not work for other database vendors. + +To use an alternate database vendor (other than MariaDB) you can use the `externalDatabase.dataflow.url` and `externalDatabase.skipper.url` properties to provide the JDBC URLs for the dataflow server and skipper respectively. If these properties are defined, they will take precedence over the individual attributes. As an example of configuring an external MS SQL Server database: + +```console +mariadb.enabled=false +externalDatabase.password=mypassword +externalDatabase.dataflow.url=jdbc:sqlserver://mssql-server:1433 +externalDatabase.dataflow.user=mydataflowuser +externalDatabase.skipper.url=jdbc:sqlserver://mssql-server:1433 +externalDatabase.skipper.user=myskipperuser +externalDatabase.hibernateDialect=org.hibernate.dialect.SQLServer2012Dialect +``` + +NOTE: If you disable MariaDB per above you MUST supply values for the `externalDatabase` connection. + +### Adding extra flags + +In case you want to add extra environment variables to any Spring Cloud component, you can use `XXX.extraEnvs` parameter(s), where XXX is placeholder you need to replace with the actual component(s). For instance, to add extra flags to Spring Cloud Data Flow, use: + +```yaml +server: + extraEnvs: + - name: FOO + value: BAR +``` + +### Using custom Dataflow configuration + +This helm chart supports using custom configuration for Dataflow server. + +You can specify the configuration for Dataflow server by setting the `server.existingConfigmap` parameter to an external ConfigMap with the configuration file. + +### Using custom Skipper configuration + +This helm chart supports using custom configuration for Skipper server. + +You can specify the configuration for Skipper server by setting the `skipper.existingConfigmap` parameter to an external ConfigMap with the configuration file. + +### Sidecars and Init Containers + +If you need additional containers to run within the same pod as Dataflow or Skipper components (e.g. an additional metrics or logging exporter), you can do so via the `XXX.sidecars` parameter(s), where XXX is the placeholder you need to replace with the actual component(s). Simply define your container according to the Kubernetes container spec. + +```yaml +server: + sidecars: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +Similarly, you can add extra init containers using the `XXX.initContainers` parameter(s). + +```yaml +server: + initContainers: + - name: your-image-name + image: your-image + imagePullPolicy: Always + ports: + - name: portname + containerPort: 1234 +``` + +### 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. + +To enable ingress integration, please set `server.ingress.enabled` to `true` + +#### Hosts + +Most likely you will only want to have one hostname that maps to this Spring Cloud Data Flow installation. If that's your case, the property `server.ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `server.ingress.extraHosts` object is can be specified as an array. You can also use `server.ingress.extraTLS` to add the TLS configuration for extra hosts. + +For each host indicated at `server.ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. + +For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. + +#### TLS + +This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are four common use cases: + +- Helm generates/manages certificate secrets based on the parameters. +- User generates/manages certificates separately. +- Helm creates self-signed certificates and generates/manages certificate secrets. +- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. +In the first two cases, it's needed a certificate and a key. We would expect them to look like this: +- certificate files should look like (and there can be more than one certificate if there is a certificate chain) + + ```console + -----BEGIN CERTIFICATE----- + MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV + ... + jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 + -----END CERTIFICATE----- + ``` + +- keys should look like: + + ```console + -----BEGIN RSA PRIVATE KEY----- + MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 + ... + wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= + -----END RSA PRIVATE KEY----- + ``` + +- If you are going to use Helm to manage the certificates based on the parameters, please copy these values into the `certificate` and `key` values for a given `server.ingress.secrets` entry. +- In case you are going to manage TLS secrets separately, please know that you must 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 `server.ingress.hostname` parameter). +- To use self-signed certificates created by Helm, set `server.ingress.tls` to `true` and `server.ingress.certManager` to `false`. +- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, set `server.ingress.certManager` boolean to true to enable the corresponding annotations for cert-manager. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + ## Parameters ### Global parameters @@ -570,195 +751,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/sprin > 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/blob/main/bitnami/spring-cloud-dataflow/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. - -### Features - -If you only need to deploy tasks and schedules, streaming and Skipper can be disabled: - -```console -server.configuration.batchEnabled=true -server.configuration.streamingEnabled=false -skipper.enabled=false -rabbitmq.enabled=false -``` - -If you only need to deploy streams, tasks and schedules can be disabled: - -```console -server.configuration.batchEnabled=false -server.configuration.streamingEnabled=true -skipper.enabled=true -rabbitmq.enabled=true -``` - -NOTE: Both `server.configuration.batchEnabled` and `server.configuration.streamingEnabled` should not be set to `false` at the same time. - -### Messaging solutions - -There are two supported messaging solutions in this chart: - -- RabbitMQ (default) -- Kafka - -To change the messaging layer to Kafka, use the following parameters: - -```console -rabbitmq.enabled=false -kafka.enabled=true -``` - -Only one messaging layer can be used at a given time. - -### Using an external database - -Sometimes you may want to have Spring Cloud components connect to an external database rather than installing one inside your cluster, e.g. to use a managed database service, or use a single database server for all your applications. To do this, the chart allows you to specify credentials for an external database under the [`externalDatabase` parameter](#database-parameters). You should also disable the MariaDB installation with the `mariadb.enabled` option. For example with the following parameters: - -```console -mariadb.enabled=false -externalDatabase.scheme=mariadb -externalDatabase.host=myexternalhost -externalDatabase.port=3306 -externalDatabase.password=mypassword -externalDatabase.dataflow.user=mydataflowuser -externalDatabase.dataflow.database=mydataflowdatabase -externalDatabase.skipper.user=myskipperuser -externalDatabase.skipper.database=myskipperdatabase -``` - -NOTE: When using the individual properties (scheme, host, port, database, an optional jdbcParameters) this chart will format the JDBC URL as `jdbc:{scheme}://{host}:{port}/{database}{jdbcParameters}`. The URL format follows that of the MariaDB database drive but may not work for other database vendors. - -To use an alternate database vendor (other than MariaDB) you can use the `externalDatabase.dataflow.url` and `externalDatabase.skipper.url` properties to provide the JDBC URLs for the dataflow server and skipper respectively. If these properties are defined, they will take precedence over the individual attributes. As an example of configuring an external MS SQL Server database: - -```console -mariadb.enabled=false -externalDatabase.password=mypassword -externalDatabase.dataflow.url=jdbc:sqlserver://mssql-server:1433 -externalDatabase.dataflow.user=mydataflowuser -externalDatabase.skipper.url=jdbc:sqlserver://mssql-server:1433 -externalDatabase.skipper.user=myskipperuser -externalDatabase.hibernateDialect=org.hibernate.dialect.SQLServer2012Dialect -``` - -NOTE: If you disable MariaDB per above you MUST supply values for the `externalDatabase` connection. - -### Adding extra flags - -In case you want to add extra environment variables to any Spring Cloud component, you can use `XXX.extraEnvs` parameter(s), where XXX is placeholder you need to replace with the actual component(s). For instance, to add extra flags to Spring Cloud Data Flow, use: - -```yaml -server: - extraEnvs: - - name: FOO - value: BAR -``` - -### Using custom Dataflow configuration - -This helm chart supports using custom configuration for Dataflow server. - -You can specify the configuration for Dataflow server by setting the `server.existingConfigmap` parameter to an external ConfigMap with the configuration file. - -### Using custom Skipper configuration - -This helm chart supports using custom configuration for Skipper server. - -You can specify the configuration for Skipper server by setting the `skipper.existingConfigmap` parameter to an external ConfigMap with the configuration file. - -### Sidecars and Init Containers - -If you need additional containers to run within the same pod as Dataflow or Skipper components (e.g. an additional metrics or logging exporter), you can do so via the `XXX.sidecars` parameter(s), where XXX is the placeholder you need to replace with the actual component(s). Simply define your container according to the Kubernetes container spec. - -```yaml -server: - sidecars: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -Similarly, you can add extra init containers using the `XXX.initContainers` parameter(s). - -```yaml -server: - initContainers: - - name: your-image-name - image: your-image - imagePullPolicy: Always - ports: - - name: portname - containerPort: 1234 -``` - -### 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. - -To enable ingress integration, please set `server.ingress.enabled` to `true` - -#### Hosts - -Most likely you will only want to have one hostname that maps to this Spring Cloud Data Flow installation. If that's your case, the property `server.ingress.hostname` will set it. However, it is possible to have more than one host. To facilitate this, the `server.ingress.extraHosts` object is can be specified as an array. You can also use `server.ingress.extraTLS` to add the TLS configuration for extra hosts. - -For each host indicated at `server.ingress.extraHosts`, please indicate a `name`, `path`, and any `annotations` that you may want the ingress controller to know about. - -For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/main/docs/user-guide/nginx-configuration/annotations.md). Not all annotations are supported by all ingress controllers, but this document does a good job of indicating which annotation is supported by many popular ingress controllers. - -#### TLS - -This chart will facilitate the creation of TLS secrets for use with the ingress controller, however, this is not required. There are four common use cases: - -- Helm generates/manages certificate secrets based on the parameters. -- User generates/manages certificates separately. -- Helm creates self-signed certificates and generates/manages certificate secrets. -- An additional tool (like [cert-manager](https://github.com/jetstack/cert-manager/)) manages the secrets for the application. -In the first two cases, it's needed a certificate and a key. We would expect them to look like this: -- certificate files should look like (and there can be more than one certificate if there is a certificate chain) - - ```console - -----BEGIN CERTIFICATE----- - MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV - ... - jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7 - -----END CERTIFICATE----- - ``` - -- keys should look like: - - ```console - -----BEGIN RSA PRIVATE KEY----- - MIIEogIBAAKCAQEAvLYcyu8f3skuRyUgeeNpeDvYBCDcgq+LsWap6zbX5f8oLqp4 - ... - wrj2wDbCDCFmfqnSJ+dKI3vFLlEz44sAV8jX/kd4Y6ZTQhlLbYc= - -----END RSA PRIVATE KEY----- - ``` - -- If you are going to use Helm to manage the certificates based on the parameters, please copy these values into the `certificate` and `key` values for a given `server.ingress.secrets` entry. -- In case you are going to manage TLS secrets separately, please know that you must 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 `server.ingress.hostname` parameter). -- To use self-signed certificates created by Helm, set `server.ingress.tls` to `true` and `server.ingress.certManager` to `false`. -- If your cluster has a [cert-manager](https://github.com/jetstack/cert-manager) add-on to automate the management and issuance of TLS certificates, set `server.ingress.certManager` boolean to true to enable the corresponding annotations for cert-manager. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## Troubleshooting Find more information about how to deal with common errors related to Bitnami Helm charts in [this troubleshooting guide](https://docs.bitnami.com/general/how-to/troubleshoot-helm-chart-issues). diff --git a/bitnami/supabase/README.md b/bitnami/supabase/README.md index d5ebf83a15..04a8ea2504 100644 --- a/bitnami/supabase/README.md +++ b/bitnami/supabase/README.md @@ -44,15 +44,149 @@ The command deploys Supabase on the Kubernetes cluster in the default configurat > **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. + +### External database support + +You may want to have supabase connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the PostgreSQL installation with the `postgresql.enabled` option. Here is an example: ```console -helm delete my-release +postgresql.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=5432 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### 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.To enable Ingress integration, set `studio.ingress.enabled` to `true`. + +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 + +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the different component sections. + +```yaml +rest: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the specific component sections. + +### 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. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the specific component sections. + +## Persistence + +The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at `/bitnami/supabase-storage`. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can also be defined. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). ## Parameters @@ -901,150 +1035,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/supab > 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/supabase/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. - -### External database support - -You may want to have supabase connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#parameters). You should also disable the PostgreSQL installation with the `postgresql.enabled` option. Here is an example: - -```console -postgresql.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -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.To enable Ingress integration, set `studio.ingress.enabled` to `true`. - -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 - -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 - -The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) volume at `/bitnami/supabase-storage`. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can also be defined. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the different component sections. - -```yaml -rest: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the specific component sections. - -### 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. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the specific component sections. - ## 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). diff --git a/bitnami/tensorflow-resnet/README.md b/bitnami/tensorflow-resnet/README.md index 98d01bcfe8..d81bf36b8d 100644 --- a/bitnami/tensorflow-resnet/README.md +++ b/bitnami/tensorflow-resnet/README.md @@ -41,21 +41,25 @@ These commands deploy Tensorflow Serving ResNet model on the Kubernetes cluster > **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 -```console -helm delete my-release -``` +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. -You can check your releases with: +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/). -```console -helm list -``` +### [Rolling vs Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers) -The command removes all the Kubernetes components associated with the chart and deletes the release. +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. + +### Set Pod affinity + +This chart allows you to set custom Pod 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 any 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. ## Parameters @@ -207,26 +211,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/tenso > 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/tensorflow-resnet/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. - -### Set Pod affinity - -This chart allows you to set custom Pod 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 any 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. - ## 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). diff --git a/bitnami/thanos/README.md b/bitnami/thanos/README.md index d73c3cfc7b..3d255047ab 100644 --- a/bitnami/thanos/README.md +++ b/bitnami/thanos/README.md @@ -42,14 +42,6 @@ These commands deploy Thanos on the Kubernetes cluster with the default configur > **Tip**: List all releases using `helm list` -## Uninstalling the Chart - -To uninstall/delete the `my-release` chart: - -```console -helm uninstall my-release -``` - ## Architecture This charts allows you install several Thanos components, so you deploy an architecture as the one below: @@ -83,6 +75,238 @@ This charts allows you install several Thanos components, so you deploy an archi Check the section [Integrate Thanos with Prometheus and Alertmanager](#integrate-thanos-with-prometheus-and-alertmanager) for detailed instructions to deploy this architecture. +## 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. + +### Adding extra flags + +In case you want to add extra flags to any Thanos component, you can use `XXX.extraFlags` parameter(s), where XXX is placeholder you need to replace with the actual component(s). For instance, to add extra flags to Thanos Store Gateway, use: + +```yaml +storegateway: + extraFlags: + - --sync-block-duration=3m + - --chunk-pool-size=2GB +``` + +This also works for multi-line flags. This can be useful when you want to configure caching for a particular component without using a configMap. For example, to configure the [query-range response cache of the Thanos Query Frontend](https://thanos.io/tip/components/query-frontend.md/#memcached), use: + +```yaml +queryFrontend: + extraFlags: + - | + --query-range.response-cache-config= + type: MEMCACHED + config: + addresses: + - :11211 + timeout: 500ms + max_idle_connections: 100 + max_async_concurrency: 10 + max_async_buffer_size: 10000 + max_get_multi_concurrency: 100 + max_get_multi_batch_size: 0 + dns_provider_update_interval: 10s + expiration: 24h +``` + +### Using custom Objstore configuration + +This helm chart supports using custom Objstore configuration. + +You can specify the Objstore configuration using the `objstoreConfig` parameter. + +In addition, you can also set an external Secret with the configuration file. This is done by setting the `existingObjstoreSecret` parameter. Note that this will override the previous option. If needed you can also provide a custom Secret Key with `existingObjstoreSecretItems`, please be aware that the Path of your Secret should be `objstore.yml`. + +### Using custom Query Service Discovery configuration + +This helm chart supports using custom Service Discovery configuration for Query. + +You can specify the Service Discovery configuration using the `query.sdConfig` parameter. + +In addition, you can also set an external ConfigMap with the Service Discovery configuration file. This is done by setting the `query.existingSDConfigmap` parameter. Note that this will override the previous option. + +### Using custom Ruler configuration + +This helm chart supports using custom Ruler configuration. + +You can specify the Ruler configuration using the `ruler.config` parameter. + +In addition, you can also set an external ConfigMap with the configuration file. This is done by setting the `ruler.existingConfigmap` parameter. Note that this will override the previous option. + +### Running Thanos with HTTPS and basic authentication + +This helm charts supports using HTTPS and basic authentication. The underlying feature is experimental and might change in the future, so are the associated settings in the chart. +For more information, please refer to [Thanos documentation](https://thanos.io/tip/operating/https.md/#running-thanos-with-https-and-basic-authentication). + +This feature can be enabled by using the following values: + +- `https.enabled=true`. Enabling HTTPS requires the user to provide the TLS certificate and Key for Thanos, which can be done using one of the following options: + + - Provide a secret using `https.existingSecret`. The secret must contain the keys `tls.crt` or `tls.key` (key names can be renamed using the values `https.keyFilename` and `https.certFilename`). + - Provide the certificate and key in your values.yaml under the values `https.cert` and `https.key`. + - Use `https.autoGenerated=true`, using this value Helm will generate a self-signed key pair during the chart initialization. Not recommended for production environments. + +- `auth.basicAuthUsers.*`. An dictionary of key / values, where the keys corresponds to the users that will have access to Thanos and the values are the plaintext passwords. Passwords will be later encrypted with bcrypt. +- Alternatively, provide your own Thanos http config file using the value `httpConfig` or `existingHttpConfigSecret`. This may cause any settings under `https.*` or `auth.*` to be ignored, except for the settings related to the TLS certificates. When providing a configuration file using these parameters, the chart Probes will fail to initialize unless one of the following fixes are applied: + - Set `https.enabled` or `auth.basicAuthUsers` with at least one user, matching the configuration file you provided. That way Probes will be configured with HTTPS and/or basic authentication accordingly. + - Configure your own Probes using `.customLivenessProbe`, `.customReadinessProbe` and `.customStartupProbe`. + - **Not recommended**. Disable the Probes. + +### Store time partitions + +Thanos store supports partion based on time. + +Setting time partitions will create N number of store statefulsets based on the number of items in the `timePartitioning` list. Each item must contain the min and max time for querying in the supported format (find more details at [Thanos documentation](https://thanos.io/tip/components/store.md/#time-based-partitioning)). + +> Note: leaving the `timePartitioning` list empty (`[]`) will create a single store for all data. + +For instance, to use 3 stores you can use a **values.yaml** like the one below: + +```yaml +timePartitioning: + # One store for data older than 6 weeks + - min: "" + max: -6w + # One store for data newer than 6 weeks and older than 2 weeks + - min: -6w + max: -2w + # One store for data newer than 2 weeks + - min: -2w + max: "" +``` + +You can also specify different resources and limits configurations for each storegateway statefulset. This is done by adding a `resources.requests` and `resources.limits` to each item you wish to change, as shown below: + +```yaml +timePartitioning: + # One store for data older than 6 weeks + - min: "" + max: -6w + # One store for data newer than 6 weeks and older than 2 weeks + - min: -6w + max: -2w + resources: #optional resources declaration for partition + requests: + cpu: 10m + memory: 100Mi + limits: + cpu: 20m + memory: 100Mi + # One store for data newer than 2 weeks + - min: -2w + max: "" +``` + +### Integrate Thanos with Prometheus and Alertmanager + +You can integrate Thanos with Prometheus & Alertmanager using this chart and the [Bitnami kube-prometheus chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) following the steps below: + +> Note: in this example we will use MinIO® (subchart) as the Objstore. Every component will be deployed in the "monitoring" namespace. + +- Create a **values.yaml** like the one below: + +```yaml +objstoreConfig: |- + type: s3 + config: + bucket: thanos + endpoint: {{ include "thanos.minio.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local:9000 + access_key: minio + secret_key: minio123 + insecure: true +query: + dnsDiscovery: + sidecarsService: kube-prometheus-prometheus-thanos + sidecarsNamespace: monitoring +bucketweb: + enabled: true +compactor: + enabled: true +storegateway: + enabled: true +ruler: + enabled: true + alertmanagers: + - http://kube-prometheus-alertmanager.monitoring.svc.cluster.local:9093 + config: |- + groups: + - name: "metamonitoring" + rules: + - alert: "PrometheusDown" + expr: absent(up{prometheus="monitoring/kube-prometheus"}) +metrics: + enabled: true + serviceMonitor: + enabled: true +minio: + enabled: true + auth: + rootPassword: minio123 + rootUser: minio + monitoringBuckets: thanos + accessKey: + password: minio + secretKey: + password: minio123 +``` + +- Install Prometheus Operator and Thanos charts: + +For Helm 3: + +```console +$ kubectl create namespace monitoring +helm install kube-prometheus \ + --set prometheus.thanos.create=true \ + --namespace monitoring \ + bitnami/kube-prometheus +helm install thanos \ + --values values.yaml \ + --namespace monitoring \ + oci://REGISTRY_NAME/REPOSITORY_NAME/thanos +``` + +> 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`. + +That's all! Now you have Thanos fully integrated with Prometheus and Alertmanager. + +### Deploy extra resources + +There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. + +### Setting Pod's affinity + +This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. + +## Persistence + +The data is persisted by default using PVC(s) on Thanos components. You can disable the persistence setting the `XXX.persistence.enabled` parameter(s) to `false`. A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `XXX.persistence.storageClass` parameter(s) or set `XXX.persistence.existingClaim` if you have already existing persistent volumes to use. + +> Note: you need to substitute the XXX placeholders above with the actual component(s) you want to configure. + +### Adjust permissions of persistent volume mountpoint + +As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volumes. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volumes before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + ## Parameters ### Global parameters @@ -1358,238 +1582,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/thano > 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/thanos/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. - -### Adding extra flags - -In case you want to add extra flags to any Thanos component, you can use `XXX.extraFlags` parameter(s), where XXX is placeholder you need to replace with the actual component(s). For instance, to add extra flags to Thanos Store Gateway, use: - -```yaml -storegateway: - extraFlags: - - --sync-block-duration=3m - - --chunk-pool-size=2GB -``` - -This also works for multi-line flags. This can be useful when you want to configure caching for a particular component without using a configMap. For example, to configure the [query-range response cache of the Thanos Query Frontend](https://thanos.io/tip/components/query-frontend.md/#memcached), use: - -```yaml -queryFrontend: - extraFlags: - - | - --query-range.response-cache-config= - type: MEMCACHED - config: - addresses: - - :11211 - timeout: 500ms - max_idle_connections: 100 - max_async_concurrency: 10 - max_async_buffer_size: 10000 - max_get_multi_concurrency: 100 - max_get_multi_batch_size: 0 - dns_provider_update_interval: 10s - expiration: 24h -``` - -### Using custom Objstore configuration - -This helm chart supports using custom Objstore configuration. - -You can specify the Objstore configuration using the `objstoreConfig` parameter. - -In addition, you can also set an external Secret with the configuration file. This is done by setting the `existingObjstoreSecret` parameter. Note that this will override the previous option. If needed you can also provide a custom Secret Key with `existingObjstoreSecretItems`, please be aware that the Path of your Secret should be `objstore.yml`. - -### Using custom Query Service Discovery configuration - -This helm chart supports using custom Service Discovery configuration for Query. - -You can specify the Service Discovery configuration using the `query.sdConfig` parameter. - -In addition, you can also set an external ConfigMap with the Service Discovery configuration file. This is done by setting the `query.existingSDConfigmap` parameter. Note that this will override the previous option. - -### Using custom Ruler configuration - -This helm chart supports using custom Ruler configuration. - -You can specify the Ruler configuration using the `ruler.config` parameter. - -In addition, you can also set an external ConfigMap with the configuration file. This is done by setting the `ruler.existingConfigmap` parameter. Note that this will override the previous option. - -### Running Thanos with HTTPS and basic authentication - -This helm charts supports using HTTPS and basic authentication. The underlying feature is experimental and might change in the future, so are the associated settings in the chart. -For more information, please refer to [Thanos documentation](https://thanos.io/tip/operating/https.md/#running-thanos-with-https-and-basic-authentication). - -This feature can be enabled by using the following values: - -- `https.enabled=true`. Enabling HTTPS requires the user to provide the TLS certificate and Key for Thanos, which can be done using one of the following options: - - - Provide a secret using `https.existingSecret`. The secret must contain the keys `tls.crt` or `tls.key` (key names can be renamed using the values `https.keyFilename` and `https.certFilename`). - - Provide the certificate and key in your values.yaml under the values `https.cert` and `https.key`. - - Use `https.autoGenerated=true`, using this value Helm will generate a self-signed key pair during the chart initialization. Not recommended for production environments. - -- `auth.basicAuthUsers.*`. An dictionary of key / values, where the keys corresponds to the users that will have access to Thanos and the values are the plaintext passwords. Passwords will be later encrypted with bcrypt. -- Alternatively, provide your own Thanos http config file using the value `httpConfig` or `existingHttpConfigSecret`. This may cause any settings under `https.*` or `auth.*` to be ignored, except for the settings related to the TLS certificates. When providing a configuration file using these parameters, the chart Probes will fail to initialize unless one of the following fixes are applied: - - Set `https.enabled` or `auth.basicAuthUsers` with at least one user, matching the configuration file you provided. That way Probes will be configured with HTTPS and/or basic authentication accordingly. - - Configure your own Probes using `.customLivenessProbe`, `.customReadinessProbe` and `.customStartupProbe`. - - **Not recommended**. Disable the Probes. - -### Store time partitions - -Thanos store supports partion based on time. - -Setting time partitions will create N number of store statefulsets based on the number of items in the `timePartitioning` list. Each item must contain the min and max time for querying in the supported format (find more details at [Thanos documentation](https://thanos.io/tip/components/store.md/#time-based-partitioning)). - -> Note: leaving the `timePartitioning` list empty (`[]`) will create a single store for all data. - -For instance, to use 3 stores you can use a **values.yaml** like the one below: - -```yaml -timePartitioning: - # One store for data older than 6 weeks - - min: "" - max: -6w - # One store for data newer than 6 weeks and older than 2 weeks - - min: -6w - max: -2w - # One store for data newer than 2 weeks - - min: -2w - max: "" -``` - -You can also specify different resources and limits configurations for each storegateway statefulset. This is done by adding a `resources.requests` and `resources.limits` to each item you wish to change, as shown below: - -```yaml -timePartitioning: - # One store for data older than 6 weeks - - min: "" - max: -6w - # One store for data newer than 6 weeks and older than 2 weeks - - min: -6w - max: -2w - resources: #optional resources declaration for partition - requests: - cpu: 10m - memory: 100Mi - limits: - cpu: 20m - memory: 100Mi - # One store for data newer than 2 weeks - - min: -2w - max: "" -``` - -### Integrate Thanos with Prometheus and Alertmanager - -You can integrate Thanos with Prometheus & Alertmanager using this chart and the [Bitnami kube-prometheus chart](https://github.com/bitnami/charts/tree/main/bitnami/kube-prometheus) following the steps below: - -> Note: in this example we will use MinIO® (subchart) as the Objstore. Every component will be deployed in the "monitoring" namespace. - -- Create a **values.yaml** like the one below: - -```yaml -objstoreConfig: |- - type: s3 - config: - bucket: thanos - endpoint: {{ include "thanos.minio.fullname" . }}.{{ .Release.Namespace }}.svc.cluster.local:9000 - access_key: minio - secret_key: minio123 - insecure: true -query: - dnsDiscovery: - sidecarsService: kube-prometheus-prometheus-thanos - sidecarsNamespace: monitoring -bucketweb: - enabled: true -compactor: - enabled: true -storegateway: - enabled: true -ruler: - enabled: true - alertmanagers: - - http://kube-prometheus-alertmanager.monitoring.svc.cluster.local:9093 - config: |- - groups: - - name: "metamonitoring" - rules: - - alert: "PrometheusDown" - expr: absent(up{prometheus="monitoring/kube-prometheus"}) -metrics: - enabled: true - serviceMonitor: - enabled: true -minio: - enabled: true - auth: - rootPassword: minio123 - rootUser: minio - monitoringBuckets: thanos - accessKey: - password: minio - secretKey: - password: minio123 -``` - -- Install Prometheus Operator and Thanos charts: - -For Helm 3: - -```console -$ kubectl create namespace monitoring -helm install kube-prometheus \ - --set prometheus.thanos.create=true \ - --namespace monitoring \ - bitnami/kube-prometheus -helm install thanos \ - --values values.yaml \ - --namespace monitoring \ - oci://REGISTRY_NAME/REPOSITORY_NAME/thanos -``` - -> 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`. - -That's all! Now you have Thanos fully integrated with Prometheus and Alertmanager. - -## Persistence - -The data is persisted by default using PVC(s) on Thanos components. You can disable the persistence setting the `XXX.persistence.enabled` parameter(s) to `false`. A default `StorageClass` is needed in the Kubernetes cluster to dynamically provision the volumes. Specify another StorageClass in the `XXX.persistence.storageClass` parameter(s) or set `XXX.persistence.existingClaim` if you have already existing persistent volumes to use. - -> Note: you need to substitute the XXX placeholders above with the actual component(s) you want to configure. - -### Adjust permissions of persistent volume mountpoint - -As the images run as non-root by default, it is necessary to adjust the ownership of the persistent volumes so that the containers can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volumes. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volumes before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### Deploy extra resources - -There are cases where you may want to deploy extra objects, such a ConfigMap containing your app's configuration or some extra deployment with a micro service used by your app. For covering this case, the chart allows adding the full specification of other objects using the `extraDeploy` parameter. - -### Setting Pod's affinity - -This chart allows you to set your custom affinity using the `XXX.affinity` parameter(s). 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 `XXX.podAffinityPreset`, `XXX.podAntiAffinityPreset`, or `XXX.nodeAffinityPreset` parameters. - ## 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). diff --git a/bitnami/tomcat/README.md b/bitnami/tomcat/README.md index 37a7580ad1..7892afedd5 100644 --- a/bitnami/tomcat/README.md +++ b/bitnami/tomcat/README.md @@ -45,15 +45,98 @@ These commands deploy Tomcat on the Kubernetes cluster in the default configurat > **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 -```console -helm delete my-release +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. + +### Use a different Tomcat version + +To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. + +### Add extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, define a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Set Pod affinity + +This chart allows you to set custom Pod 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, use one 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 Tomcat](https://github.com/bitnami/containers/tree/main/bitnami/tomcat) image stores the Tomcat data and configurations at the `/bitnami/tomcat` path of the container. + +Persistent Volume Claims (PVCs) 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. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an init container to change the ownership of the volume before mounting it in the final destination. + +You can enable this init container by setting `volumePermissions.enabled` to `true`. ## Parameters @@ -289,99 +372,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/tomca > 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/tomcat/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. - -### Use a different Tomcat version - -To modify the application version used in this chart, specify a different version of the image using the `image.tag` parameter and/or a different repository using the `image.repository` parameter. - -### Add extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, define a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set custom Pod 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, use one 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 Tomcat](https://github.com/bitnami/containers/tree/main/bitnami/tomcat) image stores the Tomcat data and configurations at the `/bitnami/tomcat` path of the container. - -Persistent Volume Claims (PVCs) 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. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an init container to change the ownership of the volume before mounting it in the final destination. - -You can enable this init container by setting `volumePermissions.enabled` to `true`. - ## 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). diff --git a/bitnami/vault/README.md b/bitnami/vault/README.md index 5999aab573..ae4c0105b7 100644 --- a/bitnami/vault/README.md +++ b/bitnami/vault/README.md @@ -39,15 +39,134 @@ The command deploys vault 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 -```console -helm delete my-release +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. + +### 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.To enable Ingress integration, set `client.ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `client.ingress.hostname` property can be used to set the host name. The `client.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 `client.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `client.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `client.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 + +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----- ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +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`. + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `server`, `csiProvider` and `injector` sections. + +```yaml +server: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `server`, `csiProvider` and `injector` sections. + +### Sidecars + +If additional containers are needed in the same pod as vault (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `server`, `csiProvider` and `injector` 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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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 inside the `server`, `csiProvider` and `injector` sections. + +## Persistence + +The [Bitnami vault](https://github.com/bitnami/containers/tree/main/bitnami/vault) image stores the vault data and configurations at the `/bitnami` 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. ## Parameters @@ -550,135 +669,6 @@ helm install my-release -f values.yaml my-repo/vault > **Tip**: You can use the default [values.yaml](https://github.com/bitnami/charts/tree/main/bitnami/vault/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. - -### 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.To enable Ingress integration, set `client.ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `client.ingress.hostname` property can be used to set the host name. The `client.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 `client.ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `client.ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `client.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 - -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 - -The [Bitnami vault](https://github.com/bitnami/containers/tree/main/bitnami/vault) image stores the vault data and configurations at the `/bitnami` 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. - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property inside the `server`, `csiProvider` and `injector` sections. - -```yaml -server: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values inside the `server`, `csiProvider` and `injector` sections. - -### Sidecars - -If additional containers are needed in the same pod as vault (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter inside the `server`, `csiProvider` and `injector` 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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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 inside the `server`, `csiProvider` and `injector` sections. - ## 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). diff --git a/bitnami/whereabouts/README.md b/bitnami/whereabouts/README.md index 65aa0cb379..a2ae60b523 100644 --- a/bitnami/whereabouts/README.md +++ b/bitnami/whereabouts/README.md @@ -43,15 +43,51 @@ The command deploys Whereabouts on the Kubernetes cluster in the default configu > **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 -```console -helm delete my-release -``` +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. -The command removes all the Kubernetes components associated with the chart and deletes the release. +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. + +### Host configuration + +Once installed, the helm chart will modify configuration files in the host nodes of the Kubernetes cluster. Ensure that the cluster allows root and privileged deployments. + +Once the whereabouts configuration is installed, check the [upstream Kubernetes documentation](https://kubernetes.io/docs/concepts/cluster-administration/networking/) on how to modify the network settings of the cluster. + +> **Important**: Double check that the host CNI binary and configuration directories are properly configured, or the deployment will fail. This is done using the `hostCNINetDir` and `hostCNIBinDir` values. + +### 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. ## Parameters @@ -192,52 +228,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/where > 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/whereabouts/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. - -### Host configuration - -Once installed, the helm chart will modify configuration files in the host nodes of the Kubernetes cluster. Ensure that the cluster allows root and privileged deployments. - -Once the whereabouts configuration is installed, check the [upstream Kubernetes documentation](https://kubernetes.io/docs/concepts/cluster-administration/networking/) on how to modify the network settings of the cluster. - -> **Important**: Double check that the host CNI binary and configuration directories are properly configured, or the deployment will fail. This is done using the `hostCNINetDir` and `hostCNIBinDir` values. - -### 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. - ## 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). diff --git a/bitnami/wildfly/README.md b/bitnami/wildfly/README.md index d95487b6e3..c7cebe7a78 100644 --- a/bitnami/wildfly/README.md +++ b/bitnami/wildfly/README.md @@ -45,15 +45,93 @@ These commands deploy WildFly on the Kubernetes cluster in the default configura > **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 -```console -helm delete my-release +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. + +## Persistence + +The [Bitnami WildFly](https://github.com/bitnami/containers/tree/main/bitnami/wildfly) image stores the WildFly data and configurations at the `/bitnami/wildfly` 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. + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + +### Add extra environment variables + +To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. + +```yaml +extraEnvVars: + - name: LOG_LEVEL + value: DEBUG ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Use Sidecars and Init Containers + +If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. + +```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/). + +### Set Pod affinity + +This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. ## Parameters @@ -267,94 +345,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/wildf > 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/wildfly/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. - -## Persistence - -The [Bitnami WildFly](https://github.com/bitnami/containers/tree/main/bitnami/wildfly) image stores the WildFly data and configurations at the `/bitnami/wildfly` 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. - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### Add extra environment variables - -To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property. - -```yaml -extraEnvVars: - - name: LOG_LEVEL - value: DEBUG -``` - -Alternatively, use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Use Sidecars and Init Containers - -If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. - -```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/). - -### Set Pod affinity - -This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/wordpress/README.md b/bitnami/wordpress/README.md index 006c3d053f..3b9094173e 100644 --- a/bitnami/wordpress/README.md +++ b/bitnami/wordpress/README.md @@ -43,15 +43,200 @@ The command deploys WordPress on the Kubernetes cluster in the default configura > **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. + +### Known limitations + +When performing admin operations that require activating the maintenance mode (such as updating a plugin or theme), it's activated in only one replica (see: [bug report](https://core.trac.wordpress.org/ticket/50797)). This implies that WP could be attending requests on other replicas while performing admin operations, with unpredictable consequences. + +To avoid that, you can manually activate/deactivate the maintenance mode on every replica using the WP CLI. For instance, if you installed WP with three replicas, you can run the commands below to activate the maintenance mode in all of them (assuming that the release name is `wordpress`): ```console -helm delete my-release +kubectl exec $(kubectl get pods -l app.kubernetes.io/name=wordpress -o jsonpath='{.items[0].metadata.name}') -c wordpress -- wp maintenance-mode activate +kubectl exec $(kubectl get pods -l app.kubernetes.io/name=wordpress -o jsonpath='{.items[1].metadata.name}') -c wordpress -- wp maintenance-mode activate +kubectl exec $(kubectl get pods -l app.kubernetes.io/name=wordpress -o jsonpath='{.items[2].metadata.name}') -c wordpress -- wp maintenance-mode activate ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +### External database support + +You may want to have WordPress connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#database-parameters). You should also disable the MariaDB installation with the `mariadb.enabled` option. Here is an example: + +```console +mariadb.enabled=false +externalDatabase.host=myexternalhost +externalDatabase.user=myuser +externalDatabase.password=mypassword +externalDatabase.database=mydatabase +externalDatabase.port=3306 +``` + +If the database already contains data from a previous WordPress installation, set the `wordpressSkipInstall` parameter to `true`. This parameter forces the container to skip the WordPress installation wizard. Otherwise, the container will assume it is a fresh installation and execute the installation wizard, potentially modifying or resetting the data in the existing database. + +[Refer to the container documentation for more information](https://github.com/bitnami/containers/tree/main/bitnami/wordpress#connect-wordpress-container-to-an-existing-database). + +### Memcached + +This chart provides support for using Memcached to cache database queries and objects improving the website performance. To enable this feature, set `wordpressConfigureCache` and `memcached.enabled` parameters to `true`. + +When this feature is enabled, a Memcached server will be deployed in your K8s cluster using the Bitnami Memcached chart and the [W3 Total Cache](https://wordpress.org/plugins/w3-total-cache/) plugin will be activated and configured to use the Memcached server for database caching. + +It is also possible to use an external cache server rather than installing one inside your cluster. To achieve this, the chart allows you to specify credentials for an external cache server with the [`externalCache` parameter](#database-parameters). You should also disable the Memcached installation with the `memcached.enabled` option. Here is an example: + +```console +wordpressConfigureCache=true +memcached.enabled=false +externalCache.host=myexternalcachehost +externalCache.port=11211 +``` + +### 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.To enable Ingress integration, set `ingress.enabled` to `true`. + +The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. + +> NOTE: For each host specified in the `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 + +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`. + +### `.htaccess` files + +For performance and security reasons, it is a good practice to configure Apache with the `AllowOverride None` directive. Instead of using `.htaccess` files, Apache will load the same directives at boot time. These directives are located in `/opt/bitnami/wordpress/wordpress-htaccess.conf`. + +By default, the container image includes all the default `.htaccess` files in WordPress (together with the default plugins). To enable this feature, install the chart with the value `allowOverrideNone=yes`. + +However, some plugins may include `.htaccess` directives that will not be loaded when `AllowOverride` is set to `None`. To make them work, create a custom `wordpress-htaccess.conf` file with all the required directives. After creating it, create a Kubernetes ConfigMap with it (for example, named `custom-htaccess`) and install the chart with the correct parameters as shown below: + +```text + allowOverrideNone=true + customHTAccessCM=custom-htaccess +``` + +Some plugins permit editing the `.htaccess` file and it may be necessary to persist it in order to keep those edits. To make these plugins work, set the `htaccessPersistenceEnabled` parameter as shown below: + +```text + allowOverrideNone=false + htaccessPersistenceEnabled=true +``` + +## Persistence + +The [Bitnami WordPress](https://github.com/bitnami/containers/tree/main/bitnami/wordpress) image stores the WordPress data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). + +### Additional environment variables + +In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. + +```yaml +wordpress: + extraEnvVars: + - name: LOG_LEVEL + value: error +``` + +Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. + +### Sidecars + +If additional containers are needed in the same pod as WordPress (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. + +```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 + +This chart allows you to set your custom affinity using the `affinity` parameter. Learn more about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, use one 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. ## Parameters @@ -411,201 +596,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/wordp > 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/wordpress/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. - -### Known limitations - -When performing admin operations that require activating the maintenance mode (such as updating a plugin or theme), it's activated in only one replica (see: [bug report](https://core.trac.wordpress.org/ticket/50797)). This implies that WP could be attending requests on other replicas while performing admin operations, with unpredictable consequences. - -To avoid that, you can manually activate/deactivate the maintenance mode on every replica using the WP CLI. For instance, if you installed WP with three replicas, you can run the commands below to activate the maintenance mode in all of them (assuming that the release name is `wordpress`): - -```console -kubectl exec $(kubectl get pods -l app.kubernetes.io/name=wordpress -o jsonpath='{.items[0].metadata.name}') -c wordpress -- wp maintenance-mode activate -kubectl exec $(kubectl get pods -l app.kubernetes.io/name=wordpress -o jsonpath='{.items[1].metadata.name}') -c wordpress -- wp maintenance-mode activate -kubectl exec $(kubectl get pods -l app.kubernetes.io/name=wordpress -o jsonpath='{.items[2].metadata.name}') -c wordpress -- wp maintenance-mode activate -``` - -### External database support - -You may want to have WordPress connect to an external database rather than installing one inside your cluster. Typical reasons for this are to use a managed database service, or to share a common database server for all your applications. To achieve this, the chart allows you to specify credentials for an external database with the [`externalDatabase` parameter](#database-parameters). You should also disable the MariaDB installation with the `mariadb.enabled` option. Here is an example: - -```console -mariadb.enabled=false -externalDatabase.host=myexternalhost -externalDatabase.user=myuser -externalDatabase.password=mypassword -externalDatabase.database=mydatabase -externalDatabase.port=3306 -``` - -If the database already contains data from a previous WordPress installation, set the `wordpressSkipInstall` parameter to `true`. This parameter forces the container to skip the WordPress installation wizard. Otherwise, the container will assume it is a fresh installation and execute the installation wizard, potentially modifying or resetting the data in the existing database. - -[Refer to the container documentation for more information](https://github.com/bitnami/containers/tree/main/bitnami/wordpress#connect-wordpress-container-to-an-existing-database). - -### Memcached - -This chart provides support for using Memcached to cache database queries and objects improving the website performance. To enable this feature, set `wordpressConfigureCache` and `memcached.enabled` parameters to `true`. - -When this feature is enabled, a Memcached server will be deployed in your K8s cluster using the Bitnami Memcached chart and the [W3 Total Cache](https://wordpress.org/plugins/w3-total-cache/) plugin will be activated and configured to use the Memcached server for database caching. - -It is also possible to use an external cache server rather than installing one inside your cluster. To achieve this, the chart allows you to specify credentials for an external cache server with the [`externalCache` parameter](#database-parameters). You should also disable the Memcached installation with the `memcached.enabled` option. Here is an example: - -```console -wordpressConfigureCache=true -memcached.enabled=false -externalCache.host=myexternalcachehost -externalCache.port=11211 -``` - -### 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.To enable Ingress integration, set `ingress.enabled` to `true`. - -The most common scenario is to have one host name mapped to the deployment. In this case, the `ingress.hostname` property can be used to set the host name. The `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 `ingress.extraHosts` parameter (if available) can be set with the host names specified as an array. The `ingress.extraTLS` parameter (if available) can also be used to add the TLS configuration for extra hosts. - -> NOTE: For each host specified in the `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 - -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`. - -### `.htaccess` files - -For performance and security reasons, it is a good practice to configure Apache with the `AllowOverride None` directive. Instead of using `.htaccess` files, Apache will load the same directives at boot time. These directives are located in `/opt/bitnami/wordpress/wordpress-htaccess.conf`. - -By default, the container image includes all the default `.htaccess` files in WordPress (together with the default plugins). To enable this feature, install the chart with the value `allowOverrideNone=yes`. - -However, some plugins may include `.htaccess` directives that will not be loaded when `AllowOverride` is set to `None`. To make them work, create a custom `wordpress-htaccess.conf` file with all the required directives. After creating it, create a Kubernetes ConfigMap with it (for example, named `custom-htaccess`) and install the chart with the correct parameters as shown below: - -```text - allowOverrideNone=true - customHTAccessCM=custom-htaccess -``` - -Some plugins permit editing the `.htaccess` file and it may be necessary to persist it in order to keep those edits. To make these plugins work, set the `htaccessPersistenceEnabled` parameter as shown below: - -```text - allowOverrideNone=false - htaccessPersistenceEnabled=true -``` - -## Persistence - -The [Bitnami WordPress](https://github.com/bitnami/containers/tree/main/bitnami/wordpress) image stores the WordPress data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Additional environment variables - -In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. - -```yaml -wordpress: - extraEnvVars: - - name: LOG_LEVEL - value: error -``` - -Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values. - -### Sidecars - -If additional containers are needed in the same pod as WordPress (such as additional metrics or logging exporters), they can be defined using the `sidecars` parameter. - -```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 - -This chart allows you to set your custom affinity using the `affinity` parameter. Learn more about Pod affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, use one 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. - ## 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). diff --git a/bitnami/zookeeper/README.md b/bitnami/zookeeper/README.md index 8d65721f6b..56c819e967 100644 --- a/bitnami/zookeeper/README.md +++ b/bitnami/zookeeper/README.md @@ -42,15 +42,94 @@ These commands deploy ZooKeeper on the Kubernetes cluster in the default configu > **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 -```console -helm delete my-release +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. + +### Configure log level + +You can configure the ZooKeeper log level using the `ZOO_LOG_LEVEL` environment variable or the parameter `logLevel`. By default, it is set to `ERROR` because each use of the liveness probe and the readiness probe produces an `INFO` message on connection and a `WARN` message on disconnection, generating a high volume of noise in your logs. + +In order to remove that log noise so levels can be set to 'INFO', two changes must be made. + +First, ensure that you are not getting metrics via the deprecated pattern of polling 'mntr' on the ZooKeeper client port. The preferred method of polling for Apache ZooKeeper metrics is the ZooKeeper metrics server. This is supported in this chart when setting `metrics.enabled` to `true`. + +Second, to avoid the connection/disconnection messages from the probes, you can set custom values for these checks which direct them to the ZooKeeper Admin Server instead of the client port. By default, an Admin Server will be started that listens on `localhost` at port `8080`. The following is an example of this use of the Admin Server for probes: + +```yaml +livenessProbe: + enabled: false +readinessProbe: + enabled: false +customLivenessProbe: + exec: + command: ['/bin/bash', '-c', 'curl -s -m 2 http://localhost:8080/commands/ruok | grep ruok'] + initialDelaySeconds: 30 + periodSeconds: 10 + timeoutSeconds: 5 + successThreshold: 1 + failureThreshold: 6 +customReadinessProbe: + exec: + command: ['/bin/bash', '-c', 'curl -s -m 2 http://localhost:8080/commands/ruok | grep error | grep null'] + initialDelaySeconds: 5 + periodSeconds: 10 + timeoutSeconds: 5 + successThreshold: 1 + failureThreshold: 6 ``` -The command removes all the Kubernetes components associated with the chart and deletes the release. +You can also set the log4j logging level and what log appenders are turned on, by using `ZOO_LOG4J_PROP` set inside of conf/log4j.properties as zookeeper.root.logger by default to + +```console +zookeeper.root.logger=INFO, CONSOLE +``` + +the available appender is + +- CONSOLE +- ROLLINGFILE +- RFAAUDIT +- TRACEFILE + +## Persistence + +The [Bitnami ZooKeeper](https://github.com/bitnami/containers/tree/main/bitnami/zookeeper) image stores the ZooKeeper data and configurations at the `/bitnami/zookeeper` 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. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). + +### Adjust permissions of persistent volume mountpoint + +As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. + +By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. +As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. + +You can enable this initContainer by setting `volumePermissions.enabled` to `true`. + +### Configure the data log directory + +You can use a dedicated device for logs (instead of using the data directory) to help avoiding competition between logging and snaphots. To do so, set the `dataLogDir` parameter with the path to be used for writing transaction logs. Alternatively, set this parameter with an empty string and it will result in the log being written to the data directory (Zookeeper's default behavior). + +When using a dedicated device for logs, you can use a PVC to persist the logs. To do so, set `persistence.enabled` to `true`. See the [Persistence Parameters](#persistence-parameters) section for more information. + +### Set pod affinity + +This chart allows you to set custom pod affinity using the `affinity` parameter. Find more information about pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). + +As an alternative, you can use any 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. ## Parameters @@ -356,95 +435,6 @@ helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/zooke > 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/zookeeper/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. - -### Configure log level - -You can configure the ZooKeeper log level using the `ZOO_LOG_LEVEL` environment variable or the parameter `logLevel`. By default, it is set to `ERROR` because each use of the liveness probe and the readiness probe produces an `INFO` message on connection and a `WARN` message on disconnection, generating a high volume of noise in your logs. - -In order to remove that log noise so levels can be set to 'INFO', two changes must be made. - -First, ensure that you are not getting metrics via the deprecated pattern of polling 'mntr' on the ZooKeeper client port. The preferred method of polling for Apache ZooKeeper metrics is the ZooKeeper metrics server. This is supported in this chart when setting `metrics.enabled` to `true`. - -Second, to avoid the connection/disconnection messages from the probes, you can set custom values for these checks which direct them to the ZooKeeper Admin Server instead of the client port. By default, an Admin Server will be started that listens on `localhost` at port `8080`. The following is an example of this use of the Admin Server for probes: - -```yaml -livenessProbe: - enabled: false -readinessProbe: - enabled: false -customLivenessProbe: - exec: - command: ['/bin/bash', '-c', 'curl -s -m 2 http://localhost:8080/commands/ruok | grep ruok'] - initialDelaySeconds: 30 - periodSeconds: 10 - timeoutSeconds: 5 - successThreshold: 1 - failureThreshold: 6 -customReadinessProbe: - exec: - command: ['/bin/bash', '-c', 'curl -s -m 2 http://localhost:8080/commands/ruok | grep error | grep null'] - initialDelaySeconds: 5 - periodSeconds: 10 - timeoutSeconds: 5 - successThreshold: 1 - failureThreshold: 6 -``` - -You can also set the log4j logging level and what log appenders are turned on, by using `ZOO_LOG4J_PROP` set inside of conf/log4j.properties as zookeeper.root.logger by default to - -```console -zookeeper.root.logger=INFO, CONSOLE -``` - -the available appender is - -- CONSOLE -- ROLLINGFILE -- RFAAUDIT -- TRACEFILE - -## Persistence - -The [Bitnami ZooKeeper](https://github.com/bitnami/containers/tree/main/bitnami/zookeeper) image stores the ZooKeeper data and configurations at the `/bitnami/zookeeper` 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. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - -### Adjust permissions of persistent volume mountpoint - -As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it. - -By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions. -As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination. - -You can enable this initContainer by setting `volumePermissions.enabled` to `true`. - -### Configure the data log directory - -You can use a dedicated device for logs (instead of using the data directory) to help avoiding competition between logging and snaphots. To do so, set the `dataLogDir` parameter with the path to be used for writing transaction logs. Alternatively, set this parameter with an empty string and it will result in the log being written to the data directory (Zookeeper's default behavior). - -When using a dedicated device for logs, you can use a PVC to persist the logs. To do so, set `persistence.enabled` to `true`. See the [Persistence Parameters](#persistence-parameters) section for more information. - -### Set pod affinity - -This chart allows you to set custom pod affinity using the `affinity` parameter. Find more information about pod affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity). - -As an alternative, you can use any 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. - ## 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). diff --git a/template/CHART_NAME/README.md b/template/CHART_NAME/README.md index 4926805297..0927c7f97c 100644 --- a/template/CHART_NAME/README.md +++ b/template/CHART_NAME/README.md @@ -37,47 +37,6 @@ The command deploys %%CHART_NAME%% on the Kubernetes cluster in the default conf > **Tip**: List all releases using `helm list` -## Uninstalling the Chart - -To uninstall/delete the `my-release` deployment: - -```console -helm delete my-release -``` - -The command removes all the Kubernetes components associated with the chart and deletes the release. - -## Parameters - -See to create the table - -The above parameters map to the env variables defined in [bitnami/%%CHART_NAME%%](https://github.com/bitnami/containers/tree/main/bitnami/%%CHART_NAME%%). For more information please refer to the [bitnami/%%CHART_NAME%%](https://github.com/bitnami/containers/tree/main/bitnami/%%CHART_NAME%%) image documentation. - -Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example, - -```console -helm install my-release \ - --set %%CHART_NAME%%Username=admin \ - --set %%CHART_NAME%%Password=password \ - --set mariadb.auth.rootPassword=secretpassword \ - oci://REGISTRY_NAME/REPOSITORY_NAME/%%CHART_NAME%% -``` - -> 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`. - -The above command sets the %%CHART_NAME%% administrator account username and password to `admin` and `password` respectively. Additionally, it sets the MariaDB `root` user password to `secretpassword`. - -> NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available. - -Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example, - -```console -helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/%%CHART_NAME%% -``` - -> 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/blob/main/template/CHART_NAME/values.yaml) - ## Configuration and installation details ### [Rolling VS Immutable tags](https://docs.bitnami.com/tutorials/understand-rolling-tags-containers) @@ -147,12 +106,6 @@ tls.certCAFilename="ca.pem" ### %%OTHER_SECTIONS%% -## Persistence - -The [Bitnami %%CHART_NAME%%](https://github.com/bitnami/containers/tree/main/bitnami/%%CHART_NAME%%) image stores the %%CHART_NAME%% data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. - -If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). - ### Additional environment variables In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property. @@ -212,6 +165,43 @@ This chart allows you to set your custom affinity using the `affinity` parameter As an alternative, use one 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 %%CHART_NAME%%](https://github.com/bitnami/containers/tree/main/bitnami/%%CHART_NAME%%) image stores the %%CHART_NAME%% data and configurations at the `/bitnami` path of the container. Persistent Volume Claims are used to keep the data across deployments. + +If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/). + +## Parameters + +See to create the table + +The above parameters map to the env variables defined in [bitnami/%%CHART_NAME%%](https://github.com/bitnami/containers/tree/main/bitnami/%%CHART_NAME%%). For more information please refer to the [bitnami/%%CHART_NAME%%](https://github.com/bitnami/containers/tree/main/bitnami/%%CHART_NAME%%) image documentation. + +Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example, + +```console +helm install my-release \ + --set %%CHART_NAME%%Username=admin \ + --set %%CHART_NAME%%Password=password \ + --set mariadb.auth.rootPassword=secretpassword \ + oci://REGISTRY_NAME/REPOSITORY_NAME/%%CHART_NAME%% +``` + +> 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`. + +The above command sets the %%CHART_NAME%% administrator account username and password to `admin` and `password` respectively. Additionally, it sets the MariaDB `root` user password to `secretpassword`. + +> NOTE: Once this chart is deployed, it is not possible to change the application's access credentials, such as usernames or passwords, using Helm. To change these application credentials after deployment, delete any persistent volumes (PVs) used by the chart and re-deploy it, or use the application's built-in administrative tools if available. + +Alternatively, a YAML file that specifies the values for the above parameters can be provided while installing the chart. For example, + +```console +helm install my-release -f values.yaml oci://REGISTRY_NAME/REPOSITORY_NAME/%%CHART_NAME%% +``` + +> 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/blob/main/template/CHART_NAME/values.yaml) + ## 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).