Bitnami/charts
2
0
Fork 0
mirror of https://github.com/bitnami/charts.git synced 2026-03-16 06:47:30 +08:00
Code Issues Packages Projects Releases Wiki Activity

[bitnami/*] Move documentation sections from docs.bitnami.com back to the README (#22203)

Browse Source 
* [bitnami/*] Move documentation sections from docs.bitnami.com back to the README

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move use-external-database section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move configure-sidecar-init-containers section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move configure-sidecar-init-containers section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move configure-ingress section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move enable-tls-ingress section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Remove upgrade-helm3 section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move upgrade section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move upgrade section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move configure-sidecar-init-containers section to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Remove get-started link in GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Move rest of docs sections to GitHub

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [CONTENT-6404] Remove some docs.bitnami.com urls from the READMEs

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Fix linter

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Fix linter

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Fix linter

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Fix linter

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Ignore img folder when packaging the helm chart

Signed-off-by: Jota Martos <jotamartos@vmware.com>

* [bitnami/*] Update template's README file

Signed-off-by: Jota Martos <jotamartos@vmware.com>

---------

Signed-off-by: Jota Martos <jotamartos@vmware.com>
Signed-off-by: Juan José Martos <jotamartos@gmail.com>
This commit is contained in:
Juan José Martos
2024-01-24 11:26:12 +01:00
committed by GitHub
parent 9e6d5c9f96
commit 7564f36ca1
227 changed files with 5817 additions and 481 deletions
Download Patch File Download Diff File Expand all files Collapse all files

239
bitnami/mongodb/README.md
View File

@@ -61,7 +61,69 @@ architecture="standalone"
architecture="replicaset"
```
Refer to the [chart documentation for more information on each of these architectures](https://docs.bitnami.com/kubernetes/infrastructure/mongodb/get-started/understand-architecture/).
### Standalone architecture
The *standalone* architecture installs a deployment (or StatefulSet) with one MongoDB&reg; server (it cannot be scaled):
```text
----------------
| MongoDB&reg; |
| svc |
----------------
|
v
------------
|MongoDB&reg;|
| Server |
| Pod |
-----------
```
### Replicaset architecture
The chart also supports the *replicaset* architecture with and without a MongoDB(&reg;) Arbiter:
When the MongoDB(&reg;) Arbiter is enabled, the chart installs two StatefulSets: A StatefulSet with N MongoDB(&reg;) servers (organised with one primary and N-1 secondary nodes), and a StatefulSet with one MongoDB(&reg;) arbiter node (it cannot be scaled).
```text
---------------- ---------------- ---------------- -------------
| MongoDB&reg; 0 | | MongoDB&reg; 1 | | MongoDB&reg; N | | Arbiter |
| external svc | | external svc | | external svc | | svc |
---------------- ---------------- ---------------- -------------
| | | |
v v v v
---------------- ---------------- ---------------- --------------
| MongoDB&reg; 0 | | MongoDB&reg; 1 | | MongoDB&reg; N | | MongoDB&reg; |
| Server | | Server | | Server | | Arbiter |
| Pod | | Pod | | Pod | | Pod |
---------------- ---------------- ---------------- --------------
primary secondary secondary
```
The PSA model is useful when the third Availability Zone cannot hold a full MongoDB(&reg;) instance. The MongoDB(&reg;) Arbiter as decision maker is lightweight and can run alongside other workloads.
> NOTE: An update takes your MongoDB(&reg;) replicaset offline if the Arbiter is enabled and the number of MongoDB(&reg;) replicas is two. Helm applies updates to the StatefulSets for the MongoDB(&reg;) instance and the Arbiter at the same time so you lose two out of three quorum votes.
Without the Arbiter, the chart deploys a single statefulset with N MongoDB(&reg;) servers (organised with one primary and N-1 secondary nodes).
```text
---------------- ---------------- ----------------
| MongoDB&reg; 0 | | MongoDB&reg; 1 | | MongoDB&reg; N |
| external svc | | external svc | | external svc |
---------------- ---------------- ----------------
| | |
v v v
---------------- ---------------- ----------------
| MongoDB&reg; 0 | | MongoDB&reg; 1 | | MongoDB&reg; N |
| Server | | Server | | Server |
| Pod | | Pod | | Pod |
---------------- ---------------- ----------------
primary secondary secondary
```
There are no services load balancing requests between MongoDB(&reg;) nodes; instead, each node has an associated service to access them individually.
> NOTE: Although the first replica is initially assigned the primary role, any of the secondary nodes can become the primary if it is down, or during upgrades. Do not make any assumption about what replica has the primary role. Instead, configure your MongoDB(&reg;) client with the list of MongoDB(&reg;) hostnames so it can dynamically choose the node to send requests.
## Parameters
@@ -695,7 +757,55 @@ In order to access MongoDB(&reg;) nodes from outside the cluster when using a re
- Using LoadBalancer services
- Using NodePort services.
Refer to the [chart documentation for more details and configuration examples](https://docs.bitnami.com/kubernetes/infrastructure/mongodb/configuration/configure-external-access-replicaset/).
#### Use LoadBalancer services
Two alternatives are available to use *LoadBalancer* services:
- Use random load balancer IP addresses using an *initContainer* that waits for the IP addresses to be ready and discovers them automatically. An example deployment configuration is shown below:
```text
architecture=replicaset
replicaCount=2
externalAccess.enabled=true
externalAccess.service.type=LoadBalancer
externalAccess.service.port=27017
externalAccess.autoDiscovery.enabled=true
serviceAccount.create=true
rbac.create=true
```
> NOTE: This option requires creating RBAC rules on clusters where RBAC policies are enabled.
- Manually specify the load balancer IP addresses. An example deployment configuration is shown below, with the placeholder EXTERNAL-IP-ADDRESS-X used in place of the load balancer IP addresses:
```text
architecture=replicaset
replicaCount=2
externalAccess.enabled=true
externalAccess.service.type=LoadBalancer
externalAccess.service.port=27017
externalAccess.service.loadBalancerIPs[0]='EXTERNAL-IP-ADDRESS-1'
externalAccess.service.loadBalancerIPs[1]='EXTERNAL-IP-ADDRESS-2'
```
> NOTE: This option requires knowing the load balancer IP addresses, so that each MongoDB&reg; node's advertised hostname is configured with it.
#### Use NodePort services
Manually specify the node ports to use. An example deployment configuration is shown below, with the placeholder NODE-PORT-X used in place of the node ports:
```text
architecture=replicaset
replicaCount=2
externalAccess.enabled=true
externalAccess.service.type=NodePort
externalAccess.service.nodePorts[0]='NODE-PORT-1'
externalAccess.service.nodePorts[1]='NODE-PORT-2'
```
> NOTE: This option requires knowing the node ports that will be exposed, so each MongoDB&reg; node's advertised hostname is configured with it.
The pod will try to get the external IP address of the node using the command `curl -s https://ipinfo.io/IP-ADDRESS` unless the `externalAccess.service.domain` parameter is set.
### Bootstrapping with an External Cluster
@@ -724,11 +834,45 @@ Alternatively, you can use a ConfigMap or a Secret with the environment variable
### Use Sidecars and Init Containers
If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter. Similarly, extra init containers can be added using the `initContainers` parameter.
If additional containers are needed in the same pod (such as additional metrics or logging exporters), they can be defined using the `sidecars` config parameter.
Refer to the chart documentation for more information on, and examples of, configuring and using [sidecars and init containers](https://docs.bitnami.com/kubernetes/infrastructure/mongodb/configuration/configure-sidecar-init-containers/).
```yaml
sidecars:
- name: your-image-name
image: your-image
imagePullPolicy: Always
ports:
- name: portname
containerPort: 1234
```
## Persistence
If these sidecars export extra ports, extra port definitions can be added using the `service.extraPorts` parameter (where available), as shown in the example below:
```yaml
service:
extraPorts:
- name: extraPort
port: 11311
targetPort: 11311
```
> NOTE: This Helm chart already includes sidecar containers for the Prometheus exporters (where applicable). These can be activated by adding the `--enable-metrics=true` parameter at deployment time. The `sidecars` parameter should therefore only be used for any extra sidecar containers.
If additional init containers are needed in the same pod, they can be defined using the `initContainers` parameter. Here is an example:
```yaml
initContainers:
- name: your-image-name
image: your-image
imagePullPolicy: Always
ports:
- name: portname
containerPort: 1234
```
Learn more about [sidecar containers](https://kubernetes.io/docs/concepts/workloads/pods/) and [init containers](https://kubernetes.io/docs/concepts/workloads/pods/init-containers/).
### Persistence
The [Bitnami MongoDB(&reg;)](https://github.com/bitnami/containers/tree/main/bitnami/mongodb) image stores the MongoDB(&reg;) data and configurations at the `/bitnami/mongodb` path of the container.
@@ -736,17 +880,88 @@ The chart mounts a [Persistent Volume](https://kubernetes.io/docs/concepts/stora
If you encounter errors when working with persistent volumes, refer to our [troubleshooting guide for persistent volumes](https://docs.bitnami.com/kubernetes/faq/troubleshooting/troubleshooting-persistence-volumes/).
## Use custom Prometheus rules
### Backup and restore MongoDB(R) deployments
Custom Prometheus rules can be defined for the Prometheus Operator by using the `prometheusRule` parameter.
Two different approaches are available to back up and restore Bitnami MongoDB&reg; Helm chart deployments on Kubernetes:
Refer to the [chart documentation for an example of a custom rule](https://docs.bitnami.com/kubernetes/infrastructure/mongodb/administration/use-prometheus-rules/).
- Back up the data from the source deployment and restore it in a new deployment using MongoDB&reg; built-in backup/restore tools.
- Back up the persistent volumes from the source deployment and attach them to a new deployment using Velero, a Kubernetes backup/restore tool.
## Enable SSL/TLS
#### Method 1: Backup and restore data using MongoDB&reg; built-in tools
This method involves the following steps:
- Use the *mongodump* tool to create a snapshot of the data in the source cluster.
- Create a new MongoDB&reg; Cluster deployment and forward the MongoDB&reg; Cluster service port for the new deployment.
- Restore the data using the *mongorestore* tool to import the backup to the new cluster.
> NOTE: Under this approach, it is important to create the new deployment on the destination cluster using the same credentials as the original deployment on the source cluster.
#### Method 2: Back up and restore persistent data volumes
This method involves copying the persistent data volumes for the MongoDB&reg; nodes and reusing them in a new deployment with [Velero](https://velero.io/), an open source Kubernetes backup/restore tool. This method is only suitable when:
- The Kubernetes provider is [supported by Velero](https://velero.io/docs/latest/supported-providers/).
- Both clusters are on the same Kubernetes provider, as this is a requirement of [Velero's native support for migrating persistent volumes](https://velero.io/docs/latest/migration-case/).
- The restored deployment on the destination cluster will have the same name, namespace, topology and credentials as the original deployment on the source cluster.
This method involves the following steps:
- Install Velero on the source and destination clusters.
- Use Velero to back up the PersistentVolumes (PVs) used by the deployment on the source cluster.
- Use Velero to restore the backed-up PVs on the destination cluster.
- Create a new deployment on the destination cluster with the same chart, deployment name, credentials and other parameters as the original. This new deployment will use the restored PVs and hence the original data.
Refer to our detailed [tutorial on backing up and restoring MongoDB&reg; chart deployments on Kubernetes](https://docs.bitnami.com/tutorials/backup-restore-data-mongodb-kubernetes/), which covers both these approaches, for more information.
### Use custom Prometheus rules
Custom Prometheus rules can be defined for the Prometheus Operator by using the `prometheusRule` parameter. A basic configuration example is shown below:
```text
metrics:
enabled: true
prometheusRule:
enabled: true
rules:
- name: rule1
rules:
- alert: HighRequestLatency
expr: job:request_latency_seconds:mean5m{job="myjob"} > 0.5
for: 10m
labels:
severity: page
annotations:
summary: High request latency
```
### Enable SSL/TLS
This chart supports enabling SSL/TLS between nodes in the cluster, as well as between MongoDB(&reg;) clients and nodes, by setting the `MONGODB_EXTRA_FLAGS` and `MONGODB_CLIENT_EXTRA_FLAGS` container environment variables, together with the correct `MONGODB_ADVERTISED_HOSTNAME`. To enable full TLS encryption, set the `tls.enabled` parameter to `true`.
Refer to the [chart documentation for more information on enabling TLS](https://docs.bitnami.com/kubernetes/infrastructure/mongodb/administration/enable-tls/).
#### Generate the self-signed certificates via pre-install Helm hooks
The `secrets-ca.yaml` file utilizes the Helm "pre-install" hook to ensure that the certificates will only be generated on chart install.
The `genCA()` function will create a new self-signed x509 certificate authority. The `genSignedCert()` function creates an object with the certificate and key, which are base64-encoded and used in a YAML-like object. The `genSignedCert()` function is passed the CN, an empty IP list (the nil part), the validity and the CA created previously.
A Kubernetes Secret is used to hold the signed certificate created above, and the `initContainer` sets up the rest. Using Helm's hook annotations ensures that the certificates will only be generated on chart install. This will prevent overriding the certificates if the chart is upgraded.
#### Use your own CA
To use your own CA, set `tls.caCert` and `tls.caKey` with appropriate base64 encoded data. The `secrets-ca.yaml` file will utilize this data to create the Secret.
> NOTE: Currently, only RSA private keys are supported.
#### Access the cluster
To access the cluster, enable the init container which generates the MongoDB(&reg;) server/client PEM key needed to access the cluster. Please be sure to include the `$my_hostname` section with your actual hostname, and the alternative hostnames section should contain the hostnames that should be allowed access to the MongoDB(&reg;) replicaset. Additionally, if external access is enabled, the load balancer IP addresses are added to the alternative names list.
> NOTE: You will be generating self-signed certificates for the MongoDB(&reg;) deployment. The init container generates a new MongoDB(&reg;) private key which will be used to create a Certificate Authority (CA) and the public certificate for the CA. The Certificate Signing Request will be created as well and signed using the private key of the CA previously created. Finally, the PEM bundle will be created using the private key and public certificate. This process will be repeated for each node in the cluster.
#### Start the cluster
After the certificates have been generated and made available to the containers at the correct mount points, the MongoDB(&reg;) server will be started with TLS enabled. The options for the TLS mode will be one of `disabled`, `allowTLS`, `preferTLS`, or `requireTLS`. This value can be changed via the `MONGODB_EXTRA_FLAGS` field using the `tlsMode` parameter. The client should now be able to connect to the TLS-enabled cluster with the provided certificates.
### Set Pod affinity
@@ -796,8 +1011,6 @@ Please visit the release notes from the upstream project at <https://github.com/
[On November 13, 2020, Helm v2 support formally ended](https://github.com/helm/charts#status-of-the-project). This major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.
[Learn more about this change and related upgrade considerations](https://docs.bitnami.com/kubernetes/infrastructure/mongodb/administration/upgrade-helm3/).
### To 9.0.0
MongoDB(&reg;) container images were updated to `4.4.x` and it can affect compatibility with older versions of MongoDB(&reg;). Refer to the following guides to upgrade your applications:
@@ -896,4 +1109,4 @@ Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
limitations under the License.