chapter: Common Storage Configuration

text:
This works just the same way as the Ingress settings: The Configuration can be performed at various levels:
- Per Component / Chart
`storage.`
- Per Instance
`global.storage.`
- Per Environment
`global.environment.storage.`
This enables you to have configuration yaml files per environment (e.g. for DEV, QA and PROD) setting environment defaults.
You then do not have to touch the Instance configuration.
For storage, there are several volume types:
- **conf**, Shared File, RWX, global per environment
- **data**, Disk, RWO, optional per component
- **file**, Shared File, RWX, optional per ReplicaSet
- **temp**, EmptyDir
- **ptemp**, Shared File, RWX, global per environment
- **log**, EmptyDir, should be empty, so just in case
- **pool**, optional path on the conf share mounted by some components
- **generic**, allows to mount any pre-defined PV into a container


chapter: conf

text:
The *conf* storage is a global PVC with RWX (file) shared by every component in the environment. The component creates a sub directory
on the share and mounts it to the config directory in the container.
`storage.conf.name` sets the name of the PVC to be created and used.
`mounts.conf.path` defines the target directory in the container.
As the environment normally provides the *conf* share, you can set the class and the size in the environment.
If you habe your RWX storage class provided by a CIFS / SMB shared file system, you need to disable linux commands like *chmod*.
This can be done in the storage environment settings:
```
global:
environment:
storage:
conf:
cifs: true
```


chapter: data

text:
Every component can create a data PVC with RWO (disk). You can set the `class` for this disk directly at the mount definition `mounts.data.class`. If unset, it uses the definition for the data class from `global.storage.data.class` or from the environment definition at `global.environment.storage.data.class`.
If the class is not defined, it is not included in the manifest and so the cluster default is taken.
Set the size at `mounts.data.size`.  No default for the size.


chapter: file

text:
Every component can create a file PVC with RWX (shared file). You can set the `class` for this share directly at the mount definition `mounts.file.class`. If unset, it uses the definition for the file class from `global.storage.file.class` or from the environment definition at `global.environment.storage.file.class`.
If the class is not defined, it is not included in the manifest and so the cluster default is taken.
Set the size at `mounts.file.size`.  No default for the size.
This file mount is used for example for the *nscale Rendition Server* to create a common workload directory for all PODs across cluster nodes.


chapter: temp

text:
If a *temp* mount point is given in the values file, it creates an `emptyDir` volume with the `sizeLimit` of `mounts.temp.size`. If no limit is given, the volume will have no limit and the cluster node default is used.
If you want to back this volume by memory, specify `mounts.temp.medium: memory`. Be aware, that this will utilize a RAM disk and count against your PODs resources.
> The *nscale Application Layer* caches fulltext data in temp. Please be aware of your component behaviour when setting medium and size. Your plugins might be requireing speed or size.


chapter: ptemp

text:
*ptemp* is a shared, persistant version of temp. It is used to store temporary data, that needs to live beyond the life of a pod, like exports from the database or account logs from storage layer.
The ptemp is created by the environment and all pods are free to use it, just like conf.


chapter: logs

text:
If a *logs* mount point is given in the values file, it creates an `emptyDir` volume with the `sizeLimit` of `mounts.logs.size`. If no limit is given, the volume will have no limit and the cluster node default is used.
The components are writing logs to `stdout` and `stderr`, so the logs directory should not be necessary. This is just in case any plugin writes something to the contaainers file system.
Additionally, if you use the *nplus Remote Management Server* component, you might want the legacy way of reading log files, and this would be the storage for that.


chapter: pool

text: You can define a path at `mount.pool`, then this component will have access. This is used to hand binary data to the components, such as plugins or *nscale Generic Base Apps* along with the *nscale App Installer*.


chapter: Pre-Created Persistent Volumes

text:
For security reasons, Persistent Volumes can be pre-created and then referenced by the PVC. In order to do so, you can set
- `storage.conf.volumeName` in the environment configuration to set a specific volume reference for the config share, and
- `mounts.data.volumeName` in each components values to set a specific volume reference for the (optional) data volume, as well as
- `mounts.file.volumeName` in each components values to set a specific volume reference for the (optional) file volume
As the volume is specific to a certain volume, it cannot be set globally.


