mirror of
https://github.com/bitnami/charts.git
synced 2026-03-04 14:57:36 +08:00
[bitnami/tomcat] README changes (#7011)
* T40895 README changes * T40895 README changes * T40895 Updated Chart.yaml * Update Chart.yaml For changes in the README it's not needed to bump the chart version Co-authored-by: Vikram Vaswani <vvaswani@vmware.com> Co-authored-by: Carlos Rodríguez Hernández <carlosrh@vmware.com>
This commit is contained in:
vikram-bitnami
@@ -207,7 +207,7 @@ $ helm install my-release -f values.yaml bitnami/tomcat
|
||||
|
||||
## Configuration and installation details
|
||||
|
||||
### [Rolling VS Immutable tags](https://docs.bitnami.com/containers/how-to/understand-rolling-tags-containers/)
|
||||
### [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.
|
||||
|
||||
@@ -215,27 +215,11 @@ Bitnami will release a new chart updating its containers if a new version of the
|
||||
|
||||
### Change Tomcat version
|
||||
|
||||
To modify the Tomcat version used in this chart you can specify a [valid image tag](https://hub.docker.com/r/bitnami/tomcat/tags/) using the `image.tag` parameter. For example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters.
|
||||
To modify the Tomcat version used in this chart, specify a [valid image tag](https://hub.docker.com/r/bitnami/tomcat/tags/) using the `image.tag` parameter - for example, `image.tag=X.Y.Z`. This approach is also applicable to other images like exporters.
|
||||
|
||||
## Persistence
|
||||
### Add extra environment variables
|
||||
|
||||
The [Bitnami Tomcat](https://github.com/bitnami/bitnami-docker-tomcat) image stores the Tomcat data and configurations at the `/bitnami/tomcat` path of the container.
|
||||
|
||||
Persistent Volume Claims are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
|
||||
See the [Parameters](#parameters) section to configure the PVC or to disable persistence.
|
||||
|
||||
### Adjust permissions of persistent volume mountpoint
|
||||
|
||||
As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it.
|
||||
|
||||
By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions.
|
||||
As an alternative, this chart supports using an initContainer to change the ownership of the volume before mounting it in the final destination.
|
||||
|
||||
You can enable this initContainer by setting `volumePermissions.enabled` to `true`.
|
||||
|
||||
### Adding extra environment variables
|
||||
|
||||
In case you want to add extra environment variables (useful for advanced operations like custom init scripts), you can use the `extraEnvVars` property.
|
||||
To add extra environment variables (useful for advanced operations like custom init scripts), use the `extraEnvVars` property.
|
||||
|
||||
```yaml
|
||||
extraEnvVars:
|
||||
@@ -243,39 +227,36 @@ extraEnvVars:
|
||||
value: DEBUG
|
||||
```
|
||||
|
||||
Alternatively, you can use a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values.
|
||||
Alternatively, define a ConfigMap or a Secret with the environment variables. To do so, use the `extraEnvVarsCM` or the `extraEnvVarsSecret` values.
|
||||
|
||||
### Sidecars and Init Containers
|
||||
### Use Sidecars and Init Containers
|
||||
|
||||
If you have a need for additional containers to run within the same pod as the Tomcat app (e.g. an additional metrics or logging exporter), you can do so via the `sidecars` config parameter. Simply define your container according to the Kubernetes container spec.
|
||||
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.
|
||||
|
||||
```yaml
|
||||
sidecars:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
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/tomcat/configuration/configure-sidecar-init-containers/).
|
||||
|
||||
Similarly, you can add extra init containers using the `initContainers` parameter.
|
||||
### Set Pod affinity
|
||||
|
||||
```yaml
|
||||
initContainers:
|
||||
- name: your-image-name
|
||||
image: your-image
|
||||
imagePullPolicy: Always
|
||||
ports:
|
||||
- name: portname
|
||||
containerPort: 1234
|
||||
```
|
||||
This chart allows you to set custom Pod affinity using the `affinity` parameter. Find more information about Pod's affinity in the [Kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
|
||||
### Setting Pod's affinity
|
||||
As an alternative, use one of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/master/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters.
|
||||
|
||||
This chart allows you to set your custom affinity using the `affinity` parameter. Find more information about Pod's affinity in the [kubernetes documentation](https://kubernetes.io/docs/concepts/configuration/assign-pod-node/#affinity-and-anti-affinity).
|
||||
## Persistence
|
||||
|
||||
As an alternative, you can use of the preset configurations for pod affinity, pod anti-affinity, and node affinity available at the [bitnami/common](https://github.com/bitnami/charts/tree/master/bitnami/common#affinities) chart. To do so, set the `podAffinityPreset`, `podAntiAffinityPreset`, or `nodeAffinityPreset` parameters.
|
||||
The [Bitnami Tomcat](https://github.com/bitnami/bitnami-docker-tomcat) image stores the Tomcat data and configurations at the `/bitnami/tomcat` path of the container.
|
||||
|
||||
Persistent Volume Claims (PVCs) are used to keep the data across deployments. This is known to work in GCE, AWS, and minikube.
|
||||
|
||||
See the [Parameters](#parameters) section to configure the PVC or to disable persistence.
|
||||
|
||||
### Adjust permissions of persistent volume mountpoint
|
||||
|
||||
As the image run as non-root by default, it is necessary to adjust the ownership of the persistent volume so that the container can write data into it.
|
||||
|
||||
By default, the chart is configured to use Kubernetes Security Context to automatically change the ownership of the volume. However, this feature does not work in all Kubernetes distributions.
|
||||
As an alternative, this chart supports using an init container to change the ownership of the volume before mounting it in the final destination.
|
||||
|
||||
You can enable this init container by setting `volumePermissions.enabled` to `true`.
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
@@ -301,24 +282,9 @@ $ helm upgrade tomcat bitnami/tomcat --set tomcatPassword=$TOMCAT_PASSWORD
|
||||
|
||||
### To 7.0.0
|
||||
|
||||
[On November 13, 2020, Helm v2 support was formally finished](https://github.com/helm/charts#status-of-the-project), this major version is the result of the required changes applied to the Helm Chart to be able to incorporate the different features added in Helm v3 and to be consistent with the Helm project itself regarding the Helm v2 EOL.
|
||||
[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.
|
||||
|
||||
### What changes were introduced in this major version?
|
||||
|
||||
- Previous versions of this Helm Chart use `apiVersion: v1` (installable by both Helm 2 and 3), this Helm Chart was updated to `apiVersion: v2` (installable by Helm 3 only). [Here](https://helm.sh/docs/topics/charts/#the-apiversion-field) you can find more information about the `apiVersion` field.
|
||||
- The different fields present in the *Chart.yaml* file has been ordered alphabetically in a homogeneous way for all the Bitnami Helm Charts
|
||||
|
||||
### Considerations when upgrading to this version
|
||||
|
||||
- If you want to upgrade to this version from a previous one installed with Helm v3, you shouldn't face any issues
|
||||
- If you want to upgrade to this version using Helm v2, this scenario is not supported as this version doesn't support Helm v2 anymore
|
||||
- If you installed the previous version with Helm v2 and wants to upgrade to this version with Helm v3, please refer to the [official Helm documentation](https://helm.sh/docs/topics/v2_v3_migration/#migration-use-cases) about migrating from Helm v2 to v3
|
||||
|
||||
### Useful links
|
||||
|
||||
- https://docs.bitnami.com/tutorials/resolve-helm2-helm3-post-migration-issues/
|
||||
- https://helm.sh/docs/topics/v2_v3_migration/
|
||||
- https://helm.sh/blog/migrate-from-helm-v2-to-helm-v3/
|
||||
[Learn more about this change and related upgrade considerations](https://docs.bitnami.com/kubernetes/infrastructure/tomcat/administration/upgrade-helm3/).
|
||||
|
||||
### To 5.0.0
|
||||
|
||||
|
||||
Reference in New Issue
Block a user