mirror of
https://github.com/wahyd4/charts.git
synced 2026-08-22 03:25:53 +10:00
Merge branch 'master' into minio-ingress
This commit is contained in:
Alejandro Moreno
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: airflow
|
||||
version: 4.0.1
|
||||
version: 4.0.2
|
||||
appVersion: 1.10.5
|
||||
description: Apache Airflow is a platform to programmatically author, schedule and monitor workflows.
|
||||
keywords:
|
||||
|
||||
+25
-28
@@ -42,7 +42,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Kafka chart and their default values.
|
||||
|
||||
@@ -170,13 +170,17 @@ $ helm install --name my-release -f values.yaml bitnami/airflow
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/airflow
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- URL used to access to airflow web ui:
|
||||
```diff
|
||||
@@ -202,46 +206,39 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/airflow
|
||||
+ ingress.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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 Airflow chart relies on the PostgreSQL chart persistence. This means that Airflow does not persist anything.
|
||||
|
||||
## Generate a Fernet key
|
||||
### 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://bcb.github.io/airflow/fernet-key)
|
||||
|
||||
## Load DAG files
|
||||
### Load DAG files
|
||||
|
||||
There are three 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: Load locally from the `files` folder
|
||||
#### Option 1: Load locally from the `files` folder
|
||||
|
||||
If you plan to deploy the chart from your filesystem, you can copy your DAG files inside the `files/dags` directory. A config map will be created with those files and it will be mounted in all airflow nodes..
|
||||
If you plan to deploy the chart from your filesystem, you can copy your DAG files inside the `files/dags` directory. A config map will be created with those files and it will be mounted in all airflow nodes.
|
||||
|
||||
### Option 2: Specify an existing config map
|
||||
#### Option 2: 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 `--set airflow.dagsConfigMap`.
|
||||
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 `airflow.dagsConfigMap`.
|
||||
|
||||
### Option 3: Get your DAG files from a git repository
|
||||
#### Option 3: Get your DAG files from a git repository
|
||||
|
||||
You can store all your DAG files on a GitHub repository and then clone to the Airflow pods with an initContainer. The repository will be periodically updated using a sidecar container. In order to do that, you can deploy airflow with the following options:
|
||||
|
||||
```console
|
||||
helm install --name my-release bitnami/airflow \
|
||||
--set airflow.cloneDagFilesFromGit.enabled=true \
|
||||
--set airflow.cloneDagFilesFromGit.repository=https://github.com/USERNAME/REPOSITORY \
|
||||
--set airflow.cloneDagFilesFromGit.branch=master
|
||||
--set airflow.cloneDagFilesFromGit.interval=60
|
||||
airflow.cloneDagFilesFromGit.enabled=true
|
||||
airflow.cloneDagFilesFromGit.repository=https://github.com/USERNAME/REPOSITORY
|
||||
airflow.cloneDagFilesFromGit.branch=master
|
||||
airflow.cloneDagFilesFromGit.interval=60
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
The Bitnami Airflow chart relies on the PostgreSQL chart persistence. This means that Airflow does not persist anything.
|
||||
|
||||
## Notable changes
|
||||
|
||||
### 1.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: apache
|
||||
version: 7.2.0
|
||||
version: 7.2.1
|
||||
appVersion: 2.4.41
|
||||
description: Chart for Apache HTTP Server
|
||||
keywords:
|
||||
|
||||
+22
-17
@@ -47,7 +47,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Apache chart and their default values.
|
||||
|
||||
@@ -121,22 +121,7 @@ $ helm install --name my-release -f values.yaml bitnami/apache
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Deploying your 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.
|
||||
|
||||
In the following example you can deploy a example web application using git:
|
||||
|
||||
```
|
||||
helm install bitnami/apache --set cloneHtdocsFromGit.enabled=true --set cloneHtdocsFromGit.repository=https://github.com/mdn/beginner-html-site-styled.git --set cloneHtdocsFromGit.branch=master
|
||||
```
|
||||
|
||||
To use your own `httpd.conf` file you can mount it using the `httpdConfConfigMap` parameter, which is the name of a Config Map with the contents of your `httpd.conf`. Additionaly, you can copy your `httpd.conf` to `/files/httpd.conf` in your current working directory to mount it to the container.
|
||||
|
||||
You may also want to mount different virtual host configurations. This can be done using the `vhostsConfigMap` value. This is a pointer to a ConfigMap with the desired Apache virtual host configurations. You can also copy your virtual host configurations under the `files/vhosts/` directory in your current working directory to mount them as a Config Map to the container.
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
@@ -144,6 +129,26 @@ It is strongly recommended to use immutable tags in a production environment. Th
|
||||
|
||||
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 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.
|
||||
|
||||
You can deploy a example web application using git deploying the chart with the following parameters:
|
||||
|
||||
```console
|
||||
cloneHtdocsFromGit.enabled=true
|
||||
cloneHtdocsFromGit.repository=https://github.com/mdn/beginner-html-site-styled.git
|
||||
cloneHtdocsFromGit.branch=master
|
||||
```
|
||||
|
||||
To use your own `httpd.conf` file you can mount it using the `httpdConfConfigMap` parameter, which is the name of a Config Map with the contents of your `httpd.conf`. Additionaly, you can copy your `httpd.conf` to `/files/httpd.conf` in your current working directory to mount it to the container.
|
||||
|
||||
You may also want to mount different virtual host configurations. This can be done using the `vhostsConfigMap` value. This is a pointer to a ConfigMap with the desired Apache virtual host configurations. You can also copy your virtual host configurations under the `files/vhosts/` directory in your current working directory to mount them as a Config Map to the container.
|
||||
|
||||
## Notable changes
|
||||
|
||||
### 7.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: cassandra
|
||||
version: 4.1.3
|
||||
version: 4.1.4
|
||||
appVersion: 3.11.4
|
||||
description: Apache Cassandra is a free and open-source distributed database management system designed to handle large amounts of data across many commodity servers, providing high availability with no single point of failure. Cassandra offers robust support for clusters spanning multiple datacenters, with asynchronous masterless replication allowing low latency operations for all clients.
|
||||
icon: https://bitnami.com/assets/stacks/cassandra/img/cassandra-stack-220x234.png
|
||||
|
||||
+32
-44
@@ -44,7 +44,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the cassandra chart and their default values.
|
||||
|
||||
@@ -154,13 +154,17 @@ $ helm install --name my-release -f values.yaml bitnami/cassandra
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/cassandra
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Number of Cassandra and seed nodes:
|
||||
```diff
|
||||
@@ -194,11 +198,30 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/cassandra
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### Enable TLS for Cassandra
|
||||
|
||||
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.
|
||||
You can enable TLS between client and server and between nodes. In order to do so, you need to set the following values:
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
* For internode cluster encryption, set `cluster.internodeEncryption` to a value different from `none`. Available values are `all`, `dc` or `rack`.
|
||||
* For client-server encryption, set `cluster.clientEncryption` to true.
|
||||
|
||||
In addition to this, you **must** create a secret containing the *keystore* and *truststore* certificates and their corresponding protection passwords. Then, set the `tlsEncryptionSecretName` when deploying the chart.
|
||||
|
||||
You can create the secret (named for example `cassandra-tls`) using `--from-file=./keystore`, `--from-file=./truststore`, `--from-literal=keystore-password=PUT_YOUR_KEYSTORE_PASSWORD` and `--from-literal=truststore-password=PUT_YOUR_TRUSTSTORE_PASSWORD` options, assuming you have your certificates in your working directory (replace the PUT_YOUR_KEYSTORE_PASSWORD and PUT_YOUR_TRUSTSTORE_PASSWORD placeholders).To deploy Cassandra with TLS you can use those parameters:
|
||||
|
||||
```console
|
||||
cluster.internodeEncryption=all
|
||||
cluster.clientEncryption=true
|
||||
tlsEncryptionSecretName=cassandra-tls
|
||||
```
|
||||
|
||||
### Initializing the database
|
||||
|
||||
The [Bitnami cassandra](https://github.com/bitnami/bitnami-docker-cassandra) image allows having initialization scripts mounted in `/docker-entrypoint.initdb`. This is done in the chart by adding files in the `files/docker-entrypoint-initdb.d` folder (in order to do so, clone this chart) or by setting the `initDBConfigMap` value with a `ConfigMap` (named, for example, `init-db`) that includes the necessary `sh` or `cql` scripts:
|
||||
|
||||
```console
|
||||
initDBConfigMap=init-db
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
@@ -216,41 +239,6 @@ As an alternative, this chart supports using an initContainer to change the owne
|
||||
|
||||
You can enable this initContainer by setting `volumePermissions.enabled` to `true`.
|
||||
|
||||
## Enable TLS for Cassandra
|
||||
|
||||
You can enable TLS between client and server and between nodes. In order to do so, you need to set the following values:
|
||||
|
||||
* For internode cluster encryption, set `cluster.internodeEncryption` to a value different from `none`. Available values are `all`, `dc` or `rack`.
|
||||
* For client-server encryption, set `cluster.clientEncryption` to true.
|
||||
|
||||
In addition to this, you **must** create a secret containing the *keystore* and *truststore* certificates and their corresponding protection passwords. Then, set the `tlsEncryptionSecretName` when deploying the chart.
|
||||
|
||||
You can create the secret with this command assuming you have your certificates in your working directory (replace the PUT_YOUR_KEYSTORE_PASSWORD and PUT_YOUR_TRUSTSTORE_PASSWORD placeholders):
|
||||
|
||||
```console
|
||||
kubectl create secret generic casssandra-tls --from-file=./keystore --from-file=./truststore --from-literal=keystore-password=PUT_YOUR_KEYSTORE_PASSWORD --from-literal=truststore-password=PUT_YOUR_TRUSTSTORE_PASSWORD
|
||||
```
|
||||
|
||||
As an example of Cassandra installed with TLS you can use this command:
|
||||
|
||||
```console
|
||||
helm install --name my-release bitnami/cassandra --set cluster.internodeEncryption=all \
|
||||
--set cluster.clientEncryption=true --set tlsEncryptionSecretName=cassandra-tls \
|
||||
```
|
||||
|
||||
## Initializing the database
|
||||
|
||||
The [Bitnami cassandra](https://github.com/bitnami/bitnami-docker-cassandra) image allows having initialization scripts mounted in `/docker-entrypoint.initdb`. This is done in the chart by adding files in the `files/docker-entrypoint-initdb.d` folder (in order to do so, clone this chart) or by setting the `initDBConfigMap` value with a `ConfigMap` that includes the necessary `sh` or `cql` scripts:
|
||||
|
||||
```bash
|
||||
kubectl create configmap init-db --from-file=path/to/scripts
|
||||
helm install bitnami/cassandra --set initDBConfigMap=init-db
|
||||
```
|
||||
|
||||
## Using a custom Cassandra image
|
||||
|
||||
This chart uses the [Bitnami cassandra](https://github.com/bitnami/bitnami-docker-cassandra) image by default. In case you want to use a different image, you can redefine the container entrypoint by setting the `entrypoint` and `cmd` values.
|
||||
|
||||
## Upgrade
|
||||
|
||||
### 4.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: consul
|
||||
version: 6.0.4
|
||||
version: 6.0.5
|
||||
appVersion: 1.6.1
|
||||
description: Highly available and distributed service discovery and key-value store designed with support for the modern data center to make distributed systems and configuration easy.
|
||||
home: https://www.consul.io/
|
||||
|
||||
+44
-83
@@ -47,7 +47,7 @@ The command removes all the Kubernetes components associated with the chart and
|
||||
$ helm delete --purge my-release
|
||||
```
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the HashiCorp Consul chart and their default values.
|
||||
|
||||
@@ -145,19 +145,7 @@ $ helm install --name my-release -f values.yaml bitnami/consul
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/consul
|
||||
```
|
||||
|
||||
- Start a side-car prometheus exporter:
|
||||
```diff
|
||||
- metrics.enabled: false
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
@@ -165,65 +153,41 @@ It is strongly recommended to use immutable tags in a production environment. Th
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
## Persistence
|
||||
### Production configuration
|
||||
|
||||
The [Bitnami HashiCorp Consul](https://github.com/bitnami/bitnami-docker-consul) image stores the HashiCorp Consul data at the `/bitnami` path of the container.
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
|
||||
See the [Configuration](#configuration) section to configure the PVC or to disable persistence.
|
||||
- Start a side-car prometheus exporter:
|
||||
```diff
|
||||
- metrics.enabled: false
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### Adjust permissions of persistent volume mountpoint
|
||||
### Ingress
|
||||
|
||||
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](https://kubeapps.com/charts/stable/nginx-ingress)
|
||||
or [traefik](https://kubeapps.com/charts/stable/traefik) you can utilize
|
||||
the ingress controller to service your HashiCorp Consul UI application.
|
||||
This chart provides support for ingress resources. If you have an ingress controller installed on your cluster, such as [nginx-ingress](https://kubeapps.com/charts/stable/nginx-ingress) or [traefik](https://kubeapps.com/charts/stable/traefik) you can utilize the ingress controller to service your HashiCorp Consul UI 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
|
||||
HashiCorp Consul installation, however it is possible to have more than one
|
||||
host. To facilitate this, the `ingress.hosts` object is an array.
|
||||
#### Hosts
|
||||
Most likely you will only want to have one hostname that maps to this HashiCorp Consul installation, however it is possible to have more than one host. To facilitate this, the `ingress.hosts` object is an array.
|
||||
|
||||
For each item, please indicate a `name`, `tls`, `tlsSecret`, and any
|
||||
`annotations` that you may want the ingress controller to know about.
|
||||
For each item, please indicate a `name`, `tls`, `tlsSecret`, and any `annotations` that you may want the ingress controller to know about.
|
||||
|
||||
Indicating TLS will cause HashiCorp Consul to generate HTTPS urls, and
|
||||
HashiCorp Consul will be connected to at port 443. The actual secret that
|
||||
`tlsSecret` references does not have to be generated by this chart.
|
||||
However, please note that if TLS is enabled, the ingress record will not
|
||||
work until this secret exists.
|
||||
Indicating TLS will cause HashiCorp Consul to generate HTTPS urls, and HashiCorp Consul will be connected to at port 443. The actual secret that `tlsSecret` references does not have to be generated by this chart. However, please note that if TLS is enabled, the ingress record will not work until this secret exists.
|
||||
|
||||
For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/master/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.
|
||||
For annotations, please see [this document](https://github.com/kubernetes/ingress-nginx/blob/master/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:
|
||||
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 [kube-lego](https://kubeapps.com/charts/stable/kube-lego))
|
||||
manages the secrets for the application
|
||||
* an additional tool (like [kube-lego](https://kubeapps.com/charts/stable/kube-lego)) 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:
|
||||
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)
|
||||
* certificate files should look like (and there can be more than one certificate if there is a certificate chain)
|
||||
|
||||
```
|
||||
-----BEGIN CERTIFICATE-----
|
||||
@@ -232,40 +196,25 @@ MIID6TCCAtGgAwIBAgIJAIaCwivkeB5EMA0GCSqGSIb3DQEBCwUAMFYxCzAJBgNV
|
||||
jScrvkiBO65F46KioCL9h5tDvomdU1aqpI/CBzhvZn1c0ZTf87tGQR8NK7v7
|
||||
-----END CERTIFICATE-----
|
||||
```
|
||||
|
||||
* keys should look like:
|
||||
|
||||
```
|
||||
-----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 by doing the following:
|
||||
|
||||
```
|
||||
kubectl create secret tls consul.local-tls --key /path/to/key.key --cert /path/to/cert.crt
|
||||
```
|
||||
|
||||
Please see [this example](https://github.com/kubernetes/contrib/tree/master/ingress/controllers/nginx/examples/tls)
|
||||
for more information.
|
||||
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.
|
||||
|
||||
## Enable TLS encryption between servers
|
||||
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.
|
||||
|
||||
```
|
||||
kubectl create secret generic consul-tls-encryption \
|
||||
--from-file=ca.pem \
|
||||
--from-file=consul.pem \
|
||||
--from-file=consul-key.pem
|
||||
```
|
||||
|
||||
> 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:
|
||||
@@ -279,16 +228,28 @@ If the secret is specified, the chart will locate those files at `/opt/bitnami/c
|
||||
"verify_server_hostname": true,
|
||||
```
|
||||
|
||||
After creating the secret, you can install the helm chart specyfing the secret name:
|
||||
After creating the secret, you can install the helm chart specyfing the secret name using `tlsEncryptionSecretName=consul-tls-encryption`.
|
||||
|
||||
```
|
||||
helm install bitnami/consul --set tlsEncryptionSecretName=consul-tls-encryption
|
||||
```
|
||||
|
||||
## Metrics
|
||||
### 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.
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami HashiCorp Consul](https://github.com/bitnami/bitnami-docker-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 [Configuration](#configuration) 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`.
|
||||
|
||||
## Upgrading
|
||||
|
||||
### To 6.0.0
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
apiVersion: v1
|
||||
name: elasticsearch
|
||||
version: 6.3.11
|
||||
appVersion: 7.4.0
|
||||
version: 6.3.13
|
||||
appVersion: 7.4.1
|
||||
description: A highly scalable open-source full-text search and analytics engine
|
||||
keywords:
|
||||
- elasticsearch
|
||||
|
||||
@@ -48,7 +48,7 @@ The command removes all the Kubernetes components associated with the chart and
|
||||
$ helm delete --purge my-release
|
||||
```
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the Elasticsearch chart and their default values.
|
||||
|
||||
@@ -210,13 +210,17 @@ $ helm install --name my-release -f values.yaml bitnami/elasticsearch
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml).
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/elasticsearch
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Desired number of Elasticsearch master-eligible nodes:
|
||||
```diff
|
||||
@@ -370,11 +374,14 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/elasticsear
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### Troubleshooting
|
||||
|
||||
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.
|
||||
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:
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
- [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)
|
||||
|
||||
You can use a **privileged** initContainer (using the `sysctlImage.enabled=true` parameter) to change those settings in the Kernel.
|
||||
|
||||
## Persistence
|
||||
|
||||
@@ -391,21 +398,6 @@ As an alternative, this chart supports using an initContainer to change the owne
|
||||
|
||||
You can enable this initContainer by setting `volumePermissions.enabled` to `true`.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
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)
|
||||
|
||||
You can use a **privileged** initContainer to changes those settings in the Kernel by enabling the `sysctlImage.enabled`:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
--set sysctlImage.enabled=true \
|
||||
bitnami/elasticsearch
|
||||
```
|
||||
|
||||
## Upgrading
|
||||
|
||||
### To 3.0.0
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/elasticsearch
|
||||
tag: 7.4.0-debian-9-r0
|
||||
tag: 7.4.1-debian-9-r0
|
||||
## Specify a imagePullPolicy
|
||||
## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
|
||||
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
|
||||
@@ -336,7 +336,7 @@ metrics:
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/elasticsearch-exporter
|
||||
tag: 1.1.0-debian-9-r42
|
||||
tag: 1.1.0-debian-9-r61
|
||||
pullPolicy: IfNotPresent
|
||||
## Optionally specify an array of imagePullSecrets.
|
||||
## Secrets must be manually created in the namespace.
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/elasticsearch
|
||||
tag: 7.4.0-debian-9-r0
|
||||
tag: 7.4.1-debian-9-r0
|
||||
## Specify a imagePullPolicy
|
||||
## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
|
||||
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
|
||||
@@ -336,7 +336,7 @@ metrics:
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/elasticsearch-exporter
|
||||
tag: 1.1.0-debian-9-r42
|
||||
tag: 1.1.0-debian-9-r61
|
||||
pullPolicy: IfNotPresent
|
||||
## Optionally specify an array of imagePullSecrets.
|
||||
## Secrets must be manually created in the namespace.
|
||||
|
||||
@@ -1,7 +1,7 @@
|
||||
apiVersion: v1
|
||||
name: etcd
|
||||
version: 4.3.10
|
||||
appVersion: 3.4.2
|
||||
version: 4.3.12
|
||||
appVersion: 3.4.3
|
||||
description: etcd is a distributed key value store that provides a reliable way to store data across a cluster of machines
|
||||
keywords:
|
||||
- etcd
|
||||
|
||||
+43
-75
@@ -44,7 +44,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the etcd chart and their default values.
|
||||
|
||||
@@ -151,13 +151,17 @@ $ helm install --name my-release -f values.yaml bitnami/etcd
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration and horizontal scaling
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/etcd
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Number of etcd nodes:
|
||||
```diff
|
||||
@@ -195,27 +199,13 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/etcd
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
To horizontally scale this chart once it has been deployed:
|
||||
|
||||
```console
|
||||
$ helm upgrade my-release bitnami/etcd \
|
||||
-f ./values-production.yaml \
|
||||
--set statefulset.replicaCount=5
|
||||
```
|
||||
|
||||
> **Note**: Scaling the statefulset with `kubectl scale ...` command is highly discouraged. Use `helm upgrade ...` for horizontal scaling so you ensure all the environment variables used to configure the ectd cluster are properly updated.
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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 horizontally scale this chart once it has been deployed, you can upgrade the deployment using a new value for the `statefulset.replicaCount` parameter.
|
||||
|
||||
### 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, use the `envVarsConfigMap` value to point to a ConfigMap that contains them. Example:
|
||||
- Using environment variables: etcd allows setting environment variables that map to configuration settings. In order to set extra environment variables, use the `envVarsConfigMap` value to point to a ConfigMap (shown in the below example) that contains them. This ConfigMap can be created with the `-f /tmp/configurationEnvVars.yaml` flag. Then deploy the chart with the `envVarsConfigMap=etcd-env-vars` parameter:
|
||||
|
||||
```console
|
||||
$ cat << EOF > /tmp/configurationEnvVars.yaml
|
||||
@@ -228,70 +218,67 @@ data:
|
||||
ETCD_AUTO_COMPACTION_RETENTION: "0"
|
||||
ETCD_HEARTBEAT_INTERVAL: "150"
|
||||
EOF
|
||||
|
||||
$ kubectl create -f /tmp/configurationEnvVars.yaml
|
||||
$ helm install bitnami/etcd --set envVarsConfigMap=etcd-env-vars
|
||||
```
|
||||
|
||||
- Using a custom `etcd.conf.yml`: The etcd chart allows mounting a custom etcd.conf.yml file using the `configFileConfigMap` value. Example:
|
||||
- Using a custom `etcd.conf.yml`: The etcd chart allows mounting a custom etcd.conf.yml file as ConfigMap (named, for example, etcd-conf) and deploy it using the `configFileConfigMap=etcd-conf` parameter.
|
||||
|
||||
### Enable security for etcd
|
||||
|
||||
#### Configure RBAC
|
||||
|
||||
In order to enable [Role-based access control for etcd](https://coreos.com/etcd/docs/latest/op-guide/authentication.html) you can set the following parameters:
|
||||
|
||||
```console
|
||||
$ kubectl create configmap etcd-conf --from-file=etcd.conf.yml
|
||||
$ helm install bitnami/etcd --set configFileConfigMap=etcd-conf
|
||||
```
|
||||
|
||||
## Enable security for etcd
|
||||
|
||||
### Configure RBAC
|
||||
|
||||
In order to enable [Role-based access control for etcd](https://coreos.com/etcd/docs/latest/op-guide/authentication.html) you can run the following command:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release --set auth.rbac.enabled --set auth.rbac.rootPassword=YOUR-PASSWORD bitnami/etcd
|
||||
auth.rbac.enabled=true
|
||||
auth.rbac.rootPassword=YOUR-PASSWORD
|
||||
```
|
||||
|
||||
The previous command will deploy etcd creating a `root` user with its associate `root` role with access to everything. The rest of users will use the `guest` role and won't have permissions to do anything.
|
||||
|
||||
### Configure certificated for peer communication
|
||||
#### Configure certificated for peer communication
|
||||
|
||||
In order to enable secure transport between peer nodes deploy the helm chart with these options:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release --set auth.peer.secureTransport=true --set auth.peer.useAutoTLS=true bitnami/etcd
|
||||
auth.peer.secureTransport=true
|
||||
auth.peer.useAutoTLS=true
|
||||
```
|
||||
|
||||
### Configure certificates for client communication
|
||||
#### Configure certificates for client communication
|
||||
|
||||
In order to enable secure transport between client and server you have to create a secret containing the cert and key files and the CA used to sign those client certificates.
|
||||
|
||||
You can create that secret with this command:
|
||||
You can create that secret and deploy the helm chart with these options:
|
||||
|
||||
```console
|
||||
$ kubectl create secret generic etcd-client-certs --from-file=ca.crt=path/to/ca.crt --from-file=cert.pem=path/to/cert.pem --from-file=key.pem=path/to/key.pem
|
||||
```
|
||||
|
||||
Once the secret is created, you can deploy the helm chart with these options:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release --set auth.client.secureTransport=true --set auth.client.enableAuthentication=true --set auth.client.existingSecret=etcd-client-certs bitnami/etcd
|
||||
auth.client.secureTransport=true
|
||||
auth.client.enableAuthentication=true
|
||||
auth.client.existingSecret=etcd-client-certs
|
||||
```
|
||||
|
||||
> Ref: [etcd security model](https://coreos.com/etcd/docs/latest/op-guide/security.html)
|
||||
>
|
||||
> Ref: [Generate self-signed certificagtes for etcd](https://coreos.com/os/docs/latest/generate-self-signed-certificates.html)
|
||||
|
||||
## Persistence and Disaster recovery
|
||||
### Disaster recovery
|
||||
|
||||
### Persistence
|
||||
|
||||
The [Bitnami etcd](https://github.com/bitnami/bitnami-docker-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. This is known to work in GCE, AWS, and Minikube. To enable persistence, deploy the helm chart with these options:
|
||||
You can enable auto 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. You can enable it using the following parameters:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/etcd \
|
||||
--set persistence.enable=true \
|
||||
--set persistence.size=8Gi
|
||||
persistence.enable=true
|
||||
disasterRecovery.enabled=true
|
||||
disasterRecovery.pvc.size=2Gi
|
||||
disasterRecovery.pvc.storageClassName=nfs
|
||||
```
|
||||
|
||||
> **Note**: Disaster recovery feature requires using volumes with ReadWriteMany access mode. For instance, you can use the stable/nfs-server-provisioner chart to provide NFS PVCs.
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami etcd](https://github.com/bitnami/bitnami-docker-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.
|
||||
|
||||
By default, the chart mounts a [Persistent Volume](http://kubernetes.io/docs/user-guide/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning. See the [Configuration](#configuration) 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.
|
||||
@@ -301,25 +288,6 @@ As an alternative, this chart supports using an initContainer to change the owne
|
||||
|
||||
You can enable this initContainer by setting `volumePermissions.enabled` to `true`.
|
||||
|
||||
### Disaster recovery
|
||||
|
||||
You can enable auto 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.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/etcd \
|
||||
--set persistence.enable=true \
|
||||
--set disasterRecovery.enabled=true \
|
||||
--set disasterRecovery.pvc.size=2Gi \
|
||||
--set disasterRecovery.pvc.storageClassName=nfs
|
||||
```
|
||||
|
||||
> **Note**: Disaster recovery feature requires using volumes with ReadWriteMany access mode. For instance, you can use the stable/nfs-server-provisioner chart to provide NFS PVCs:
|
||||
|
||||
```console
|
||||
$ helm install --name nfs-server-provisioner stable/nfs-server-provisioner \
|
||||
--set persistence.enabled=true --set persistence.size=10Gi
|
||||
```
|
||||
|
||||
## Upgrading
|
||||
|
||||
### To 3.0.0
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/etcd
|
||||
tag: 3.4.2-debian-9-r0
|
||||
tag: 3.4.3-debian-9-r0
|
||||
## Specify a imagePullPolicy
|
||||
## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
|
||||
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/etcd
|
||||
tag: 3.4.2-debian-9-r0
|
||||
tag: 3.4.3-debian-9-r0
|
||||
## Specify a imagePullPolicy
|
||||
## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
|
||||
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: grafana
|
||||
version: 1.0.0
|
||||
version: 1.0.1
|
||||
appVersion: 6.4.3
|
||||
description: Grafana is an open source, feature rich metrics dashboard and graph editor for Graphite, Elasticsearch, OpenTSDB, Prometheus and InfluxDB.
|
||||
keywords:
|
||||
|
||||
+30
-37
@@ -45,7 +45,7 @@ $ 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.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the grafana chart and their default values.
|
||||
|
||||
@@ -140,6 +140,25 @@ $ helm install --name my-release -f values.yaml bitnami/grafana
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Enable ingress controller
|
||||
|
||||
```diff
|
||||
- ingress.enabled: false
|
||||
+ ingress.enabled: true
|
||||
```
|
||||
|
||||
### Using custom configuration
|
||||
|
||||
Grafana support multiples configuration files. Using kubernetes you can mount a file using a ConfigMap. For example, to mount a custom `grafana.ini` file or `custom.ini` file you can create a ConfigMap like the following:
|
||||
@@ -154,36 +173,20 @@ data:
|
||||
# Raw text of the file
|
||||
```
|
||||
|
||||
And now you need to pass the ConfigMap name, to the corresponding parameter:
|
||||
|
||||
```console
|
||||
$ helm install bitnami/grafana --set config.useGrafanaIniFile=true,config.grafanaIniConfigMap=myconfig
|
||||
```
|
||||
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, after the creation of the dashboard and datasource ConfigMap in the same way that the explained for the `grafana.ini` file, execute the following to deploy Grafana with custom dashboards:
|
||||
For example, after the creation of the dashboard and datasource ConfigMap in the same way that the explained for the `grafana.ini` file, use the following parameters to deploy Grafana with custom dashboards:
|
||||
|
||||
```console
|
||||
$ helm install bitnami/grafana --set "dashboardsProvider.enabled=true,datasources.secretName=datasource-secret,dashboardsConfigMaps[0].configMapName=mydashboard,dashboardsConfigMaps[0].fileName=mydashboard.json"
|
||||
```
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/grafana
|
||||
```
|
||||
|
||||
- Enable ingress controller
|
||||
|
||||
```diff
|
||||
- ingress.enabled: false
|
||||
+ ingress.enabled: true
|
||||
dashboardsProvider.enabled=true
|
||||
datasources.secretName=datasource-secret
|
||||
dashboardsConfigMaps[0].configMapName=mydashboard
|
||||
dashboardsConfigMaps[0].fileName=mydashboard.json
|
||||
```
|
||||
|
||||
### LDAP configuration
|
||||
@@ -242,16 +245,12 @@ data:
|
||||
email = "email"
|
||||
```
|
||||
|
||||
Create the ConfigMap into the cluster:
|
||||
Create the ConfigMap into the cluster and deploy the Grafana Helm Chart using the existing ConfigMap and the following parameters:
|
||||
|
||||
```console
|
||||
$ kubectl create -f configmap.yaml
|
||||
```
|
||||
|
||||
And deploy the Grafana Helm Chart using the existing ConfigMap:
|
||||
|
||||
```console
|
||||
$ helm install bitnami/grafana --set ldap.enabled=true,ldap.configMapName=ldap-config,ldap.allowSignUp=true
|
||||
ldap.enabled=true
|
||||
ldap.configMapName=ldap-config
|
||||
ldap.allowSignUp=true
|
||||
```
|
||||
|
||||
### Supporting HA (High Availability)
|
||||
@@ -261,12 +260,6 @@ To configure the external database provide a configuration file containing the [
|
||||
|
||||
More information about Grafana HA [here](https://grafana.com/docs/tutorials/ha_setup/)
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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 Grafana](https://github.com/bitnami/bitnami-docker-grafana) image stores the Grafana data and configurations at the `/opt/bitnami/grafana/data` path of the container.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: harbor
|
||||
version: 2.6.12
|
||||
version: 2.6.13
|
||||
appVersion: 1.9.1
|
||||
description: Harbor is an an open source trusted cloud native registry project that stores, signs, and scans content
|
||||
keywords:
|
||||
|
||||
+54
-67
@@ -49,69 +49,7 @@ $ helm delete --purge my-release
|
||||
|
||||
Additionaly, if `persistence.resourcePolicy` is set to `keep`, you should manually delete the PVCs.
|
||||
|
||||
## Downloading the chart
|
||||
|
||||
Download Harbor helm chart
|
||||
|
||||
```bash
|
||||
$ git clone https://github.com/bitnami/charts
|
||||
```
|
||||
|
||||
Change directory to Harbor code
|
||||
|
||||
```bash
|
||||
$ cd charts/bitnami/harbor
|
||||
```
|
||||
|
||||
## Configuration
|
||||
|
||||
### Configure the way how to expose Harbor service:
|
||||
|
||||
- **Ingress**: The ingress controller must be installed in the Kubernetes cluster.
|
||||
**Notes:** 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.
|
||||
- **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
|
||||
2. populate the token service URL returned to docker/notary client
|
||||
|
||||
Format: `protocol://domain[:port]`. Usually:
|
||||
|
||||
- if expose the service via `Ingress`, the `domain` should be the value of `service.ingress.hosts.core`
|
||||
- if expose the service via `ClusterIP`, the `domain` should be the value of `service.clusterIP.name`
|
||||
- if expose the service via `NodePort`, the `domain` should be the IP address of one Kubernetes node
|
||||
- if expose the service via `LoadBalancer`, 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.
|
||||
|
||||
### 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:
|
||||
|
||||
- **Secret keys**: Secret keys are used for secure communication between components. Fill `core.secret`, `jobservice.secret` and `registry.secret` to configure.
|
||||
- **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)).
|
||||
|
||||
### 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`.
|
||||
|
||||
### Configure the deployment options:
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the Harbor chart and the default values. They can be configured in `values.yaml` or set via `--set` flag during installation.
|
||||
|
||||
@@ -359,9 +297,18 @@ Alternatively, a YAML file that specifies the values for the above parameters ca
|
||||
```console
|
||||
$ helm install --name my-release -f values.yaml bitnami/harbor
|
||||
```
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`:
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- The way how to expose the service: `Ingress`, `ClusterIP`, `NodePort` or `LoadBalancer`:
|
||||
```diff
|
||||
@@ -393,11 +340,51 @@ This chart includes a `values-production.yaml` file where you can find some para
|
||||
+ postgresql.replication.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### Configure the way how to expose Harbor service:
|
||||
|
||||
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.
|
||||
- **Ingress**: The ingress controller must be installed in the Kubernetes cluster.
|
||||
**Notes:** 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.
|
||||
- **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.
|
||||
|
||||
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 external URL:
|
||||
|
||||
The external URL for Harbor core service is used to:
|
||||
|
||||
1. populate the docker/helm commands showed on portal
|
||||
2. populate the token service URL returned to docker/notary client
|
||||
|
||||
Format: `protocol://domain[:port]`. Usually:
|
||||
|
||||
- if expose the service via `Ingress`, the `domain` should be the value of `service.ingress.hosts.core`
|
||||
- if expose the service via `ClusterIP`, the `domain` should be the value of `service.clusterIP.name`
|
||||
- if expose the service via `NodePort`, the `domain` should be the IP address of one Kubernetes node
|
||||
- if expose the service via `LoadBalancer`, 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.
|
||||
|
||||
### 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:
|
||||
|
||||
- **Secret keys**: Secret keys are used for secure communication between components. Fill `core.secret`, `jobservice.secret` and `registry.secret` to configure.
|
||||
- **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)).
|
||||
|
||||
### 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`.
|
||||
|
||||
## Upgrade
|
||||
|
||||
|
||||
@@ -15,4 +15,4 @@ maintainers:
|
||||
name: influxdb
|
||||
sources:
|
||||
- https://github.com/bitnami/bitnami-docker-influxdb
|
||||
version: 0.1.1
|
||||
version: 0.1.2
|
||||
|
||||
+94
-101
@@ -45,84 +45,7 @@ $ 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.
|
||||
|
||||
## Standalone vs High Availability architecture
|
||||
|
||||
You can install the InfluxDB chart with two different architecture setups: `standalone` or `high-availability`
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/minio --set architecture="standalone"
|
||||
```
|
||||
|
||||
or
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/minio --set architecture="high-availability"
|
||||
```
|
||||
|
||||
The standalone architecture installs a deployment with one InfluxDB server (it cannot be scaled):
|
||||
|
||||
```
|
||||
┌──────────────────┐
|
||||
│ Ingress │
|
||||
│ Controller │
|
||||
└────────┬─────────┘
|
||||
|
|
||||
│ /query
|
||||
│ /write
|
||||
▼
|
||||
┌────────────────┐
|
||||
│ InfluxDB │
|
||||
| svc │
|
||||
└───────┬────────┘
|
||||
│
|
||||
▼
|
||||
┌──────────┐
|
||||
│ InfluxDB │
|
||||
│ Server │
|
||||
│ Pod │
|
||||
└──────────┘
|
||||
```
|
||||
|
||||
The high availability install a statefulset with N InfluxDB servers and M InfluxDB Relay instances:
|
||||
|
||||
```
|
||||
┌──────────────────┐
|
||||
│ Ingress │
|
||||
│ Controller │
|
||||
└───────┬─┬────────┘
|
||||
│ │
|
||||
│ │
|
||||
┌────────────┘ └─────────────┐
|
||||
│ │
|
||||
│ /write /query │
|
||||
▼ ▼
|
||||
┌────────────────┐ ┌────────────────┐
|
||||
│ InfluxDB Relay │ │ InfluxDB │
|
||||
│ svc │ │ svc │
|
||||
└───────┬─┬──────┘ └─────┬─┬────────┘
|
||||
┌────── │─|───────────────|─│───────┐
|
||||
| │ | | │ ▼
|
||||
┌─────┴────┐ │ | | │ ┌──────────┐
|
||||
│ InfluxDB │ │ | | │ │ InfluxDB │
|
||||
│ Relay │◀─┘ | | └─▶│ Server │
|
||||
│ Pod │ │ │ │ Pod │
|
||||
└─────┬────┘ │ │ └──────────┘
|
||||
| │ │ ▲
|
||||
└─────────│───────────────│─────┐ |
|
||||
│ │ | |
|
||||
┌──────────── │───────────────│───────────┘
|
||||
| │ │ |
|
||||
| │ │ ▼
|
||||
┌─┴────────┐ │ │ ┌──────────┐
|
||||
│ InfluxDB │ │ │ │ InfluxDB │
|
||||
│ Relay │◀───┘ └──▶│ Server │
|
||||
│ Pod │ │ Pod │
|
||||
└─────┬────┘ └──────────┘
|
||||
| ▲
|
||||
└───────────────────────────────────┘
|
||||
```
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the InfluxDB chart and their default values.
|
||||
|
||||
@@ -256,25 +179,17 @@ $ helm install --name my-release -f values.yaml bitnami/influxdb
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### Configure the way how to expose InfluxDB
|
||||
## Configuration and installation details
|
||||
|
||||
- **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.
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
### Adjust permissions of persistent volume mountpoint
|
||||
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.
|
||||
|
||||
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`.
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Production configuration and horizontal scaling
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`:
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Use the `high-availability` architecture:
|
||||
|
||||
@@ -308,22 +223,91 @@ This chart includes a `values-production.yaml` file where you can find some para
|
||||
+ networkPolicy.allowExternal: false
|
||||
```
|
||||
|
||||
To horizontally scale this chart once it has been deployed (only available in the `high-availability` architecture):
|
||||
To horizontally scale this chart once it has been deployed (only available in the `high-availability` architecture), you can use the following parameters:
|
||||
|
||||
```console
|
||||
$ helm upgrade my-release bitnami/influxdb \
|
||||
-f ./values-production.yaml \
|
||||
--set influxdb.replicaCount=3 \
|
||||
--set relay.replicaCount=2
|
||||
influxdb.replicaCount=3
|
||||
relay.replicaCount=2
|
||||
```
|
||||
|
||||
> **Note**: Scaling the statefulset with `kubectl scale ...` command is discouraged. Use `helm upgrade ...` for horizontal scaling to ensure the InfluxDB Relay configuration is refreshed and aware of the new pods.
|
||||
## Standalone vs High Availability architecture
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
You can install the InfluxDB chart with two different architecture setups: "standalone" or "high-availability", you can use the `architecture` parameter:
|
||||
|
||||
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.
|
||||
```console
|
||||
architecture="standalone"
|
||||
architecture="high-availability"
|
||||
```
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
The standalone architecture installs a deployment with one InfluxDB server (it cannot be scaled):
|
||||
|
||||
```
|
||||
┌──────────────────┐
|
||||
│ Ingress │
|
||||
│ Controller │
|
||||
└────────┬─────────┘
|
||||
|
|
||||
│ /query
|
||||
│ /write
|
||||
▼
|
||||
┌────────────────┐
|
||||
│ InfluxDB │
|
||||
| svc │
|
||||
└───────┬────────┘
|
||||
│
|
||||
▼
|
||||
┌──────────┐
|
||||
│ InfluxDB │
|
||||
│ Server │
|
||||
│ Pod │
|
||||
└──────────┘
|
||||
```
|
||||
|
||||
The high availability install a statefulset with N InfluxDB servers and M InfluxDB Relay instances:
|
||||
|
||||
```
|
||||
┌──────────────────┐
|
||||
│ Ingress │
|
||||
│ Controller │
|
||||
└───────┬─┬────────┘
|
||||
│ │
|
||||
│ │
|
||||
┌────────────┘ └─────────────┐
|
||||
│ │
|
||||
│ /write /query │
|
||||
▼ ▼
|
||||
┌────────────────┐ ┌────────────────┐
|
||||
│ InfluxDB Relay │ │ InfluxDB │
|
||||
│ svc │ │ svc │
|
||||
└───────┬─┬──────┘ └─────┬─┬────────┘
|
||||
┌────── │─|───────────────|─│───────┐
|
||||
| │ | | │ ▼
|
||||
┌─────┴────┐ │ | | │ ┌──────────┐
|
||||
│ InfluxDB │ │ | | │ │ InfluxDB │
|
||||
│ Relay │◀─┘ | | └─▶│ Server │
|
||||
│ Pod │ │ │ │ Pod │
|
||||
└─────┬────┘ │ │ └──────────┘
|
||||
| │ │ ▲
|
||||
└─────────│───────────────│─────┐ |
|
||||
│ │ | |
|
||||
┌──────────── │───────────────│───────────┘
|
||||
| │ │ |
|
||||
| │ │ ▼
|
||||
┌─┴────────┐ │ │ ┌──────────┐
|
||||
│ InfluxDB │ │ │ │ InfluxDB │
|
||||
│ Relay │◀───┘ └──▶│ Server │
|
||||
│ Pod │ │ 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
|
||||
|
||||
@@ -355,11 +339,20 @@ In addition to these options, you can also set an external ConfigMap with all th
|
||||
|
||||
The allowed extensions are `.sh`, and `.txt`.
|
||||
|
||||
### Persistence
|
||||
## 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`.
|
||||
|
||||
## Upgrade
|
||||
|
||||
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 `adminUser.pwd`, `user.pwd`, `readUser.pwd` and `writeUser.pwd` parameters when upgrading the chart:
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: jenkins
|
||||
version: 3.4.5
|
||||
version: 3.4.6
|
||||
appVersion: 2.190.1
|
||||
description: The leading open source automation server
|
||||
keywords:
|
||||
|
||||
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Jenkins chart and their default values.
|
||||
|
||||
@@ -133,6 +133,8 @@ $ helm install --name my-release -f values.yaml bitnami/jenkins
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: kafka
|
||||
version: 6.1.2
|
||||
version: 6.1.3
|
||||
appVersion: 2.3.0
|
||||
description: Apache Kafka is a distributed streaming platform.
|
||||
keywords:
|
||||
|
||||
+28
-35
@@ -44,7 +44,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Kafka chart and their default values.
|
||||
|
||||
@@ -193,13 +193,17 @@ $ helm install --name my-release -f values.yaml bitnami/kafka
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration and horizontal scaling
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/kafka
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Number of Kafka nodes:
|
||||
```diff
|
||||
@@ -260,25 +264,14 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/kafka
|
||||
+ zookeeper.metrics.enabled: true
|
||||
```
|
||||
|
||||
To horizontally scale this chart, first download the [values-production.yaml](values-production.yaml) file to your local folder, then:
|
||||
To horizontally scale this chart once it has been deployed, you can upgrade the deployment using a new value for the `replicaCount` parameter.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/kafka
|
||||
$ kubectl scale statefulset my-kafka-slave --replicas=3
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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 custom parameters
|
||||
### Setting custom parameters
|
||||
|
||||
Any environment variable beginning with `KAFKA_CFG_` will be mapped to its corresponding Kafka key. For example, use `KAFKA_CFG_BACKGROUND_THREADS` in order to set `background.threads`.
|
||||
In order to pass custom environment variables use the `extraEnvVars` property.
|
||||
|
||||
## Enable security for Kafka and Zookeeper
|
||||
### Enable security for Kafka and Zookeeper
|
||||
|
||||
If you enabled the authentication for Kafka, the SASL_SSL listener will be configured with your provided inputs. In particular you can set the following pair of credentials:
|
||||
|
||||
@@ -288,25 +281,25 @@ If you enabled the authentication for Kafka, the SASL_SSL listener will be confi
|
||||
|
||||
In order to configure the authentication, you **must** create a secret containing the *kafka.keystore.jks* and *kafka.trustore.jks* certificates and pass the secret name with the `--auth.certificatesSecret` option when deploying the chart.
|
||||
|
||||
You can create the secret with this command assuming you have your certificates in your working directory:
|
||||
You can create the secret and deploy the chart with authentication using the following parameters:
|
||||
|
||||
```console
|
||||
kubectl create secret generic kafka-certificates --from-file=./kafka.keystore.jks --from-file=./kafka.truststore.jks
|
||||
auth.enabled=true
|
||||
auth.brokerUser=brokerUser
|
||||
auth.brokerPassword=brokerPassword
|
||||
auth.interBrokerUser=interBrokerUser
|
||||
auth.interBrokerPassword=interBrokerPassword
|
||||
auth.zookeeperUser=zookeeperUser
|
||||
auth.zookeeperPassword=zookeeperPassword
|
||||
zookeeper.auth.enabled=true
|
||||
zookeeper.auth.serverUsers=zookeeperUser
|
||||
zookeeper.auth.serverPasswords=zookeeperPassword
|
||||
zookeeper.auth.clientUser=zookeeperUser
|
||||
zookeeper.auth.clientPassword=zookeeperPassword
|
||||
auth.certificatesSecret=kafka-certificates
|
||||
```
|
||||
|
||||
As an example of Kafka installed with authentication you can use this command:
|
||||
|
||||
```console
|
||||
helm install --name my-release bitnami/kafka --set auth.enabled=true \
|
||||
--set auth.brokerUser=brokerUser --set auth.brokerPassword=brokerPassword \
|
||||
--set auth.interBrokerUser=interBrokerUser --set auth.interBrokerPassword=interBrokerPassword \
|
||||
--set auth.zookeeperUser=zookeeperUser --set auth.zookeeperPassword=zookeeperPassword \
|
||||
--set zookeeper.auth.enabled=true --set zookeeper.auth.serverUsers=zookeeperUser --set zookeeper.auth.serverPasswords=zookeeperPassword \
|
||||
--set zookeeper.auth.clientUser=zookeeperUser --set zookeeper.auth.clientPassword=zookeeperPassword \
|
||||
--set auth.certificatesSecret=kafka-certificates
|
||||
```
|
||||
|
||||
> **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 `--set auth.certificatesPassword` option to provide your password.
|
||||
> **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 `auth.certificatesPassword` option to provide your password.
|
||||
|
||||
## Persistence
|
||||
|
||||
|
||||
@@ -3,4 +3,4 @@ dependencies:
|
||||
repository: https://charts.bitnami.com/bitnami
|
||||
version: 5.0.4
|
||||
digest: sha256:2f3c43ce02e3966648b8c89be121fe39537f62ea1d161ad908f51ddc90e4243e
|
||||
generated: 2019-10-23T07:19:44.128778945Z
|
||||
generated: 2019-10-24T08:08:15.103409916Z
|
||||
|
||||
@@ -187,8 +187,10 @@ spec:
|
||||
value: {{ .Values.logRetentionCheckIntervalMs | quote }}
|
||||
- name: KAFKA_CFG_LOG_RETENTION_HOURS
|
||||
value: {{ .Values.logRetentionHours | quote }}
|
||||
{{- if .Values.logMessageFormatVersion }}
|
||||
- name: KAFKA_CFG_LOG_MESSAGE_FORMAT_VERSION
|
||||
value: {{ .Values.logMessageFormatVersion | quote }}
|
||||
{{- end }}
|
||||
- name: KAFKA_CFG_MESSAGE_MAX_BYTES
|
||||
value: {{ .Values.maxMessageBytes | replace "_" "" | quote }}
|
||||
- name: KAFKA_CFG_LOG_SEGMENT_BYTES
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/kafka
|
||||
tag: 2.3.0-debian-9-r113
|
||||
tag: 2.3.0-debian-9-r114
|
||||
## Specify a imagePullPolicy
|
||||
## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
|
||||
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
|
||||
@@ -337,7 +337,7 @@ metrics:
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/kafka-exporter
|
||||
tag: 1.2.0-debian-9-r72
|
||||
tag: 1.2.0-debian-9-r73
|
||||
pullPolicy: IfNotPresent
|
||||
## Optionally specify an array of imagePullSecrets.
|
||||
## Secrets must be manually created in the namespace.
|
||||
@@ -368,7 +368,7 @@ metrics:
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/jmx-exporter
|
||||
tag: 0.12.0-debian-9-r72
|
||||
tag: 0.12.0-debian-9-r73
|
||||
pullPolicy: IfNotPresent
|
||||
## Optionally specify an array of imagePullSecrets.
|
||||
## Secrets must be manually created in the namespace.
|
||||
|
||||
@@ -14,7 +14,7 @@
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/kafka
|
||||
tag: 2.3.0-debian-9-r113
|
||||
tag: 2.3.0-debian-9-r114
|
||||
## Specify a imagePullPolicy
|
||||
## Defaults to 'Always' if image tag is 'latest', else set to 'IfNotPresent'
|
||||
## ref: http://kubernetes.io/docs/user-guide/images/#pre-pulling-images
|
||||
@@ -337,7 +337,7 @@ metrics:
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/kafka-exporter
|
||||
tag: 1.2.0-debian-9-r72
|
||||
tag: 1.2.0-debian-9-r73
|
||||
pullPolicy: IfNotPresent
|
||||
## Optionally specify an array of imagePullSecrets.
|
||||
## Secrets must be manually created in the namespace.
|
||||
@@ -368,7 +368,7 @@ metrics:
|
||||
image:
|
||||
registry: docker.io
|
||||
repository: bitnami/jmx-exporter
|
||||
tag: 0.12.0-debian-9-r72
|
||||
tag: 0.12.0-debian-9-r73
|
||||
pullPolicy: IfNotPresent
|
||||
## Optionally specify an array of imagePullSecrets.
|
||||
## Secrets must be manually created in the namespace.
|
||||
|
||||
@@ -2,7 +2,7 @@ apiVersion: v1
|
||||
name: kibana
|
||||
appVersion: 7.4.1
|
||||
description: Kibana is an open source, browser based analytics and search dashboard for Elasticsearch.
|
||||
version: 0.1.1
|
||||
version: 1.0.0
|
||||
keywords:
|
||||
- kibana
|
||||
- analitics
|
||||
|
||||
+183
-214
@@ -63,89 +63,93 @@ $ 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
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the kibana chart and their default values.
|
||||
|
||||
| Parameter | Description | Default |
|
||||
| ------------------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------- |
|
||||
| `global.imageRegistry` | Global Docker image registry | `nil` |
|
||||
| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` (does not add image pull secrets to deployed pods) |
|
||||
| `global.storageClass` | Global storage class for dynamic provisioning | `nil` |
|
||||
| `image.registry` | Kibana image registry | `docker.io` |
|
||||
| `image.repository` | Kibana image name | `bitnami/kibana` |
|
||||
| `image.tag` | Kibana image tag | `{TAG_NAME}` |
|
||||
| `image.pullPolicy` | Kibana image pull policy | `IfNotPresent` |
|
||||
| `image.pullSecrets` | Specify docker-registry secret names as an array | `[]` (does not add image pull secrets to deployed pods) |
|
||||
| `nameOverride` | String to partially override kibana.fullname template with a string (will prepend the release name) | `nil` |
|
||||
| `fullnameOverride` | String to fully override kibana.fullname template with a string | `nil` |
|
||||
| `replicaCount` | Number of replicas of the Kibana Pod | `1` |
|
||||
| `updateStrategy` | Update strategy for deployment (evaluated as a template) | `{type: "RollingUpdate"}` |
|
||||
| `schedulerName` | Alternative scheduler | `nil` |
|
||||
| `plugins` | Array containing the Kibana plugins to be installed in deployment | `[]` |
|
||||
| `savedObjects.urls` | Array containing links to NDJSON files to be imported during Kibana initialization | `[]` |
|
||||
| `savedObjects.configmap` | Configmap containing NDJSON files to be imported during Kibana initialization (evaluated as a template) | `[]` |
|
||||
| `extraConfiguration` | Extra settings to be added to the default kibana.yml configmap that the chart creates (unless replaced using `configurationCM`). Evaluated as a template | `nil` |
|
||||
| `configurationCM` | ConfigMap containing a kibana.yml file that will replace the default one specified in configuration.yaml | `nil` |
|
||||
| `extraEnvVars` | Array containing extra env vars to configure Kibana | `nil` |
|
||||
| `extraEnvVarsCM` | ConfigMap containing extra env vars to configure Kibana | `nil` |
|
||||
| `extraEnvVarsSecret` | Secret containing extra env vars to configure Kibana (in case of sensitive data) | `nil` |
|
||||
| `extraVolumes` | Array of extra volumes to be added to the Kibana deployment (evaluated as template). Requires setting `extraVolumeMounts` | `nil` |
|
||||
| `extraVolumeMounts` | Array of extra volume mounts to be added to the Kibana deployment (evaluated as template). Normally used with `extraVolumes`. | `nil` |
|
||||
| `volumePermissions.enabled` | Enable init container that changes volume permissions in the data directory (for cases where the default k8s `runAsUser` and `fsUser` values do not work) | `false` |
|
||||
| `volumePermissions.image.registry` | Init container volume-permissions image registry | `docker.io` |
|
||||
| `volumePermissions.image.repository` | Init container volume-permissions image name | `bitnami/minideb` |
|
||||
| `volumePermissions.image.tag` | Init container volume-permissions image tag | `stretch` |
|
||||
| `volumePermissions.image.pullPolicy` | Init container volume-permissions image pull policy | `Always` |
|
||||
| `volumePermissions.resources` | Init container resource requests/limit | `nil` |
|
||||
| `persistence.enabled` | Enable persistence | `true` |
|
||||
| `presistence.storageClass` | Storage class to use with the PVC | `nil` |
|
||||
| `persistence.accessMode` | Access mode to the PV | `ReadWriteOnce` |
|
||||
| `persistence.size` | Size for the PV | `10Gi` |
|
||||
| `livenessProbe.enabled` | Enable/disable the Liveness probe | `true` |
|
||||
| `livenessProbe.initialDelaySeconds` | Delay before liveness probe is initiated | `60` |
|
||||
| `livenessProbe.periodSeconds` | How often to perform the probe | `10` |
|
||||
| `livenessProbe.timeoutSeconds` | When the probe times out | `5` |
|
||||
| `livenessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed.| `1` |
|
||||
| `livenessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | `6` |
|
||||
| `readinessProbe.enabled` | Enable/disable the Readiness probe | `true` |
|
||||
| `readinessProbe.initialDelaySeconds` | Delay before readiness probe is initiated | `5` |
|
||||
| `readinessProbe.periodSeconds` | How often to perform the probe | `10` |
|
||||
| `readinessProbe.timeoutSeconds` | When the probe times out | `5` |
|
||||
| `readinessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | `6` |
|
||||
| `readinessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed.| `1` |
|
||||
| `service.type` | Kubernetes Service type | | `ClusterIP` |
|
||||
| `service.nodePort` | Port to bind to for NodePort service type (client port) | `nil` |
|
||||
| `service.annotations` | Annotations for Kibana service (evaluated as a template) | `{}` |
|
||||
| `service.externalTrafficPolicy` | Enable client source IP preservation | `Cluster` |
|
||||
| `service.loadBalancerIP` | loadBalancerIP if Kibana service type is `LoadBalancer` | `nil` |
|
||||
| `service.extraPorts` | Extra ports to expose in the service (normally used with the `sidecar` value). Evaluated as a template. | `nil` |
|
||||
| `forceInitScripts` | Force the execution of the init scripts located in `/docker-entrypoint-initdb.d` | `false` |
|
||||
| `initScriptsCM` | ConfigMap containing `/docker-entrypoint-initdb.d` scripts to be executed at initialization time (evaluated as a template) | `nil` |
|
||||
| `initScriptsSecret` | Secret containing `/docker-entrypoint-initdb.d` scripts to be executed at initialization time (that contain sensitive data). Evaluated as a template. | `nil` |
|
||||
| `ingress.enabled` | Enable the use of the ingress controller to access the web UI | `false` |
|
||||
| `ingress.annotations` | Annotations for the Kibana Ingress | `{}` |
|
||||
| `ingress.hosts` | Add hosts to the ingress controller with name and path | `name: kibana.local`, `path: /` |
|
||||
| `ingress.tls` | Configure TLS for the Kibana Ingress | `[]` |
|
||||
| `securityContext.enabled` | Enable securityContext on for Kibana deployment | `true` |
|
||||
| `securityContext.runAsUser` | User for the security context | `1001` |
|
||||
| `securityContext.fsGroup` | Group to configure permissions for volumes | `1001` |
|
||||
| `resources` | Configure resource requests and limits (evaluated as a template) | `nil` |
|
||||
| `nodeSelector` | Node labels for pod assignment (evaluated as a template) | `{}` |
|
||||
| `tolerations` | Tolerations for pod assignment (evaluated as a template) | `[]` |
|
||||
| `affinity` | Affinity for pod assignment (evaluated as a template) | `{}` |
|
||||
| `podAnnotations` | Pod annotations (evaluated as a template) | `{}` |
|
||||
| `sidecars` | Attach additional containers to the pod (evaluated as a template) | `nil` |
|
||||
| `initContainers` | Add additional init containers to the pod (evaluated as a template) | `nil` |
|
||||
| `metrics.enabled` | Start a side-car prometheus exporter | `false` |
|
||||
| `metrics.service.annotations` | Prometheus annotations for the Kibana service | `{ prometheus.io/scrape: "true", prometheus.io/port: "80", prometheus.io/path: "_prometheus/metrics" }` |
|
||||
| `elasticsearch.enabled` | Use bundled Elasticsearch | `true` |
|
||||
| `elasticsearch.sysctlImage.enabled` | Use sysctl image for bundled Elasticsearch | `false` |
|
||||
| `elasticsearch.master.replicas` | Desired number of Elasticsearch master-eligible nodes | `1` |
|
||||
| `elasticsearch.coordinating.replicas` | Desired number of Elasticsearch coordinating-only nodes | `1` |
|
||||
| `elasticsearch.data.replicas` | Desired number of Elasticsearch data nodes | `1` |
|
||||
| `elasticsearch.external.hosts` | Array containing the hostnames for the already existing Elasticsearch instances | `nil` |
|
||||
| `elasticsearch.external.port` | Port for the accessing external Elasticsearch instances | `nil` |
|
||||
| Parameter | Description | Default |
|
||||
| ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- |
|
||||
| `global.imageRegistry` | Global Docker image registry | `nil` |
|
||||
| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` (does not add image pull secrets to deployed pods) |
|
||||
| `global.storageClass` | Global storage class for dynamic provisioning | `nil` |
|
||||
| `image.registry` | Kibana image registry | `docker.io` |
|
||||
| `image.repository` | Kibana image name | `bitnami/kibana` |
|
||||
| `image.tag` | Kibana image tag | `{TAG_NAME}` |
|
||||
| `image.pullPolicy` | Kibana image pull policy | `IfNotPresent` |
|
||||
| `image.pullSecrets` | Specify docker-registry secret names as an array | `[]` (does not add image pull secrets to deployed pods) |
|
||||
| `nameOverride` | String to partially override kibana.fullname template with a string (will prepend the release name) | `nil` |
|
||||
| `fullnameOverride` | String to fully override kibana.fullname template with a string | `nil` |
|
||||
| `replicaCount` | Number of replicas of the Kibana Pod | `1` |
|
||||
| `updateStrategy` | Update strategy for deployment (evaluated as a template) | `{type: "RollingUpdate"}` |
|
||||
| `schedulerName` | Alternative scheduler | `nil` |
|
||||
| `plugins` | Array containing the Kibana plugins to be installed in deployment | `[]` |
|
||||
| `savedObjects.urls` | Array containing links to NDJSON files to be imported during Kibana initialization | `[]` |
|
||||
| `savedObjects.configmap` | Configmap containing NDJSON files to be imported during Kibana initialization (evaluated as a template) | `[]` |
|
||||
| `extraConfiguration` | Extra settings to be added to the default kibana.yml configmap that the chart creates (unless replaced using `configurationCM`). Evaluated as a template | `nil` |
|
||||
| `configurationCM` | ConfigMap containing a kibana.yml file that will replace the default one specified in configuration.yaml | `nil` |
|
||||
| `extraEnvVars` | Array containing extra env vars to configure Kibana | `nil` |
|
||||
| `extraEnvVarsCM` | ConfigMap containing extra env vars to configure Kibana | `nil` |
|
||||
| `extraEnvVarsSecret` | Secret containing extra env vars to configure Kibana (in case of sensitive data) | `nil` |
|
||||
| `extraVolumes` | Array of extra volumes to be added to the Kibana deployment (evaluated as template). Requires setting `extraVolumeMounts` | `nil` |
|
||||
| `extraVolumeMounts` | Array of extra volume mounts to be added to the Kibana deployment (evaluated as template). Normally used with `extraVolumes`. | `nil` |
|
||||
| `volumePermissions.enabled` | Enable init container that changes volume permissions in the data directory (for cases where the default k8s `runAsUser` and `fsUser` values do not work) | `false` |
|
||||
| `volumePermissions.image.registry` | Init container volume-permissions image registry | `docker.io` |
|
||||
| `volumePermissions.image.repository` | Init container volume-permissions image name | `bitnami/minideb` |
|
||||
| `volumePermissions.image.tag` | Init container volume-permissions image tag | `stretch` |
|
||||
| `volumePermissions.image.pullPolicy` | Init container volume-permissions image pull policy | `Always` |
|
||||
| `volumePermissions.resources` | Init container resource requests/limit | `nil` |
|
||||
| `persistence.enabled` | Enable persistence | `true` |
|
||||
| `presistence.storageClass` | Storage class to use with the PVC | `nil` |
|
||||
| `persistence.accessMode` | Access mode to the PV | `ReadWriteOnce` |
|
||||
| `persistence.size` | Size for the PV | `10Gi` |
|
||||
| `livenessProbe.enabled` | Enable/disable the Liveness probe | `true` |
|
||||
| `livenessProbe.initialDelaySeconds` | Delay before liveness probe is initiated | `60` |
|
||||
| `livenessProbe.periodSeconds` | How often to perform the probe | `10` |
|
||||
| `livenessProbe.timeoutSeconds` | When the probe times out | `5` |
|
||||
| `livenessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed. | `1` |
|
||||
| `livenessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | `6` |
|
||||
| `readinessProbe.enabled` | Enable/disable the Readiness probe | `true` |
|
||||
| `readinessProbe.initialDelaySeconds` | Delay before readiness probe is initiated | `5` |
|
||||
| `readinessProbe.periodSeconds` | How often to perform the probe | `10` |
|
||||
| `readinessProbe.timeoutSeconds` | When the probe times out | `5` |
|
||||
| `readinessProbe.failureThreshold` | Minimum consecutive failures for the probe to be considered failed after having succeeded. | `6` |
|
||||
| `readinessProbe.successThreshold` | Minimum consecutive successes for the probe to be considered successful after having failed. | `1` |
|
||||
| `service.type` | Kubernetes Service type | | `ClusterIP` |
|
||||
| `service.nodePort` | Port to bind to for NodePort service type (client port) | `nil` |
|
||||
| `service.annotations` | Annotations for Kibana service (evaluated as a template) | `{}` |
|
||||
| `service.externalTrafficPolicy` | Enable client source IP preservation | `Cluster` |
|
||||
| `service.loadBalancerIP` | loadBalancerIP if Kibana service type is `LoadBalancer` | `nil` |
|
||||
| `service.extraPorts` | Extra ports to expose in the service (normally used with the `sidecar` value). Evaluated as a template. | `nil` |
|
||||
| `forceInitScripts` | Force the execution of the init scripts located in `/docker-entrypoint-initdb.d` | `false` |
|
||||
| `initScriptsCM` | ConfigMap containing `/docker-entrypoint-initdb.d` scripts to be executed at initialization time (evaluated as a template) | `nil` |
|
||||
| `initScriptsSecret` | Secret containing `/docker-entrypoint-initdb.d` scripts to be executed at initialization time (that contain sensitive data). Evaluated as a template. | `nil` |
|
||||
| `ingress.enabled` | Enable ingress controller resource | `false` |
|
||||
| `ingress.certManager` | Add annotations for cert-manager | `false` |
|
||||
| `ingress.annotations` | Ingress annotations | `[]` |
|
||||
| `ingress.hosts[0].name` | Hostname to your Kibana installation | `kibana.local` |
|
||||
| `ingress.hosts[0].path` | Path within the url structure | `/` |
|
||||
| `ingress.hosts[0].tls` | Utilize TLS backend in ingress | `false` |
|
||||
| `ingress.hosts[0].tlsHosts` | Array of TLS hosts for ingress record (defaults to `ingress.hosts[0].name` if `nil`) | `nil` |
|
||||
| `ingress.hosts[0].tlsSecret` | TLS Secret (certificates) | `kibana.local-tls` |
|
||||
| `securityContext.enabled` | Enable securityContext on for Kibana deployment | `true` |
|
||||
| `securityContext.runAsUser` | User for the security context | `1001` |
|
||||
| `securityContext.fsGroup` | Group to configure permissions for volumes | `1001` |
|
||||
| `resources` | Configure resource requests and limits (evaluated as a template) | `nil` |
|
||||
| `nodeSelector` | Node labels for pod assignment (evaluated as a template) | `{}` |
|
||||
| `tolerations` | Tolerations for pod assignment (evaluated as a template) | `[]` |
|
||||
| `affinity` | Affinity for pod assignment (evaluated as a template) | `{}` |
|
||||
| `podAnnotations` | Pod annotations (evaluated as a template) | `{}` |
|
||||
| `sidecars` | Attach additional containers to the pod (evaluated as a template) | `nil` |
|
||||
| `initContainers` | Add additional init containers to the pod (evaluated as a template) | `nil` |
|
||||
| `metrics.enabled` | Start a side-car prometheus exporter | `false` |
|
||||
| `metrics.service.annotations` | Prometheus annotations for the Kibana service | `{ prometheus.io/scrape: "true", prometheus.io/port: "80", prometheus.io/path: "_prometheus/metrics" }` |
|
||||
| `elasticsearch.enabled` | Use bundled Elasticsearch | `true` |
|
||||
| `elasticsearch.sysctlImage.enabled` | Use sysctl image for bundled Elasticsearch | `false` |
|
||||
| `elasticsearch.master.replicas` | Desired number of Elasticsearch master-eligible nodes | `1` |
|
||||
| `elasticsearch.coordinating.replicas` | Desired number of Elasticsearch coordinating-only nodes | `1` |
|
||||
| `elasticsearch.data.replicas` | Desired number of Elasticsearch data nodes | `1` |
|
||||
| `elasticsearch.external.hosts` | Array containing the hostnames for the already existing Elasticsearch instances | `nil` |
|
||||
| `elasticsearch.external.port` | Port for the accessing external Elasticsearch instances | `nil` |
|
||||
|
||||
Specify each parameter using the `--set key=value[,key=value]` argument to `helm install`. For example,
|
||||
|
||||
@@ -164,139 +168,17 @@ $ helm install --name my-release -f values.yaml bitnami/kibana
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### Using custom configuration
|
||||
## Configuration and installation details
|
||||
|
||||
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:
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
```yaml
|
||||
apiVersion: v1
|
||||
kind: ConfigMap
|
||||
metadata:
|
||||
name: myconfig
|
||||
data:
|
||||
kibana.yml: |-
|
||||
# Raw text of the file
|
||||
```
|
||||
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.
|
||||
|
||||
And now you need to pass the ConfigMap name, to the corresponding parameter:
|
||||
|
||||
```console
|
||||
$ helm install bitnami/kibana --set 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
|
||||
```
|
||||
|
||||
### 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: 6
|
||||
```
|
||||
|
||||
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 Kibana 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.
|
||||
|
||||
```console
|
||||
$ kubectl create configmap special-scripts \
|
||||
--from-file=01_install_kibana_theme.sh \
|
||||
--from-file=02_add_special_agent.sh
|
||||
|
||||
$ kubectl create secret generic special-scripts-sensitive \
|
||||
--from-file=03_install_company_certificates.sh
|
||||
```
|
||||
|
||||
Then use the `initScriptsCM` and `initScriptsSecret` values.
|
||||
|
||||
```console
|
||||
$ helm install bitnami/kibana --name my-release \
|
||||
--set elasticsearch.enabled=false \
|
||||
--set elasticsearch.external.hosts[0]=elasticsearch-host \
|
||||
--set elasticsearch.external.port=9200 \
|
||||
--set initScriptsCM=special-scripts \
|
||||
--set initScriptsSecret=special-scripts-sensitive
|
||||
```
|
||||
|
||||
### Installing plugins
|
||||
|
||||
The Bitnami Kibana chart allows you to install a set of plugins at deployment time using the `plugins` value:
|
||||
|
||||
```console
|
||||
$ helm install bitnami/kibana --name my-release \
|
||||
--set elasticsearch.enabled=false \
|
||||
--set elasticsearch.external.hosts[0]=elasticsearch-host \
|
||||
--set elasticsearch.external.port=9200 \
|
||||
--set 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
|
||||
|
||||
### Importing saved objects
|
||||
|
||||
If you have visualizations and dashboards (in NDJSON format) that you want to import to Kibana. You can create a ConfigMap that includes them.
|
||||
|
||||
```console
|
||||
$ kubectl create configmap my-import --from-file=my-exported-data.ndjson
|
||||
```
|
||||
|
||||
Then install the chart with the `savedObjects.configmap` value:
|
||||
|
||||
```console
|
||||
helm install bitnami/kibana --name my-release \
|
||||
--set savedObjects.configmap=my-import
|
||||
```
|
||||
|
||||
Alternatively, if it is available via URL, you can install the chart as follows
|
||||
|
||||
```console
|
||||
helm install bitnami/kibana --name my-release \
|
||||
--set savedObjects.urls[0]=www.my-site.com/import.ndjson
|
||||
```
|
||||
|
||||
## 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. 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
|
||||
```
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml --set elasticsearch.enabled=false --set elasticsearch.external.hosts[0]=elasticsearch-host --set elasticsearch.external.port=9200 bitnami/kibana
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Disable bundled Elasticsearch
|
||||
|
||||
@@ -323,13 +205,106 @@ $ helm install --name my-release -f ./values-production.yaml --set elasticsearch
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### Using 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
|
||||
```
|
||||
|
||||
### 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: 6
|
||||
```
|
||||
|
||||
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 Kibana 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 `initScriptsCM` and `initScriptsSecret` values.
|
||||
|
||||
```console
|
||||
elasticsearch.enabled=false
|
||||
elasticsearch.external.hosts[0]=elasticsearch-host
|
||||
elasticsearch.external.port=9200
|
||||
initScriptsCM=special-scripts
|
||||
initScriptsSecret=special-scripts-sensitive
|
||||
```
|
||||
|
||||
### Installing plugins
|
||||
|
||||
The Bitnami Kibana chart allows you to install a set of plugins at deployment time using the `plugins` value:
|
||||
|
||||
```console
|
||||
elasticsearch.enabled=false
|
||||
elasticsearch.external.hosts[0]=elasticsearch-host
|
||||
elasticsearch.external.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
|
||||
|
||||
### Importing saved objects
|
||||
|
||||
If you have visualizations and dashboards (in NDJSON format) that you want to import to Kibana. You can create a ConfigMap that includes them and then install the chart with the `savedObjects.configmap` value: `savedObjects.configmap=my-import`
|
||||
|
||||
Alternatively, if it is available via URL, you can install the chart as follows: `savedObjects.urls[0]=www.my-site.com/import.ndjson`
|
||||
|
||||
### 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. 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 Kibana](https://github.com/bitnami/bitnami-docker-kibana) image can persist data. If enabled, the persisted path is `/bitnami/kibana` by default.
|
||||
|
||||
The chart mounts a [Persistent Volume](http://kubernetes.io/docs/user-guide/persistent-volumes/) at this location. The volume is created using dynamic volume provisioning.
|
||||
|
||||
## Adding extra volumes
|
||||
### Adding 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.
|
||||
|
||||
@@ -341,9 +316,3 @@ By default, the chart is configured to use Kubernetes Security Context to automa
|
||||
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`.
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
@@ -28,13 +28,13 @@ spec:
|
||||
- name: volume-permissions
|
||||
image: "{{ template "kibana.volumePermissions.image" . }}"
|
||||
imagePullPolicy: {{ default "" .Values.volumePermissions.image.pullPolicy | quote }}
|
||||
command: ["chown", "-R", "{{ .Values.securityContext.runAsUser }}:{{ .Values.securityContext.fsGroup }}", "{{ .Values.persistence.mountPath }}"]
|
||||
command: ["chown", "-R", "{{ .Values.securityContext.runAsUser }}:{{ .Values.securityContext.fsGroup }}", "/bitnami/kibana"]
|
||||
securityContext:
|
||||
runAsUser: 0
|
||||
resources: {{ toYaml .Values.volumePermissions.resources | nindent 10 }}
|
||||
volumeMounts:
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
- name: kibana-data
|
||||
mountPath: /bitnami/kibana
|
||||
{{- end }}
|
||||
{{- if .Values.initContainers }}
|
||||
{{- tpl (toYaml .Values.initContainers) $ | nindent 6 }}
|
||||
|
||||
@@ -13,26 +13,28 @@ metadata:
|
||||
{{ $key }}: {{ $value | quote }}
|
||||
{{- end }}
|
||||
spec:
|
||||
{{- if .Values.ingress.tls }}
|
||||
tls:
|
||||
{{- range .Values.ingress.tls }}
|
||||
- hosts:
|
||||
{{- range .hosts }}
|
||||
- {{ . | quote }}
|
||||
{{- end }}
|
||||
secretName: {{ .secretName }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
rules:
|
||||
{{- range .Values.ingress.hosts }}
|
||||
- host: {{ .host | quote }}
|
||||
- host: {{ .name }}
|
||||
http:
|
||||
paths:
|
||||
{{- range .paths }}
|
||||
- path: {{ . }}
|
||||
- path: {{ default "/" .path }}
|
||||
backend:
|
||||
serviceName: {{ include "kibana.fullname" $ }}
|
||||
serviceName: {{ $fullName }}
|
||||
servicePort: http
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
tls:
|
||||
{{- range .Values.ingress.hosts }}
|
||||
{{- if .tls }}
|
||||
- hosts:
|
||||
{{- if .tlsHosts }}
|
||||
{{- range $host := .tlsHosts }}
|
||||
- {{ $host }}
|
||||
{{- end }}
|
||||
{{- else }}
|
||||
- {{ .name }}
|
||||
{{- end }}
|
||||
secretName: {{ .tlsSecret }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
|
||||
@@ -225,15 +225,21 @@ ingress:
|
||||
## The list of hostnames to be covered with this ingress record.
|
||||
## Most likely this will be just one host, but in the event more hosts are needed, this is an array
|
||||
hosts:
|
||||
- host: kibana.local
|
||||
paths: ["/"]
|
||||
- name: kibana.local
|
||||
path: /
|
||||
|
||||
## The tls configuration for the ingress
|
||||
## see: https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
|
||||
tls: []
|
||||
# - secretName: chart-example-tls
|
||||
# hosts:
|
||||
# - chart-example.local
|
||||
## Set this to true in order to enable TLS on the ingress record
|
||||
tls: false
|
||||
|
||||
## Optionally specify the TLS hosts for the ingress record
|
||||
## Useful when the Ingress controller supports www-redirection
|
||||
## If not specified, the above host name will be used
|
||||
# tlsHosts:
|
||||
# - www.kibana.local
|
||||
# - kibana.local
|
||||
|
||||
## If TLS is set to true, you must declare what secret will store the key/certificate for TLS
|
||||
tlsSecret: kibana.local-tls
|
||||
|
||||
## SecurityContext configuration
|
||||
##
|
||||
|
||||
@@ -225,15 +225,21 @@ ingress:
|
||||
## The list of hostnames to be covered with this ingress record.
|
||||
## Most likely this will be just one host, but in the event more hosts are needed, this is an array
|
||||
hosts:
|
||||
- host: kibana.local
|
||||
paths: ["/"]
|
||||
- name: kibana.local
|
||||
path: /
|
||||
|
||||
## The tls configuration for the ingress
|
||||
## see: https://kubernetes.io/docs/concepts/services-networking/ingress/#tls
|
||||
tls: []
|
||||
# - secretName: chart-example-tls
|
||||
# hosts:
|
||||
# - chart-example.local
|
||||
## Set this to true in order to enable TLS on the ingress record
|
||||
tls: false
|
||||
|
||||
## Optionally specify the TLS hosts for the ingress record
|
||||
## Useful when the Ingress controller supports www-redirection
|
||||
## If not specified, the above host name will be used
|
||||
# tlsHosts:
|
||||
# - www.kibana.local
|
||||
# - kibana.local
|
||||
|
||||
## If TLS is set to true, you must declare what secret will store the key/certificate for TLS
|
||||
tlsSecret: kibana.local-tls
|
||||
|
||||
## SecurityContext configuration
|
||||
##
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: magento
|
||||
version: 8.3.6
|
||||
version: 8.3.7
|
||||
appVersion: 2.3.3
|
||||
description: A feature-rich flexible e-commerce solution. It includes transaction options, multi-store functionality, loyalty programs, product categorization and shopper filtering, promotion rules, and more.
|
||||
keywords:
|
||||
|
||||
+12
-14
@@ -47,7 +47,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the Magento chart and their default values.
|
||||
|
||||
@@ -182,19 +182,7 @@ $ helm install --name my-release -f values.yaml bitnami/magento
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/magento
|
||||
```
|
||||
|
||||
- Start a side-car prometheus exporter:
|
||||
```diff
|
||||
- metrics.enabled: false
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
@@ -202,6 +190,16 @@ It is strongly recommended to use immutable tags in a production environment. Th
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Start a side-car prometheus exporter:
|
||||
```diff
|
||||
- metrics.enabled: false
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami Magento](https://github.com/bitnami/bitnami-docker-magento) image stores the Magento data and configurations at the `/bitnami/magento` and `/bitnami/apache` paths of the container.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: mariadb-galera
|
||||
version: 0.4.1
|
||||
version: 0.4.2
|
||||
appVersion: 10.3.18
|
||||
description: MariaDB Galera is a multi-master database cluster solution for synchronous replication and high availability.
|
||||
keywords:
|
||||
|
||||
@@ -54,7 +54,7 @@ $ helm delete --purge my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the MariaDB Galera chart and their default values.
|
||||
|
||||
@@ -179,52 +179,17 @@ $ helm install --name my-release -f values.yaml bitnami/mariadb-galera
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### LDAP
|
||||
## Configuration and installation details
|
||||
|
||||
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.
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
- `ldap.enabled`: Enable LDAP support. Defaults to `false`.
|
||||
- `ldap.uri`: LDAP URL beginning in the form `ldap[s]://<hostname>:<port>`. 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.
|
||||
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.
|
||||
|
||||
For example:
|
||||
|
||||
```bash
|
||||
$ helm install --name my-release bitnami/mariadb-galera \
|
||||
--set ldap.enabled="true" \
|
||||
--set ldap.uri="ldap://my_ldap_server" \
|
||||
--set ldap.base="dc=example,dc=org" \
|
||||
--set ldap.binddn="cn=admin,dc=example,dc=org" \
|
||||
--set ldap.bindpw="admin" \
|
||||
--set ldap.bslookup="ou=group-ok,dc=example,dc=org" \
|
||||
--set ldap.nss_initgroups_ignoreusers="root,nslcd" \
|
||||
--set ldap.scope="sub" \
|
||||
--set ldap.tls_reqcert="demand"
|
||||
```
|
||||
|
||||
Next, login to the MariaDB server using the `mysql` client and add the PAM authenticated LDAP users.
|
||||
|
||||
For example,
|
||||
|
||||
```mysql
|
||||
CREATE USER 'bitnami'@'localhost' IDENTIFIED VIA pam USING 'mariadb';
|
||||
```
|
||||
|
||||
With the above example, when the `bitnami` user attempts to login to the MariaDB server, he/she will be authenticated against the LDAP server.
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/mariadb-galera
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Force users to specify a password:
|
||||
|
||||
@@ -244,13 +209,45 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/mariadb-gal
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### LDAP
|
||||
|
||||
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.
|
||||
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.
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
- `ldap.enabled`: Enable LDAP support. Defaults to `false`.
|
||||
- `ldap.uri`: LDAP URL beginning in the form `ldap[s]://<hostname>:<port>`. 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.
|
||||
|
||||
## Initialize a fresh instance
|
||||
For example:
|
||||
|
||||
```console
|
||||
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 MariaDB server using the `mysql` client and add the PAM authenticated LDAP users.
|
||||
|
||||
For example,
|
||||
|
||||
```mysql
|
||||
CREATE USER 'bitnami'@'localhost' IDENTIFIED VIA pam USING 'mariadb';
|
||||
```
|
||||
|
||||
With the above example, when the `bitnami` user attempts to login to the MariaDB server, he/she will be authenticated against the LDAP server.
|
||||
|
||||
### Initialize a fresh instance
|
||||
|
||||
The [Bitnami MariaDB Galera](https://github.com/bitnami/bitnami-docker-mariadb-galera) 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.
|
||||
|
||||
@@ -260,12 +257,6 @@ In addition to these options, you can also set an external ConfigMap with all th
|
||||
|
||||
The allowed extensions are `.sh`, `.sql` and `.sql.gz`.
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami MariaDB Galera](https://github.com/bitnami/bitnami-docker-mariadb-galera) image stores the MariaDB data and configurations at the `/bitnami/mariadb` path of the container.
|
||||
|
||||
The chart mounts a [Persistent Volume](kubernetes.io/docs/user-guide/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can be defined.
|
||||
|
||||
## Extra Init Containers
|
||||
|
||||
The feature allows for specifying a template string for a initContainer in the pod. Usecases include situations when you need some pre-run setup. For example, in IKS (IBM Cloud Kubernetes Service), non-root users do not have write permission on the volume mount path for NFS-powered file storage. So, you could use a initcontainer to `chown` the mount. See a example below, where we add an initContainer on the pod that reports to an external resource that the db is going to starting.
|
||||
@@ -308,6 +299,12 @@ extraContainers:
|
||||
memory: 10Mi
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami MariaDB Galera](https://github.com/bitnami/bitnami-docker-mariadb-galera) image stores the MariaDB data and configurations at the `/bitnami/mariadb` path of the container.
|
||||
|
||||
The chart mounts a [Persistent Volume](kubernetes.io/docs/user-guide/persistent-volumes/) volume at this location. The volume is created using dynamic volume provisioning, by default. An existing PersistentVolumeClaim can be defined.
|
||||
|
||||
## Upgrading
|
||||
|
||||
It's necessary to specify the existing passwords while performing a upgrade to ensure the secrets are not updated with invalid randomly generated passwords. Remember to specify the existing values of the `rootUser.password`, `db.password` and `galera.mariabackup.password` parameters when upgrading the chart:
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: memcached
|
||||
version: 3.0.2
|
||||
version: 3.0.3
|
||||
appVersion: 1.5.19
|
||||
description: Chart for Memcached
|
||||
keywords:
|
||||
|
||||
+12
-14
@@ -43,7 +43,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Memcached chart and their default values.
|
||||
|
||||
@@ -95,19 +95,7 @@ $ helm install --name my-release -f values.yaml bitnami/memcached
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/memcached
|
||||
```
|
||||
|
||||
- Start a side-car prometheus exporter:
|
||||
```diff
|
||||
- metrics.enabled: false
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
|
||||
@@ -115,6 +103,16 @@ It is strongly recommended to use immutable tags in a production environment. Th
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Start a side-car prometheus exporter:
|
||||
```diff
|
||||
- metrics.enabled: false
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
## Notable changes
|
||||
|
||||
### 3.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: metrics-server
|
||||
version: 3.2.4
|
||||
version: 3.2.5
|
||||
appVersion: 0.3.6
|
||||
description: Metrics Server is a cluster-wide aggregator of resource usage data. Metrics Server collects metrics from the Summary API, exposed by Kubelet on each node.
|
||||
keywords:
|
||||
|
||||
@@ -43,7 +43,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Metrics Server chart and their default values.
|
||||
|
||||
@@ -87,21 +87,18 @@ $ helm install --name my-release -f values.yaml bitnami/metrics-server
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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 security for Metrics Server
|
||||
### Enable security for Metrics Server. Configuring RBAC
|
||||
|
||||
### Configure RBAC
|
||||
In order to enable Role-based access control for Metrics Servier you can use the following parameter: `rbac.create=true`
|
||||
|
||||
In order to enable Role-based access control for Metrics Servier you can run the following command:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release --set rbac.create bitnami/metrics-server
|
||||
```
|
||||
## Upgrading
|
||||
|
||||
### To 2.0.0
|
||||
|
||||
+14
-24
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the MinIO chart and their default values.
|
||||
|
||||
@@ -151,13 +151,17 @@ $ helm install --name my-release -f values.yaml bitnami/minio
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/minio
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- MinIO server mode:
|
||||
```diff
|
||||
@@ -201,29 +205,15 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/minio
|
||||
+ networkPolicy.allowExternal: false
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### Distributed mode
|
||||
|
||||
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.
|
||||
You can start the MinIO chart in distributed mode with the following parameter: `mode=distributed`
|
||||
|
||||
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
|
||||
|
||||
You can start the MinIO chart in distributed mode with the following command:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/minio --set mode=distributed
|
||||
```
|
||||
|
||||
This chart sets Minio server in distributed mode with 4 nodes by default. You can change the number of nodes setting the `statefulset.replicaCount` parameter:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/minio --set mode=distributed --set statefulset.replicaCount=8
|
||||
```
|
||||
This chart sets Minio server in distributed mode with 4 nodes by default. You can change the number of nodes setting the `statefulset.replicaCount` parameter, for example to `statefulset.replicaCount=8`
|
||||
|
||||
> Note: that the number of replicas must even, greater than 4 and lower than 32
|
||||
|
||||
## Prometheus exporter
|
||||
### Prometheus exporter
|
||||
|
||||
MinIO exports Prometheus metrics at `/minio/prometheus/metrics`. To allow Prometheus collecting your MinIO metrics, modify the `values.yaml` adding the corresponding annotations:
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: mxnet
|
||||
version: 1.3.9
|
||||
version: 1.3.10
|
||||
appVersion: 1.5.1
|
||||
description: A flexible and efficient library for deep learning
|
||||
keywords:
|
||||
|
||||
+52
-78
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the MinIO chart and their default values.
|
||||
|
||||
@@ -139,13 +139,17 @@ $ helm install --name my-release -f values.yaml bitnami/mxnet
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/mxnet
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Run MXNet in distributed mode:
|
||||
```diff
|
||||
@@ -165,13 +169,7 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/mxnet
|
||||
+ workerCount: 4
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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
|
||||
### Loading your files
|
||||
|
||||
The MXNet chart supports three different ways to load your files. In order of priority, they are:
|
||||
|
||||
@@ -181,54 +179,37 @@ The MXNet chart supports three different ways to load your files. In order of pr
|
||||
|
||||
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:
|
||||
In order to use use an existing config map you can 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 the following parameters:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
--set configMap=my-config-map \
|
||||
bitnami/mxnet
|
||||
```
|
||||
|
||||
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`:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
bitnami/mxnet
|
||||
```
|
||||
|
||||
Finally, if you want to clone a git repository:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
--set cloneFilesFromGit.enabled=true \
|
||||
--set cloneFilesFromGit.repository=https://github.com/my-user/my-repo \
|
||||
--set cloneFilesFromGit.revision=master \
|
||||
bitnami/mxnet
|
||||
cloneFilesFromGit.enabled=true
|
||||
cloneFilesFromGit.repository=https://github.com/my-user/my-repo
|
||||
cloneFilesFromGit.revision=master
|
||||
```
|
||||
|
||||
In case you want to add a file that includes sensitive information, pass a secret object using the `existingSecret` parameter. All the files in the secret will be mounted in the `/secrets` folder.
|
||||
|
||||
### Distributed training example
|
||||
|
||||
We will use the gluon example from the [MXNet official repository](https://github.com/apache/incubator-mxnet/tree/master/example/gluon). Launch it with the following command:
|
||||
We will use the gluon example from the [MXNet official repository](https://github.com/apache/incubator-mxnet/tree/master/example/gluon). Launch it with the following values:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
--set mode=distributed \
|
||||
--set cloneFilesFromGit.enabled=true \
|
||||
--set cloneFilesFromGit.repository=https://github.com/apache/incubator-mxnet.git \
|
||||
--set cloneFilesFromGit.revision=master \
|
||||
--set entrypoint.file=image_classification.py \
|
||||
--set entrypoint.args="--dataset cifar10 --model vgg11 --epochs 1 --kvstore dist_sync" \
|
||||
--set entrypoint.workDir=/app/example/gluon/ \
|
||||
bitnami/mxnet
|
||||
mode=distributed
|
||||
cloneFilesFromGit.enabled=true
|
||||
cloneFilesFromGit.repository=https://github.com/apache/incubator-mxnet.git
|
||||
cloneFilesFromGit.revision=master
|
||||
entrypoint.file=image_classification.py
|
||||
entrypoint.args="--dataset cifar10 --model vgg11 --epochs 1 --kvstore dist_sync"
|
||||
entrypoint.workDir=/app/example/gluon/
|
||||
```
|
||||
|
||||
Check the logs of the worker node:
|
||||
|
||||
```console
|
||||
$ kubectl logs my-release-mxnet-worker-0 -f
|
||||
|
||||
INFO:root:Starting new image-classification task:, Namespace(batch_norm=False, batch_size=32, builtin_profiler=0, data_dir='', dataset='cifar10', dtype='float32', epochs=1, gpus='', kvstore='dist_sync', log_interval=50, lr=0.1, lr_factor=0.1, lr_steps='30,60,90', mode=None, model='vgg11', momentum=0.9, num_workers=4, prefix='', profile=False, resume='', save_frequency=10, seed=123, start_epoch=0, use_pretrained=False, use_thumbnail=False, wd=0.0001)
|
||||
INFO:root:downloaded http://data.mxnet.io/mxnet/data/cifar10.zip into data/cifar10.zip successfully
|
||||
[10:05:40] src/io/iter_image_recordio_2.cc:172: ImageRecordIOParser2: data/cifar/train.rec, use 1 threads for decoding..
|
||||
@@ -238,27 +219,20 @@ INFO:root:downloaded http://data.mxnet.io/mxnet/data/cifar10.zip into data/cifar
|
||||
If you want to increase the verbosity, set the environment variable `PS_VERBOSE=1` or `PS_VERBOSE=2` using the `commonEnvVars` value.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
--set mode=distributed \
|
||||
--set cloneFilesFromGit.enabled=true \
|
||||
--set cloneFilesFromGit.repository=https://github.com/apache/incubator-mxnet.git \
|
||||
--set cloneFilesFromGit.revision=master \
|
||||
--set entrypoint.file=image_classification.py \
|
||||
--set entrypoint.args="--dataset cifar10 --model vgg11 --epochs 1 --kvstore dist_sync" \
|
||||
--set entrypoint.workDir=/app/example/gluon/ \
|
||||
--set commonExtraEnvVars[0].name=PS_VERBOSE \
|
||||
--set commonExtraEnvVars[0].value=1 \
|
||||
bitnami/mxnet
|
||||
mode=distributed
|
||||
cloneFilesFromGit.enabled=true
|
||||
cloneFilesFromGit.repository=https://github.com/apache/incubator-mxnet.git
|
||||
cloneFilesFromGit.revision=master
|
||||
entrypoint.file=image_classification.py
|
||||
entrypoint.args="--dataset cifar10 --model vgg11 --epochs 1 --kvstore dist_sync"
|
||||
entrypoint.workDir=/app/example/gluon/
|
||||
commonExtraEnvVars[0].name=PS_VERBOSE
|
||||
commonExtraEnvVars[0].value=1
|
||||
```
|
||||
|
||||
You will now see log entries in the scheduler and server nodes.
|
||||
|
||||
```console
|
||||
$ kubectl logs my-release-mxnet-server-0
|
||||
[14:22:53] src/van.cc:290: Bind to role=server, ip=10.32.0.12, port=57099, is_recovery=0
|
||||
[14:22:53] src/van.cc:238: S[10] is connected to others
|
||||
|
||||
$ kubectl logs my-release-mxnet-scheduler-67dbd4bb7c-px2wf
|
||||
[14:22:44] src/van.cc:290: Bind to role=scheduler, id=1, ip=10.32.0.11, port=9092, is_recovery=0
|
||||
[14:22:53] src/van.cc:56: assign rank=9 to node role=worker, ip=10.32.0.17, port=55423, is_recovery=0
|
||||
[14:22:53] src/van.cc:56: assign rank=11 to node role=worker, ip=10.32.0.16, port=60779, is_recovery=0
|
||||
@@ -274,22 +248,7 @@ $ kubectl logs my-release-mxnet-scheduler-67dbd4bb7c-px2wf
|
||||
...
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami MXNet](https://github.com/bitnami/bitnami-docker-mxnet) image can persist data. If enabled, the persisted path is `/bitnami/mxnet` by default.
|
||||
|
||||
The chart mounts a [Persistent Volume](http://kubernetes.io/docs/user-guide/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`.
|
||||
|
||||
## Sidecars and Init Containers
|
||||
### Sidecars and Init Containers
|
||||
|
||||
If you have a need for additional containers to run within the same pod as MXNet (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.
|
||||
|
||||
@@ -314,3 +273,18 @@ initContainers:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami MXNet](https://github.com/bitnami/bitnami-docker-mxnet) image can persist data. If enabled, the persisted path is `/bitnami/mxnet` by default.
|
||||
|
||||
The chart mounts a [Persistent Volume](http://kubernetes.io/docs/user-guide/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`.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: mysql
|
||||
version: 6.4.6
|
||||
version: 6.4.7
|
||||
appVersion: 8.0.18
|
||||
description: Chart to create a Highly available MySQL cluster
|
||||
keywords:
|
||||
|
||||
+11
-13
@@ -44,7 +44,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the MySQL chart and their default values.
|
||||
|
||||
@@ -156,13 +156,17 @@ $ helm install --name my-release -f values.yaml bitnami/mysql
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/mysql
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Force users to specify a password:
|
||||
```diff
|
||||
@@ -188,13 +192,7 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/mysql
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
## Initialize a fresh instance
|
||||
### Initialize a fresh instance
|
||||
|
||||
The [Bitnami MySQL](https://github.com/bitnami/bitnami-docker-mysql) 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.
|
||||
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: nginx-ingress-controller
|
||||
version: 5.0.8
|
||||
version: 5.0.9
|
||||
appVersion: 0.26.1
|
||||
description: Chart for the nginx Ingress controller
|
||||
keywords:
|
||||
|
||||
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the nginx-ingress-controller chart and their default values.
|
||||
|
||||
@@ -204,13 +204,17 @@ $ helm install --name my-release -f values.yaml bitnami/nginx-ingress-controller
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/nginx-ingress-controller
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Enable "vts-status" page:
|
||||
```diff
|
||||
@@ -224,12 +228,6 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/nginx-ingre
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
## Upgrading
|
||||
|
||||
### To 1.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: nginx
|
||||
version: 4.3.9
|
||||
version: 4.3.10
|
||||
appVersion: 1.16.1
|
||||
description: Chart for the nginx server
|
||||
keywords:
|
||||
|
||||
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the NGINX Open Source chart and their default values.
|
||||
|
||||
@@ -114,6 +114,8 @@ $ helm install --name my-release -f values.yaml bitnami/nginx
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
@@ -123,7 +125,7 @@ Bitnami will release a new chart updating its containers if a new version of the
|
||||
### Providing a custom server block
|
||||
|
||||
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:
|
||||
To do this, create a values files with your server block and install the chart using it:
|
||||
|
||||
_custom-server-block.yaml_
|
||||
|
||||
@@ -137,12 +139,6 @@ serverBlock: |-
|
||||
}
|
||||
```
|
||||
|
||||
Install the chart with this value:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f custom-server-block.yaml bitnami/nginx
|
||||
```
|
||||
|
||||
## Upgrading
|
||||
|
||||
### To 1.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: node
|
||||
version: 11.2.7
|
||||
version: 11.2.8
|
||||
appVersion: 10.17.0
|
||||
description: Event-driven I/O server-side JavaScript environment based on V8
|
||||
keywords:
|
||||
|
||||
+43
-49
@@ -49,7 +49,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the Node chart and their default values.
|
||||
|
||||
@@ -128,51 +128,27 @@ $ helm install --name my-release -f values.yaml bitnami/node
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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
|
||||
### Set up an Ingress controller
|
||||
|
||||
The [Bitnami Node](https://github.com/bitnami/bitnami-docker-node) image stores the Node application and configurations at the `/app` 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 [Configuration](#configuration) 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`.
|
||||
|
||||
## Set up an Ingress controller
|
||||
|
||||
First install the nginx-ingress controller via helm:
|
||||
First install the nginx-ingress controller and then deploy the node helm chart with the following parameters:
|
||||
|
||||
```console
|
||||
$ helm install stable/nginx-ingress
|
||||
```
|
||||
|
||||
Now deploy the node helm chart:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release bitnami/node --set ingress.enabled=true,ingress.host=example.com,service.type=ClusterIP
|
||||
ingress.enabled=true
|
||||
ingress.host=example.com
|
||||
service.type=ClusterIP
|
||||
```
|
||||
|
||||
### Configure TLS termination for your ingress controller
|
||||
|
||||
You must manually create a secret containing the certificate and key for your domain. You can do it with this command:
|
||||
|
||||
```console
|
||||
$ kubectl create secret tls my-tls-secret --cert=path/to/file.cert --key=path/to/file.key
|
||||
```
|
||||
|
||||
Then ensure you deploy the Helm chart with the following ingress configuration:
|
||||
You must manually create a secret containing the certificate and key for your domain. Then ensure you deploy the Helm chart with the following ingress configuration:
|
||||
|
||||
```yaml
|
||||
ingress:
|
||||
@@ -186,12 +162,16 @@ ingress:
|
||||
- example.com
|
||||
```
|
||||
|
||||
## Connect your application to an already existing database
|
||||
### Connect your application to an already existing database
|
||||
|
||||
1. Create a secret containing your database credentials:
|
||||
1. Create a secret containing your database credentials (named `my-database-secret` as example), you can use the following options (set with `--from-literal`) to create the secret:
|
||||
|
||||
```console
|
||||
$ kubectl create secret generic my-database-secret --from-literal=host=YOUR_DATABASE_HOST --from-literal=port=YOUR_DATABASE_PORT --from-literal=username=YOUR_DATABASE_USER --from-literal=password=YOUR_DATABASE_PASSWORD --from-literal=database=YOUR_DATABASE_NAME
|
||||
host=YOUR_DATABASE_HOST
|
||||
port=YOUR_DATABASE_PORT
|
||||
username=YOUR_DATABASE_USER
|
||||
password=YOUR_DATABASE_PASSWORD
|
||||
database=YOUR_DATABASE_NAME
|
||||
```
|
||||
|
||||
`YOUR_DATABASE_HOST`, `YOUR_DATABASE_PORT`, `YOUR_DATABASE_USER`, `YOUR_DATABASE_PASSWORD`, and `YOUR_DATABASE_NAME` are placeholders that must be replaced with correct values.
|
||||
@@ -199,22 +179,22 @@ ingress:
|
||||
2. Deploy the node chart specifying the secret name
|
||||
|
||||
```console
|
||||
$ helm install --name node-app --set mongodb.install=false,externaldb.secretName=my-database-secret bitnami/node
|
||||
mongodb.install=false
|
||||
externaldb.secretName=my-database-secret
|
||||
```
|
||||
|
||||
## Provision a database using the Open Service Broker for Azure
|
||||
### Provision a database using the Open Service Broker for Azure
|
||||
|
||||
1. Install Service Catalog in your Kubernetes cluster following [this instructions](https://kubernetes.io/docs/tasks/service-catalog/install-service-catalog-using-helm/)
|
||||
2. Install the Open Service Broker for Azure in your Kubernetes cluster following [this instructions](https://github.com/Azure/open-service-broker-azure/tree/master/contrib/k8s/charts/open-service-broker-azure)
|
||||
|
||||
> TIP: you may want to install the osba chart setting the `modules.minStability=EXPERIMENTAL` to see all the available services.
|
||||
>
|
||||
> $ helm install azure/open-service-broker-azure --name osba --namespace osba \
|
||||
> --set azure.subscriptionId=$AZURE_SUBSCRIPTION_ID \
|
||||
> --set azure.tenantId=$AZURE_TENANT_ID \
|
||||
> --set azure.clientId=$AZURE_CLIENT_ID \
|
||||
> --set azure.clientSecret=$AZURE_CLIENT_SECRET \
|
||||
> --set modules.minStability=EXPERIMENTAL
|
||||
> azure.subscriptionId=$AZURE_SUBSCRIPTION_ID
|
||||
> azure.tenantId=$AZURE_TENANT_ID
|
||||
> azure.clientId=$AZURE_CLIENT_ID
|
||||
> azure.clientSecret=$AZURE_CLIENT_SECRET
|
||||
> modules.minStability=EXPERIMENTAL
|
||||
|
||||
3. Create and deploy a ServiceInstance to provision a database server in Azure cloud.
|
||||
|
||||
@@ -238,14 +218,12 @@ ingress:
|
||||
|
||||
Please update the `YOUR_AZURE_LOCATION` placeholder in the above example.
|
||||
|
||||
```command
|
||||
$ kubectl create -f mongodb-service-instance.yml
|
||||
```
|
||||
|
||||
4. Deploy the helm chart:
|
||||
|
||||
```command
|
||||
$ helm install --name node-app --set mongodb.install=false,externaldb.broker.serviceInstanceName=azure-mongodb-instance,externaldb.ssl=true bitnami/node
|
||||
mongodb.install=false
|
||||
externaldb.broker.serviceInstanceName=azure-mongodb-instance
|
||||
externaldb.ssl=true
|
||||
```
|
||||
|
||||
Once the instance has been provisioned in Azure, a new secret should have been automatically created with the connection parameters for your application.
|
||||
@@ -257,6 +235,22 @@ Deploying the helm chart enabling the Azure external database makes the followin
|
||||
|
||||
You can read more about the kubernetes service catalog at https://github.com/kubernetes-bitnami/service-catalog
|
||||
|
||||
## Persistence
|
||||
|
||||
The [Bitnami Node](https://github.com/bitnami/bitnami-docker-node) image stores the Node application and configurations at the `/app` 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 [Configuration](#configuration) 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`.
|
||||
|
||||
## Notable changes
|
||||
|
||||
### 7.0.0
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: pytorch
|
||||
version: 1.2.7
|
||||
version: 1.2.8
|
||||
appVersion: 1.3.0
|
||||
description: Deep learning platform that accelerates the transition from research prototyping to production deployment
|
||||
keywords:
|
||||
|
||||
+19
-34
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following table lists the configurable parameters of the MinIO chart and their default values.
|
||||
|
||||
@@ -129,13 +129,17 @@ $ helm install --name my-release -f values.yaml bitnami/pytorch
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/pytorch
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Run PyTorch in distributed mode:
|
||||
```diff
|
||||
@@ -149,13 +153,7 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/pytorch
|
||||
+ worldSize: 4
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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
|
||||
### Loading your files
|
||||
|
||||
The PyTorch chart supports three different ways to load your files. In order of priority, they are:
|
||||
|
||||
@@ -165,29 +163,16 @@ The PyTorch chart supports three different ways to load your files. In order of
|
||||
|
||||
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:
|
||||
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 install --name my-release \
|
||||
--set configMap=my-config-map \
|
||||
bitnami/pytorch
|
||||
```
|
||||
|
||||
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`:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
bitnami/pytorch
|
||||
```
|
||||
|
||||
Finally, if you want to clone a git repository:
|
||||
|
||||
```console
|
||||
$ helm install --name my-release \
|
||||
--set cloneFilesFromGit.enabled=true \
|
||||
--set cloneFilesFromGit.repository=https://github.com/my-user/my-repo \
|
||||
--set cloneFilesFromGit.revision=master \
|
||||
bitnami/pytorch
|
||||
cloneFilesFromGit.enabled=true
|
||||
cloneFilesFromGit.repository=https://github.com/my-user/my-repo
|
||||
cloneFilesFromGit.revision=master
|
||||
```
|
||||
|
||||
## Persistence
|
||||
|
||||
@@ -1,5 +1,5 @@
|
||||
apiVersion: v1
|
||||
version: 1.0.8
|
||||
version: 1.0.9
|
||||
appVersion: 2.4.4
|
||||
description: Spark is a fast and general-purpose cluster computing system.
|
||||
name: spark
|
||||
|
||||
+28
-40
@@ -43,7 +43,7 @@ $ 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.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the spark chart and their default values.
|
||||
|
||||
@@ -150,27 +150,17 @@ $ helm install --name my-release -f values.yaml bitnami/spark
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
### Using custom configuration
|
||||
## Configuration and installation details
|
||||
|
||||
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:
|
||||
```bash
|
||||
$ helm install bitnami/spark --set master.configurationConfigMap=configMapName
|
||||
```
|
||||
To set the configuration on the worker use:
|
||||
```bash
|
||||
$ helm install bitnami/spark --set worker.configurationConfigMap=configMapName
|
||||
```
|
||||
It can be set both at the same time with the same ConfigMap or using two ConfigMaps.
|
||||
Also, you can provide in the ConfigMap a `spark-defaults.conf` file.
|
||||
You can use both files without the other.
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/spark
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Enable ingress controller
|
||||
```diff
|
||||
@@ -236,11 +226,15 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/spark
|
||||
+ worker.autoscaling.replicasMax: 10
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### Using custom configuration
|
||||
|
||||
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.
|
||||
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`
|
||||
|
||||
Bitnami will release a new chart updating its containers if a new version of the main container, significant changes, or critical vulnerabilities exist.
|
||||
To set the configuration on the worker use: `worker.configurationConfigMap=configMapName`
|
||||
|
||||
It can be set both at the same time with the same ConfigMap or using two ConfigMaps.
|
||||
Also, you can provide in the ConfigMap a `spark-defaults.conf` file.
|
||||
You can use both files without the other.
|
||||
|
||||
### Submit an application
|
||||
|
||||
@@ -252,38 +246,32 @@ $ ./bin/spark-submit --class org.apache.spark.examples.SparkPi --master spar
|
||||
Where the master IP and port must be changed by you master IP address and port.
|
||||
> Be aware that currently is not possible to submit an application to a standalone cluster if RPC authentication is configured. More info about the issue [here](https://issues.apache.org/jira/browse/SPARK-25078).
|
||||
|
||||
## Enable security for spark
|
||||
### Enable security for spark
|
||||
|
||||
### Configure ssl communication
|
||||
#### Configure ssl communication
|
||||
|
||||
In order to enable secure transport between workers and master deploy the helm chart with these options:
|
||||
In order to enable secure transport between workers and master deploy the helm chart with this options: `ssl.enabled=true`
|
||||
|
||||
```console
|
||||
$ helm install --name my-release --set ssl.enabled=true bitnami/spark
|
||||
|
||||
```
|
||||
|
||||
### How to create the certificates secret
|
||||
#### How to create the certificates secret
|
||||
|
||||
It is needed to create two secrets to set the passwords and certificates. The name of the two secrets should be configured on `security.passwordsSecretName` and `security.certificatesSecretName`. To generate certificates for testing purpose you can use [this script](https://raw.githubusercontent.com/confluentinc/confluent-platform-security-tools/master/kafka-generate-ssl.sh).
|
||||
Into the certificates secret, the keys must be `spark-keystore.jks` and `spark-truststore.jks`, and the content must be text on JKS format.
|
||||
To generate the certificates secret, first it is needed to generate the two certificates and rename them as `spark-keystore.jks` and `spark-truststore.jks`.
|
||||
Once the certificates are created, to create the secret having the file names as keys, execute a command like the following:
|
||||
```bash
|
||||
$ kubectl create secret generic my-secret --from-file=./keystore/spark-keystore.jks --from-file=./truststore/spark-truststore.jks
|
||||
```
|
||||
Once the certificates are created, you can create the secret having the file names as keys.
|
||||
|
||||
The second secret, the secret for passwords should have four keys: `rpc-authentication-secret`, `ssl-key-password`, `ssl-keystore-password` and `ssl-truststore-password`.
|
||||
To create this secret, execute a command like the following:
|
||||
```bash
|
||||
$ kubectl create secret generic my-passwords-secret --from-literal=rpc-authentication-secret=myRPCSecret --from-literal=ssl-key-password=mySSLKeyPassword --from-literal=ssl-keystore-password=password --from-literal=ssl-truststore-password=password
|
||||
```
|
||||
|
||||
Now that the two secrets are created, deploy the chart enabling security configuration and setting the name for the certificates secret (`my-secret` in this case) at the `security.certificatesSecretName` and setting the name for the passwords secret (`my-passwords-secret` in this case) at `security.passwordsSecretName`.
|
||||
|
||||
To deploy execute the following:
|
||||
To deploy chart, use the following parameters:
|
||||
```bash
|
||||
$ helm install . --set security.certificatesSecretName=my-secret,security.passwordsSecretName=my-passwords-secret,security.rpc.authenticationEnabled=yes,security.rpc.encryptionEnabled=yes,security.storageEncrytionEnabled=yes,security.ssl.enabled=yes,security.ssl.needClientAuth=yes
|
||||
security.certificatesSecretName=my-secret
|
||||
security.passwordsSecretName=my-passwords-secret
|
||||
security.rpc.authenticationEnabled=yes
|
||||
security.rpc.encryptionEnabled=yes
|
||||
security.storageEncrytionEnabled=yes
|
||||
security.ssl.enabled=yes
|
||||
security.ssl.needClientAuth=yes
|
||||
```
|
||||
|
||||
> Be aware that currently is not possible to submit an application to a standalone cluster if RPC authentication is configured. More info about the issue [here](https://issues.apache.org/jira/browse/SPARK-25078).
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: tensorflow-resnet
|
||||
version: 1.2.4
|
||||
version: 1.2.5
|
||||
appVersion: 1.14.0
|
||||
description: Open-source software library serving the ResNet machine learning model.
|
||||
keywords:
|
||||
|
||||
@@ -58,7 +58,7 @@ $ helm list
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the TensorFlow ResNet chart and their default values.
|
||||
|
||||
@@ -112,6 +112,8 @@ $ helm install --name my-release -f values.yaml bitnami/tensorflow-resnet
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: tomcat
|
||||
version: 6.0.2
|
||||
version: 6.0.3
|
||||
appVersion: 9.0.27
|
||||
description: Chart for Apache Tomcat
|
||||
keywords:
|
||||
|
||||
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the Tomcat chart and their default values.
|
||||
|
||||
@@ -112,6 +112,8 @@ $ helm install --name my-release -f values.yaml bitnami/tomcat
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: wildfly
|
||||
version: 3.3.4
|
||||
version: 3.3.5
|
||||
appVersion: 18.0.0
|
||||
description: Chart for Wildfly
|
||||
keywords:
|
||||
|
||||
@@ -45,7 +45,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the WildFly chart and their default values.
|
||||
|
||||
@@ -106,6 +106,8 @@ $ helm install --name my-release -f values.yaml bitnami/wildfly
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: zookeeper
|
||||
version: 5.0.4
|
||||
version: 5.0.5
|
||||
appVersion: 3.5.6
|
||||
description: A centralized service for maintaining configuration information, naming, providing distributed synchronization, and providing group services for distributed applications.
|
||||
keywords:
|
||||
|
||||
+10
-12
@@ -44,7 +44,7 @@ $ helm delete my-release
|
||||
|
||||
The command removes all the Kubernetes components associated with the chart and deletes the release.
|
||||
|
||||
## Configuration
|
||||
## Parameters
|
||||
|
||||
The following tables lists the configurable parameters of the ZooKeeper chart and their default values.
|
||||
|
||||
@@ -148,13 +148,17 @@ $ helm install --name my-release -f values.yaml bitnami/zookeeper
|
||||
|
||||
> **Tip**: You can use the default [values.yaml](values.yaml)
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Production configuration
|
||||
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`.
|
||||
|
||||
```console
|
||||
$ helm install --name my-release -f ./values-production.yaml bitnami/zookeeper
|
||||
```
|
||||
This chart includes a `values-production.yaml` file where you can find some parameters oriented to production configuration in comparison to the regular `values.yaml`. You can use this file instead of the default one.
|
||||
|
||||
- Number of ZooKeeper nodes:
|
||||
```diff
|
||||
@@ -168,12 +172,6 @@ $ helm install --name my-release -f ./values-production.yaml bitnami/zookeeper
|
||||
+ metrics.enabled: true
|
||||
```
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/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.
|
||||
|
||||
### Log level
|
||||
|
||||
You can configure the ZooKeeper log level using the `ZOO_LOG_LEVEL` environment variable. By default, it is set to `ERROR` because of each readiness probe produce an `INFO` message on connection and a `WARN` message on disconnection.
|
||||
|
||||
@@ -1,22 +1,22 @@
|
||||
apiVersion: v1
|
||||
name: postgresql
|
||||
version: 6.5.0
|
||||
version: 6.5.1
|
||||
appVersion: 11.5.0
|
||||
description: Chart for PostgreSQL, an object-relational database management system (ORDBMS) with an emphasis on extensibility and on standards-compliance.
|
||||
keywords:
|
||||
- postgresql
|
||||
- postgres
|
||||
- database
|
||||
- sql
|
||||
- replication
|
||||
- cluster
|
||||
- postgresql
|
||||
- postgres
|
||||
- database
|
||||
- sql
|
||||
- replication
|
||||
- cluster
|
||||
home: https://www.postgresql.org/
|
||||
icon: https://bitnami.com/assets/stacks/postgresql/img/postgresql-stack-110x117.png
|
||||
sources:
|
||||
- https://github.com/bitnami/bitnami-docker-postgresql
|
||||
- https://github.com/bitnami/bitnami-docker-postgresql
|
||||
maintainers:
|
||||
- name: Bitnami
|
||||
email: containers@bitnami.com
|
||||
- name: desaintmartin
|
||||
email: cedric@desaintmartin.fr
|
||||
- name: Bitnami
|
||||
email: containers@bitnami.com
|
||||
- name: desaintmartin
|
||||
email: cedric@desaintmartin.fr
|
||||
engine: gotpl
|
||||
|
||||
@@ -348,3 +348,16 @@ but Helm 2.9 and 2.10 does not support it, so we need to implement this if-else
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
{{- end -}}
|
||||
|
||||
{{/*
|
||||
Renders a value that contains template.
|
||||
Usage:
|
||||
{{ include "postgresql.tplValue" ( dict "value" .Values.path.to.the.Value "context" $) }}
|
||||
*/}}
|
||||
{{- define "logstash.tplValue" -}}
|
||||
{{- if typeIs "string" .value }}
|
||||
{{- tpl .value .context }}
|
||||
{{- else }}
|
||||
{{- tpl (.value | toYaml) .context }}
|
||||
{{- end }}
|
||||
{{- end -}}
|
||||
|
||||
@@ -16,9 +16,9 @@ spec:
|
||||
loadBalancerIP: {{ .Values.metrics.service.loadBalancerIP }}
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: metrics
|
||||
port: 9187
|
||||
targetPort: metrics
|
||||
- name: metrics
|
||||
port: 9187
|
||||
targetPort: metrics
|
||||
selector:
|
||||
app: {{ template "postgresql.name" . }}
|
||||
release: {{ .Release.Name }}
|
||||
|
||||
@@ -16,19 +16,19 @@ spec:
|
||||
ingress:
|
||||
# Allow inbound connections
|
||||
- ports:
|
||||
- port: {{ template "postgresql.port" . }}
|
||||
{{- if not .Values.networkPolicy.allowExternal }}
|
||||
- port: {{ template "postgresql.port" . }}
|
||||
{{- if not .Values.networkPolicy.allowExternal }}
|
||||
from:
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
{{ template "postgresql.fullname" . }}-client: "true"
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: {{ template "postgresql.name" . }}
|
||||
release: {{ .Release.Name | quote }}
|
||||
role: slave
|
||||
{{- end }}
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
{{ template "postgresql.fullname" . }}-client: "true"
|
||||
- podSelector:
|
||||
matchLabels:
|
||||
app: {{ template "postgresql.name" . }}
|
||||
release: {{ .Release.Name | quote }}
|
||||
role: slave
|
||||
{{- end }}
|
||||
# Allow prometheus scrapes
|
||||
- ports:
|
||||
- port: 9187
|
||||
- port: 9187
|
||||
{{- end }}
|
||||
|
||||
@@ -68,155 +68,157 @@ spec:
|
||||
{{- end }}
|
||||
{{- if and .Values.volumePermissions.enabled .Values.persistence.enabled }}
|
||||
initContainers:
|
||||
- name: init-chmod-data
|
||||
image: {{ template "postgresql.volumePermissions.image" . }}
|
||||
imagePullPolicy: "{{ .Values.volumePermissions.image.pullPolicy }}"
|
||||
resources:
|
||||
{{ toYaml .Values.resources | indent 10 }}
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- |
|
||||
mkdir -p {{ .Values.persistence.mountPath }}/data
|
||||
chmod 700 {{ .Values.persistence.mountPath }}/data
|
||||
find {{ .Values.persistence.mountPath }} -mindepth 0 -maxdepth 1 -not -name ".snapshot" -not -name "lost+found" | \
|
||||
xargs chown -R {{ .Values.securityContext.runAsUser }}:{{ .Values.securityContext.fsGroup }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.volumePermissions.securityContext.runAsUser }}
|
||||
volumeMounts:
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
- name: init-chmod-data
|
||||
image: {{ template "postgresql.volumePermissions.image" . }}
|
||||
imagePullPolicy: "{{ .Values.volumePermissions.image.pullPolicy }}"
|
||||
{{- if .Values.resources }}
|
||||
resources: {{- toYaml .Values.resources | nindent 12 }}
|
||||
{{- end }}
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- |
|
||||
mkdir -p {{ .Values.persistence.mountPath }}/data
|
||||
chmod 700 {{ .Values.persistence.mountPath }}/data
|
||||
find {{ .Values.persistence.mountPath }} -mindepth 0 -maxdepth 1 -not -name ".snapshot" -not -name "lost+found" | \
|
||||
xargs chown -R {{ .Values.securityContext.runAsUser }}:{{ .Values.securityContext.fsGroup }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.volumePermissions.securityContext.runAsUser }}
|
||||
volumeMounts:
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
{{- end }}
|
||||
containers:
|
||||
- name: {{ template "postgresql.fullname" . }}
|
||||
image: {{ template "postgresql.image" . }}
|
||||
imagePullPolicy: "{{ .Values.image.pullPolicy }}"
|
||||
resources:
|
||||
{{ toYaml .Values.resources | indent 10 }}
|
||||
{{- if .Values.securityContext.enabled }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.securityContext.runAsUser }}
|
||||
{{- end }}
|
||||
env:
|
||||
- name: BITNAMI_DEBUG
|
||||
value: {{ ternary "true" "false" .Values.image.debug | quote }}
|
||||
- name: POSTGRESQL_VOLUME_DIR
|
||||
value: "{{ .Values.persistence.mountPath }}"
|
||||
- name: POSTGRESQL_PORT_NUMBER
|
||||
value: "{{ template "postgresql.port" . }}"
|
||||
{{- if .Values.persistence.mountPath }}
|
||||
- name: PGDATA
|
||||
value: {{ .Values.postgresqlDataDir | quote }}
|
||||
{{- end }}
|
||||
- name: POSTGRES_REPLICATION_MODE
|
||||
value: "slave"
|
||||
- name: POSTGRES_REPLICATION_USER
|
||||
value: {{ include "postgresql.replication.username" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-replication-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-replication-password
|
||||
{{- end }}
|
||||
- name: POSTGRES_CLUSTER_APP_NAME
|
||||
value: {{ .Values.replication.applicationName }}
|
||||
- name: POSTGRES_MASTER_HOST
|
||||
value: {{ template "postgresql.fullname" . }}
|
||||
- name: POSTGRES_MASTER_PORT_NUMBER
|
||||
value: {{ include "postgresql.port" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-password
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: postgresql
|
||||
containerPort: {{ template "postgresql.port" . }}
|
||||
{{- if .Values.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
{{- if (include "postgresql.database" .) }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -d {{ (include "postgresql.database" .) | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- else }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- end }}
|
||||
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.livenessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- -e
|
||||
{{- include "postgresql.readinessProbeCommand" . | nindent 12 }}
|
||||
initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.readinessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
volumeMounts:
|
||||
- name: {{ template "postgresql.fullname" . }}
|
||||
image: {{ template "postgresql.image" . }}
|
||||
imagePullPolicy: "{{ .Values.image.pullPolicy }}"
|
||||
{{- if .Values.resources }}
|
||||
resources: {{- toYaml .Values.resources | nindent 12 }}
|
||||
{{- end }}
|
||||
{{- if .Values.securityContext.enabled }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.securityContext.runAsUser }}
|
||||
{{- end }}
|
||||
env:
|
||||
- name: BITNAMI_DEBUG
|
||||
value: {{ ternary "true" "false" .Values.image.debug | quote }}
|
||||
- name: POSTGRESQL_VOLUME_DIR
|
||||
value: "{{ .Values.persistence.mountPath }}"
|
||||
- name: POSTGRESQL_PORT_NUMBER
|
||||
value: "{{ template "postgresql.port" . }}"
|
||||
{{- if .Values.persistence.mountPath }}
|
||||
- name: PGDATA
|
||||
value: {{ .Values.postgresqlDataDir | quote }}
|
||||
{{- end }}
|
||||
- name: POSTGRES_REPLICATION_MODE
|
||||
value: "slave"
|
||||
- name: POSTGRES_REPLICATION_USER
|
||||
value: {{ include "postgresql.replication.username" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-replication-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-replication-password
|
||||
{{- end }}
|
||||
- name: POSTGRES_CLUSTER_APP_NAME
|
||||
value: {{ .Values.replication.applicationName }}
|
||||
- name: POSTGRES_MASTER_HOST
|
||||
value: {{ template "postgresql.fullname" . }}
|
||||
- name: POSTGRES_MASTER_PORT_NUMBER
|
||||
value: {{ include "postgresql.port" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-password
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: postgresql
|
||||
containerPort: {{ template "postgresql.port" . }}
|
||||
{{- if .Values.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
{{- if (include "postgresql.database" .) }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -d {{ (include "postgresql.database" .) | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- else }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- end }}
|
||||
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.livenessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- -e
|
||||
{{- include "postgresql.readinessProbeCommand" . | nindent 16 }}
|
||||
initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.readinessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
volumeMounts:
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
mountPath: /opt/bitnami/postgresql/secrets/
|
||||
{{- end }}
|
||||
{{- if .Values.persistence.enabled }}
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
{{ end }}
|
||||
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap }}
|
||||
- name: postgresql-extended-config
|
||||
mountPath: /bitnami/postgresql/conf/conf.d/
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap }}
|
||||
- name: postgresql-config
|
||||
mountPath: /bitnami/postgresql/conf
|
||||
{{- end }}
|
||||
{{- if .Values.slave.extraVolumeMounts }}
|
||||
{{- toYaml .Values.slave.extraVolumeMounts | nindent 12 }}
|
||||
{{- end }}
|
||||
volumes:
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
mountPath: /opt/bitnami/postgresql/secrets/
|
||||
secret:
|
||||
secretName: {{ template "postgresql.secretName" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
|
||||
- name: postgresql-config
|
||||
configMap:
|
||||
name: {{ template "postgresql.configurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.persistence.enabled }}
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
{{ end }}
|
||||
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap }}
|
||||
- name: postgresql-extended-config
|
||||
mountPath: /bitnami/postgresql/conf/conf.d/
|
||||
configMap:
|
||||
name: {{ template "postgresql.extendedConfigurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap }}
|
||||
- name: postgresql-config
|
||||
mountPath: /bitnami/postgresql/conf
|
||||
{{- if not .Values.persistence.enabled }}
|
||||
- name: data
|
||||
emptyDir: {}
|
||||
{{- end }}
|
||||
{{- if .Values.slave.extraVolumeMounts }}
|
||||
{{- toYaml .Values.slave.extraVolumeMounts | nindent 8 }}
|
||||
{{- if .Values.slave.extraVolumes }}
|
||||
{{- toYaml .Values.slave.extraVolumes | nindent 8 }}
|
||||
{{- end }}
|
||||
volumes:
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
secret:
|
||||
secretName: {{ template "postgresql.secretName" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
|
||||
- name: postgresql-config
|
||||
configMap:
|
||||
name: {{ template "postgresql.configurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap }}
|
||||
- name: postgresql-extended-config
|
||||
configMap:
|
||||
name: {{ template "postgresql.extendedConfigurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if not .Values.persistence.enabled }}
|
||||
- name: data
|
||||
emptyDir: {}
|
||||
{{- end }}
|
||||
{{- if .Values.slave.extraVolumes }}
|
||||
{{- toYaml .Values.slave.extraVolumes | nindent 6}}
|
||||
{{- end }}
|
||||
updateStrategy:
|
||||
type: {{ .Values.updateStrategy.type }}
|
||||
{{- if (eq "Recreate" .Values.updateStrategy.type) }}
|
||||
|
||||
@@ -72,256 +72,259 @@ spec:
|
||||
{{- end }}
|
||||
{{- if and .Values.volumePermissions.enabled .Values.persistence.enabled }}
|
||||
initContainers:
|
||||
- name: init-chmod-data
|
||||
image: {{ template "postgresql.volumePermissions.image" . }}
|
||||
imagePullPolicy: "{{ .Values.volumePermissions.image.pullPolicy }}"
|
||||
resources:
|
||||
{{ toYaml .Values.resources | indent 10 }}
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- |
|
||||
mkdir -p {{ .Values.persistence.mountPath }}/data
|
||||
chmod 700 {{ .Values.persistence.mountPath }}/data
|
||||
find {{ .Values.persistence.mountPath }} -mindepth 0 -maxdepth 1 -not -name ".snapshot" -not -name "lost+found" | \
|
||||
xargs chown -R {{ .Values.securityContext.runAsUser }}:{{ .Values.securityContext.fsGroup }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.volumePermissions.securityContext.runAsUser }}
|
||||
volumeMounts:
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
- name: init-chmod-data
|
||||
image: {{ template "postgresql.volumePermissions.image" . }}
|
||||
imagePullPolicy: "{{ .Values.volumePermissions.image.pullPolicy }}"
|
||||
{{- if .Values.resources }}
|
||||
resources: {{- toYaml .Values.resources | nindent 12 }}
|
||||
{{- end }}
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- |
|
||||
mkdir -p {{ .Values.persistence.mountPath }}/data
|
||||
chmod 700 {{ .Values.persistence.mountPath }}/data
|
||||
find {{ .Values.persistence.mountPath }} -mindepth 0 -maxdepth 1 -not -name ".snapshot" -not -name "lost+found" | \
|
||||
xargs chown -R {{ .Values.securityContext.runAsUser }}:{{ .Values.securityContext.fsGroup }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.volumePermissions.securityContext.runAsUser }}
|
||||
volumeMounts:
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
{{- end }}
|
||||
containers:
|
||||
- name: {{ template "postgresql.fullname" . }}
|
||||
image: {{ template "postgresql.image" . }}
|
||||
imagePullPolicy: "{{ .Values.image.pullPolicy }}"
|
||||
resources:
|
||||
{{ toYaml .Values.resources | indent 10 }}
|
||||
{{- if .Values.securityContext.enabled }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.securityContext.runAsUser }}
|
||||
- name: {{ template "postgresql.fullname" . }}
|
||||
image: {{ template "postgresql.image" . }}
|
||||
imagePullPolicy: "{{ .Values.image.pullPolicy }}"
|
||||
{{- if .Values.resources }}
|
||||
resources: {{- toYaml .Values.resources | nindent 12 }}
|
||||
{{- end }}
|
||||
{{- if .Values.securityContext.enabled }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.securityContext.runAsUser }}
|
||||
{{- end }}
|
||||
env:
|
||||
- name: BITNAMI_DEBUG
|
||||
value: {{ ternary "true" "false" .Values.image.debug | quote }}
|
||||
- name: POSTGRESQL_PORT_NUMBER
|
||||
value: "{{ template "postgresql.port" . }}"
|
||||
- name: POSTGRESQL_VOLUME_DIR
|
||||
value: "{{ .Values.persistence.mountPath }}"
|
||||
{{- if .Values.postgresqlInitdbArgs }}
|
||||
- name: POSTGRES_INITDB_ARGS
|
||||
value: {{ .Values.postgresqlInitdbArgs | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.postgresqlInitdbWalDir }}
|
||||
- name: POSTGRES_INITDB_WALDIR
|
||||
value: {{ .Values.postgresqlInitdbWalDir | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.persistence.mountPath }}
|
||||
- name: PGDATA
|
||||
value: {{ .Values.postgresqlDataDir | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.replication.enabled }}
|
||||
- name: POSTGRES_REPLICATION_MODE
|
||||
value: "master"
|
||||
- name: POSTGRES_REPLICATION_USER
|
||||
value: {{ include "postgresql.replication.username" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-replication-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-replication-password
|
||||
{{- end }}
|
||||
{{- if not (eq .Values.replication.synchronousCommit "off")}}
|
||||
- name: POSTGRES_SYNCHRONOUS_COMMIT_MODE
|
||||
value: {{ .Values.replication.synchronousCommit | quote }}
|
||||
- name: POSTGRES_NUM_SYNCHRONOUS_REPLICAS
|
||||
value: {{ .Values.replication.numSynchronousReplicas | quote }}
|
||||
{{- end }}
|
||||
- name: POSTGRES_CLUSTER_APP_NAME
|
||||
value: {{ .Values.replication.applicationName }}
|
||||
{{- end }}
|
||||
- name: POSTGRES_USER
|
||||
value: {{ include "postgresql.username" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-password
|
||||
{{- end }}
|
||||
{{- if (include "postgresql.database" .) }}
|
||||
- name: POSTGRES_DB
|
||||
value: {{ (include "postgresql.database" .) | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.extraEnv }}
|
||||
{{- include "postgresql.tplValue" (dict "value" .Values.extraEnv "context" $) | nindent 12 }}
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: postgresql
|
||||
containerPort: {{ template "postgresql.port" . }}
|
||||
{{- if .Values.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
{{- if (include "postgresql.database" .) }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -d {{ (include "postgresql.database" .) | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- else }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- end }}
|
||||
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.livenessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- -e
|
||||
{{- include "postgresql.readinessProbeCommand" . | nindent 16 }}
|
||||
initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.readinessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
volumeMounts:
|
||||
{{- if or (.Files.Glob "files/docker-entrypoint-initdb.d/*.{sh,sql,sql.gz}") .Values.initdbScriptsConfigMap .Values.initdbScripts }}
|
||||
- name: custom-init-scripts
|
||||
mountPath: /docker-entrypoint-initdb.d/
|
||||
{{- end }}
|
||||
{{- if .Values.initdbScriptsSecret }}
|
||||
- name: custom-init-scripts-secret
|
||||
mountPath: /docker-entrypoint-initdb.d/secret
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap }}
|
||||
- name: postgresql-extended-config
|
||||
mountPath: /bitnami/postgresql/conf/conf.d/
|
||||
{{- end }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
mountPath: /opt/bitnami/postgresql/secrets/
|
||||
{{- end }}
|
||||
{{- if .Values.persistence.enabled }}
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap }}
|
||||
- name: postgresql-config
|
||||
mountPath: /bitnami/postgresql/conf
|
||||
{{- end }}
|
||||
{{- if .Values.master.extraVolumeMounts }}
|
||||
{{- toYaml .Values.master.extraVolumeMounts | nindent 12 }}
|
||||
{{- end }}
|
||||
{{- if .Values.metrics.enabled }}
|
||||
- name: metrics
|
||||
image: {{ template "postgresql.metrics.image" . }}
|
||||
imagePullPolicy: {{ .Values.metrics.image.pullPolicy | quote }}
|
||||
{{- if .Values.metrics.securityContext.enabled }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.metrics.securityContext.runAsUser }}
|
||||
{{- end }}
|
||||
env:
|
||||
- name: BITNAMI_DEBUG
|
||||
value: {{ ternary "true" "false" .Values.image.debug | quote }}
|
||||
- name: POSTGRESQL_PORT_NUMBER
|
||||
value: "{{ template "postgresql.port" . }}"
|
||||
- name: POSTGRESQL_VOLUME_DIR
|
||||
value: "{{ .Values.persistence.mountPath }}"
|
||||
{{- if .Values.postgresqlInitdbArgs }}
|
||||
- name: POSTGRES_INITDB_ARGS
|
||||
value: {{ .Values.postgresqlInitdbArgs | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.postgresqlInitdbWalDir }}
|
||||
- name: POSTGRES_INITDB_WALDIR
|
||||
value: {{ .Values.postgresqlInitdbWalDir | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.persistence.mountPath }}
|
||||
- name: PGDATA
|
||||
value: {{ .Values.postgresqlDataDir | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.replication.enabled }}
|
||||
- name: POSTGRES_REPLICATION_MODE
|
||||
value: "master"
|
||||
- name: POSTGRES_REPLICATION_USER
|
||||
value: {{ include "postgresql.replication.username" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-replication-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_REPLICATION_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-replication-password
|
||||
{{- end }}
|
||||
{{- if not (eq .Values.replication.synchronousCommit "off")}}
|
||||
- name: POSTGRES_SYNCHRONOUS_COMMIT_MODE
|
||||
value: {{ .Values.replication.synchronousCommit | quote }}
|
||||
- name: POSTGRES_NUM_SYNCHRONOUS_REPLICAS
|
||||
value: {{ .Values.replication.numSynchronousReplicas | quote }}
|
||||
{{- end }}
|
||||
- name: POSTGRES_CLUSTER_APP_NAME
|
||||
value: {{ .Values.replication.applicationName }}
|
||||
{{- end }}
|
||||
- name: POSTGRES_USER
|
||||
value: {{ include "postgresql.username" . | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: POSTGRES_PASSWORD_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-password"
|
||||
{{- else }}
|
||||
- name: POSTGRES_PASSWORD
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-password
|
||||
{{- end }}
|
||||
{{- if (include "postgresql.database" .) }}
|
||||
- name: POSTGRES_DB
|
||||
value: {{ (include "postgresql.database" .) | quote }}
|
||||
{{- end }}
|
||||
{{- if .Values.extraEnv }}
|
||||
{{ tpl (toYaml .Values.extraEnv) $ | indent 8 }}
|
||||
env:
|
||||
{{- $database := required "In order to enable metrics you need to specify a database (.Values.postgresqlDatabase or .Values.global.postgresql.postgresqlDatabase)" (include "postgresql.database" .) }}
|
||||
- name: DATA_SOURCE_URI
|
||||
value: {{ printf "127.0.0.1:%d/%s?sslmode=disable" (int (include "postgresql.port" .)) $database | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: DATA_SOURCE_PASS_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-password"
|
||||
{{- else }}
|
||||
- name: DATA_SOURCE_PASS
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-password
|
||||
{{- end }}
|
||||
- name: DATA_SOURCE_USER
|
||||
value: {{ template "postgresql.username" . }}
|
||||
{{- if .Values.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /
|
||||
port: metrics
|
||||
initialDelaySeconds: {{ .Values.metrics.livenessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.metrics.livenessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.metrics.livenessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.metrics.livenessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.metrics.livenessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /
|
||||
port: metrics
|
||||
initialDelaySeconds: {{ .Values.metrics.readinessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.metrics.readinessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.metrics.readinessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.metrics.readinessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.metrics.readinessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
volumeMounts:
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
mountPath: /opt/bitnami/postgresql/secrets/
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: metrics
|
||||
containerPort: 9187
|
||||
{{- if .Values.metrics.resources }}
|
||||
resources: {{- toYaml .Values.metrics.resources | nindent 12 }}
|
||||
{{- end }}
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: postgresql
|
||||
containerPort: {{ template "postgresql.port" . }}
|
||||
{{- if .Values.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
{{- if (include "postgresql.database" .) }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -d {{ (include "postgresql.database" .) | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- else }}
|
||||
- exec pg_isready -U {{ include "postgresql.username" . | quote }} -h 127.0.0.1 -p {{ template "postgresql.port" . }}
|
||||
{{- end }}
|
||||
initialDelaySeconds: {{ .Values.livenessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.livenessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.livenessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.livenessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.livenessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
exec:
|
||||
command:
|
||||
- sh
|
||||
- -c
|
||||
- -e
|
||||
{{- include "postgresql.readinessProbeCommand" . | nindent 12 }}
|
||||
initialDelaySeconds: {{ .Values.readinessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.readinessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.readinessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.readinessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.readinessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
volumeMounts:
|
||||
{{- if or (.Files.Glob "files/docker-entrypoint-initdb.d/*.{sh,sql,sql.gz}") .Values.initdbScriptsConfigMap .Values.initdbScripts }}
|
||||
- name: custom-init-scripts
|
||||
mountPath: /docker-entrypoint-initdb.d/
|
||||
{{- end }}
|
||||
{{- if .Values.initdbScriptsSecret }}
|
||||
- name: custom-init-scripts-secret
|
||||
mountPath: /docker-entrypoint-initdb.d/secret
|
||||
volumes:
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
|
||||
- name: postgresql-config
|
||||
configMap:
|
||||
name: {{ template "postgresql.configurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap }}
|
||||
- name: postgresql-extended-config
|
||||
mountPath: /bitnami/postgresql/conf/conf.d/
|
||||
configMap:
|
||||
name: {{ template "postgresql.extendedConfigurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
mountPath: /opt/bitnami/postgresql/secrets/
|
||||
secret:
|
||||
secretName: {{ template "postgresql.secretName" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.persistence.enabled }}
|
||||
- name: data
|
||||
mountPath: {{ .Values.persistence.mountPath }}
|
||||
subPath: {{ .Values.persistence.subPath }}
|
||||
{{- if or (.Files.Glob "files/docker-entrypoint-initdb.d/*.{sh,sql,sql.gz}") .Values.initdbScriptsConfigMap .Values.initdbScripts }}
|
||||
- name: custom-init-scripts
|
||||
configMap:
|
||||
name: {{ template "postgresql.initdbScriptsCM" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap }}
|
||||
- name: postgresql-config
|
||||
mountPath: /bitnami/postgresql/conf
|
||||
{{- if .Values.initdbScriptsSecret }}
|
||||
- name: custom-init-scripts-secret
|
||||
secret:
|
||||
secretName: {{ template "postgresql.initdbScriptsSecret" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.master.extraVolumeMounts }}
|
||||
{{- toYaml .Values.master.extraVolumeMounts | nindent 8 }}
|
||||
{{- if .Values.master.extraVolumes }}
|
||||
{{- toYaml .Values.master.extraVolumes | nindent 8 }}
|
||||
{{- end }}
|
||||
{{- if .Values.metrics.enabled }}
|
||||
- name: metrics
|
||||
image: {{ template "postgresql.metrics.image" . }}
|
||||
imagePullPolicy: {{ .Values.metrics.image.pullPolicy | quote }}
|
||||
{{- if .Values.metrics.securityContext.enabled }}
|
||||
securityContext:
|
||||
runAsUser: {{ .Values.metrics.securityContext.runAsUser }}
|
||||
{{- end }}
|
||||
env:
|
||||
{{- $database := required "In order to enable metrics you need to specify a database (.Values.postgresqlDatabase or .Values.global.postgresql.postgresqlDatabase)" (include "postgresql.database" .) }}
|
||||
- name: DATA_SOURCE_URI
|
||||
value: {{ printf "127.0.0.1:%d/%s?sslmode=disable" (int (include "postgresql.port" .)) $database | quote }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: DATA_SOURCE_PASS_FILE
|
||||
value: "/opt/bitnami/postgresql/secrets/postgresql-password"
|
||||
{{- else }}
|
||||
- name: DATA_SOURCE_PASS
|
||||
valueFrom:
|
||||
secretKeyRef:
|
||||
name: {{ template "postgresql.secretName" . }}
|
||||
key: postgresql-password
|
||||
{{- end }}
|
||||
- name: DATA_SOURCE_USER
|
||||
value: {{ template "postgresql.username" . }}
|
||||
{{- if .Values.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /
|
||||
port: metrics
|
||||
initialDelaySeconds: {{ .Values.metrics.livenessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.metrics.livenessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.metrics.livenessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.metrics.livenessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.metrics.livenessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /
|
||||
port: metrics
|
||||
initialDelaySeconds: {{ .Values.metrics.readinessProbe.initialDelaySeconds }}
|
||||
periodSeconds: {{ .Values.metrics.readinessProbe.periodSeconds }}
|
||||
timeoutSeconds: {{ .Values.metrics.readinessProbe.timeoutSeconds }}
|
||||
successThreshold: {{ .Values.metrics.readinessProbe.successThreshold }}
|
||||
failureThreshold: {{ .Values.metrics.readinessProbe.failureThreshold }}
|
||||
{{- end }}
|
||||
volumeMounts:
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
mountPath: /opt/bitnami/postgresql/secrets/
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: metrics
|
||||
containerPort: 9187
|
||||
resources:
|
||||
{{ toYaml .Values.metrics.resources | indent 10 }}
|
||||
{{- end }}
|
||||
volumes:
|
||||
{{- if or (.Files.Glob "files/postgresql.conf") (.Files.Glob "files/pg_hba.conf") .Values.postgresqlConfiguration .Values.pgHbaConfiguration .Values.configurationConfigMap}}
|
||||
- name: postgresql-config
|
||||
configMap:
|
||||
name: {{ template "postgresql.configurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/conf.d/*.conf") .Values.postgresqlExtendedConf .Values.extendedConfConfigMap }}
|
||||
- name: postgresql-extended-config
|
||||
configMap:
|
||||
name: {{ template "postgresql.extendedConfigurationCM" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.usePasswordFile }}
|
||||
- name: postgresql-password
|
||||
secret:
|
||||
secretName: {{ template "postgresql.secretName" . }}
|
||||
{{- end }}
|
||||
{{- if or (.Files.Glob "files/docker-entrypoint-initdb.d/*.{sh,sql,sql.gz}") .Values.initdbScriptsConfigMap .Values.initdbScripts }}
|
||||
- name: custom-init-scripts
|
||||
configMap:
|
||||
name: {{ template "postgresql.initdbScriptsCM" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.initdbScriptsSecret }}
|
||||
- name: custom-init-scripts-secret
|
||||
secret:
|
||||
secretName: {{ template "postgresql.initdbScriptsSecret" . }}
|
||||
{{- end }}
|
||||
{{- if .Values.master.extraVolumes }}
|
||||
{{- toYaml .Values.master.extraVolumes | nindent 6}}
|
||||
{{- end }}
|
||||
{{- if and .Values.persistence.enabled .Values.persistence.existingClaim }}
|
||||
- name: data
|
||||
persistentVolumeClaim:
|
||||
- name: data
|
||||
persistentVolumeClaim:
|
||||
{{- with .Values.persistence.existingClaim }}
|
||||
claimName: {{ tpl . $ }}
|
||||
claimName: {{ tpl . $ }}
|
||||
{{- end }}
|
||||
{{- else if not .Values.persistence.enabled }}
|
||||
- name: data
|
||||
emptyDir: {}
|
||||
- name: data
|
||||
emptyDir: {}
|
||||
{{- else if and .Values.persistence.enabled (not .Values.persistence.existingClaim) }}
|
||||
volumeClaimTemplates:
|
||||
- metadata:
|
||||
|
||||
@@ -11,9 +11,9 @@ spec:
|
||||
type: ClusterIP
|
||||
clusterIP: None
|
||||
ports:
|
||||
- name: postgresql
|
||||
port: {{ template "postgresql.port" . }}
|
||||
targetPort: postgresql
|
||||
- name: postgresql
|
||||
port: {{ template "postgresql.port" . }}
|
||||
targetPort: postgresql
|
||||
selector:
|
||||
app: {{ template "postgresql.name" . }}
|
||||
release: {{ .Release.Name | quote }}
|
||||
|
||||
@@ -18,12 +18,12 @@ spec:
|
||||
loadBalancerIP: {{ .Values.service.loadBalancerIP }}
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: postgresql
|
||||
port: {{ template "postgresql.port" . }}
|
||||
targetPort: postgresql
|
||||
{{- if .Values.service.nodePort }}
|
||||
nodePort: {{ .Values.service.nodePort }}
|
||||
{{- end }}
|
||||
- name: postgresql
|
||||
port: {{ template "postgresql.port" . }}
|
||||
targetPort: postgresql
|
||||
{{- if .Values.service.nodePort }}
|
||||
nodePort: {{ .Values.service.nodePort }}
|
||||
{{- end }}
|
||||
selector:
|
||||
app: {{ template "postgresql.name" . }}
|
||||
release: {{ .Release.Name | quote }}
|
||||
|
||||
@@ -26,12 +26,12 @@ spec:
|
||||
clusterIP: {{ .Values.service.clusterIP }}
|
||||
{{- end }}
|
||||
ports:
|
||||
- name: postgresql
|
||||
port: {{ template "postgresql.port" . }}
|
||||
targetPort: postgresql
|
||||
{{- if .Values.service.nodePort }}
|
||||
nodePort: {{ .Values.service.nodePort }}
|
||||
{{- end }}
|
||||
- name: postgresql
|
||||
port: {{ template "postgresql.port" . }}
|
||||
targetPort: postgresql
|
||||
{{- if .Values.service.nodePort }}
|
||||
nodePort: {{ .Values.service.nodePort }}
|
||||
{{- end }}
|
||||
selector:
|
||||
app: {{ template "postgresql.name" . }}
|
||||
release: {{ .Release.Name | quote }}
|
||||
|
||||
@@ -1,6 +1,6 @@
|
||||
apiVersion: v1
|
||||
name: rabbitmq
|
||||
version: 6.9.0
|
||||
version: 6.10.0
|
||||
appVersion: 3.8.0
|
||||
description: Open source message broker software that implements the Advanced Message Queuing Protocol (AMQP)
|
||||
keywords:
|
||||
|
||||
+122
-110
@@ -46,116 +46,128 @@ The command removes all the Kubernetes components associated with the chart and
|
||||
|
||||
The following table lists the configurable parameters of the RabbitMQ chart and their default values.
|
||||
|
||||
| Parameter | Description | Default |
|
||||
| ------------------------------------ | ------------------------------------------------ | ------------------------------------------------------- |
|
||||
| `global.imageRegistry` | Global Docker image registry | `nil` |
|
||||
| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` (does not add image pull secrets to deployed pods) |
|
||||
| `global.storageClass` | Global storage class for dynamic provisioning | `nil` |
|
||||
| `image.registry` | Rabbitmq Image registry | `docker.io` |
|
||||
| `image.repository` | Rabbitmq Image name | `bitnami/rabbitmq` |
|
||||
| `image.tag` | Rabbitmq Image tag | `{TAG_NAME}` |
|
||||
| `image.pullPolicy` | Image pull policy | `IfNotPresent` |
|
||||
| `image.pullSecrets` | Specify docker-registry secret names as an array | `nil` |
|
||||
| `image.debug` | Specify if debug values should be set | `false` |
|
||||
| `nameOverride` | String to partially override rabbitmq.fullname template with a string (will prepend the release name) | `nil` |
|
||||
| `fullnameOverride` | String to fully override rabbitmq.fullname template with a string | `nil` |
|
||||
| `rbacEnabled` | Specify if rbac is enabled in your cluster | `true` |
|
||||
| `podManagementPolicy` | Pod management policy | `OrderedReady` |
|
||||
| `rabbitmq.username` | RabbitMQ application username | `user` |
|
||||
| `rabbitmq.password` | RabbitMQ application password | _random 10 character long alphanumeric string_ |
|
||||
| `rabbitmq.existingPasswordSecret` | Existing secret with RabbitMQ credentials | `nil` |
|
||||
| `rabbitmq.erlangCookie` | Erlang cookie | _random 32 character long alphanumeric string_ |
|
||||
| `rabbitmq.existingErlangSecret` | Existing secret with RabbitMQ Erlang cookie | `nil` |
|
||||
| `rabbitmq.plugins` | List of plugins to enable | `rabbitmq_management rabbitmq_peer_discovery_k8s` |
|
||||
| `rabbitmq.extraPlugins` | Extra plugings to enable | `nil` |
|
||||
| `rabbitmq.clustering.address_type` | Switch clustering mode | `ip` or `hostname` |
|
||||
| `rabbitmq.clustering.k8s_domain` | Customize internal k8s cluster domain | `cluster.local` |
|
||||
| `rabbitmq.logs` | Value for the RABBITMQ_LOGS environment variable | `-` |
|
||||
| `rabbitmq.setUlimitNofiles` | Specify if max file descriptor limit should be set | `true` |
|
||||
| `rabbitmq.ulimitNofiles` | Max File Descriptor limit | `65536` |
|
||||
| `rabbitmq.maxAvailableSchedulers` | RabbitMQ maximum available scheduler threads | `2` |
|
||||
| `rabbitmq.onlineSchedulers` | RabbitMQ online scheduler threads | `1` |
|
||||
| `rabbitmq.env` | RabbitMQ [environment variables](https://www.rabbitmq.com/configure.html#customise-environment) | `{}` |
|
||||
| `rabbitmq.configuration` | Required cluster configuration | See values.yaml |
|
||||
| `rabbitmq.extraConfiguration` | Extra configuration to add to rabbitmq.conf | See values.yaml |
|
||||
| `rabbitmq.advancedConfiguration` | Extra configuration (in classic format) to add to advanced.config | See values.yaml |
|
||||
| `rabbitmq.tls.enabled` | Enable TLS support to rabbitmq | | `false` |
|
||||
| `rabbitmq.tls.failIfNoPeerCert` | When set to true, TLS connection will be rejected if client fails to provide a certificate | `true` |
|
||||
| `rabbitmq.tls.sslOptionsVerify` | `verify_peer` | Should [peer verification](https://www.rabbitmq.com/ssl.html#peer-verification) be enabled? |
|
||||
| `rabbitmq.tls.caCertificate` | Ca certificate | Certificate Authority (CA) bundle content |
|
||||
| `rabbitmq.tls.serverCertificate` | Server certificate | Server certificate content |
|
||||
| `rabbitmq.tls.serverKey` | Server Key | Server private key content |
|
||||
| `rabbitmq.tls.existingSecret` | Existing secret with certificate content to rabbitmq credentials | `nil` |
|
||||
| `service.type` | Kubernetes Service type | `ClusterIP` |
|
||||
| `service.port` | Amqp port | `5672` |
|
||||
| `service.tlsPort` | Amqp TLS port | `5671` |
|
||||
| `service.distPort` | Erlang distribution server port | `25672` |
|
||||
| `service.nodePort` | Node port override, if serviceType NodePort | _random available between 30000-32767_ |
|
||||
| `service.nodeTlsPort` | Node port override, if serviceType NodePort | _random available between 30000-32767_ |
|
||||
| `service.managerPort` | RabbitMQ Manager port | `15672` |
|
||||
| `service.extraPorts` | Extra ports to expose in the service | `nil` |
|
||||
| `service.extraContainerPorts` | Extra ports to be included in container spec, primarily informational | `nil` |
|
||||
| `persistence.enabled` | Use a PVC to persist data | `true` |
|
||||
| `service.annotations` | service annotations as an array | [] |
|
||||
| `schedulerName` | Name of the k8s service (other than default) | `nil` |
|
||||
| `persistence.storageClass` | Storage class of backing PVC | `nil` (uses alpha storage class annotation) |
|
||||
| `persistence.existingClaim` | RabbitMQ data Persistent Volume existing claim name, evaluated as a template | "" |
|
||||
| `persistence.accessMode` | Use volume as ReadOnly or ReadWrite | `ReadWriteOnce` |
|
||||
| `persistence.size` | Size of data volume | `8Gi` |
|
||||
| `persistence.path` | Mount path of the data volume | `/opt/bitnami/rabbitmq/var/lib/rabbitmq` |
|
||||
| `securityContext.enabled` | Enable security context | `true` |
|
||||
| `securityContext.fsGroup` | Group ID for the container | `1001` |
|
||||
| `securityContext.runAsUser` | User ID for the container | `1001` |
|
||||
| `resources` | resource needs and limits to apply to the pod | {} |
|
||||
| `replicas` | Replica count | `1` |
|
||||
| `priorityClassName` | Pod priority class name | `` |
|
||||
| `nodeSelector` | Node labels for pod assignment | {} |
|
||||
| `affinity` | Affinity settings for pod assignment | {} |
|
||||
| `tolerations` | Toleration labels for pod assignment | [] |
|
||||
| `updateStrategy` | Statefulset update strategy policy | `RollingUpdate` |
|
||||
| `ingress.enabled` | Enable ingress resource for Management console | `false` |
|
||||
| `ingress.hostName` | Hostname to your RabbitMQ installation | `nil` |
|
||||
| `ingress.path` | Path within the url structure | `/` |
|
||||
| `ingress.tls` | enable ingress with tls | `false` |
|
||||
| `ingress.tlsSecret` | tls type secret to be used | `myTlsSecret` |
|
||||
| `ingress.annotations` | ingress annotations as an array | [] |
|
||||
| `livenessProbe.enabled` | would you like a livenessProbed to be enabled | `true` |
|
||||
| `livenessProbe.initialDelaySeconds` | number of seconds | 120 |
|
||||
| `livenessProbe.timeoutSeconds` | number of seconds | 20 |
|
||||
| `livenessProbe.periodSeconds` | number of seconds | 30 |
|
||||
| `livenessProbe.failureThreshold` | number of failures | 6 |
|
||||
| `livenessProbe.successThreshold` | number of successes | 1 |
|
||||
| `readinessProbe.enabled` | would you like a readinessProbe to be enabled | `true` |
|
||||
| `readinessProbe.initialDelaySeconds` | number of seconds | 10 |
|
||||
| `readinessProbe.timeoutSeconds` | number of seconds | 20 |
|
||||
| `readinessProbe.periodSeconds` | number of seconds | 30 |
|
||||
| `readinessProbe.failureThreshold` | number of failures | 3 |
|
||||
| `readinessProbe.successThreshold` | number of successes | 1 |
|
||||
| `metrics.enabled` | Start a side-car prometheus exporter | `false` |
|
||||
| `metrics.image.registry` | Exporter image registry | `docker.io` |
|
||||
| `metrics.image.repository` | Exporter image name | `bitnami/rabbitmq-exporter` |
|
||||
| `metrics.image.tag` | Exporter image tag | `{TAG_NAME}` |
|
||||
| `metrics.image.pullPolicy` | Exporter image pull policy | `IfNotPresent` |
|
||||
| `metrics.serviceMonitor.enabled` | Create ServiceMonitor Resource for scraping metrics using PrometheusOperator | `false` |
|
||||
| `metrics.serviceMonitor.namespace` | Namespace where servicemonitor resource should be created | `nil` |
|
||||
| `metrics.serviceMonitor.interval` | Specify the interval at which metrics should be scraped | `30s` |
|
||||
| `metrics.serviceMonitor.scrapeTimeout`| Specify the timeout after which the scrape is ended | `nil` |
|
||||
| `metrics.serviceMonitor.relabellings`| Specify Metric Relabellings to add to the scrape endpoint | `nil` |
|
||||
| `metrics.serviceMonitor.honorLabels` | honorLabels chooses the metric's labels on collisions with target labels. | `false` |
|
||||
| `metrics.serviceMonitor.additionalLabels`| Used to pass Labels that are required by the Installed Prometheus Operator | `{}` |
|
||||
| `metrics.port` | Prometheus metrics exporter port | `9419` |
|
||||
| `metrics.env` | Exporter [configuration environment variables](https://github.com/kbudde/rabbitmq_exporter#configuration) | `{}` |
|
||||
| `metrics.resources` | Exporter resource requests/limit | `nil` |
|
||||
| `metrics.capabilities` | Exporter: Comma-separated list of extended [scraping capabilities supported by the target RabbitMQ server](https://github.com/kbudde/rabbitmq_exporter#extended-rabbitmq-capabilities) | `bert,no_sort` |
|
||||
| `podLabels` | Additional labels for the statefulset pod(s). | {} |
|
||||
| `volumePermissions.enabled` | Enable init container that changes volume permissions in the data directory (for cases where the default k8s `runAsUser` and `fsUser` values do not work) | `false` |
|
||||
| `volumePermissions.image.registry` | Init container volume-permissions image registry | `docker.io` |
|
||||
| `volumePermissions.image.repository` | Init container volume-permissions image name | `bitnami/minideb` |
|
||||
| `volumePermissions.image.tag` | Init container volume-permissions image tag | `stretch` |
|
||||
| `volumePermissions.image.pullPolicy` | Init container volume-permissions image pull policy | `Always` |
|
||||
| `volumePermissions.resources` | Init container resource requests/limit | `nil` |
|
||||
| `forceBoot.enabled` | Executes 'rabbitmqctl force_boot' to force boot cluster shut down unexpectedly in an unknown order. Use it only if you prefer availability over integrity. | `false` |
|
||||
| `extraSecrets` | Optionally specify extra secrets to be created by the chart. | `{}` |
|
||||
| Parameter | Description | Default |
|
||||
| -------------------------------------------- | ------------------------------------------------ | ------------------------------------------------------- |
|
||||
| `global.imageRegistry` | Global Docker image registry | `nil` |
|
||||
| `global.imagePullSecrets` | Global Docker registry secret names as an array | `[]` (does not add image pull secrets to deployed pods) |
|
||||
| `global.storageClass` | Global storage class for dynamic provisioning | `nil` |
|
||||
| `image.registry` | Rabbitmq Image registry | `docker.io` |
|
||||
| `image.repository` | Rabbitmq Image name | `bitnami/rabbitmq` |
|
||||
| `image.tag` | Rabbitmq Image tag | `{TAG_NAME}` |
|
||||
| `image.pullPolicy` | Image pull policy | `IfNotPresent` |
|
||||
| `image.pullSecrets` | Specify docker-registry secret names as an array | `nil` |
|
||||
| `image.debug` | Specify if debug values should be set | `false` |
|
||||
| `nameOverride` | String to partially override rabbitmq.fullname template with a string (will prepend the release name) | `nil` |
|
||||
| `fullnameOverride` | String to fully override rabbitmq.fullname template with a string | `nil` |
|
||||
| `rbacEnabled` | Specify if rbac is enabled in your cluster | `true` |
|
||||
| `podManagementPolicy` | Pod management policy | `OrderedReady` |
|
||||
| `rabbitmq.username` | RabbitMQ application username | `user` |
|
||||
| `rabbitmq.password` | RabbitMQ application password | _random 10 character long alphanumeric string_ |
|
||||
| `rabbitmq.existingPasswordSecret` | Existing secret with RabbitMQ credentials | `nil` |
|
||||
| `rabbitmq.erlangCookie` | Erlang cookie | _random 32 character long alphanumeric string_ |
|
||||
| `rabbitmq.existingErlangSecret` | Existing secret with RabbitMQ Erlang cookie | `nil` |
|
||||
| `rabbitmq.plugins` | List of plugins to enable | `rabbitmq_management rabbitmq_peer_discovery_k8s` |
|
||||
| `rabbitmq.extraPlugins` | Extra plugings to enable | `nil` |
|
||||
| `rabbitmq.clustering.address_type` | Switch clustering mode | `ip` or `hostname` |
|
||||
| `rabbitmq.clustering.k8s_domain` | Customize internal k8s cluster domain | `cluster.local` |
|
||||
| `rabbitmq.logs` | Value for the RABBITMQ_LOGS environment variable | `-` |
|
||||
| `rabbitmq.setUlimitNofiles` | Specify if max file descriptor limit should be set | `true` |
|
||||
| `rabbitmq.ulimitNofiles` | Max File Descriptor limit | `65536` |
|
||||
| `rabbitmq.maxAvailableSchedulers` | RabbitMQ maximum available scheduler threads | `2` |
|
||||
| `rabbitmq.onlineSchedulers` | RabbitMQ online scheduler threads | `1` |
|
||||
| `rabbitmq.env` | RabbitMQ [environment variables](https://www.rabbitmq.com/configure.html#customise-environment) | `{}` |
|
||||
| `rabbitmq.configuration` | Required cluster configuration | See values.yaml |
|
||||
| `rabbitmq.extraConfiguration` | Extra configuration to add to rabbitmq.conf | See values.yaml |
|
||||
| `rabbitmq.advancedConfiguration` | Extra configuration (in classic format) to add to advanced.config | See values.yaml |
|
||||
| `rabbitmq.tls.enabled` | Enable TLS support to rabbitmq | `false` |
|
||||
| `rabbitmq.tls.failIfNoPeerCert` | When set to true, TLS connection will be rejected if client fails to provide a certificate | `true` |
|
||||
| `rabbitmq.tls.sslOptionsVerify` | `verify_peer` | Should [peer verification](https://www.rabbitmq.com/ssl.html#peer-verification) be enabled? |
|
||||
| `rabbitmq.tls.caCertificate` | Ca certificate | Certificate Authority (CA) bundle content |
|
||||
| `rabbitmq.tls.serverCertificate` | Server certificate | Server certificate content |
|
||||
| `rabbitmq.tls.serverKey` | Server Key | Server private key content |
|
||||
| `rabbitmq.tls.existingSecret` | Existing secret with certificate content to rabbitmq credentials | `nil` |
|
||||
| `service.type` | Kubernetes Service type | `ClusterIP` |
|
||||
| `service.port` | Amqp port | `5672` |
|
||||
| `service.tlsPort` | Amqp TLS port | `5671` |
|
||||
| `service.distPort` | Erlang distribution server port | `25672` |
|
||||
| `service.nodePort` | Node port override, if serviceType NodePort | _random available between 30000-32767_ |
|
||||
| `service.nodeTlsPort` | Node port override, if serviceType NodePort | _random available between 30000-32767_ |
|
||||
| `service.managerPort` | RabbitMQ Manager port | `15672` |
|
||||
| `service.extraPorts` | Extra ports to expose in the service | `nil` |
|
||||
| `service.extraContainerPorts` | Extra ports to be included in container spec, primarily informational | `nil` |
|
||||
| `persistence.enabled` | Use a PVC to persist data | `true` |
|
||||
| `service.annotations` | service annotations as an array | [] |
|
||||
| `schedulerName` | Name of the k8s service (other than default) | `nil` |
|
||||
| `persistence.storageClass` | Storage class of backing PVC | `nil` (uses alpha storage class annotation) |
|
||||
| `persistence.existingClaim` | RabbitMQ data Persistent Volume existing claim name, evaluated as a template | "" |
|
||||
| `persistence.accessMode` | Use volume as ReadOnly or ReadWrite | `ReadWriteOnce` |
|
||||
| `persistence.size` | Size of data volume | `8Gi` |
|
||||
| `persistence.path` | Mount path of the data volume | `/opt/bitnami/rabbitmq/var/lib/rabbitmq` |
|
||||
| `securityContext.enabled` | Enable security context | `true` |
|
||||
| `securityContext.fsGroup` | Group ID for the container | `1001` |
|
||||
| `securityContext.runAsUser` | User ID for the container | `1001` |
|
||||
| `resources` | resource needs and limits to apply to the pod | {} |
|
||||
| `replicas` | Replica count | `1` |
|
||||
| `priorityClassName` | Pod priority class name | `` |
|
||||
| `nodeSelector` | Node labels for pod assignment | {} |
|
||||
| `affinity` | Affinity settings for pod assignment | {} |
|
||||
| `tolerations` | Toleration labels for pod assignment | [] |
|
||||
| `updateStrategy` | Statefulset update strategy policy | `RollingUpdate` |
|
||||
| `ingress.enabled` | Enable ingress resource for Management console | `false` |
|
||||
| `ingress.hostName` | Hostname to your RabbitMQ installation | `nil` |
|
||||
| `ingress.path` | Path within the url structure | `/` |
|
||||
| `ingress.tls` | enable ingress with tls | `false` |
|
||||
| `ingress.tlsSecret` | tls type secret to be used | `myTlsSecret` |
|
||||
| `ingress.annotations` | ingress annotations as an array | [] |
|
||||
| `livenessProbe.enabled` | would you like a livenessProbed to be enabled | `true` |
|
||||
| `livenessProbe.initialDelaySeconds` | number of seconds | 120 |
|
||||
| `livenessProbe.timeoutSeconds` | number of seconds | 20 |
|
||||
| `livenessProbe.periodSeconds` | number of seconds | 30 |
|
||||
| `livenessProbe.failureThreshold` | number of failures | 6 |
|
||||
| `livenessProbe.successThreshold` | number of successes | 1 |
|
||||
| `readinessProbe.enabled` | would you like a readinessProbe to be enabled | `true` |
|
||||
| `readinessProbe.initialDelaySeconds` | number of seconds | 10 |
|
||||
| `readinessProbe.timeoutSeconds` | number of seconds | 20 |
|
||||
| `readinessProbe.periodSeconds` | number of seconds | 30 |
|
||||
| `readinessProbe.failureThreshold` | number of failures | 3 |
|
||||
| `readinessProbe.successThreshold` | number of successes | 1 |
|
||||
| `metrics.enabled` | Start a side-car prometheus exporter | `false` |
|
||||
| `metrics.image.registry` | Exporter image registry | `docker.io` |
|
||||
| `metrics.image.repository` | Exporter image name | `bitnami/rabbitmq-exporter` |
|
||||
| `metrics.image.tag` | Exporter image tag | `{TAG_NAME}` |
|
||||
| `metrics.image.pullPolicy` | Exporter image pull policy | `IfNotPresent` |
|
||||
| `metrics.livenessProbe.enabled` | would you like a livenessProbed to be enabled | `true` |
|
||||
| `metrics.livenessProbe.initialDelaySeconds` | number of seconds | 15 |
|
||||
| `metrics.livenessProbe.timeoutSeconds` | number of seconds | 5 |
|
||||
| `metrics.livenessProbe.periodSeconds` | number of seconds | 30 |
|
||||
| `metrics.livenessProbe.failureThreshold` | number of failures | 6 |
|
||||
| `metrics.livenessProbe.successThreshold` | number of successes | 1 |
|
||||
| `metrics.readinessProbe.enabled` | would you like a readinessProbe to be enabled | `true` |
|
||||
| `metrics.readinessProbe.initialDelaySeconds` | number of seconds | 5 |
|
||||
| `metrics.readinessProbe.timeoutSeconds` | number of seconds | 5 |
|
||||
| `metrics.readinessProbe.periodSeconds` | number of seconds | 30 |
|
||||
| `metrics.readinessProbe.failureThreshold` | number of failures | 3 |
|
||||
| `metrics.readinessProbe.successThreshold` | number of successes | 1 |
|
||||
| `metrics.serviceMonitor.enabled` | Create ServiceMonitor Resource for scraping metrics using PrometheusOperator | `false` |
|
||||
| `metrics.serviceMonitor.namespace` | Namespace where servicemonitor resource should be created | `nil` |
|
||||
| `metrics.serviceMonitor.interval` | Specify the interval at which metrics should be scraped | `30s` |
|
||||
| `metrics.serviceMonitor.scrapeTimeout` | Specify the timeout after which the scrape is ended | `nil` |
|
||||
| `metrics.serviceMonitor.relabellings` | Specify Metric Relabellings to add to the scrape endpoint | `nil` |
|
||||
| `metrics.serviceMonitor.honorLabels` | honorLabels chooses the metric's labels on collisions with target labels. | `false` |
|
||||
| `metrics.serviceMonitor.additionalLabels` | Used to pass Labels that are required by the Installed Prometheus Operator | `{}` |
|
||||
| `metrics.port ` | Prometheus metrics exporter port | `9419` |
|
||||
| `metrics.env` | Exporter [configuration environment variables](https://github.com/kbudde/rabbitmq_exporter#configuration) | `{}` |
|
||||
| `metrics.resources` | Exporter resource requests/limit | `nil` |
|
||||
| `metrics.capabilities` | Exporter: Comma-separated list of extended [scraping capabilities supported by the target RabbitMQ server](https://github.com/kbudde/rabbitmq_exporter#extended-rabbitmq-capabilities) | `bert,no_sort` |
|
||||
| `podLabels` | Additional labels for the statefulset pod(s). | {} |
|
||||
| `volumePermissions.enabled` | Enable init container that changes volume permissions in the data directory (for cases where the default k8s `runAsUser` and `fsUser` values do not work) | `false |
|
||||
| `volumePermissions.image.registry` | Init container volume-permissions image registry | `docker.io` |
|
||||
| `volumePermissions.image.repository` | Init container volume-permissions image name | `bitnami/minideb` |
|
||||
| `volumePermissions.image.tag` | Init container volume-permissions image tag | `stretch` |
|
||||
| `volumePermissions.image.pullPolicy` | Init container volume-permissions image pull policy | `Always` |
|
||||
| `volumePermissions.resources` | Init container resource requests/limit | `nil` |
|
||||
| `forceBoot.enabled` | Executes 'rabbitmqctl force_boot' to force boot cluster shut down unexpectedly in an unknown order. Use it only if you prefer availability over integrity. | `false` |
|
||||
| `extraSecrets` | Optionally specify extra secrets to be created by the chart. | `{}` |
|
||||
|
||||
The above parameters map to the env variables defined in [bitnami/rabbitmq](http://github.com/bitnami/bitnami-docker-rabbitmq). For more information please refer to the [bitnami/rabbitmq](http://github.com/bitnami/bitnami-docker-rabbitmq) image documentation.
|
||||
|
||||
|
||||
@@ -246,18 +246,28 @@ spec:
|
||||
ports:
|
||||
- name: metrics
|
||||
containerPort: 9090
|
||||
{{- if .Values.metrics.livenessProbe.enabled }}
|
||||
livenessProbe:
|
||||
httpGet:
|
||||
path: /metrics
|
||||
port: metrics
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
initialDelaySeconds: {{ .Values.metrics.livenessProbe.initialDelaySeconds }}
|
||||
timeoutSeconds: {{ .Values.metrics.livenessProbe.timeoutSeconds }}
|
||||
periodSeconds: {{ .Values.metrics.livenessProbe.periodSeconds }}
|
||||
failureThreshold: {{ .Values.metrics.livenessProbe.failureThreshold }}
|
||||
successThreshold: {{ .Values.metrics.livenessProbe.successThreshold }}
|
||||
{{- end }}
|
||||
{{- if .Values.metrics.readinessProbe.enabled }}
|
||||
readinessProbe:
|
||||
httpGet:
|
||||
path: /metrics
|
||||
port: metrics
|
||||
initialDelaySeconds: 5
|
||||
timeoutSeconds: 5
|
||||
initialDelaySeconds: {{ .Values.metrics.readinessProbe.initialDelaySeconds }}
|
||||
timeoutSeconds: {{ .Values.metrics.readinessProbe.timeoutSeconds }}
|
||||
periodSeconds: {{ .Values.metrics.readinessProbe.periodSeconds }}
|
||||
failureThreshold: {{ .Values.metrics.readinessProbe.failureThreshold }}
|
||||
successThreshold: {{ .Values.metrics.readinessProbe.successThreshold }}
|
||||
{{- end }}
|
||||
resources:
|
||||
{{ toYaml .Values.metrics.resources | indent 10 }}
|
||||
{{- end }}
|
||||
|
||||
@@ -349,6 +349,22 @@ metrics:
|
||||
prometheus.io/scrape: "true"
|
||||
prometheus.io/port: "9090"
|
||||
|
||||
livenessProbe:
|
||||
enabled: true
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
periodSeconds: 30
|
||||
failureThreshold: 6
|
||||
successThreshold: 1
|
||||
|
||||
readinessProbe:
|
||||
enabled: true
|
||||
initialDelaySeconds: 5
|
||||
timeoutSeconds: 5
|
||||
periodSeconds: 30
|
||||
failureThreshold: 3
|
||||
successThreshold: 1
|
||||
|
||||
## Prometheus Service Monitor
|
||||
## ref: https://github.com/coreos/prometheus-operator
|
||||
## https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#endpoint
|
||||
|
||||
@@ -349,6 +349,22 @@ metrics:
|
||||
prometheus.io/scrape: "true"
|
||||
prometheus.io/port: "9090"
|
||||
|
||||
livenessProbe:
|
||||
enabled: true
|
||||
initialDelaySeconds: 15
|
||||
timeoutSeconds: 5
|
||||
periodSeconds: 30
|
||||
failureThreshold: 6
|
||||
successThreshold: 1
|
||||
|
||||
readinessProbe:
|
||||
enabled: true
|
||||
initialDelaySeconds: 5
|
||||
timeoutSeconds: 5
|
||||
periodSeconds: 30
|
||||
failureThreshold: 3
|
||||
successThreshold: 1
|
||||
|
||||
## Prometheus Service Monitor
|
||||
## ref: https://github.com/coreos/prometheus-operator
|
||||
## https://github.com/coreos/prometheus-operator/blob/master/Documentation/api.md#endpoint
|
||||
|
||||
Reference in New Issue
Block a user