public/helm-charts
1
0
Fork 0
mirror of https://github.com/bjw-s-labs/helm-charts.git synced 2025-07-03 16:37:04 +02:00
Code Issues Projects Releases Packages Wiki Activity

feat(common): Release 2.0.0 (#189)

Browse source
This commit is contained in:
Bᴇʀɴᴅ Sᴄʜᴏʀɢᴇʀs 2023-10-02 13:21:17 +02:00 • committed by GitHub
parent 8a42d212af
commit 98677d85b2
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
56 changed files with 1192 additions and 1804 deletions
Download patch file Download diff file Expand all files Collapse all files

49
docs/common-library/howto/helm-templates.md Normal file
View file

@ -0,0 +1,49 @@
---
hide:
- toc
---
# Helm templates
Some fields in the common library `values.yaml` allow the use of Helm templates for their values.
This is often indicated by a remark similar to `Helm template enabled` in the field description.
This feature allows you to set the value of that key to the output of the given Helm template.
## Example
Given the following `values.yaml`
```yaml
containers:
subcleaner:
name: subcleaner
image:
repository: k8s.gcr.io/git-sync/git-sync
tag: {{.Chart.AppVersion}}
args:
- --repo=https://github.com/KBlixt/subcleaner.git
- --branch=master
- --depth=1
- --root=/add-ons/subcleaner
```
This would render as follows:
```yaml
containers:
subcleaner:
name: subcleaner
image:
repository: k8s.gcr.io/git-sync/git-sync
tag: v3.6.2
args:
- --repo=https://github.com/KBlixt/subcleaner.git
- --branch=master
- --depth=1
- --root=/add-ons/subcleaner
```

3
docs/common-library/howto/index.md Normal file
View file

@ -0,0 +1,3 @@
# How to...
Here you can find information on how to accomplish specific scenario's.

42
docs/common-library/howto/multiple-subpath.md Normal file
View file

@ -0,0 +1,42 @@
---
hide:
- toc
---
# Multiple subPaths for 1 volume
It is possible to mount multiple subPaths from the same volume to a
container. This can be achieved by specifying `subPath` with a list
instead of a string.
## Example
```yaml
persistence:
config:
type: configMap
name: my-configMap
advancedMounts:
main: # (1)
main: # (2)
- path: /data/config.yaml
readOnly: false
subPath: config.yaml
- path: /data/secondConfigFile.yaml
readOnly: false
subPath: secondConfigFile.yaml
second-container: # (3)
- path: /appdata/config
readOnly: true
second-controller: # (4)
main: # (5)
- path: /data/config.yaml
readOnly: false
subPath: config.yaml
```
1. the controller with the "main" identifier
2. the container with the "main" identifier
3. the container with the "second-container" identifier
4. the controller with the "second-controller" identifier
5. the container with the "main" identifier

43
docs/common-library/index.md Normal file
View file

@ -0,0 +1,43 @@
---
hide:
- toc
---
# Common Library
!!! note
The Common library chart is not meant to be installed directly, application
charts use the Common library as a dependency.
See the [app template](../app-template/index.md) for an example how to
deploy it.
## Background
In Helm 3, their team introduced the concept of a
[Library chart](https://helm.sh/docs/topics/library_charts/).
> A library chart is a type of Helm chart that defines chart primitives or
> definitions which can be shared by Helm templates in other charts. This
> allows users to share snippets of code that can be re-used across charts,
> avoiding repetition and keeping charts DRY.
The common library was created because I saw many charts requiring only a
few select configuration options in their Helm charts.
!!! note
Take one of the many applications like `sonarr` or `nzbget`. Each of these
charts only require setting `service`, `port`, `persistence`, `ingress`
and `image` since state and app configuration is handled by the application
itself.
In order to stay somewhat DRY (Don't Repeat Yourself) and keeping with Helm 3
usage for a Library chart, I saw this pattern and decided it was worth it to
create a library. This means each one of these app charts has a
dependency on what I call the `common` library.
## Source code
The source code for the common library chart can be found
[here](https://github.com/bjw-s/helm-charts/tree/main/charts/library/common).

88
docs/common-library/storage/globalOptions.md Normal file
View file

@ -0,0 +1,88 @@
# Global Options
The following options are available for all persistence types:
## enabled
Enables or disables the persistence item. Defaults to `true`.
## type
Sets the persistence type
Valid options are:
- [`configMap`](types/configmap.md)
- [`custom`](types/custom.md)
- [`emptyDir`](types/emptyDir.md)
- [`hostPath`](types/hostPath.md)
- [`nfs`](types/nfs-share.md)
- [`persistentVolumeClaim`](types/persistentVolumeClaim.md)
- [`secret`](types/secret.md)
## globalMounts
Configure mounts to all controllers and containers. By default the persistence item
will be mounted to `/<name_of_the_peristence_item>`.
**Example**
```yaml
globalMounts:
- path: /config
readOnly: false
```
### path
Where to mount the volume in the main container. Defaults to `/<name_of_the_volume>`
### readOnly
Specify if the volume should be mounted read-only
### subPath
Specifies a sub-path inside the referenced volume instead of its root.
## advancedMounts
Explicitly configure mounts for specific controllers and containers.
**Example**
```yaml
advancedMounts:
main: # (1)
main: # (2)
- path: /data/config.yaml
readOnly: true
subPath: config.yaml
second-container: # (3)
- path: /appdata/config
readOnly: true
second-controller: # (4)
main: # (5)
- path: /data/config.yaml
readOnly: false
subPath: config.yaml
```
1. the controller with the "main" identifier
2. the container with the "main" identifier
3. the container with the "second-container" identifier
4. the controller with the "second-controller" identifier
5. the container with the "main" identifier
### path
Where to mount the volume in the main container. Defaults to `/<name_of_the_volume>`
### readOnly
Specify if the volume should be mounted read-only
### subPath
Specifies a sub-path inside the referenced volume instead of its root.

6
docs/common-library/storage/permissions.md Normal file
View file

@ -0,0 +1,6 @@
# Permissions
Charts do not modify file or folder permissions on volumes out of the box.
This means that you will have to make sure that your storage can be written to
by the application.

31
docs/common-library/storage/types/configmap.md Normal file
View file

@ -0,0 +1,31 @@
---
hide:
- toc
---
# ConfigMap
In order to mount a configMap to a mount point within the Pod you can use the
`configMap` type persistence item.
| Field | Mandatory | Docs / Description |
| ------------- | --------- | -------------------------------------------------------------------------- |
| `name` | Yes | Which configMap should be mounted. Supports Helm templating. |
| `defaultMode` | No | The default file access permission bit. |
| `items` | No | Specify item-specific configuration. Will be passed 1:1 to the volumeSpec. |
!!! note
Even if not specified, the configMap will be read-only.
## Minimal configuration
```yaml
persistence:
config:
enabled: true
type: configMap
name: mySettings
```
This will mount the contents of the pre-existing `mySettings` configMap to `/config`.

34
docs/common-library/storage/types/custom.md Normal file
View file

@ -0,0 +1,34 @@
---
hide:
- toc
---
# Custom
When you wish to specify a custom volume, you can use the `custom` type.
This can be used for example to mount configMap or Secret objects.
See the [Kubernetes docs](https://kubernetes.io/docs/concepts/storage/volumes/)
for more information.
| Field | Mandatory | Docs / Description |
| ------------ | --------- | -------------------------------- |
| `volumeSpec` | Yes | Define the raw Volume spec here. |
## Minimal configuration
```yaml
persistence:
config:
enabled: true
type: custom
volumeSpec:
downwardAPI:
items:
- path: "labels"
fieldRef:
fieldPath: metadata.labels
- path: "annotations"
fieldRef:
fieldPath: metadata.annotations
```

28
docs/common-library/storage/types/emptyDir.md Normal file
View file

@ -0,0 +1,28 @@
---
hide:
- toc
---
# Empty Dir
Sometimes you need to share some data between containers, or need some
scratch space. That is where an emptyDir can come in.
See the [Kubernetes docs](https://kubernetes.io/docs/concepts/storage/volumes/#emptydir)
for more information.
| Field | Mandatory | Docs / Description |
| ----------- | --------- | ---------------------------------------------------------------------------------------------------------------- |
| `medium` | No | Set this to `Memory` to mount a tmpfs (RAM-backed filesystem) instead of the storage medium that backs the node. |
| `sizeLimit` | No | If the `SizeMemoryBackedVolumes` feature gate is enabled, you can specify a size for memory backed volumes. |
## Minimal configuration
```yaml
persistence:
config:
enabled: true
type: emptyDir
```
This will create an ephemeral emptyDir volume and mount it to `/config`.

32
docs/common-library/storage/types/hostPath.md Normal file
View file

@ -0,0 +1,32 @@
---
hide:
- toc
---
# Host path
In order to mount a path from the node where the Pod is running you can use a
`hostPath` type persistence item.
This can also be used to mount an attached USB device to a Pod. Note that
this will most likely also require setting an elevated `securityContext`.
See the [Kubernetes docs](https://kubernetes.io/docs/concepts/storage/volumes/#hostpath)
for more information.
| Field | Mandatory | Docs / Description |
| -------------- | --------- | ----------------------------------------------------------------------------------------------------------------- |
| `hostPath` | Yes | Which path on the host should be mounted. |
| `hostPathType` | No | Specifying a hostPathType adds a check before trying to mount the path. See Kubernetes documentation for options. |
## Minimal configuration
```yaml
persistence:
config:
enabled: true
type: hostPath
hostPath: /dev
```
This will mount the `/dev` folder from the underlying host to `/dev` in the container.

32
docs/common-library/storage/types/nfs-share.md Normal file
View file

@ -0,0 +1,32 @@
---
hide:
- toc
---
# NFS Share
To mount an NFS share to your Pod you can either pre-create a persistentVolumeClaim
referring to it, or you can specify an inline NFS volume:
!!! note
Mounting an NFS share this way does not allow for specifying mount options.
If you require these, you must create a PVC to mount the share.
| Field | Mandatory | Docs / Description |
| -------- | --------- | ------------------------------------------ |
| `server` | Yes | Host name or IP address of the NFS server. |
| `path` | Yes | The path on the server to mount. |
## Minimal configuration
```yaml
persistence:
config:
enabled: true
type: nfs
server: 10.10.0.8
path: /tank/nas/library
```
This will mount the NFS share `/tank/nas/library` on server `10.10.0.8` to `/config`.

57
docs/common-library/storage/types/persistentVolumeClaim.md Normal file
View file

@ -0,0 +1,57 @@
# Persistent Volume Claim
This is probably the most common storage type, therefore it is also the
default when no `type` is specified.
It can be attached in two ways.
- [Dynamically provisioned](#dynamically-provisioned)
- [Existing claim](#existing-claim)
## Dynamically provisioned
Charts can be configured to create the required persistentVolumeClaim
manifests on the fly.
| Field | Mandatory | Docs / Description |
| -------------- | --------- | ------------------------------------------------------------------------------------ |
| `accessMode` | Yes | [link](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#access-modes) |
| `size` | Yes | [link](https://kubernetes.io/docs/concepts/storage/persistent-volumes/#resources) |
| `nameOverride` | No | Override the name suffix that is used for this volume. |
| `storageClass` | No | Storage class to use for this volume. |
| `retain` | No | Set to true to retain the PVC upon `helm uninstall`. |
### Minimal configuration
```yaml
persistence:
config:
enabled: true
type: persistentVolumeClaim
accessMode: ReadWriteOnce
size: 1Gi
```
This will create a 1Gi RWO PVC named `RELEASE-NAME-config` with the default
storageClass, which will mount to `/config`.
## Existing claim
Charts can be configured to attach to a pre-existing persistentVolumeClaim.
| Field | Mandatory | Docs / Description |
| --------------- | --------- | ------------------------------------------------------ |
| `existingClaim` | Yes | Name of the existing PVC |
| `nameOverride` | No | Override the name suffix that is used for this volume. |
### Minimal configuration
```yaml
persistence:
config:
enabled: true
type: persistentVolumeClaim
existingClaim: myAppData
```
This will mount an existing PVC named `myAppData` to `/config`.

31
docs/common-library/storage/types/secret.md Normal file
View file

@ -0,0 +1,31 @@
---
hide:
- toc
---
# Secret
In order to mount a Secret to a mount point within the Pod you can use the
`secret` type persistence item.
| Field | Mandatory | Docs / Description |
| ------------- | --------- | -------------------------------------------------------------------------- |
| `name` | Yes | Which Secret should be mounted. Supports Helm templating. |
| `defaultMode` | No | The default file access permission bit. |
| `items` | No | Specify item-specific configuration. Will be passed 1:1 to the volumeSpec. |
!!! note
Even if not specified, the Secret will be read-only.
## Minimal configuration
```yaml
persistence:
config:
enabled: true
type: secret
name: mySecret
```
This will mount the contents of the pre-existing `mySecret` Secret to `/config`.