chapter: Setting storage values

text:
| Key  | Component  | Instance  | Environment |
| ---- | ----------- | ----------- | ----------- |
| conf.name | ✔ | ✔ | `conf` |
| data.class | ✔ | ✔ | ✔ |
| data.size | ✔ | - | - |
| data.paths | predefined list | - | - |
| data.volumeName | ✔ | - | - |
| file.class | ✔ | ✔ | ✔ |
| file.size | ✔ | - | - |
| file.paths | predefined list | - | - |
| file.volumeName | ✔ | - | - |
| temp.size | ✔ | - | - |
| temp.medium | ✔ | - | - |
| temp.path | predefined | - | - |
| logs.size | ✔ | - | - |
| logs.medium | ✔ | - | - |
| logs.path | predefined | - | - |
Avoid to change the values marked as *predefined*.


chapter: Working with Certificates

text:
There are two types of certificates than you might want to customize in your deployment:
- (Root-) Certificate Authorities
- Private Certificates and Key Files
**Root CA** extensions will be needed if you want to access other services via https (egress), that have certificates signed by a non-default authority.
In that case, you can upload the authority (public) certificate to trust it.
The process differs from component to component, as some are written in java (and require the certificate to be inside a keystore)
and others are written in C++ or else and might require a PEM certificate store (like the Storage Layer).
First thing is to create the store in whatever format it is needed and then upload it into a secret. Within the helm values, you can then
set the destination path and file name next to the secret where you stored the certificate. There can be multiple certificates.
```
mounts:
caCerts:
paths:
- "/etc/pki/tls/certs/ca-bundle.crt"
- "/usr/lib/jvm/jre/lib/security/cacerts"
secret: ca-secret
```
In this example, the secret *ca-secret* needs to hold two files:
- a cacerts file (under that key), which is a java keystore file and will
be placed as the cacerts file in the Java deployment of the component (In this case the NAPPL).
- a *ca-bundle.crt* file which is a PEM format file that holds all trusted CAs you need.
The *paths* list defines the path and filename of the target as well as the key of the files within the secret.
In Storage Layer, this might look like this:
```
mounts:
caCerts:
paths:
- "/opt/ceyoniq/nscale-server/storage-layer/etc/CA.CER"
secret: ca-secret
```
In this case, the Sorage Layer requires the root ca certs to be a file of exactly this name in the etc directory of the deployment.
Please consult the storage layer manual for more information.
**component Certificates** and Key files are normally used to hold private tls certificates to encrypt https traffic (ingress).
The configuration of these keystores is identical to the ca stores:
```
mounts:
componentCerts:
paths:
- "/opt/ceyoniq/nscale-server/application-layer/conf/certificates.store"
secret:
```
In this case, the secret must have a key named *certificates.store* that holds the java keystore with the required certificates.
> Please note, that alternatively, you can also upload this file to the conf directory of the application layer. If you do not specify a secret, this
mount will not be implemented.
Uploading to this file to the conf would be like this:
```
kubectl cp certificates.store nplus-toolbox-0:/conf/<myInstance>/nappl
```
**Alternatively, you can also define a configMap** for the public CA certificates, then the configuration would be like this:
```
mounts:
caCerts:
paths:
- "/opt/ceyoniq/nscale-server/storage-layer/etc/CA.CER"
configMap: ca-map
```


chapter: Using the generic mount interface

text:
This allows you to mount any pre-provisioned PVs, secret or configMap as a directory or single file into any container.
It can be used e.g. to mount migration nfs, cifs / samba shares into a pipeliner container.
Use the following format:
```
mounts:
generic:
- name: <name>:
path: <the path in the container, where you want to mount this>
volumeName: <the name of the PV to be mounted>
configMap: <the name of the configMap to bemounted>
secret: <the name of the secret to bemounted>
subPath: [a (optional) subpath to be used inside the PV]
accessMode: <ReadWriteMany|ReadWriteOnce|ReadOnlyMany|ReadWriteOncePod>
size: <size request>
```
Please see the *generic* sample in the samples directory for detailes.